How to Build Sustainable Open Source Software Projects

In my last post about “The Next Decade of .NET Open Source” I alluded to a future blog post about open source sustainability. This is it.

Some background: in January 2015, fresh off of the very public failure of MarkedUp, my first company, and the total destruction of my life savings at the ripe age of 29 - I founded my current company Petabridge. We’re five years old now, growing rapidly, and we’re entirely self-funded.

Petabridge is a business built entirely around supporting the users of its .NET Open Source projects, primarily the Akka.NET project, which I founded out of necessity in order to build a real-time marketing automation product at my previous business.

That’s the origin story of how I got here and why I’m delighted to hear others start talking more actively about the need for “open source sustainability” in communities everywhere. I developed a model that worked for our project and that exact model isn’t translatable to every other project, but the theory that built the model is. And that theory is what I want to share.

Sustainable Open Source Projects are Sustainable Businesses

What we really mean by “sustainable” OSS projects are projects where the core contributors have a sustainable interest in keeping the project going, getting others to use it, responding to bug reports, and so forth.

There’s a time-tested system for creating self-sustaining organizations and it’s called “capitalism,” in which the incentives that further the customers’ interests are aligned with those of organizations responsible for producing the good or service consumed by the customer, thus creating a positive feedback loop and competition that drives innovation, better experiences, and more choices.

Misalignment of incentives are what make OSS unsustainable today - customers, OSS consumers, get something for free and producers get nothing but more unpaid demands for their time in return. Aligning these incentives is the solution to the problem.

Sustainable open source projects are ones that spawn sustainable businesses. Everything else limps along perpetually underfunded, vulnerable to being killed by something as mundane as boredom, and fades into obscurity - replaced by a project and an organization that has incentives that align it to longevity.

Case Study: OpenSSL and Heartbleed

Before I started Petabridge, one of the case studies that nearly scared me off from going anywhere near the open source software market was the OpenSSL “Heartbleed” saga in early 2014. OpenSSL has the kind of success that few open source projects can dream of, being a critical piece of infrastructure used far and wide across Internet giants, cloud providers, and so forth.

OpenSSL is a project entirely sustained by the volunteer efforts of its contributors and donations, and once the damage of the Heartbleed bug became apparent the tech community started a conversation around having Internet giants invest into the OSS projects they use every day for critical infrastructure in their businesses. Prior to the Heartbleed bug in 2014 the OpenSSL Software Foundation received about $2,000 per year in donations, which doesn’t even buy you a week of a senior programmer’s time in Silicon Valley. After the Heartbleed vulnerability captured the attention of the greater developer community the project managed to raise… An additional $9,000.

In the words of Steve Marquees, the OpenSSL Software Foundation president at the time:

Thanks to that publicity there has been an outpouring of grassroots support from the OpenSSL user community, roughly two hundred donations this past week[3] along with many messages of support and encouragement. Most were for $5 or $10 and, judging from the E-mail addresses and names, were from all around the world. I haven’t finished entering all of them to get an exact total, but all those donations together come to about US$9,000. Even if those donations continue to arrive at the same rate indefinitely (they won’t), and even though every penny of those funds goes directly to OpenSSL team members, it is nowhere near enough to properly sustain the manpower levels needed to support such a complex and critical software product. While OpenSSL does “belong to the people” it is neither realistic nor appropriate to expect that a few hundred, or even a few thousand, individuals provide all the financial support. The ones who should be contributing real resources are the commercial companies and governments who use OpenSSL extensively and take it for granted.

Your project will not be as popular or as essential to the day-to-day work of large government agencies, Fortune 500 companies, or FAANG businesses as OpenSSL. Your donation model isn’t going to outperform theirs… Tidelift, Patreon, or Github Sponsors be damned.

An important note: OpenSSL is very much alive and doing well. I don’t know if they raise enough money in the aftermath of Heartbleed to employ full-time engineering staff or if they carry on using the same model they had in years past, relying largely on the uncompensated volunteer effort of their contributors. In either case, the project deserves nothing but our respect. I only use them as a cautionary tale to show how something as critical as their project struggles acquire the funds it needs relying on a donation model to employ full-time development resources. The lesson is: you should expect a worse performance for your project.

OSS Burnout: Working for Free on Things That Don’t Matter to You

The volunteer model of OSS is ultimately not sustainable in the long run for most projects because of burnout and no real sense of ownership over the project. There are exceptions to this of course, people who take great pleasure and craftsmanship in contributing towards as project they enjoy as a hobby, but they are not the rule.

Open source burnout occurs for core developers and contributors most often because they feel like they have to work for free on things that don’t matter to them. Again, a misalignment of incentives.

You gave birth to this project, put it out there in the world, people began using it, and in starts the deluge of bug reports, feature requests, questions about your design decisions, and so forth. You feel responsible for the quality of your work, but the excitement and validation you had the first time someone opened an issue on your Github repository has long since passed. You used to feel excited about coming home from your day job and spending a couple of hours every other night working on your OSS idea. Now it makes you feel guilty and disappointed in yourself every time you look at the aging pull requests, issues with no responses, and the months since your last release.

I remember watching this talk from Jacob “Fat” Thornton, one of the creators of Twitter Bootstrap, back in 2013 about the subject of OSS burnout (starting at around 20 minutes in:)

When the novelty of working on your OSS project wears off, burn out can set in. The “cute puppy” phase, as Jacob called it, is over… And now you’re left to the rote task of triaging bugs, debugging racy unit tests, creating documentation… No one is giving you upvotes on Hacker News or retweets on Twitter anymore. You feel like you have to work on the project in order to avoid guilt and that’s far removed from the joyful experience it once was.

I’ve been working on Akka.NET, in some way or another, every day for six years - and I still love doing it because when you build a business around your OSS project your incentives for working on it change radically towards something that looks sustainable.

I still have the feeling of craftsmanship I get when I personally solve a nasty bug, create a new sample, add a new feature, or improve the performance of an existing one, all of the things I used to feel working on Akka.NET before running Petabridge became my job - but because my business revolves around supporting OSS customers full time I do this work feeling like “this is my livelihood” rather than “this is my burden.”

I enjoy it when we solve problems even for non-paying anonymous Internet users because I think to myself “our customers are always watching, and maybe this person might be one some day” and thus we try to the best of our ability to take care of everyone. Everyone on our team wants to earn the business of our customers every day.

When your OSS becomes your work, rather than an unpaid obligation, the change in mindset lays the foundation for being sustainable - when you support the project and the project supports you back.

Donation Math

Let’s suppose you are one person working on an amazing OSS project on the side and it takes off; you make $125,000 per year working as a salaried intermediate level programmer in Los Angeles. You start getting lots of bug reports, installations, and it begins to become a burden. You love your project and think it can become something great that will make a real difference to others if you had more time to work on it. How do you buy your own time?

Programmers are very well compensated compared to other professions, given the low barriers to entry and the high salaries plus benefits. A donation funding model for OSS projects probably isn’t a realistic option for developers - because… Well let’s take a look at some math.

Full replacement cost of your current income… When launching a startup I typically use the following formula to determine the full cost of hiring an employee:

Base Salary x (1 + LOD (scalar)) = Full Cost

That LOD value in California = 40%, because that includes payroll taxes (~8.5% for employees, ~17% for self-employed), healthcare, retirement, parking, bonuses, vacation, etc… We’ll use that figure here.

Your real cost = $175,000.

Now break that down into an hourly rate to transform your “work” into quantifiable units.

40 hours per week * (52 weeks per year) = 2080 billable hours per year, assuming no vacation
$175,000 / 2080 = $84.13 per hour.

So let’s suppose you want to use Github Sponsors donations to fund your project because you don’t feel like you have any marketing / sales experience and starting a business seems too risky. Donation sizes on projects can range anywhere from $1/person/month to as high as $500/person/month from what I’ve seen. Let’s pick a realistic per-person target - $10/person/month, about the same price as a subscription streaming service.

Let’s suppose you’re willing to work an extra 10 hours per work, as a side gig, on your project: about 40 hours per month. How many donors do you need to break even on those 40 hours per month compared to your salary?

40 * $84.13 = $3,365.38
3,365.38 / 10 = 337 (rounding up) $10 / mo donors.

The size, importance, and visibility of your OSS project would need to be tremendous to bring in that many donors. The amount of effort you’d have to spend on just promoting your project to get that many donors is another full-time job in and of itself. Are you willing to put that much time in for an extra $3,365.38 per month? Probably not. This is why I ultimately think the donor model for OSS sustainability is doomed - the numbers don’t scale.

Are a few hundred bucks worth of monthly donations going to change how you feel about putting in an extra 40 hours a week on your project versus living comfortably off just your salary? Unlikely.

Business Math

Let’s take a look at the same scenario as before, but this time we’re going to go into it with an entrepreneurial mindset. Let’s say you want to make as much money as you do right now, but you really want to have the freedom to work on your project full time.

There are multiple models you can use in OSS to go about doing that:

1. Services model - sell training, consulting, and support directly to the users of your software;
2. Open core model - build something premium and proprietary around your OSS that is valuable to customers with deep pockets, i.e. access control and auditing are important for enterprise users but not your core OSS audience;
3. Licensing model - introduce a copyleft license for the OSS and a dual proprietary ($$) license for the companies who want to use the technology in their businesses;
4. Managed services model - build some managed services on top of your OSS that you can sell directly as a PaaS-style product, i.e. if you built a distributed database, offer a managed service for that on the Azure / AWS marketplace; and
5. Reputation model - rather than trying to sell anything to the users of your OSS, use the prestige and popularity of your OSS contributions to attract better job offers for yourself, attract customers to your business, attract engineering talent to your company, draw attention to your other paid products, etc…

Not all projects can support all models. For instance, if you built a CSS UI framework you can’t really do a managed service model - but you can do a licensing model (Highcharts does this) or a services / reptutation model (Zurb does both of these).

In the case of Petabridge we build application frameworks, which means that customer code is built directly on top of ours, therefore a licensing model is totally unfeasible and a managed service model probably is too. So in our case, we sell services and open core - Phobos is our APM suite on top of Akka.NET, for instance.

Here’s how the math works differently - suppose you still want to hit that $3,365.38 per month target. You won’t be working full time on the project at that monthly rate, of course - this is just to draw a distinction between the donation model example and a real business model.

How about offering training for a fee or holding an in-person workshop at a conference? If your library is critical enough to a company that is using it in a core area of their own technology, they’ll pay for training and they may also pay for support. Offering online trainings, workshops, remote consulting, or support are all models that make earning $3,365 is much more doable.

On top of that, working on the project now becomes an investment in growing your business - the more work you do to fix bugs and address user issues, the better your reputation becomes with better customers and your addressable market may also expand as the project becomes more mature and more useful to a larger and larger audience. The incentives between the project and its developers are now aligned.

Which Projects Can Actually be Businesses?

The scaling laws around OSS projects will vary, significantly, depending on what the project does. I doubt you can build a sustainable business around something like a serializer - that’d need to be a project that is OSS by virtue of a big tech giant like Google or Microsoft. The problem with a serializer is that, while important, it’s in a space that has lots of great free solutions and it doesn’t really touch many different parts of the business. In other words, it’s a narrow-use case tool competing with lots of free alternatives (like JSON serialization.)

For an OSS technology to be capable of supporting a business, I think it needs to do the following things:

1. Be technically complex / expensive enough that your customers couldn’t build it themselves;
2. Must touch multiple parts of a customer’s business - i.e. a UI framework, queueing system, web framework, databases, etc;
3. Must be a radical improvement or departure from current options - can’t be an incremental improvement that another dominant project could just steal; and
4. Must offer understandable business value to end-users.

At the risk of catching giant amounts of grief from the Internet, where functional programming technologies and projects often struggle is item number 4. The benefits can be explained to another highly technical person, but often not to someone with purchasing power.

Our serializer example fails test number 2 or 3.

So those OSS examples that fail these tests can’t really be the foundation of a self-sustaining business in and of themselves - that’s why the business models you typically see supporting more marginal type technologies (things that are useful, but not useful enough to buy) are almost always reputation models. Google doesn’t earn any money from supporting Protocol Buffers, but they get a lot of recognition and access to developers doing cool stuff via their OSS engagement. In their case that OSS project is an indirect part of their business, versus something like Kubernetes (another Google OSS project) which is now a major part of every cloud ecosystem on the planet, which is very much a direct part of their business.

Wrapping Up

Petabridge has been five years of really hard work, long hours, emotional roller-coasters, and, especially during the first couple of years of the business, asking myself “am I dumb for doing this?”

But it’s also been five years of adventure, traveling around the world to work with customers, feeling like the work my team and I do makes a meaningful difference to others, interesting technical work, building great relationships with colleagues all around the world, and the satisfaction of creating a sustainable business.

It’s an exciting time to be involved in an open source business because it’s actually becoming easier to sell to larger companies as OSS buy-in is now the rule, not the exception. That battle is already over and open source won. There’s lots of opportunities to disrupt existing projects or create ones in categories that didn’t exist five or ten years ago. But go into the open source world with your eyes open - it can be fun and exciting at first, but ultimately open source is a business.

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..

Tweet Follow @Aaronontheweb