Challenges of a Product Manager in the Open Source World

Welcome in 2010!

This will be the year of… well, no. Not yet. Let me start with some contemplation.

Others have already discussed the role of product management in the context of Open Source and community with respect to one concrete Open Source project, as Matt Asay did writing about Product management goes open source. And my colleague Alex Evans has discussed the feature submission, evaluation and implementation process for products of Novell’s Workgroup business: What happens to Enhancement Requests?

Beyond that, it has specific challenges to be product manager for an Enterprise Linux Operating System, such as SUSE Linux Enterprise Server. These challenges reside in the unique relationship between customers, partners, community and the usual business aspects (finance, marketing…).

Or should I say “communities,” as my product ships with more than 1500 single packages?

Besides the usual way of customers to communicate with a software vendor, customers in my context can directly influence the software itself, before it becomes part of a product, when they work in the community of the application(s) they are interested in. The same way partners, i.e., hardware vendors (IHVs), independent software vendors (ISVs), service partners… can directly influence small packages or even large parts of the software, before it becomes part of a product.

This participation and active change is one of the real benefits of the Open Source model, and I don’t want to miss it.

Let me repeat: this is the brain, heart, and soul of the Open Source development model! Compared to the closed product management and product development model, it also has a risk and a burden:

• Within the closed model product management, architect and engineering balance the requirements of the various stakeholders. And they completely own architecture and development.
• Within the Open Source model though, product management, architect and engineering still are required to balance those requirements. A major part of their potential decisions, however, has already been made by the communities. The team responsible for the product does not completly own all decisions for the product – neither with respect to architecture nor technical implementation.

This may sound complex, thus let me share a recent example tomorrow.