Home

Blog

What I had to unlearn about growth for Open Source companies

Notes on growth, design for open source start-ups

What I had to unlearn about growth for Open Source companies

Why the growth playbook I brought from SMEs, F&B and conventional start-ups stopped mapping neatly onto community, adoption and monetisation in open source.

by David Soh

12 Sep 2026

10 min read

Growth strategy

Business Models

Open Source

This is the second essay in a short series on growth and strategy. The first, Before you scale growth, Design what you need to learn, is about designing the learning system around an early commercial motion. This one is about the assumptions underneath that work.

I was not new to growth when I entered open source.
I had worked on growth for SMEs, particularly in F&B, and around more conventional start-ups. I knew how to think about positioning, acquisition, retention, customer value and conversion.

What I underestimated was how much those methods depended on a particular relationship between the business and the customer.

In most of my previous work, the economic logic was relatively legible. A business created an offer. A customer discovered it. If the value was convincing enough, they paid. Growth meant improving the path between those moments and making the value stronger over time.

It fundamentally being open-source disrupted that sequence:
Someone could discover the product, install it, use it every day, recommend it to others, create documentation, answer community questions, build integrations, contribute code and introduce it inside an organisation, without ever becoming a paying customer.

The Premise

The problem was not that my old frameworks were useless. It was that the system they assumed was no longer the system I was operating in.

01 – STARTING (ALMOST) COMPLETELY NEW

I had brought a growth playbook into a different economic system which proved my instincts wrong at every turn

In F&B and other SMEs, “community” had usually meant some combination of loyalty, word of mouth, repeat patronage and belonging. These were enormously valuable, but the commercial relationship remained straightforward: the customer ultimately bought the product or service.

In conventional start-ups, even when acquisition was product-led or the product had a free tier, I could still think in terms of a relatively familiar sequence: attract the right users, create value, convert some percentage, retain the ones who pay, expand where possible.

It was this logic which had shaped the questions I instinctively asked.

Translating capability into consequence

Product language → Organisational meaning/value

Familiar growth logic

A relatively legible customer journey

Acquisition

Bring the right people into the funnel.

Value

Solve a problem strongly enough to retain them.

Conversion

Move enough users into a commercial relationship.

Community

Strengthen loyalty, advocacy and repeat behaviour.

What open source introduced

Value could circulate without purchase

Adoption

Could grow substantially without revenue.

Value

Could be created by users as well as the company.

Payment

Could come from a different actor than the user.

Community

Could become part of product, support and distribution.

This distinction became important because it changed what “growth” was actually measuring. More usage could mean more potential customers. But it could also mean more contributors, more advocates, more internal champions, more integrations, more knowledge and more legitimacy.

Those were all forms of value. They were simply not the same kind of value.

02– UNIT OF GROWTH

The person using the product was no longer necessarily the customer, so what then?

One of the first things I had to unlearn was the instinct to treat every user as a potential customer moving through a commercial journey. In short, I had learn what the unit of growth would be.

In open source, one person can occupy several roles at once. A developer may use the product personally, advocate for it internally, answer questions in the community and eventually become the person who brings an enterprise opportunity to the company. Another user may create just as much ecosystem value and never enter a buying process at all.

One ecosystem, different roles

Uses

Self-hosting

Gets direct utility from the open product.

Improves

Self-hosting

Adds code, documentation, feedback, integrations or knowledge.

Distributes

Advocate

Who appears to experience the problem most intensely?

Translates

Internal champion

Makes the case for wider organisational adoption.

Evaluates

Technical stakeholder

Tests whether the product fits infrastructure, security or governance needs.

Funds

Economic buyer

Authorises a commercial relationship around organisational value.

The more useful question therefore became less “How do we convert the user?” and more “What role is this person playing in the ecosystem, what value are they creating or receiving, and what would need to change for a commercial problem to emerge?”

Which, i had to figure out by myself that it was a fundamentally different unit of analysis.

03 – COMMUNITY

I had to stop treating community as an audience around the business.

This was probably the largest conceptual shift.

In previous work, community was something a business cultivated around an offer. It could create trust, loyalty, identity and word of mouth. But the business was still largely responsible for producing the thing being sold.

Open source blurred that boundary. Community members could improve the product, identify problems, create extensions, teach other users, answer support questions, produce examples and make the technology more credible simply by choosing to build with it.

I had previously thought of community as an audience around a business.

But in open source, I learned to see community as part of the core business system itself.

That changed how I thought about monetisation decisions too. A pricing change was not only a pricing decision. A licensing decision was not only a legal decision. Moving functionality behind a commercial boundary could affect trust, participation, advocacy and the willingness of people to contribute.

The company was not simply extracting value from a market. It was participating in a value system that extended beyond itself.

04 – MONETISATION

A free user was not an unfinished paying customer.

This sounds obvious now. It did not feel obvious when I was trying to translate a large base of free adoption into a commercial strategy.

The conventional question is seductive: if many people use the product for free, how do we convert more of them?

But that assumes the problem is insufficient conversion.

In open source, some users may already be receiving exactly the value they should receive for free. Their continued use can improve distribution, produce feedback, create integrations, build community knowledge and establish the project as something other people are willing to trust.

How the monetisation question changed

Conversion → additional value

Question I brought from experience

How do we turn more free users into paying customers?

A reasonable question in many businesses, but one that treats free usage primarily as unrealised revenue.

→

Question I learned to ask

What new problem appears when usage becomes organisational?

Look for needs created by scale, governance, risk, accountability, support and institutional adoption.

As one can see, the second question changed the shape of how I began to view the commercial opportunity.

An individual may be perfectly served by the open product. An organisation operating at scale can encounter a different set of problems: governance, access control, security, reliability, administration, compliance, procurement, support and accountability.

Those are not simply just "more features", they are problems created by a different context of use.

Thus, I started seeing monetisation less as extracting payment from existing utility and more as creating additional value at the point where adoption becomes organisational.

05 – SIGNALS

Adoption and revenue could move in the same direction without moving at the same speed.

This was the second uncomfortable lesson, as in my previous experience, higher adoption typically indicated commercial success. Increased customer engagement or product adoption often led directly to revenue.

Open source made the relationship much looser.

A project could achieve broad use, technical respect, and high visibility even if its commercial development lagged. Community growth might demonstrate relevance without confirming that users had the budget, authority, or organisational need to buy.

Two kinds of evidence

Evidence of

Product relevance

Usage, deployments, contributions, integrations, community activity, recommendations and continued engagement can show that the product is genuinely useful.

Evidence of

Commercial demand

Budget, buying triggers, internal champions, procurement activity, security requirements, willingness to pay and repeatable enterprise problems show that a market is forming.

Adoption remained a priority, but I found that interpreting the data became even more critical to understanding the impact of the work that needed to be done.

I realised that relying on a single metric to address multiple objectives limited our ability to draw meaningful conclusions, so I began to separate our measurement approaches.

06 – COMMERCIAL BOUNDARY

Monetisation had to add value without weakening the system that created adoption.

Once I stopped viewing community and free usage as lost revenue, I began to consider where to draw the line between free and commercial use.

I still believe there is no universal formula, as each project, license, community, and market presents unique challenges.

However, I found the following perspective and framing helpful:

The open commons

Protect the value that drives utility, trust and participation.

The open layer can create adoption, experimentation, community knowledge, advocacy and an ecosystem around the product.

The commercial layer

Charge where organisational scale creates materially different needs.

The paid relationship should solve problems that become meaningful around governance, accountability, deployment, support, risk or scale.

Essentially, preserve the engine, monetise the new problem

The key lesson was not to avoid monetising free products, but to recognise that monetisation decisions have secondary effects. A commercial model can either support the ecosystem or unintentionally undermine the factors that made the project valuable.

To which, I believe this perspective helps to frame growth as an act of stewardship rather than optimisation. The list below documents my key lessons as a list for easy digestability.

Understand the value system before optimising the funnel.

The path to revenue depends on how value moves between users, contributors, champions and buyers.

Do not confuse a user with a lead.

A non-paying user can still be creating enormous value for an open-source ecosystem without ever needing to become a customer.

Treat community as infrastructure, not merely an audience.

Community can contribute to the product, knowledge, distribution, support and trust that make growth possible.

Monetise a new problem, not simply existing access.

Organisational adoption often creates needs that individual usage never had. That can be a more durable source of commercial value.

Separate relevance from commercial demand.

Usage can prove that something matters. Buying behaviour proves that a particular problem has an economic owner.

Let the business model change the method.

A framework is only useful if the mechanics that made it useful exist in the system you are working with.

I became less interested in universal growth frameworks and more interested in the system underneath them.

Segmentation, positioning, acquisition, customer journeys, funnels, and conversion remain core tools in my practice, all of which I continue to apply where they add value.

What has evolved is my approach to these concepts. I recognise that their meaning and impact can vary significantly depending on the business context.

True to my roots as a service designer, I now want to better understand the mechanics that make any growth and revenue framework useful: who creates value, who receives it, who distributes it, who pays, what is being protected, and what changes when the product moves from individual use to organisational adoption. The harder part will be getting the experience needed in order to sharpen my instincts as a whole.

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

Before you scale growth, Design what you need to learn

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.