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 ...