A large customer wants a feature in your open-source project. They will pay to get it built. You want the revenue, and the feature might help everyone. This sounds like the easiest deal an open-source company can make.
It rarely is. The customer may think they are buying a delivery date and a permanent place on your roadmap. Contributors may think the customer is buying influence over a project they help maintain. Your team may think it is selling engineering time. Those are three different transactions, and the disagreement usually appears after the code is written.
Start with the problem, not the proposed feature
A customer request often arrives as a specification: “Add an export endpoint,” “Support this authentication provider,” or “Make this query ten times faster.” Before estimating the work, ask what the customer needs to accomplish and what happens if the project never adopts their proposed solution.
Suppose a customer asks for a new authentication integration because its security team will not approve a rollout without one. The underlying need is a compliant deployment, not necessarily that particular integration. A configuration change, an existing extension point, or a private adapter may solve it faster. Discovering that early protects the customer’s budget and your project’s architecture.
It also reveals whether the request belongs in the shared software. A capability that fits the project’s purpose, has a maintainable interface, and would be useful beyond one deployment is a plausible upstream feature. A workaround for one company’s internal workflow may be valuable paid work without becoming part of the project.
Decide what the payment buys
I would not sell “a feature merged into the open-source project” as a simple deliverable. A merge is not just a shipping event. It creates an expectation that someone will review, document, test, and maintain the feature as the rest of the project changes. If your company controls the repository, you can promise to do that work—but you should price and plan for it. If the project has independent maintainers, you cannot sell their approval at all.
Instead, make the commercial commitment precise. Depending on the request, the customer might be buying:
- An investigation and a written technical proposal.
- Implementation against an agreed interface and acceptance tests.
- A supported integration for its deployment, whether or not it is merged upstream.
- Your company’s commitment to maintain an upstream feature for a defined period.
These are different scopes with different risks. A paid discovery phase is often worthwhile when the architecture is uncertain. It gives both sides a decision point before a rough idea turns into a contractual promise.
Keep upstream decisions legible
Payment can fund development without buying immunity from review. Say that plainly to the customer and to other contributors. Publish a design proposal when the work affects shared behavior. Explain the problem it solves, the alternatives considered, and who will maintain the result. Give reviewers a real opportunity to change the design.
That process is not a theatrical vote after the contract is signed. If meaningful review could overturn the approach, conduct it before you commit to that approach. If the customer needs confidentiality, agree on what can be discussed publicly and when. If the project’s governance does not permit the necessary review on the customer’s timetable, do not promise an upstream delivery date.
The same principle applies when your company is the primary maintainer. You may have the authority to merge a change, but authority does not erase the maintenance burden. Contributors notice when one customer’s deadline suddenly outranks long-standing bugs. You do not have to treat every request equally; you do have to be honest about why work is being prioritized and who will carry it afterward.
Price the life of the feature
The first implementation is usually the easiest cost to estimate and the least useful cost to price alone. Authentication integrations need updates when providers change APIs. Export formats acquire compatibility expectations. Performance improvements need regression tests across workloads the first customer may never run.
Put the ongoing obligation in the deal. Specify which releases you will support, what breaks your commitment, how defects are reported, and whether future changes require another contract. If the customer requires a fixed deadline, reserve time for review and rework rather than treating upstream acceptance as a final checkbox.
Be especially careful with a feature whose only active user is the paying customer. If they later leave, will you keep maintaining it? If not, design an extension point, isolate the integration, or agree on a retirement policy before it becomes a permanent obligation for volunteers. Open source makes code available; it does not make maintenance free.
Leave both sides with a credible outcome
A good sponsored-feature agreement has an outcome even if the upstream proposal changes or fails. The customer gets usable software, a supported alternative, or a clear stop after discovery. The project gets work it can reasonably sustain, not an unreviewable promise made elsewhere.
This does not mean keeping paid work out of the open. It means separating the customer’s legitimate right to buy an outcome from the project’s need to decide what belongs in its shared codebase. When those commitments are explicit, sponsorship can pay for improvements everyone uses. When they are blurred, the same check can buy a release deadline today and a trust problem for years.
Leave a Reply