Section 7.6. Benefits of Increased Adoption

7.6. Benefits of Increased Adoption

Productization is boring, for the most part. That's why it is so broadly ignored. The fact that many open source projects thrive for so long with such meager productization suggests that it is not vital to growth, at least in the early stages. Frankly, for some sorts of projects, productization really doesn't matter much.

For example, if you are creating a special extension to the Linux kernel that can be used only by those who compile their own Linux executable from the source code, productization is not that meaningful. The whole target audience is so sophisticated that a good README file will get everyone where they need to go.

However, open source is outgrowing its "by developers, for developers" ethos, where productization is a sideshow. At various points in this book, we noted how open source is bursting out of the basement of the infrastructure stack, where only developers and sophisticates pay attention, and increasingly is being used to create applications that the general population employs. Applications need productization to thrive.

When the purpose of an open source product is not just one developer scratching an itch, but rather, is to serve as a corporate marketing or collaboration device, or as the platform for a business, ease of use and productization matter mightily.

Achieving productization is primarily a function of leadership. Frankly, completing the productization is not a popular activity in commercial products. The cream of the development team rarely spends its time creating documentation, configuration and administration tools, installation scripts, and all the other aspects of productization we covered in this chapter. But better productization creates better software for all users. Somehow, someone has to be motivated to do the work. Junior people can be paired with senior people. The prestige of joining the development team can be held out as a carrot. Leaders of open source projects frequently break down and do the boring work themselves after realizing the project will not grow without it, or because they get sick of the bulletin boards being flooded with simple questions. Some projects turn productization into a line of business and charge for the best stuff.

The reason to execute on productization is to bring more people into the community of a project. For commercially oriented open source, where marketing or sales of services or hardware is the goal, increasing the community is clearly beneficial.

What about your normal itch-scratchers doing an application? What is in it for them to have a larger user community who benefits from productization? The answer depends on the project leaders' motivation. If the only goal is to create software for your own use, with help from other like-minded experts, expanding the community might be an annoyance rather than a benefit. If, however, the project leaders are interested in creating a product for the ages, a great work of software art, more people at all levels are required to hasten the pace at which features are vetted by usage and new requirements are suggested. Opening the door to more users means opening the door to more use, and that means better software.