There is risk with every project. Risk can be associated with product quality, cost overruns, and schedule slips, to name a few. You don't have to be using an open source application like Drupal to experience these risks. But if you are going to manage your project in such a way as to mitigate risk, you need to know a few aspects of open source applications that can introduce risk to your project.

Potential Risks

Below are just a few examples of potential risks for which you might want to create risk mitigation plans. When reviewing these risks, consider the probability of the risk actually occurring and what it would take to avoid the risk in the first place. You might find that the effort to avoid might cost more than the risk itself.

Support

Unlike proprietary applications, "Support" in an open source community is not someone sitting at a virtual helpdesk waiting for your chat call or email. Even when you choose to request paid support, you might not get what you need.

What do you do when you can't find a knowledgeable volunteer from the community to help you? Below are some options to consider when mitigating risk.

• Increase your own skill base so that you don't have to rely on others for the small stuff
• Offer to pay for support so that you don't have to wait on a volunteer
• Partner with an experience Drupal services business for development and maintenance support

Application Redesign

If you are a user of MS Office products, you will know what I mean when I say going from 2003 to 2007 was an application redesign. The navigation changed so much it was like having to learn a new way of thinking. Then there are the compatibility issues when trying to open files created in 2007 format in 2003 application.

The same risk applies to open source applications. What happens if the community makes a significant change in the way the system works? There is always a chance that this will happen. The level of investment many of the community leaders have in the application will limit the probability of this happening over night.

In order to mitigate this risk, try becoming involved in the community. Watch discussions on Drupal.org and follow Dries' blog (http://buytaert.net/) where he talks about Drupal and addresses concerns regarding the direction Drupal might go from one version to the next. If you have a concern, post your comments - make your case as many have done. If change is going to occur, either decide to break from the community version of Drupal or makes plans to upgrade at appropriate intervals.

Open Source Application Cancelled

What if Drupal goes away? Drupal launched in 2001 and has been growing steadily ever since. In my humble opinion, the probability that the community would walk away from Drupal after its wide acceptance around the world is very low.
Just like with any application (open source, proprietary, or homegrown) you run the risk that someday the people who made the application go away and you are stuck with an application that has no support and no updates in the future. This is simply a risk that you can't assume won't happen.

How do you avoid this issue? Technically you can't, it's there all the time. You just have to look at the situation and judge whether you feel there enough interest and investment to sustain the community for the time you will have a need for the community.

Security

Security in software applications will always be an issue. Some fear that open source applications are less safe than proprietary applications. In other words, have a greater risk of having security issues. In some cases this is more true than with others. The Drupal community, however, has good security monitoring and updating practices.
In order to mitigate risks associated security issues, you might consider one of the following options.

• Ensure that your installation of Drupal is connected to the community and your site is always monitoring the community for code and security updates.
• Apply the security updates when they become available for Drupal's core and any contributed module.
• Investigate a contributed module before using it. See if anyone has found any issues and if there is a resolution.
• If a security issue surfaces, assess its applicability to your use to determine the level of risk in your case.
• Work with the module project developer to patch the security issue if one exists or if you find one yourself.

Remember, no code is perfect. The number of code hackers out there today trying to cause damage continues to grow. Even if you build your site from scratch, you have the risk of unanticipated security holes. Assess your risk tolerance and proceed appropriately.

Schedules

Another potential risk is associated with scheduling. With open source, you run the risk of missing a delivery date if you did not take into consideration that one or more features are not currently available before you promised to deliver that functionality. Or they are available but have not been fully tested thus creating potential issues in the site.

Schedules are difficult to predict on web development projects. Unless you have your own coding team and resources, you might consider breaking your project into phases. Collect the requirements for the site and then assess how much can be done with existing modules versus custom work and then create your schedule. How many clients want to go through this process? Some will be willing and some won't but it is an option.

Requirements

An incomplete deliverable is always a risk. Of course, incomplete deliverable might be a matter of opinion. What the client has in mind and what they ask for might be two different things. If you are the developer, it is in your best interest to dig past the "I want a blog." statements from the client to learn more about what they are trying to do.

I have often had conversations with clients where they say they want a specific technology but it turns out that they think they need that technology to do what they want to do based on what friend told them or on what they read someplace.
That is what this book is all about.

Vendor/Contractors

If you hire a vendor or contractor to help you get your site built, you run the risk that the vendor cannot deliver as promised and you are out the money you have paid them to get the job done AND you don't have the site you wanted or needed.
The demand for more sophisticated sites is increasing. More and more want-to-be Drupal developers are making promises they can't keep. In order to mitigate your risk, consider the following.

Vendor issues are not unique to open source applications but checking references can help reveal the obvious issues.
Establish a relationship with your vendor such that you are an integrated team thus allowing you be aware of what they are doing and how well they are proceeding.

Make an effort to learn as much about configuring Drupal as you can. There are numerous videos, books, and training courses available to help you learn enough to know if your vendor is trying to pull the wool over your eyes.
Hire a consultant to go between you and the vendor. Let that person be the learned colleague that can advise you on how the vendor is doing.

Don't use a vendor. Hire your own development team and create your own web department. Of course there are many risks associated with this option but it is an option that in the long run, you might end up opting for if your site becomes the next Amazon.com.

Maintenance

If you focus primarily on getting your site to be exactly what you want, you run the risk of creating a site that cannot be updated later without significant time or cost.

Each time you deviate from how Drupal and its contributed modules are designed, you run the risk that your deviations will have to be redone each time you update the core system and/or its contributed modules. As long as you are aware of risks like these you can plan accordingly. Remember, document, document, document.

Conclusion

If you have ever managed a software application development project, the risks mentioned above are not news to you. There are a few open source specific issues that get thrown into the mix but for the most part, you can find these risks (and others) if you are using a proprietary application or your own home grown solution.

The key to success is to keep these in mind so that as you make decisions about your project, you know if you are introducing a risk that you can manage or not.