Product Management in Open Source Projects – Need, Pain or Useless?
Some weeks ago Holger Dyroff (COO at ownCloud) and Patrick Maier (Product Manager at ownCloud) gave a talk about the role of product management between open source projects and derived products at openSUSE Conference 2017 at Z-Bau, Nuremberg. As this topic obviously is a very important one around ownCloud we’d also like to share our […]
Some weeks ago Holger Dyroff (COO at ownCloud) and Patrick Maier (Product Manager at ownCloud) gave a talk about the role of product management between open source projects and derived products at openSUSE Conference 2017 at Z-Bau, Nuremberg. As this topic obviously is a very important one around ownCloud we’d also like to share our thoughts in a blog post.
Product Management in Open Source Projects – Need, Pain or Useless?
When preparing for our talk we did research, read some articles, had discussions and quickly realized that even though we might be talking about one and the same software it’s inevitable to differentiate between open source projects and products as those are in fact two separate things with different stakeholders and goals. Therefore we took a look at both to discover their goals and where they might differ.
A look at open source projects
So, what are open source projects? How are they characterized? What are the goals and typical outcomes?
First, they typically consist of volunteers that have some interest in the topic and therefore engage with it. There’s a lot of enthusiasm that you can feel when attending conferences around FOSS.
People are creative, they want to expand their horizons, think around the corner.
It’s also a lot about learning and fun as everybody can join no matter on their qualification or skill level which is great as it brings people together and provides a platform for mutual inspiration and exchange. So it’s about ‘doing things together’ with flat hierarchies and rather quick decision-making.
In comparison with closed-source projects it’s also based on the belief that the involvement of many people drives the project in the right direction – this is can be described with the term ‘law of large numbers’ that actually originates from statistics and describes the result of performing an experiment a large number of times. If you do this the average of the results will be close to the expectation. Paired with the diversity in opinions and characteristics of participants the assumption is that this leads to great software that fulfills the expectations of at least the largest part of users sooner or later.
Putting this together the project drives innovation by uniting various kinds of views and opinions and as a result produces a common good from people for people – Awesome so far!
Let’s get a bit of hard reality into this: A motivated start of such projects is many times followed by difficult decisions where people might get disappointed. And as time is scarce and people need to pay their bills many promising projects experience stagnation at some point. At this point the ‘product’ comes into play as a possible solution to turn the corner and bring movement back to the project.
A look at products
So, products always depend on their ability to attract customers and to prevail in competition.
Customers put up certain requirements to the software. They need good and intuitive usability even for less experienced users. Stability is at the heart of a customers’ expectation of a good product. Therefore it is inevitable to maintain excellent QA. Furthermore customers demand professional support and maintenance should be as easy as possible.
Knowing this it should be easy to see that the ones who derive the product from an open source project experience pressure from customers and the markets. This pressure naturally brings movement into the product as bills may only be paid when customers are happy. To make customers happy the product needs to fulfill requirements in a certain quality within a certain time frame.
The relation between Project and Product
In the best case the project is a basis for the product and both profit from each other in a balanced way. For this you take the project at some point in time and professionalize it to meet the requirements of a product as discussed before.
You attract customers with marketing efforts, sell the product and build up a standing in the market. If this works out nicely the product generates revenue which can then be used to reinvest into the product and project, respectively.
This drives momentum back to the project as contributions are made and issues that in the project would not have been touched get solved as a need for the product. This might open up new ways in the project.
Also as stability is a key criteria for products these efforts go back to the project which benefits as contributors might not have the highest priority on stability but users of course like it when a service works seamlessly out-of-the-box.
The project again enjoys freedom in two ways:
– People can use the software for free and do whatever they want with it
– People should also be free in their way of thinking of the future of the software, which again drives innovation and incubation that comes back to the product where it’s really needed because there’s competition and other products improve as well.
This again attracts more customers and stabilizes or in the best case even increases revenue and the circle starts from the beginning. So, from iteration to iteration the product and also the project improve steadily which creates value for all parties involved.
What we explained above obviously is a model that works in a perfect world. In reality there are obstacles that both the project and the product need to consider. When we thought and discussed about it many questions came up to our minds. We were not able to answer all of them conclusively but we discussed some in our talk that you can watch here in full length.
This is what we’ve learned from our experience and research about the need of product management in open source projects:
– Open Source projects need freedom – not management
To be able to prosper and develop great ideas that lead to innovation open source projects need enough space and freedom. It’s very inhibiting if you put constraints on projects as people might not be able to evolve and have fun with their contributions.
– Product Management is a need for Products
On the other hand product management – as the name says – is a real need for products as you have many different stakeholders and interests that need to be balanced in order to come to something like a win-win situation for all involved parties.
– Projects need Community Management and Community Marketing
For projects it should be best to establish proper community management and marketing to socialize the roadmap and connect the various parties, attract others and get movement into the thing. Remember it’s not only code that is a contribution. Word of mouth has value as well and you need a lot more than only code to get an open source project rolling.