Pitch an Open-Source Project Without Confusing Usage With a Business

Suppose your traction slide carries a tall bar labeled "Customers" with a seven-figure number on it, and the number came from a package registry's install count. Two slides later, a smaller figure lists your paying accounts. Nobody in the room says anything, but the two numbers are now doing a job neither of them can do: they suggest a pipeline between a public library and a paid service, and they imply that someone has measured it.

The bar isn't lying, exactly. It's wearing the wrong label, and the wrong label is the whole pitch's problem.

The fix is not to shrink anything or to bury the community numbers. It's to draw two accounts and one ledger: an operating account for the public project, an account for the paid offer, and a short list of the work that runs between them. Each of your numbers then belongs to one of those accounts, and the reader can tell which. That's the difference between a pitch that sounds impressive and a pitch that survives a follow-up question.

What this piece won't do is pick a license, judge whether a commercial use is permitted, or decide whether your particular offer is a good business. Those questions belong to whoever owns the license record, the contracts and the company's money. What it will do is give you a structure that a technical or commercial reader can check, line by line, without needing a lawyer in the room.

Two accounts and one ledger

To keep this concrete, the rest of the article uses an invented company and an invented project. Godwit is a fictional open-source library for shared calendars: it represents events, expands recurrence rules, resolves time zones and computes availability windows. Alderway is a fictional company of eleven people that sells Godwit Cloud, a managed version of that library. The numbers, prices, patches and promises below are all made up for the exercise. Nothing here is a real project, a real contract, or a recommendation about either.

With that in place, here's the shape to aim for.

The project's operating account answers: what is available to anyone, who decides what changes, who does the upkeep, and what that upkeep costs in hours. Its population is users and contributors, and neither group has agreed to pay you anything.

The paid offer's account answers: what a customer buys, what you owe them once they have bought it, and what the money pays for. Its population is customers, and their obligations run in one direction, toward you.

The ledger between them answers: which of the project's work or people the business actually depends on, and which parts the business supplies itself. This is the part most decks skip, and it's the part that makes the other two believable.

An open project and a commercial offer can reinforce each other without being the same population, the same product, or the same promise.

What the public project actually runs on

Most pitches describe the project by its features. That's the least useful half. The half a reader needs is the operating side: who can merge a change, who fixes things when nobody is being paid to, and how quickly a decision gets made.

For Godwit, the invented facts look like this. Nine people hold merge rights. Two hundred and forty people have had at least one commit merged since 2016, but in the last twelve months only thirty-four contributed code, and six of those thirty-four accounted for most of the merged lines. The library is published to two package registries. Releases follow a versioning policy that supports the previous two major versions, and the project runs a private security disclosure process with an advisory list and a patch release path — a process that exists because someone agreed to run it, not because repositories produce it automatically.

One of the nine maintainers works at Alderway and spends roughly a day a week on Godwit during work hours. The other eight do not. That single sentence already tells a careful reader more about your company than a star count, and it's the kind of sentence you should be willing to say out loud.

Governance matters here too, and it's easy to blur. Alderway uses Godwit heavily, employs one of its maintainers, and pays part of the CI bill. That is a real relationship. It is not control. Unless Alderway holds the merge rights, writes the roadmap, or has the authority to change the project's terms, the deck should not use the word "our" about the project's direction. Say what you contribute and what you don't decide.

The Open Source Guides' page on getting paid for open-source work is useful context for this section, at a general level: it treats contributor motivations and financial arrangements as varied, and maintenance itself as labor that has to come from somewhere. It is a map of possible arrangements, not an endorsement of yours or a validation of your business.

What a customer buys

Now write the second account as a purchase, not an aspiration.

Alderway's invented offer has three parts. Hosting starts at US$180 per month per environment: Alderway runs the API, stores the data, handles backups, and keeps the timezone data current. A support tier at US$2,000 per month adds a four-business-hour response commitment, a named contact and an escalation path. Implementation is quoted separately, typically between US$15,000 and US$40,000, and covers migrating a customer's existing calendar data, wiring up single sign-on and integrating with the customer's on-call tooling.

Sixty-three accounts pay for something. Eleven of them are on the support tier.

Notice what that paragraph does that a "we monetize the open-source project" slide cannot. It names an artifact, a price, a party and an obligation. It also reveals that Alderway's customers are not a subset of Godwit's users: some of the sixty-three run the library themselves and buy support, while others never install it at all and simply call the hosted API. There is no clean chain from an install to an account, and no honest way to compute one from the numbers you have.

If an offer is not yet sold, keep the tense honest. "We plan to launch a support tier in the second quarter" is a perfectly good slide. It just belongs on a different page from revenue, and it shouldn't share a heading with a figure that describes something that already exists.

The labor between them

Here is where the two accounts meet, and where a pitch either earns trust or spends it.

Godwit's upkeep is not finished work that Alderway can simply consume. The issue triage, the reviews, the release cutting, the documentation, the security responses and the timezone data tracking all continue whether or not Alderway sells anything. Alderway supplies one paid day a week toward that, plus the project's CI costs. The rest comes from other employers' time and people's unpaid hours. Eight of the nine maintainers can stop tomorrow without asking Alderway.

That dependency has a sharper edge in the fictional example. The recurrence engine — the part that expands repeating events, and the part Godwit Cloud leans on hardest — is maintained mainly by one of the nine, who does not work at Alderway and whom Alderway does not pay. She has kept that module for four years. The pitch should be able to say that plainly and then say what Alderway does about it: nothing that guarantees anything, because no arrangement can promise another person's future attention. What a company can honestly claim is what it does today — sponsor the work, fund review time, train a second reviewer, or accept that a fix may take longer than the customer commitment assumes.

That last possibility is already live in the example. Alderway publishes a commitment that when the public timezone database releases an update, hosted customers will have it within fourteen days. Usually that's a packaging job. But when an offset change interacts badly with the recurrence engine, the fix needs a code change in a library Alderway doesn't control. Alderway's hosted service currently runs Godwit plus two small patches that exist as open pull requests, unreviewed by maintainers Alderway doesn't employ; one has been open for five months. The hosted service runs them anyway, which means the sentence "we run the same code as the public release" is not quite true, and the deck should not imply that it is.

None of this disqualifies the business. It tells a reader exactly where the fragility sits, which is what they were going to ask about anyway. Funders and technical buyers both tend to trust a founder who has already found the weak joint.

Every number belongs to a population

Here is the invented slide that gets it wrong.

GODWIT — TRACTION

Customers ............................... 1.4M
Contributors ............................ 240
Paying accounts ......................... 63

The 1.4M is the combined install count across both package registries over twelve months. Labeling it "customers" doesn't merely exaggerate. It collapses a public distribution event into a commercial relationship, and it invites a reader to divide 63 by 1,400,000 and produce a conversion rate that measures nothing.

The repaired version attaches each count to its account and states what it doesn't show.

No conversion rate appears anywhere in that table, because the two populations don't nest. A customer may never install the library. An installer may be a build server. A contributor may never pay for anything, and a paying account may never contribute a line. Community scale is real and worth mentioning — it's just context sitting next to the commercial account, not evidence inside it.

Name the obligations, don't clear them

Finally, the pitch usually owes the reader three facts it can state without interpreting anything.

The license. Quote the actual license the repository carries, by name and version, and say where the project records the terms it asks contributors to accept. Then stop. Whether that license permits a specific commercial use, and whether the project has collected the rights it would need to change course, are questions for whoever owns that record. "Our lawyers are reviewing it" is fine in a pitch, as long as it isn't dressed up as a clearance you already have.

Contribution ownership. Employees of Alderway contribute code to Godwit, and the pitch should not assume that this makes those contributions the company's property. Employee contributions, contractor contributions and outside contributions can all carry different terms depending on where the people are and what the project asks them to sign. Flag the question; don't answer it on a slide.

Names and bundled data. Alderway sells "Godwit Cloud." Whether that use of the project's name is fine depends on who holds the name and what the project's policy says, which is a checkable fact rather than a guess. The same goes for the timezone data the library bundles, which arrives with its own terms.

None of these need to be resolved to give a good pitch. They need to be visible, so that the people who can resolve them know they're on the list.

The diagram to end on

End the pitch with a picture rather than another paragraph. The one below is the whole method in a single view: two operating accounts, side by side, and the dependency running between them.

GODWIT (public project)                  ALDERWAY (paid service)
─────────────────────────────────        ─────────────────────────────────
Who runs it: 9 maintainers with          Who runs it: 11 employees
merge rights; Alderway employs one

What it does: library code, releases,    What it does: hosted API, storage,
docs, issue triage, security response,   timezone updates, support desk,
timezone data tracking                   paid implementations

Funded by: employers, sponsors,          Funded by: 63 paying accounts,
unpaid time, one paid day a week         including 11 on the support tier,
from Alderway plus CI costs              and quoted implementation work

Owes: users and contributors             Owes: customers, under contract —
(no purchase required)                   14-day timezone rollout commitment

                   \                     /
                    \                   /
                     ── dependency ────
        Alderway depends on Godwit releases, on reviews
        from maintainers it does not employ, and on two
        open pull requests its service runs ahead of
        upstream. If Alderway disappeared, the project
        would lose a CI bill and about one day a week of
        paid review time — not its users, its roadmap
        or the copies already installed.

A reader who can see that diagram can answer the three questions your pitch is really being asked. Who can use or contribute to the project, and on what terms? What does a customer pay for, and what do you owe them afterwards? Which of the work and the dependencies does the business own, and which does it merely lean on?

Put those answers on the page in that order and the tall bar can stay where it is, labeled as what it is.

Frequently asked questions

Why is a package install count not a customer count?

Installs belong to project activity, not a commercial relationship. Many may be automated builds, and customers may run the library themselves, buy support without installing it, or never install it. There is no clean chain from install to account, so a conversion rate from installs to paying accounts measures nothing.

What are the two accounts and one ledger in this pitch structure?

The project's operating account covers what is available to anyone, who decides changes, who does upkeep and what it costs in hours. The paid offer's account covers what a customer buys, what the seller owes after purchase, and what the money pays for. The ledger between them names which project work or people the business depends on and which parts it supplies itself.

How should a company describe its relationship to an open-source project it uses heavily?

State what it contributes and what it does not decide. In the fictional example, Alderway employs one maintainer, uses Godwit heavily and pays part of the CI bill, but that is a relationship, not control. Unless it holds merge rights, writes the roadmap or can change the project's terms, the deck should not use 'our' about the project's direction.

Which obligations can be made visible without resolving them legally?

The license, quoted by name and version and with the location of contributor terms; contribution ownership, including employee, contractor and outside contributions; and names and bundled data, such as the use of 'Godwit Cloud' and the timezone data's own terms. The article says these need to be visible, not cleared, in the pitch.

What does the dependency ledger reveal in the fictional diagram?

Alderway depends on Godwit releases, reviews from maintainers it does not employ, and two open pull requests its service runs ahead of upstream. If Alderway disappeared, the project would lose a CI bill and about one day a week of paid review time, not its users, roadmap or installed copies.

Further reading

• Explain a Product’s Pricing Model Without Recreating the Rate Card — It separates the offering from the charging unit and shows what the base fee includes, so a buyer reading your paid-offer slide can predict an invoice.
• Show Customer Concentration Before One Account Becomes the Whole Growth Story — Before showing sixty-three paying accounts, this asks what counts as one customer and how every share is measured against a single reconciled base, so the distribution is visible.