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 teams—and perhaps making contributions to productization—you 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.
If you ask a CTO who has lived through creating a commercial software product when productization occurred, usually the answer is “At the last minute, only when we had to because we started to sell more software.” At that point, productization becomes a huge priority, because the number of newly arrived customers at the beginner and intermediate levels starts to grow. They need to be educated and must be able to perform simple tasks for themselves. If productization is lacking, the company pays in terms of support costs or frustrated customers.
For open source projects, this “last minute” comes when the number of users participating in the project overwhelms the core development team, which frequently becomes annoyed that so many beginner-level questions are flooding mailing lists. The first response is usually to create a parallel support structure of user-only mailing lists and other community features, out of which the developers hope that users can create materials to help themselves.
Alert open source developers should try to stay ahead of their users and provide some support before becoming frantic. Here are some guidelines for providing this help for users at different skill levels:
Provide basic information and community support for beginners and intermediates.
Reduce the skills gap for getting started through installation scripts and administrative interfaces.
Accelerate learning by providing architectural documentation and sample code for advanced- and expert-level users.
Add features and functions to support integration with related systems.
These guidelines will help in terms of planning productization so that an open source project has a chance to perform productization before it becomes a problem for the user community and thwarts wider adoption.