Chapter 7. Making Open Source Projects Easy to Adopt

In the preceding chapters, we outlined ways to build the necessary skills for using open source in the enterprise. But what happens when you are finished evaluating and implementing an open source project within an organization? In this chapter and the following two chapters, we will look at some of the emerging issues that are shaping the future of open source. At the same time, we will show how your company can manage the risks, and reap the rewards, of participating in the evolution of open source.

In Chapter 1, we proposed that the challenge to using open source was to overcome the lack of productization found in most open source projects. This chapter will examine what it means to be productized, the benefits that accrue to an open source project for doing a better job, and how IT departments can participate in productization to help build skills.

Productization tends to arrive late to open source products, if it comes at all. In many open source projects, the implied attitude toward productization is dismissive, as if the leaders of the project were declaring, "Look, you've got the source code; if you can't figure out what you need from there, perhaps you should not be using this software." This is a hard-line position: it insists that the only barrier to open source adoption is a skills gap. While few project leaders hold this view consciously, the lack of attention to productization says it all.

Who cares, really? Perhaps the lack of productization should just be seen as a fact of life for open source projects. The open source projects that take that view weaken their appeal for those of beginner and intermediate skill levels in IT departments and other groups. However, this chapter argues that for most open source projects a small investment in productization can yield tremendous benefits in terms of making the software available to a larger community.

Productization is not something that only serves the needs of beginners. When software is easy to use, has features that automate or assist common operations, and works easily with other programs in its intended environment, everybody is happier.

Productization can reduce the learning curve for potential project participants and make it easier for other projects to incorporate a project into their software. Some projects have turned their high-quality productization into a source of revenue by charging for documentation or by selling a fully productized commercial version. In addition, participating in improving productization provides a way for a larger part of the user community to contribute to an open source project. If you can't write code, but you are thrilled with how cool a project is, you can consider writing documentation to become part of the team.

This chapter also has a lot to say to IT departments in organizations considering the use of open source software. By making your needs known to open source development teamsand perhaps making contributions to productizationyou can improve their software while expanding business opportunities for everyone in a project's ecosystem. IT departments using open source products are the biggest market for consulting and other services related to open source projects.