#10. You want to move to open source because others are doing it.
Open source is catching up and you don’t want to be left behind. Your partners are using it, your competitors are using it and your customers are using it. You have read a number of success stories on the web and in print media. You don’t want to be part of “late majority” on this one. You want to start a project quickly and join the bandwagon and show immediate success. Most often, this won’t work, as implementing a successful open source project involves more than downloading and installing the software. There is little help on the software and very little information on the best practices to be employed.
What you can do: While there are numerous advantages of using the open source software, it has its own limitations. Understand the intricacies involved and set the right expectations internally. Once you have the first project up and running, successfully, you will get more support for future implementations.

#9. You don’t like the user interface.
Open Source software is often criticized, many a time, rightly so, for lacking in ease-of-use and sophistication. First, there are very few applications that are released as open source. A few are being released but they are not time-tested. So, a majority of stuff available as open source are tools.
Somehow open source developers tend to focus more on features than on form. If you are looking for cool interfaces and snappy designs out of the box, you are in for a surprise (negative one!).
What you can do: The landscape is changing – Eclipse (the Java IDE), Firefox (the browser from Mozilla) and NetBeans (another Java IDE) all front-end open source applications. Plone is another great example of a successful open source project – amongst other things; it is an user interface on top of a feature platform (Zope) and a Content Management Framework. However, as a organization adopting a open source application for the very first time, be prepare to invest in building cool interfaces yourself. There may not be any help out of the box.

#8. You want documentation.
You and/or your team is used to working off documentation or technology books available in the bookstores. Unfortunately, not all open source tools come up with the necessary documentation. Some popular open source tools do not have books out yet. There is another problem with open source software. The release cycles are shorter than typical commercial counterparts. So, the shelf lives of books are shorter. This provides little incentive for publishers and authors to come up with more titles.
What you can do: Yes, the reality is many a time it a 80-line README file as opposed to a 80-page installation document. Working on open source tools requires a different mind-set. You need to be prepared to work off mailing lists/newsgroups, websites, newsletters and bits and pieces of documentation that are available.
Bear in mind, that with the advent of software giants (IBM, HP, CA are all leading proponents of several open source projects) into the open source realm this is expected to be an area of “explosive” improvement in the coming years/ projects.

#7. You haven’t found the right application to move to open source.
While starting an open source with the wrong application at hand is a disaster, not finding the right application can be a nightmare. There are very few open source failures that get reported on the press. The first open source project is strategic as decisions related to the next ones depend mainly on the level of success of the first project.
What you can do: Start small. If this is the first project, pick one that is not mission-critical. Better yet, pick an internal facing application that has limited audience. It is better to make a huge success out of a small project to prove that this works!

#6. You chose open source only to save licensing costs.
Granted, that the license costs are zero for open source tools. This means nothing if the implementation costs skyrocket. The key is to look at the Total Cost of Ownership (TCO). This is a hard number to calculate and depending on whom you ask and what tools you pick, the TCO of open source based applications can be higher or lower than the commercial counterparts.
What you can do: License cost savings are only one part of the whole equation. That is not the only benefit offered by open source. Check your motivations and take a hard look at the TCO. What you find may surprise you and may either provide a strong business case to proceed or provide insights that will take you back to the drawing board.

#5. You don’t want to invest in building capacity.
While open source is hot, it is still not easy to find the right talent at the right price for all your initiatives. Many companies are reluctant to build capacity for open source development in-house. This is a tricky situation, as companies that are still in “dating” mode with open source will have a hard time to “commit” before finalizing on the tools and technologies. They will be looking at the success of an initial pilot to determine whether to commit or not. However, the success of an open source initiative might depend on a company committing to building internal capacity.
What you can do: What we have found is that companies that are most successful in implementing open source applications invest in building internal capacity to maintain the current applications and also take care of minor enhancements.

#4. You want applications that can be used out of the box.
With the popularity of salesforce.com and other such ASPs, it is not uncommon for you to expect open source applications that can be used from day one. The fact of the matter is, even commercial software packages need “configuration” and/ or customization.
What you can do: There are several initiatives that are underway to build open source based applications that can be customized to suit your needs. SugarCRM for CRM and ERP5 for implementing ERP solutions for mid-size customers come to mind. However, Open source has still a long way to go in this regard.

#3. You are scared of experimenting.
You expect guarantees similar to the ones offered by commercial vendors. You don’t want to take chances or you don’t have time to take chances on your current project.
What you can do: Chances are that open source may not be right for you at this point in time. There are risks involved (In fact there are risks involved even while implementing commercial software) and there is no single controlling force that defines and manages the product road-map, in the open source world. The key is to weigh the risks and rewards and come up with a solution. The appetite for handling risk varies from company to company and hence it is difficult to make a generic solution to address this issue.

#2. The right open source tools were not chosen.
You have bought into the open source philosophy and decided to go ahead with an initiative. You have picked the right project and the right people to implement the solution. However, there is a choice overload out there in the open source tools world. The same objective can be achieved reasonably well by multiple other open source tools. Your initiative might fail (it may be a while when this realization happens) if the right open source tools are not chosen.
What you can do: While the short-term objectives for your project might be easily met with many open source tools, the choice of tools should be based on the roadmap for your intended application. This requires in-depth analysis and planning and involves the same effort that you put in when you chose a commercial application.

#1. IT folks think that Open Source is not good for their resume.
This is the hardest problem to crack as it is outside the technology realm. This problem is rarely discussed in management meetings. There are many symptoms though:

Open source initiative may be stalled or sabotaged

Open source initiative may be starved of necessary support resources due to other “high priority” commitments

The choice of a particular open source tool may be opposed citing support, stability or other concerns

What you can do: The lesson to be learnt here is that it is not enough for the management team to buy into the open source but you should also enroll the extended staff in the buy-in process. The category (open source) sale has to happen internally. In fact, the ideal situation would be to have a few evangelists from within the IT organization to push open source.

Rajesh Setty is the president and CEO of CIGNEX that helps companies with their open source initiatives in U.S. and Europe. For more insights on how else you can tackle the latest open source initiative, email him: rajesh@cignex.com.