Positioning for open source companies
Position an open source company by separating the free project from what a customer pays for. Peter Levine and Jennifer Li describe three stages that have to stay true together: developers who contribute, users who adopt the project, and a paid offer those users want. The page has to tell a visitor which of the three they are looking at.
On this page
The project and the paid product are different offers
Levine and Li, writing for Andreessen Horowitz in 2019, describe three pillars that begin as stages. Project-community fit is developers who contribute. Product-market fit is people who adopt the project. Value-market fit is a paid offer those users want. They call the open source project a developer-driven way in, and the business the work of connecting that arrival to a commercial product. The free project is also a competitive alternative to your paid product. Dunford’s first step still applies: say what someone would do if the paid offer did not exist. Often the answer is your own project.
The line between free and paid has to be sayable
On an open-core model, Levine and Li warn that the community can turn on you when it is unclear which features stay in the project and which move into the paid product. The pitfall they name is a fork. Write the line in the positioning document before you write the homepage. A developer should be able to repeat what stays free, and a buyer should be able to repeat what they are paying for.
Steps
Say what the project is
One sentence a developer can check against the repo.
Say what the paid offer adds
Hosting, support, a control, a workflow. Something the project does not do.
Name who pays
The person with the organizational problem, not every GitHub star.
Name the other alternatives
Build it, a rival project, or a vendor that is not open source.
Keep the two lines apart
The README and the pricing page should not tell different stories about the boundary.
Who the line is for
| Reader | What they need | What fails |
|---|---|---|
| Contributor or user | What the project does, and that they can run it | A pricing page where the repo should be |
| Person who pays | The job the project leaves them to staff | “Enterprise features” with no job |
| Someone choosing a vendor | Why you, not the other project or a closed product | A list of GitHub stars |
FAQs
Should the homepage lead with the license?
Lead with the job. The license answers a question developers will ask. It does not say why a buyer pays.
Is the community the customer?
The community is how the project spreads, in Levine and Li’s account. The customer is whoever pays for the offer the project does not include.
What if we have not decided what is paid?
Then the homepage cannot say it. Decide the boundary, write it down, and expect the project’s users to read it.