Fighting for Open Source Sustainability: Introducing Code Sponsor

tl;dr: Two-thirds of the top OSS projects are maintained by one or two people. This is not sustainable. We can help.

Eric Berry

Published in

CodeFund

9 min readSep 11, 2017

The Rise of Open Source

Over the last decade, open source software (OSS) has experienced a rise as rapid and in many ways, as transformational as the Personal Computing revolution. Ten years ago, OSS was a playground for hobbyists to share their work with each other via code patches or SourceForge. Today, a huge part of our lives and livelihoods rely on OSS. It’s in our websites, in our phones, even our refrigerators.

The reasons this happened are too complex to get into here, but they range from the rise of GitHub for making code visible to dependency management solutions like RubyGems and npm that reduce the friction and cost of using shared code.

And for the most part, it’s been great. Software authors are able to publish their work and have it seen by others. This collaborative reduces the number of people we have solving the same problems in different silos, and raises the quality of the solutions.

And when software gets used by others, it’s great too! It raises the profile of the authors, helping them find employment and sometimes even direct support of their projects.

This usage also means someone’s hobby project can become a critical dependency that our apps, websites, or hardware rely on. Billions and billions of dollars in revenue and productivity depend on this fractal map of dependencies, many of which are created and maintained by just one solo developer.

This is where things got weird in a way that we in the tech industry are just starting to grapple with.

The dark side

Now that we rely on open source software for our livelihoods and have abstracted away the ways we use it, the development community has gravitated toward a consumer-oriented mindset. We pull a product off the shelf, plug it in, and forget about it. We imagine the developers behind our critical dependencies are standing by, waiting to improve their software and answer our support questions.

In reality, approximately two-thirds of these mission-critical projects are maintained by just one or two people, in their spare time.

As OSS usage rocketed, this created a mindset of “producers” and “consumers”, where we as Open Source users feel entitled to a high level of customer service, for a product we don’t pay for, at the expense of people who already had a job and were simply sharing their software for their own enjoyment or satisfaction.

The toll this takes on maintainers is simple: they burn out and quit. Over the past few years, we’ve seen several examples of high-profile OSS exits, with maintainers simply giving up and mission-critical software being under-maintained, and then abandoned.

In addition to being inhumane to the original authors of OSS software, this leads to broken dependencies, hidden bugs, and potentially catastrophic security holes in software we use every day.

The “s” word

Kyle Matthews is the creator and maintainer of gatsby

The term we’re using as an industry to start having this conversation is “sustainability“. There are a lot of angles to this, but in a nutshell, it means “what can we do to make sure software authors continue to release their code as open source, and how do we maintain the OSS code that becomes mission critical?”

The way we’ve sustained open source in the past is simple: We let the maintainers burn out and replace them. Maybe they had kids and can’t sustain an unpaid side job and would do OSS if they could get paid for it. Maybe they tired of the stream of complaints for the very public work they do.

But it’s been fine up until now, because a fresh young developer, full of optimism and eagerness to help, will take the project over, start plowing through the backlog of issues, and enjoy the benefits of OSS. They get to do fulfilling work serving their fellow developers, with the only caveat being they won’t be paid for their work.

The problem is that a decade in, authors are starting to catch on to this pattern, and we are seeing younger and younger people burn out and fewer people willing to take over existing projects.

This adds up to a looming crisis in our industry, as our infrastructure threatens to crumble because fewer people are willing to dive down and do this unpaid, thankless, often difficult work.

That’s the bad news.

What we’ve tried so far

Many people who love OSS see the writing on the wall and are trying to bring sustainability to open source. Here are some of the approaches and challenges with them:

Donations. It’s actually become quite easy to drop in a button asking for donations, or for larger projects to join Open Collective where they can publicly manage funding.
Sponsored, full time OSS development. Some larger corporations (AT&T, Salesforce, GitHub, Red Hat, and others) actually pay one or more people to work on a large, popular open source project full time. Not only are they building business value, but this buys community goodwill, and can be a strong marketing and recruiting tactic for developer-centric companies. However, this is always going to be the “1%” approach due to the huge expense and the complexity of that arrangement. It’s also one of the first budgets to be cut once things get tight.
Being nicer to maintainers. Being kind and patient with maintainers actually makes a huge difference, since much of the source of burnout in OSS is due to the attitude of the “entitled consumer” who chips away at the satisfaction that makes OSS work rewarding. It doesn’t solve the broader problem but it’s an important piece of the puzzle.
Paid training, support, and upgrades. Some projects can actually create a healthy, sustained ecosystem by selling paid training courses, or selling a paid support plan or even upgraded version of their OSS product. For developers with solid marketing and business skills, this can actually be quite lucrative.

The challenges with current approaches

All these efforts are helping! The tone of entitlement is increasingly considered unhealthy and unwelcome in most open source communities. Some high-profile OSS developers get great jobs doing OSS full-time at high-profile companies. Some projects are sustaining themselves because their maintainer is business-minded and understands how to marry their project with a sustainable business.

The problem is, for the remaining OSS maintainers that don’t meet those criteria and who would like to make money with their open source, they are stuck. There just isn’t a way for developers to get paid to do open source without begging for money, which, even when successful, winds up being a one-time push.

Asking for donations takes its own toll on developers, and when it works, it often winds up generating a one-time result, making developers afraid to “go back to the well” and test the goodwill of their community by asking over and over again. Worse yet, the lack of support often leads to using guilt to motivate communities to action, which is never successful in the long term.

This leaves the vast majority of developers who would like to support themselves, at least in part, with their OSS work without good options.

Why we created Code Sponsor

We believe strongly that any solution to OSS sustainability has to be sustainable itself. That means there has to be significant, sustained upside to the people participating on all sides.

That’s exactly what we’re trying with Code Sponsor. We know we’re not building the solution to the entire OSS sustainability puzzle, but we have a model that is already starting to work.

Here’s how it works:

We already know there are many open source maintainers that would accept payments for their work if they could find some way to make money doing OSS. On the other side, there are a ton of companies that benefit from and care about OSS and would sponsor if there was some obvious, tangible benefit to them, and not a ton of upfront cost.

Code Sponsor is a mix of a marketplace and a matchmaker: We build relationships with both sponsors and OSS developers, then match up developers and projects with sponsors that are a good fit for each other. Integrating your project is simple:

A maintainer puts put a single line of markup into the Readme of their project’s repository homepage and on their documentation website.
The maintainer chooses from a selection of sponsors which ones fit them and their project the best.
Code Sponsor displays a simple, relevant text advertisement from the sponsor.
The developer starts getting paid.

The ads look like this:

Sponsors pay for each click, and part of that money goes to the maintainer(s), while part goes to maintaining Code Sponsor itself.

These simple messages actually buy sponsors goodwill with developers and lets them get a simple, straightforward message to a targeted group of software developers, which is historically a hard group to reach in an effective and authentic way.

This entire model hinges on maintaining the trust of OSS developers and our sponsors, so we’re taking extra care here, following a much more stringent set of guidelines than you typically see in other forms of advertising.

We strictly follow the Ethical Advertising guidelines (highly influenced by Read the Docs) to prevent irrelevant ads or anything that would abuse the trust of maintainers. That means there’s no tracking, no re-marketing, no selling or passing along information. Our sponsors only have access to

How many impressions by date
How many unique clicks by date
How many repositories are sponsored by them

This model allows all sides to stay sustainable: OSS developers get paid for their work, sponsors get a message to a hard-to-reach audience, and Code Sponsor can exist as a stable business, paying developers to improve the Code Sponsor product and experience for both sponsors and maintainers.

Addressing concerns

Like any new idea, there are bound to be vectors for abuse, and the number one concern with Code Sponsor is building and keeping the trust of our maintainers and sponsors.

Code Sponsor is built by developers who are passionate about OSS and sustainability, and our genuine goal is to preserve the best in open source by helping authors get paid for their hard work.

We also know there are going to be concerns. Here are some of the ones we’ve heard:

What if there are many maintainers on my project? Who gets the money?

If you have a larger project with multiple maintainers, we recommend using Open Collective to manage the funding distribution and Code Sponsor to generate the funds. We can direct all payouts to your collective.

I don’t spend much time maintaining this project anymore. Why should I make money?

Maintaining open source software is hard work, but so is creating it. If you were to get paid for code you are no longer actively maintaining because it’s pretty solid, would the money help you build more OSS?

Will putting ads on my docs harm trust with my OSS users and collaborators?

The ads have to follow our strict guidelines and will never look spammy. You can see ads on these repositories and see for yourself:

Will people click on the ads?

Our initial testing shows that if the ads are tasteful and relevant, the click rates are good and result in maintainers actually making money. In August 2017, we saw strong click through rates, happy developers and positive outcomes with our sponsors.

How will you keep from turning my favorite repository website into an ad haven?

We are committed to making sure Code Sponsor serves OSS maintainers. Like any product designed to help people make money, we have to be on guard for the kind of abuse that ruins the experience for everyone. If any repository is found to be violating our guidelines, we will — without hesitation — remove them.

Isn’t this a violation of GitHub TOS?

We have made many changes that put us in compliance. We now allow sponsors and developers to connect through a sort of matchmaking service. The developer can select which sponsors are most relevant to them and their project (through Code Sponsor). The sponsor then provides a custom image of support that can be used by the developer. Our sponsors are excited to help sustain open source!

What happens next?

We know Code Sponsor is only one part of the solution to sustaining open source, but we think it’s a key piece of the puzzle. We believe the part that helps get OSS developers paid for their work is the most delicate, making it critical that the OSS development community has a strong voice in the solution.

Code Sponsor is currently running in an open beta, working with maintainers first and foremost. We have a list of fantastic sponsors already lined up, sponsoring OSS projects large and small, with lots more to announce in the future as we expand the scope of our beta before launching more broadly.

We’re delighted with the response from the community and the results so far. We’re already helping get maintainers paid for their work and we can’t wait to see what we can accomplish with a community-minded solution that is sustainable on all sides.

If you’d like to sponsor independent OSS through Code Sponsor, participate in our beta as a maintainer, or just want more info, please reach out by emailing us at team@codesponsor.io or visiting us at http://codesponsor.io.