A new funding model for open source software
tl;dr
I maintain a semi-popular open source project. This is a recollection of my attempts at various potential methods of getting paid so I could remain full time supporting it, and what happened when I tried them.
In the end, I decided that the most honest and respectful way of doing so is to build a business on top of it, as a separate product in an adjacent market that supports and pays for the development of the open-source one. I considered the common freemium and open-core models espoused elsewhere. Having been satisfied with neither, I've come up with a hybrid model that I think could be useful for others and might be a better fit for open-source in some cases, because it aims to keep the core open-souce product un-monetized. Details in the article below.
After our new release a few days ago, I had a little bit of time to go through the questions I’ve received over the past few days. Most of them relate to how our new funding structure works with the existing project (no changes) and whether it affects what we want to build (it does not).
Considering open-source funding is something of a conversation starter (or ender) these days, I wanted to post something on what we’re doing, how it works, and why we ended up doing it this way.
Some context
Aether (Website, Github) is an open-source, peer-to-peer app to create Reddit-like communities without servers. It allows each community to elect or impeach their mods, an all mod actions are public. Moderators cannot delete posts without an audit log. Likewise, users can choose which mods they want to have active for them — they can disable a mod as they wish.
Aether had been almost a year-long project for me at the point of shipping, and I worked full time on it. This was not in expectation of anything: I needed a “sabbatical” of sorts from my work at a FAANG company, and that was largely it. Nevertheless, after the release, it started to get real usage.
At that point, not only I started to get support requests, I was also nearing the end of my savings. The only way I could continue this, which had become a full-time job at that point, was that I would somehow get paid for it. Or I would have to go back to having a full-time job and let go. Thus began my journey to find whether living on Aether would be possible.
Life as a hunter-gatherer
What I tried
Nadia’s Lemonade Stand was the first thing I encountered. On one hand, this is a great resource. On the other, it makes clear that the funding you can get through these is a far cry from what you would need to be able to survive in San Francisco.
I tried some, still. It turned out that these tools worked better for letting people express their support. For that, they’re great: it makes you feel good and supported — as long as it is not your main compensation and more of a ‘keep up the good work’ tip.
What they don’t offer is a living wage or any way to go full time maintaining an open-source project. This was easy to see for me, coming from a FAANG salary — that made the opportunity cost obvious. If you can make $10,000 a month from donations doing open source work, I can guarantee you that your salary in any large tech company (or even startup) would be much more — to the tune of 10x to 25x. And you would be eating the difference.
The issue isn’t even that you might not be able to live on it: it’s that if you can make enough to live on donations per month, by all economic reasoning, you shouldn’t. You’d be paying so much in opportunity cost for the privilege. You’re better off working for FAANG for a few years, save up the money, and use your newfound wealth towards open-source. This is tough because it creates an environment where open-source is only possible for either very junior folks, which use it to make a name for themselves, people in Academia, including students, and educators, or financially independent people.
For the first two, I would argue it’s a win-win, you help everybody out, make your name, and then use this to get a good job. For the lattermost, it’s a good deal since you’re ultimately not concerned with making money. However, the life skills that got you to there likely also prevents you from forfeiting ~99% of your output in opportunity cost for the privilege. Incidentally, only a few of the many excellent programmers here in Silicon Valley that have ‘made it’ financially write open-source code.
My verdict for kind of funding was that most of us couldn’t make a living through it, except through personal sacrifice. This could either be living preferences (e.g. moving to a cheaper country where you know no one) or paying a shocking amount of money in opportunity cost. And that’s money you’re giving up that you could use to better provide for your kid(s), for your wife, and your greater family.
What I didn’t try
Aether is a community app, so it does get a decent number of eyeballs per month. The reason I built this was to build a community place without a catch, away from the prying eyes of any mega-corp — a place of Internet’s own that exists in nowhere but in the ‘minds’ (i.e. devices) of its members.
Advertising into it could be built in a fashion that does not track users. This does not work, because unlikely as it seems, the vast majority of the value of advertising comes from targeting. And for targeting to work, you need lots of user data. So the only way for anyone to make money from advertising is to track users, to some extent. In the end, I decided it was incompatible with the core idea for us to have advertising. If for nothing else, I use Aether every day, and I would like to keep using it.
Attempts at subsistence farming
After trying to make donations work, I ended up moving to something more organised. That was seeking sponsorship from corporations. For this, the result was middling, and @feross
puts it better than I can:
“Sustainability” only means subsistence
Increasingly, maintainers are starting to go through a mindset shift. We don’t want to ask politely for donations anymore – donations that often never come, or when they do they’re usually only enough for maintainers to sustain themselves but never enough to thrive.
Sustainability is another way to say subsistence. This is why the common phrase “open source sustainability” isn’t ideal. (Source)
This is not as bleak as it sounds so much as it is obvious — especially so if you consider it a restating of the fact that donations come from the goodwill budget. That budget is usually either nonexistent for most people, and companies. All the while the things they do with your source code earns them the very money they strike under profit. The open-source developer, however, (rightly or wrongly) expects it to be considered under core business expense. This is the source of most of the anguish.
It’s also understandable from the company’s side, though. Since the raison d’etre of a business is to make money, and of open source is for developers to give things away for businesses to exploit. In an ideal world, any company who donates some of the proceeds back to the open-source maintainer will be out-competed by another who uses the open-source product but does not — since the latter will have more capital at hand that it can use to better itself.
As a result, a successful open source maintainer not even only makes its users indifferent to his or her plight, he/she actively discourages them, because any donation that would go to the maintainer would improve the open-source software for anyone, making the donating company effectively pay for improving software used by competitors.
This is sad because it’s a prisoners’ dilemma situation where the Nash equilibrium squarely sits at the lone option that makes the maintainer go starving. To be able to avoid this game-theoretic doomsday scenario that most open source projects suffer from, the maintainer needs to be able to offer to the paying company some advantage, something to give back to its paying users.
That, I realised, after an embarrassingly long time spent pondering, is a bog-standard, good old business that sells goods or services.
(In fact, capitalism can be thought of as an emergent natural phenomenon arising out of the Nash equilibrium state of an unsupervised, repeated prisoners’ dilemma. Nevertheless, that’s a topic for another day.)
Long story short, my attempts to get funding from companies that would ostensibly support the goal rolled up to dead ends, because it turned out that most of their ‘foundations’ that they had set up were thinly veiled attempts to get other people to implement their crypto coin of choice. Their non-profit funding was a way to pay a trivial amount of sum to cover for that.
I have also tried to raise funding from some actual, honest-to-god foundations. It turned out that the amounts of funding that we ended up talking about ended up within the ‘donations’ range. The only difference was that they would provide it as a lump sum instead of averaged over month-to-month.
The dawn of the Agricultural revolution
At this point, it was pretty obvious to me that I would need to take care of this myself. It was becoming obvious that the only real way to make money out of an open-source project to ensure its continuity would be to build a good business on top. As obvious as it is to someone not within the open-source world, this was a revelation for me. I now think it’s one of the things that make sense without needing much of an intricate justification: if you’d like money, offer something in exchange.
That was refreshing, as it cuts down the number of assumptions you make about the world drastically. Instead of having a nebulous path through which you produce value as open-source software, and then expect to have some of that value return to you somehow, you make your software available as before, but give people who pay you, more stuff.
But isn’t that proprietary software? Not always, though that is one way. There were a few approaches I considered.
Freemium open-source
This is a model where the core product is open source, but add-ons are not. Redis is (arguably) one example of this. The issue with this is that this leads to a point where the open-source product is not very useful or modern. Since most new development happens in the add-ons, and that’s where most of the new work goes.
Being able to sustain this and also have the core, non-add-on version useful takes ongoing vigilance. Since Aether was a communication product designed for public discussion, the add-on space was small. It could have been possible to offer better tools for elite users like moderators to allow for better automation, for example. Though it is likely it would still end up in a place where there is a tension between adding a feature to the core, and to the premium add-on you sell.
Open-core
This is where you have a core product, and a second paid product that builds on top of that. That second product provides extra features not found in the first. Gitlab is the vanguard of this one. The difference between freemium and this is that the extra features are usually subscription only and that you get either all or none. This is usually called a Community Edition (available for free), and an Enterprise Edition (paid).
The principal issue with the open-core is that it’s undefined what would happen if someone sends in a pull request that adds a paid feature in the free version. Since the paid version is a superset of the free one, by definition any paid feature would be an improvement. Yet, the company would be inclined to not accept the PR since that would weaken their paid product. They would be competing with themselves.
In practice, that does not happen often. Not many people are capable of adding nontrivial features to large applications, and fewer still want to do it for free. Nevertheless, this remains a large incentive mismatch that one cannot ignore.
Our model, or what we ended up going with
“Aether model” (for lack of a better name)
This model involves, like the open-core, two products. However, instead of one being a superset of the other, they are two different products. They aim for divergent goals, non-overlapping use cases, and different users. They share a similar codebase kept in sync, though they grow in different directions.
In our case, Aether P2P is a peer-to-peer network that creates self-governing public communities.
The second product, we ended up building as Aether Pro,. It’s a SaaS app that we offer on a subscription basis, that targets internal teams within tech companies, being a collaboration tool like Slack. It’s a Reddit-like, threaded forum that disrupts people fewer times than having Slack open, with its constant, ongoing pings.
In other words, not only that Aether P2P cannot do the job of Aether Pro, but it’s also that Aether Pro cannot do the job of Aether P2P.
An example of this purpose-separation in action is this. In Aether P2P, everything is public. One of the features I’ve received the most for that version was to have private communities.
In Aether P2P, this is impossible, because it’s a peer-to-peer network. The only way to incentivise people to pass on the content and use their bandwidth to serve the network is for them to gain something from it. Any content that would be private to a specific party would benefit no one in the network except its recipient. As a result, the network would have no incentive to carry it. If I implemented this feature in the P2P edition, somebody would fork it, remove it and release their own. And they would be right since it would be an improvement to remove it for anybody except the recipients of those private messages.
On the other hand, in Aether Pro, we can have everything private, because we are now hosting Aether Pro backends on our SaaS. And these backends are provisioned by Kubernetes to our exact requirements — no user needs to carry content that it cannot read or act on. That said, this also means Aether Pro cannot serve public communities, and that is fine! We have Aether P2P for that.
It’s a similar story with the target audiences: the Pro audience is groups of 5-25 large teams of engineers who collaboratively work on a codebase. This is common with remote companies where people build their product across many time zones. Aether Pro, above Slack, offers them a way to communicate async with each other that does not break anyone’s focus. It allows them to have a complex, multi-threaded discussion across themselves.
For the Aether P2P, the audience is similar, likely even the same people, but in personal contexts. This targets essentially a very techy, Reddit-like audience. Because these audiences interact and share members, it makes the P2P version a valuable marketing tool for us to invest in, since it brings us, in the marketing parlance, qualified leads. This sets incentives right, too. We pay for the development of Aether P2P out of our marketing budget, because every time we do something with it, we get new users… users who are also in our target market for Aether Pro, and like Aether P2P enough to make the recommendation to their employers.
Other benefits
- We do not depend on anyone’s benevolence: we offer a service and charge money in exchange. It’s an honest, sustainable business.
- Since the source code is shared to some extent, the improvements, bug fixes we do on the Pro can move to the P2P for free. P2P edition by default gets kept up to date by the work done on the Pro, no extra effort needed.
- Since they target different markets, we don’t have to ever think about ‘Would adding this feature to P2P cannibalise Pro sales?'
- Lastly, it makes Aether P2P completely free of any attempts to monetise it. Since the majority of the issues with any communication platform is caused by attempts to make money, this is a good thing. Aether P2P does not need to do anything more than remaining attractive to its current type of users.
- It allows me to avoid marketing. Or rather, I turned the least appetising part of my job as a founder into writing open-source code. I then release it and later talk, to people about it. That is the extent of our ‘marketing’. Today, our work for Aether’s P2P edition is funded by the marketing budget for the Pro, and it has a pretty great ROI. To me, this is a major win.
In the end, I’m a nerd: I’m not great at getting on stage and talking to people. Never been great at that, probably won’t ever be. But what I can do is I can write code, and if that can be my way of reaching out, I’ll be happy.
P.S. If you’d like to try Aether Pro with your team, here’s a coupon code for 30% off: FOUNDER-REFERRAL
. If you’re an engineer, this is a good way to buy the calm at work. You can also see a few more reasons why here at aether.app.