The question I keep returning to: can open source be a viable model for a solopreneur? Not just philosophically — I believe in it — but financially. Can you give everything away and still build something sustainable?
There are two distinct things I am considering making open: code and writing. They operate differently, attract different communities, and generate value through different mechanisms. They need to be treated differently.
Why Open at All
Three reasons, in descending order of idealism.
The first is straightforward: I have built on the work of others for my entire career — open source tools, open documentation, open thinking from people who decided to share rather than sell. Giving something back is not a strategy. It is an obligation I feel comfortable carrying.
The second is practical. An enterprise or team that can start using something before buying it has a fundamentally different relationship with the decision to pay. The friction of evaluation disappears. The risk of the first conversation disappears. Trust is built before money is discussed, not as a precondition of it.
The third is about scale. The alternative — closed software, a sales team, a pipeline, a quota — requires a machine to run it. A solopreneur who tries to get traction through enterprise sales without that machine ends up either burning out chasing deals or becoming the thing they built the company to avoid. Open is not just philosophically appealing. For a solopreneur, it is the only model that does not require you to become someone else to execute it.
Two Kinds of Openness
Code as Open Source makes software visible, forkable, and modifiable. Under permissive licenses like MIT or Apache 2.0, anyone can use it for any purpose. Under copyleft licenses like GPL or AGPL, derivative works must remain open — AGPL extends this to software used over a network, closing the loophole that would otherwise let a hosted service use the code without contributing back. The license choice shapes who can use the code and under what conditions.
For a solopreneur, open sourcing code builds trust — you can see what you are getting — and creates visibility. It forces discipline around modularity and documentation. The trade-off is that competitors can use your work, and users who extract significant value from it have no obligation to pay. The protection is that open source licenses explicitly disclaim all warranty — which means no implicit support obligation, no liability for downstream use, and no expectation of maintenance beyond what you choose to provide. For a solopreneur, that disclaimer is not a limitation to apologise for. It is what makes publishing at all sustainable.
Writing as Creative Commons is to text what open source licenses are to code. CC BY allows any use with attribution. CC BY-SA requires derivatives to carry the same license — the share-alike equivalent of copyleft. CC BY-NC restricts commercial use. CC BY-ND prohibits derivatives. The choice determines what others can do with your thinking.
The primary reason to write and license it openly is to share expertise and a perspective on how things can be done better. Not to market — to contribute. CC licensing makes that writing shareable in ways that default copyright does not: someone who finds it useful can republish, adapt, or teach from it, and attribution requirements ensure your name travels with the work. Reach and credibility follow from that, but they are not the point. The point is the ideas.
The Constraint: Getting Paid
For a funded company or an academic institution, open work can exist without directly generating income — there are other revenue streams or grants to cross-subsidise it. For a solopreneur, there are not. If the open work does not connect to income, it cannot continue.
What getting paid means to me: sustainable income that does not require an ever-increasing number of hours. Not maximum income — enough income, consistently, without trading more time for every euro of it. The ceiling of a time-for-money model is fixed by the hours available, and it belongs to whoever is doing the work.
The question is not just how do I get paid but how do I get paid without the revenue scaling linearly with time — mine or anyone else’s. If the answer is “sell more hours”, and the open work still needs doing, you end up running both in parallel. That is not sustainable. It is the fastest route to burning out on the thing you were trying to build — and that does not benefit anybody.
To be clear: I do not object to selling time for money. Consultancy, advisory, paid workshops — these are legitimate and I expect them to be part of what I do. The problem is when they are the only stream. A business that depends entirely on time-for-money has no buffer, no ability to step back from client work to build something, and no income when the work pauses.
The Landscape of Monetization Models
Code and writing have different audiences, different leverage points, and different viable models. They are treated separately below.
Code
| Model | Description | My take |
|---|---|---|
| Consultancy and services | Get paid for time and expertise. The revenue model is time-for-money. | Fine as one stream — not as the only one. If it fills all available time, there is no time left to develop the open source. |
| Paid feature development | A user or company funds a specific improvement to the codebase. The work is scoped, time-based, and ships back into the open project. | Viable and product-aligned. Different from consultancy — you are building something that benefits all users, not advising on one client’s problem. |
| Support and maintenance contracts | Sell reliability and continuity rather than features. | Viable as a layer, but carries two risks: an incident can trigger simultaneous demand from all contract holders at once — an avalanche — and it sits in tension with the no-warranty stance of the open source license. |
| Sponsorships | Voluntary payments from users or companies who want to support the project. GitHub Sponsors, Open Collective. | Not a primary stream. Tends to be small and unpredictable unless the project reaches significant adoption. Useful supplement, not a foundation. |
| YouTube / video | Publish tutorials, walkthroughs, and architecture explanations as video content. Ad revenue scales with views. | Viable option. Passive once published. Builds visibility for the project as well as generating revenue — slow to compound but doubles as distribution. |
| Open Core | Free open version, paid enterprise version with additional features. | Not appealing. Requires deliberately withholding value; puts commercial and open interests in structural opposition. |
| Dual licensing | Open under a copyleft license, with a commercial license for those who cannot comply. Works well for infrastructure. | Viable — the mechanism for getting paid by competitors or anyone making money from the work without wanting to open their own modifications. |
| SaaS / hosted product | Run the open source as a managed service. Revenue scales with usage rather than time. | Strong option. Scales without proportional time if the right license is in place. Especially strong in combination with dual licensing. |
Writing
| Model | Description | My take |
|---|---|---|
| Consultancy and advisory | Get paid for time and expertise applied to the writing domain. Clients engage you to work on their specific context. | Fine as one stream — not as the only one. If it fills all available time, there is no time left to write. |
| Speaking engagements | Present the ideas at conferences, events, or private sessions. | Good complement to consistent writing. Time-bound per event, but follows naturally from reach. |
| Workshops | The ideas delivered live to a group — in-person or remote. | Viable, but scales only to the number of people in the room. Closer to time-for-money than courses. |
| Sponsorships | Sell advertising or sponsorship slots against the writing — newsletter, site, or other content formats. | Not a primary stream. Depends on audience size; unpredictable early on. |
| YouTube / video | Publish the ideas as video content. Ad revenue scales passively with views once the channel has reach. | Viable option. Passive once the content is published. Depends on volume and reach — slow to build, but compounds. |
| Licensing | Under CC BY-NC, commercial reuse of the writing requires permission. Individual posts remain open. | Relevant for protecting commercial use without restricting sharing. Enables selling compiled work or licensing excerpts. |
| Books and ebooks | Compiled, structured, expanded versions of the writing. | Good option. The curation and editing create value the individual posts do not have; the CC license does not give away the compiled work. |
| Courses | The ideas as structured learning, recorded and sold. | Strong option. Build once, sell many times — scales independently of time. |
The right model depends on what the open work is, who uses it, and what additional value can be built on top of it. The tables above are a landscape — not a recommendation.
What I Will Actually Do
Most of the avenues in the tables above are ones I expect to explore at some point. Not all at once — the viable ones only become accessible as the model and tooling develop, and the writing only becomes a foundation for courses or books once there is enough of it.
The rough order I expect to follow: consultancy and paid feature development come first, because they require nothing more than having something worth working on and people who know about it. Sponsorships, speaking, and YouTube follow from consistent output and audience — they require reach, not just work. SaaS and dual licensing become relevant once the tooling is solid enough to run as a service and defend as a product. Books and courses follow once the writing has the depth to compile into something more than a list of posts.
What I will not do is open core. The structural tension it creates — between what is open and what is withheld — is not something I want to manage, and I do not think it is honest to the people who depend on the open version. Support contracts as a standalone model are also off the table: the avalanche risk and the contradiction with the no-warranty stance of the license make it a bad fit.
Everything else is on the table. The order is set by what the work makes available, not by what I would prefer to do first.
If you are working through the same questions as a solopreneur — how to stay open, how to get paid, what to build first — I would like to hear how you are thinking about it. Get in touch.
This post is a snapshot of where my thinking is now. The model is still being built, the tooling is still being built, and the answers will change as both develop. If you want to follow the journey — the decisions, the mistakes, and what actually works — subscribe to my RSS feed.