This post was due about 4 years ago. In the meantime things changed. Some didn’t 🙂

I would like to propose that open source projects should create an in-house product management organisation/working group/team to work as part of the wider open source project community. This is not easy because, in the world of open-source software, product management has either a bad name or it is nonexistent.

The word “management” doesn’t help much. In part, it is understandable why. Open source is a process based on voluntary participation, so no one wants any pesky^[1] managers of anything. Open source projects have to be this place where we’re free from the microscope of the ever-watchful performance review. Many need this freedom so that innovation can prevail, or at least that is the general impression.

One special thing in open source is we don’t know for sure if we have a product. An open-source project, the upstream source, is an abstract, some kind of ideal form with generic function. In the default state of the Open-Source Project, function signals intent and possibility. This is rather than concrete tooling or paths. It is the implementation, the downstream project, where the code becomes a product. The downstream project is where results are concrete and the users use the product. Hence, only the implementation is laser-focused on optimizing for the fastest and best path. This is in theory, but have you ever seen such an open-source project? I haven’t.

Instead, I have seen countless instances of people taking a release and installing it. They follow the steps in the brief docs available, then they struggle to work with that project, assuming it is the product. This struggle is what Ubuntu solved for home users of Linux. This struggle is what Suse solved for business users of Linux. The same struggle is what WordPress solved for not tech-savvy web publishers. Also, this is what Elastic solved for Lucene. We can spot many examples on the same line. They all solved the fact that we never have this ideal situation of upstream projects and downstream products. In general, the project is the product.

The great exception to this is software tooling. Frameworks, libraries, systems. But then, software engineers are not real users, are they? Tinkerers are not users, and no product exists for a tinkerer, because they’ll do it apart anyway.

Product management is a natural result of user power going through development resistance. 

This results in product management happening, whether we like it or not, even if nobody is actually doing it on purpose. 

The lack of organizations dealing with product management in projects, results in a sort of “spontaneous” product management which is captured by various actors. For instance, a long time ago, the developers of Pidgin^[2], the instant messaging client, got behind the wheel. They demanded that their users adapt to typing messages in a self-resizing box. They closed the massive backlash of negative feedback with “will not fix”. Another time, Alfresco^[3], the leading open source ECM, had been managed as a product by its implementers from the start. They effectively created and educated the market for this kind of open source product. That ended up eventually transforming that software into what the users need.

In my personal experience I noticed that when no product management exists or it is not captured, like in younger projects, a product-market fit fails to be created. The project lacks adoption, despite being innovative, problem-solving and created by brilliant people. There are reasons why 90% of Github projects are practically invisible, and this is one of them.

Sometimes product management is captured, but not by members of the community. Instead, it is captured by the largest company backers of the projects. This is a trend seen in WordPress or various Linux distributions. These companies are pouring in human resources, logistics, and financial support into the projects they back. In return, the project gets agenda reconciliation between large players. Agenda reconciliation, despite the best possible intentions and instead of proper product management. To be clear, the backers do indeed contribute but end up appearing more like buying a stake in the project, which resembles pay to win instead of pay to play.

In these cases, the product is guided based on the legitimate users of large company backers, a situation which leaves smaller contributors and hobbyists out of the product vision and reality. It is not to say that this cohort of smaller contributors and hobbyists cannot continue to take part. Still, it is a cohort that, no matter how enthusiastic, will find it very hard to build a unified voice. They will find it even harder to create momentum for their initiatives or expectations.

The same is the case for certain open source projects which fall into the “tools” exception, for example, Node or React. Large company backers manage these projects as products. Yet, their tinkerer users are reaping the benefits of large companies solving their future problems. So, the problem turns out to be an advantage in this situation.

The missing product organization

In general, a well maintained open source project has:

• marketing, branding, and communication of releases, mission, community values and more;
• interface design and user experience design;
• it has support in forums and instant messaging, where users can sometimes get answers straight from actual developers;
• of course, there is tech and development;

But, there is no product organization. One might argue that “product” is everything above, which is true. But having those activities does not substitute product management, which is a distinct activity on its own.

In my opinion, when projects have no distinct “product” organization, the larger community suffers. Either there is no community at all, for example, Chrome has a handful of developers that do it all, or the community feels alienated and underrepresented.

Ok, it is clear by now that I support a product management organization in open source projects. But what good does this organization do?

The goal of the organization is to leave no feature behind, to avoid rotting parts of the platform and to make sure each part of the community gets the features that they need to be empowered by the platform.

Product management would not step over community management. That means people will still be angry and upset. But at least we can have a traceable process of the gone past, and of the incoming future.

In order to create a good product organization in an open-source project, we need to make a clear distinction between features and innovation. In open-source projects, only features need product management, not innovation.

Product innovation is all the work which satisfies one of these two outcomes:

a) it increases the size of the core user base

b) it increases the amount of added value for the product

It is high-level goals which open up the project to innovation. That is the place where the community, the project leaders, the project backers, and the end-users meet and decide. Product innovation is the result of the overall innovation ability of the entire community.

Features are a different animal. Features are everything that empowers the user to use the product. Also, it is here where innovation actually has its impact. Features need to be managed in open source projects, like they are in all projects, to counter the idealism of innovation.  Features need to be managed to keep them from being sidetracked, to allow maintenance to stay focused and not be discarded.

To prevent hindering open source innovation, product managers need not be decision-makers. One of the most important tools of a good product manager is being able to decide. But, in the case of open source projects, a product person is simply guiding, shepherding folks in the weird place between goals and tasks. In a sense, these are still decisions, but in a space that is shifting constantly. They’re the “tool” kind of decisions, the kinds which help the project advance and can be forgotten about, later down the road.

A product manager in an open-source environment – but not only – should be an exercise in being disposable. They should not be or become linchpins or key decision-makers and hinder product innovation.

Where a product manager shines is being a transitory source of truth. That means that for a while anyone involved is able, provided the job is well done, to get swift and clear direction and sense.

A product manager in an open-source project will mainly:

• connect the dots to help in decision making for everything concerning new features
• bridge the gaps between users and developers, individual users and business users, designers and developers, designers and users, interest-based groups of developers and interest-based groups of contributors, contributors and users and so many other combinations.

While all that could be handled on the go by the community in ad-hoc ways, product focused people keep their product evolving, fit and engaging as a core mission, unlike ad-hoc needs solved with quick interventions. 

There should be a product management organization in any open source project.

This organization should be the result of a team which does specifically that: product management. This enables us to have people who can take care of creating the “zen” between all the stakeholders of all the products based on the project.

Product managers in an open-source project are an “aether-like” presence. They should strive to be a better transmission medium for ideas, information, culture, and goals, along with the others, in other teams, who will or already do these things. Their role is to reconcile visions. They make sure feedback is given. They communicate and disseminate information about decisions or proposals. They practice persistence for creating momentum in various parts of the community. They attend to making practical calls where resources are scarce but valuable.

For instance, where would product management work great for WordPress? Well, here are a few suggestions:

• Gutenberg’s implementation outside of the editor.
• The evolution of Themes.
• Core’s integration with better and more modern tooling.
• Help process such as retrospectives and requests for comments.
• Keeping people on the same page on multi-month multi-team projects.
• Reviving dying components by making the case for new features in those components.
• Running meetings, doing agendas, keeping agendas.

But all this is to be discovered in time, by the entire community. For every product of WordPress, there should be at least one person volunteering their time in the product organization: WordPress the application framework, WordPress the CMS, WordPress the web builder, WordPress the blog engine, WordPress the page builder, because all these facets are what makes WordPress be able to run 35% of the Web.

Everybody works so hard to keep open source projects in a good shape and so often we find ourselves baffled by direction changes. Let’s mitigate this by using proven techniques and processes so that our time spent here is more focused and after all, yes, more enjoyable.

---

[1] In some areas, “management” has been accepted as a form of “organizer”, a big word for basic chores. Yet, management is not about organizing, instead management is about empowerment. Particularly, product management is a hotchpotch of hard-learned lessons in various areas. Business, engineering, research, human resources and, you guessed it, management, all intertwined in a nice theory meant to help people empower products.

[2] Why Product Management is Open Source’s Fatal Flaw, #4986, #4962

[3] The rise of Alfresco: ECM that people will really use, The plain truth about Alfresco’s open source ethos,