What Should Actually Be Paid For in Open Source?
Designing the boundary between a commons and a business, and why I think good monetisation begins when the company takes on a new kind of responsibility.
by David Soh
14 Sep 2026
12 min read
Growth strategy
Business Models
Monetisation
Open Source
When I was scouring the web on monetisation, I found a similar rhetoric across many content creators and it seemed like
By the time I had worked through the difference between adoption and commercial demand, I was left with a more uncomfortable question. If the open product is genuinely useful, if free users are creating value for the ecosystem, and if community participation is part of what makes the project stronger, then monetisation cannot simply mean finding more ways to restrict access.
The Premise
"What new value should the commercial organisation be responsible for creating?"
In this essay, I show how I began thinking about monetisation less as a pricing exercise and more as a boundary-design problem. What belongs to the shared ecosystem? What becomes materially different when an individual tool becomes organisational infrastructure? And where can a paid relationship make both the customer and the wider project stronger?
I wanted to test that instinct against the research rather than simply turn my own experience into a universal rule.
01 – STARTING WITH THE VALUE
02– WHAT'S THE BOUNDARY?
01 Commons
Access & utility
The product solves a real problem and remains usable, inspectable and adaptable. This is where experimentation and initial trust can begin.
02 Ecosystem
Participation & knowledge
Users, contributors and partners add documentation, integrations, feedback, advocacy and know-how that make the system more valuable.
03 Organisation
Scale & coordination
Deployment creates new needs around governance, identity, security, lifecycle, administration, procurement and internal adoption.
04 Commercial
Assurance & accountability
The company takes responsibility for reducing risk, maintaining reliability, supporting operations and standing behind the product in ways the commons cannot be expected to.
In my opinion, the key transition occurs between the third and fourth layers.
An organisation does not always pay because it suddenly wants access to something technically unavailable. It may pay because the consequences of failure have changed. A hobby project can tolerate uncertainty. A production system serving thousands of employees may need someone accountable for security updates, compatibility, support, recovery and long-term operation.
This shift introduces a new set of challenges that require a different approach.
03 – RESPONSIBILITY
This is the idea I keep returning to: rather than seeing monetisation as just locking features, I find it more helpful to think of it as a responsibility boundary.
Increasing organisational dependence → increasing need for accountability
Open access creates possibility.
Commercial responsibility creates confidence.
Confidence can be worth paying for when uncertainty becomes expensive.
04 – DIFFERENT MODELS
Subscription / assurance
Keep the software open.
Monetise confidence around operating it.
Customers pay for tested releases, long-term maintenance, support, security, certification, interoperability and a supplier relationship.
Question I learned to ask
What new problem appears when usage becomes organisational?
The boundary is partly product-based: the open project continues to provide meaningful utility while proprietary capabilities address additional organisational needs.
The issue is not about moral or commercial superiority. Much rather, the boundary itself represents a strategic design decision.
After I understood this, I stopped searching for a single open-source monetisation model. Instead, I began to look for the connections between four things: the commons, the user's problem, the organisation's new problem, and the unique responsibility the company can take on.
This is where my view goes beyond simply describing existing business models.
The first represents a value proposition, while the second may risk undermining existing trust.
06 – A WORKING FRAMEWORK
These questions are designed to surface the trade-offs involved, rather than to deliver a mechanically correct answer.
01
What value must remain open for the ecosystem to keep working?
Identify the utility, interoperability, experimentation or participation that drives adoption and community health.
Treat these as strategic assets, not automatically as unmonetised inventory.
02
What new problem appears when usage becomes organisational?
Look for needs created by scale, coordination, governance, risk, compliance, reliability, deployment and procurement rather than simply asking which existing feature could be gated.
03
What responsibility can the commercial organisation credibly take on?
The strongest paid value may come from commitments the community cannot reasonably be expected to guarantee: support, lifecycle, assurance, administration, accountability or organisation-specific capability
04
Is there an economic owner for that problem?
A monetisable problem needs someone with budget, authority and a consequence they are trying to avoid or an outcome they are trying to achieve.
05
Does the paid model reinforce the commons or quietly consume it?
Look beyond conversion. Find out if whether revenue creates resources, trust or capability that feed back into the wider ecosystem and what could happen to community behaviour if the boundary moves.
In my experience, conventional monetisation discussions tend to overlook the last question .
If community health and commercial value can reinforce each other, as the Linux Foundation's recent commercial open-source research suggests, then protecting the commons is not necessarily philanthropy sitting outside the business model 3 , it can be part of the commercial strategy itself.
07
This distinction has significantly influenced my current perspective.
In conventional businesses, uncaptured value is often seen as leakage. Within open source, however, the presence of uncaptured value can be fundamental to the system’s overall value and resilience.
The strategic focus shifts to understanding which value should be captured and which should remain open in order to sustain the ecosystem.
The aim would be to create a fair and healthy exchange among everyone involved.
The commons provides accessible utility, encourages experimentation, and invites participation, and the broader ecosystem extends the product’s reach, deepens knowledge, and builds legitimacy. As organisations adopt the product, new complexities and risks emerge. The commercial entity is then positioned to address these higher-order challenges.
Now, revenue enables ongoing investment in the product, strengthens customer relationships, and supports the ecosystem that underpins long-term success.
What I would takeaway
The question is not how much of the commons a company can successfully monetise. It is what new responsibility the commercial organisation can take on that makes both the customer and the commons stronger.
As it should already be apparent:
I included research in this piece because the first two essays in this series focused mostly on my own experiences. For this essay, I want to document how my ideas compare with those of researchers and companies that have spent more time studying open-source economics. The framework above is my synthesis; it is not presented as a framework from Harvard, the Linux Foundation, Red Hat, or GitLab.
I chose examples that show clear differences and not to cover every possible case. Eg., licensing, hosting, dual licensing, services, sponsorship, managed cloud, and other models all set different boundaries. My goal is not to rank these models, but to help readers think about the boundaries they create.
01
These reflections come from my own experience working on growth and strategy around Open WebUI. They describe how my thinking changed during that work, rather than the company's current commercial strategy or an official view on how open-source companies should monetise.
Previously in this series
How I used service-design thinking to make an early commercial motion more deliberate, clarifying the problem, mapping the buying journey and building a growth system designed to learn.