Handling Contributions as a Solopreneur

Open source culture carries an assumption: if the code is public, contributions are welcome. Fork it, send a PR, collaborate. Beneath it sits a second, from the maintainer’s side — that people even want to contribute. Both hold for a handful of large, well-resourced projects. For everything else, they are defaults inherited from a culture built around exceptions.

The two share a root: the belief that publishing source code and running an open collaborative project are the same act. They are not. They are separate decisions that merely travel together in the projects most people have heard of. Pull them apart, and for a solopreneur with a commercial model one position comes into focus — source open, contributions closed by default.

What follows works through it one question at a time. Can the two be separated? Should the contribution side be closed? What would it take to open it again?

Can They Be Separated?

Start with the license, because it asks less than people assume. AGPL requires only that the source be available to anyone who uses the software, including over a network. It says nothing about accepting pull requests, answering issues, or running a contribution workflow. Publishing the source satisfies it — the code is visible, forkable, auditable — with no maintainer relationship owed to whoever finds the repository. Open source licenses are distribution terms, not governance.

That gap is the point. “Open source” bundles two decisions under one name — publish the source, and accept contributions — but only the first is a licensing question. The second is a choice, answerable on its own terms.

Two Challenges That Push the Door Shut

It can be separated. Whether it should be comes down to two forces that both push the same way — one about ownership, one about noise.

Ownership

The previous post landed on AGPL plus dual licensing as the compensation path: operators who cannot accept the open terms buy a commercial license instead. That depends on one person — or one entity — holding rights to the entire codebase.

An external contribution does not sink that model, but it comes with strings. Merged without a Contributor License Agreement (CLA), the contributor keeps copyright over their changes, and dual licensing the whole then needs their consent — hard to gather after the fact. The model survives, but only on terms, and that leaves two ways to keep ownership clean:

• Require a CLA from every contributor, licensing rights back to the owner. Routine for a large project with legal infrastructure; a heavier lift for a solopreneur, though not without its uses.
• Take no outside contributions, keeping copyright within the owning group. Clean dual licensing, no CLA workflow.

For a solopreneur guarding a commercial path, the second is cleaner — the code stays public, the copyright clean, the commercial path intact. But cleaner is not free: it turns away genuine contributions and forces would-be contributors to fork, and improvements made in those forks never return to the source. Not a failure of openness so much as a consequence of the model, with costs of its own. Whether it is the right call is what the rest of this post works out.

The logic applies to the writing too, but less forcefully. CC BY-SA covers the content, and published writing is open by default — readable, quotable, adaptable under the same terms. Open commercial circulation under CC BY-SA does not require owning all copyright: a contributor’s work sits under CC BY-SA alongside everything else, with no ownership conflict as long as the terms carry forward. The reason is the proprietary derivative path — a closed book, a locked compilation that cannot carry the license forward. For that, the author needs to own all copyright. One unattributed co-author blocks it. The CLA prevents that problem before it starts.

Noise

The second force is newer. Before AI-assisted development, unsolicited low-quality contributions were an occasional annoyance a maintainer could triage in an hour a month. No longer: any public repo on an active topic now draws AI-generated issues and PRs faster than one person can absorb — lower quality, higher volume, none with a CLA attached.

For a community project with several maintainers, that is a management problem. For a solopreneur whose output is the work itself, it is a distraction with no upside. The closed-contribution case does not depend on AI — but AI may be what removes the last reason to keep the door open.

What Would It Take to Open the Door?

The previous section already named one instrument: a CLA, under which the contributor licenses their rights to the owner so copyright stays clean and the code’s commercial path intact. That is one of three ways the door can open — and in all three the contributor gives up their copyright claim over whatever they contribute. The difference is only what comes back.

One fault line runs under all of it. Contributions work when contributors benefit — visibility, recognition, or improvements to something they use. Commercial licensing strains that: the author captures the revenue, the contributor does not. The instinct is to reach for the license as the lever, but it is the wrong one — AGPL and CC BY-SA govern the terms of use, not who may contribute, and loosening to MIT or CC BY would strip the commercial leverage both licenses carry. What is missing is a reason for the contributor. For the paid options, that reason is money — and both sit on commercial contracts, with scope, payment terms, and rights settled before work begins. They split on one question: when?

Pay at Contribution

Paid up front, for the work itself, whatever the project earns later. The risk sits with the funder, not the contributor.

• Bounties. A cash reward attached to a specific issue or feature — Algora, IssueHunt, Gitcoin. Good for discrete tasks, poor for ongoing stewardship.
• Grants. A foundation funds defined work — NLnet, the Sovereign Tech Fund, the Prototype Fund. The answer for widely-depended-on infrastructure with no natural buyer.
• Salaried or contract maintainers. A funded entity employs contributors directly. Blender and Godot pay a core team from a donation pool while the software stays free; Red Hat and open-core firms are the commercial version.
• Recurring sponsorship. GitHub Sponsors, Open Collective, Tidelift — the last paying maintainers a subscription-funded income for maintenance and security work.

For writing, the picture differs. Under CC BY-SA, open commercial circulation is already free — paying a contributor does not unlock anything the license has not already permitted for open use. The paid path has two justifications: the proprietary derivative edge (a closed book, a locked course that cannot carry the license forward) or straightforward incentive — paying attracts more and better contributions regardless of the license. That motivational logic applies to writing just as it does to code. The question is whether the volume or quality gained is worth the overhead.

Pay at Licensing

Here the contributor takes a share of the commercial income their work generates — nothing up front, money only when it sells. The most direct alignment of incentives, and the most demanding to run.

Nearly every working example pays for a separable unit: an asset on Unity or Envato, a plugin on the Shopify or JetBrains stores, a chapter in an anthology, a track in a catalogue. A platform can price and pay per unit because each is sold and attributed on its own. A change merged into an integrated codebase — or a paragraph woven into an essay — is none of those things; it cannot be priced or attributed apart from everything around it, so none of these transfer.

The one shape that survives is co-authorship: contributors to a single, indivisible work agree in advance how to split what it earns. Nothing is sold separately — the whole is sold, the proceeds divided by contract. But the split is not solved once. Like company equity, it must keep holding up as the work grows: an early contributor holds a share fixed at that moment while later ones add more against a pool that no longer reflects who is carrying the work. Dilute the early stake, or let it stand unearned? Cap tables and vesting exist because that question has no clean answer — and a solo project has none of that machinery.

No Pay, Just Contribution

Someone hits a bug, fixes it for their own use, and would rather upstream it than maintain a private fork forever. The reward is the merge itself, plus the recognition around it — a name in the contributors list, a visible track record. Payment was never the point.

A CLA is the instrument: the contributor grants their rights so ownership stays clean and the code’s commercial path intact while the change still lands. They give the part away knowingly, in exchange for not having to maintain it — dissolving the forced fork without a financial model.

For writing, the CLA still applies but for narrower reasons. CC BY-SA handles open circulation freely — no ownership friction there. The CLA secures the proprietary derivative path (without it, the author cannot issue a commercial license covering a contributor’s portion) and the upstream motivation: a contributor who spots an error could publish a corrected version under CC BY-SA, but the CLA-gated merge puts it in the canonical work instead.

The overhead mirrors commercial contracts — agreements, PR review, a process to hold — and the noise gate applies to all contribution models equally. What distinguishes the CLA is the asymmetry: unpaid work feeding something that could be sold commercially. Many take that trade gladly; others balk, and that reaction is fair.

The scope is narrow: small, self-interested fixes, not sustained development. What stays closed is the expectation that anyone does the ongoing work for free.

Weighing the Options

Three positions have surfaced along the way. Set side by side, the trade-offs stop being abstract:

1. Open, contributions closed — public source, no outside contributions at all.
2. Open, paid contributions — public source, contributions open and paid at point of commit; ownership protected by commercial agreement, not CLA.
3. Open, CLA contributions — public source, contributions closed by default but a CLA-gated door for small, self-interested fixes; no payment.

Read down the columns and the decision takes shape. Closed contributions is the simplest to run but turns every would-be contributor away and traps improvements in private forks. Paid contributions recovers that and adds direct compensation — but only once funding exists. The CLA column sits between: no money needed, fixes return to source, the door genuinely rather than nominally open.

For writing, the table reads differently. Open commercial use under CC BY-SA is already free — paid contributions serve two purposes: the proprietary derivative edge (a closed book or course that cannot carry the license forward) and straightforward incentive — paying attracts more and better contributions regardless of the license. The commercial scope is narrower than for code, but the motivational logic is the same. The CLA still applies, but the contributor’s commercial exposure is different: their work circulates freely in the open; the CLA secures the author’s ability to issue proprietary licenses at the derivative edge, not to gate the open contribution itself.

Where I Land

So here is the decision — for now, and open to revision — stated plainly:

• The source stays open. AGPL for the code, CC BY-SA for the writing. The reasons are transparency, adoption, credibility, continuity, and the dual-licensing leverage — none of which depend on contributions.
• Starting at CLA contributions — for both. For code, the default is CLA contributions: no open PR queue, no standing invitation, but the gate is unlocked for small, self-interested fixes. Raise an issue, sign the CLA, register an account — the fix lands, the asymmetry stated plainly, never hidden behind an open-source badge. For writing, the CLA still applies — the author needs copyright ownership to keep the proprietary derivative path open. What changes under CC BY-SA is the commercial exposure for contributors: their work circulates freely in the open, not locked behind a commercial gate.
• Moving to paid contributions when affordable — for both. Once real licensing revenue or outside funding exists, the model shifts to paid contributions: commercial agreements, direct compensation, the contribution returned to source and the contributor paid for it. For code, this is the primary commercial path. For writing, the commercial scope is narrower — but the motivational logic is the same: paying attracts more and better contributions regardless of the license.
• The Pandora’s box caveat. The CLA gate remains open even after payment starts — small fixes that do not merit payment stay under it. But the boundary will need to be held deliberately: once money enters the picture, contributors who accepted the asymmetry before may not accept it after. The distinction between “a fix too small to pay for” and “work worth compensating” is a judgement call, and it needs to be made explicitly, not inherited.

That is the position today. For code, the CLA gate is open and payment waits on revenue. For writing, the CLA gate is the same — but under CC BY-SA the contributor’s work circulates freely in the open; the gate defends the proprietary derivative edge rather than all commercial use. When paid contributions become viable for both, the definition of what qualifies will matter as much as the decision to pay at all.