Greatest Barriers to Open-Source Adoption

CIO.com asked 328 information technology business executives and managers if they use open source applications in their organizations. The good news is that 53% answered that they are already using open source tools. The survey also uncovered why the other 47% had not.

Greatest Barriers to Open-Source Software Adoption at Your Company?
Concern Percent
Product support concerns 45%
Awareness/knowledge of available solutions 29%
Security concerns 26%
Lack of support by management 22%
Licensing or legal concerns 21%
Investment in architecture from other vendor(s) 20%
Software quality issues 20%
Customization concerns 15%
Not relevant to our product or service 7%
Pressure on open-source providers by commercial vendors 5%
Software cost allocation policies 2%
Other 9%

For Corporate Software Developers

Support

To all you corporate software developers, the number one reason that some of your organizations do not allow open source products is because your bosses are afraid that there is no support for the tool. You need to show him that a particular tool is backed by a company who offers support. Show him or her the web page that explains the various support options that they provide.

If there is indeed no support for a given tool, then you are the support. Explain how you have the source code, and how well it is documented. Discuss the benefits of an open product and how you can get help from user groups via forums, IRC, and mailing lists. Put your bosses at ease by showing them these mailing lists, and how active they are, or point out how many questions in the forum get answered on a daily basis.

Awareness

The number two reason was awareness. This is easy to fix. Show them the projects. Show the alternatives.  In some cases, you can show how the alternatives are interchangeable. Take for example Hibernate and an open source database. You could describe how a project using Hibernate backed by MySQL, two popular open source projects, can be migrated to Hibernate and Postgres in seconds, with no SQL changes, no new stored procedures and almost no risk.

The point is, your managers are not surfing the internet researching open source projects and their alternatives. You probably are. You have to bring the projects to your managers and present them in a way to showcase the size of their communities, the available support, and the commitment of the project’s developers.

To the Open Source Project Leaders

For you project leaders of open source projects, this survey screams to us too.  If we review what these managers are telling us, and we can alleviate their concerns, then we can get into the corporate domain. Again, if we look at the top two reasons we see that corporate managers are telling us what they want and what they need.

Support

First is support. If you can provide support, then you can nix their number one concern. Support can come in many ways. The support that they were referring to in the survey was probably paid support. This is harder for smaller open source projects to setup but that doesn’t mean you can’t offer many lower levels of support. Mailing lists, IRC channels, forums, and issue lists are also valid types of support. If you don’t offer the paid support but do offer the other types of support, you are really leaving it on the corporate developer to sell those forms to their managers are good support.

Try to stay active in your forums and mailing lists, don’t leave any questions unanswered, acknowledge every issue that is submitted, and hopefully this will show to the managers that while they can not pay for premium support, the project is indeed supported by the development team.

Awareness

And again, the number two reason that some organizations have not adopted your product is because the big wigs don’t even know that you exist. You have to promote your project and you have to stay committed to promoting your project. Most of us get into open source projects to write code, but project promotion is as important as the code and is often an overlooked or under appreciated aspect of the project.

There are many ways to promote your project. Pushing Pixel’s Kirill Grouchnikov point out a few ways in Party of One: Promote. You can promote your project by simply spending some time writing documentation, or write up some tutorials or design decision explanations in a simple blog post. For our project, Architecture Rules, we recently posted Architecture Rules 101 and Architecture Rules 102 which provided simple tutorials of easy configurations. These two tutorials have landed us dozens of new users.  We also use a blog platform to document our project and provide code examples. These are simple things that we have done to promote our project and to increase awareness.

Conclusion

So weather you’re a software developer looking to introduce open source tools to your environment, or a project leader wanting to find more users, look to product support and project promotion.  These two project areas will alleviate up to 80% of a software manager’s concerns and increase both the end user developer and the project leader’s chances of the open source project finding its way into the corporate domain.