# Product management for open source products

- Link: https://www.andreidraganescu.info/2023/01/04/product-management-for-open-source-products/
- Published: 2023-01-04T12:10:14+03:00
- Author: Andrei Draganescu

> 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](https://www.productbeautiful.com/2008/05/02/why-product-management-is-open-sources-fatal-flaw/),
[#4986](https://developer.pidgin.im/ticket/4986), [#4962](https://developer.pidgin.im/ticket/4962)

[3] [The rise of Alfresco: ECM that people will really use](https://www.networkworld.com/article/2298534/the-rise-of-alfresco--ecm-that-people-will-really-use.html),
[The plain truth about Alfresco’s open source ethos](https://ecmarchitect.com/archives/2015/05/24/4017),