DEV Community

Cover image for Open Source Sustainability

Open Source Sustainability

erikras profile image Erik Rasmussen Updated on ・8 min read

As we round the bend into the second half of this most exceptional year, 2020, two things happened that affected me and my open source work: CodeFund announced they were shutting down, and social pressure forced Tanner Linsley and myself to remove the Scarf analytics service from our open source libraries.


CodeFund has meant a lot to me over the years. I was an early adopter, and the monthly revenue it generated – which has never been more than roughly equivalent to what my dayjob pays me for a single day of work – was really motivating. When I was 85% done with the MVP of Final Form, I was stalled for motivation, and seeing that I could potentially get some income from having another popular library gave me the stamina to make it to the finish line.

(That metaphor was not intentionally related to Final Form's logo, I swear.)

I still think that radio, television, the internet, social media, YouTube, and podcasts have shown us that making something that people want, giving it to them for free, but with ads, is a viable strategy for a producer-consumer relationship that works with how our brains make decisions. The eyes that peruse the documentation pages for open source libraries are very valuable to advertisers. Developers not only can influence decisions about which SaaS solutions their employers adopt, but are also, generally, pretty well paid and have disposable income to spend on gadgets and things.

In the future, I hope more companies like CodeFund spring up to offer themselves as middlemen between OSS devs and advertisers; I think there's still money to be conjured from this space. I think Microsoft, as the owner of both GitHub and NPM, is uniquely positioned to make a difference in open source sustainability via advertising.


Installing an analytics tracker in my open source library had never occurred to me before Avi, from Scarf, approached me to talk about it. The way it works is simple. Much like how this very webpage, totally unbeknownst to you and without your consent, probably caused your computer to download half a dozen (or more) little 1x1px gifs, allowing some unknown-to-you corporations to triangulate, using only the HTTP headers of those requests, where you are, what device you're on, and sometimes all the way down to your actually identity, including Scarf as a dependency in my library caused a single HTTP request to fire off whenever anyone ran npm install on a project that included my library as a dependency. Scarf would then determine the location of the request, only to the resolution of the country, and attempt to deduce if the IP address belonged to a corporation, and then record the name of the corporation and the country, discarding the IP address itself.

My initial reaction to this idea was similar to that of most developers I have spoken to about it. Eww! Gross! That's creepy to have a library reporting to some third party every time I run npm install. The implicit contract when I run npm install is that I expect my computer to go fetch some metadata and possibly published library code from NPM, and NPM only. But then Avi explained that the long term goal of Scarf was to then approach these corporations to request financial support, and it was a novel idea to the seemingly intractable problem that this post is about, so I consented to give it a try.

The results that rolled in over the next few weeks were stunning. Microsoft, Google, Amazon, and Apple were all using my library! It was hugely validating and motivating. ...but it also made more salient the fact that, between Github Sponsors and Open Collective, the library was receiving a grand total of just under $30/month in sponsorship.

In the end, I'm glad that briefly had Scarf enabled as a test of open source analytics and get a feel for that avenue of attack on this problem, but, unlike all the Silicon Valley behemouths that are gaining value from my library, I cannot, in good faith, continue to force my consumers to give up any information about themselves in exchange for using my library.

NPM has all of these analytics, but does not share them. I think Microsoft, as the owner of NPM, is uniquely positioned to make a difference in open source sustainability via analytics.

What is the value of Open Source?

For the purposes of this discussion, I'm going to ignore that, on most platforms, most of the code all the way down to the kernel is open source. Let's start at the web app level. You want to build a web application that can receive Hypertext Transfer Protocol requests and return Hypertext Markup Language. Personally, I'm old enough to remember when web applications were actual compiled executables (or scripts) in the /cgi-bin directory that did exactly that: listened to a port for HTTP requests and squirted out HTML. If you had to start at that level every single time, double-checking the HTTP specs, to design your web application, you'd never get anywhere. The reason the web even exists is that it has been collaborative from the beginning, with people sharing their code and having others improve upon it, like Science in Academia.

If I want to build a single page app to track COVID-19 data, and building that included designing a charting library from scratch, it'd never get done. But there are a plethora of charting libraries out there that people have spent many, many hours building and perfecting, just given to strings attached. And so, I can whip up my COVID-19 tracking app in a day or two! Am I stealing from the chart devs? No, of course not. They posted their code to the public square and let anyone have it. Were I a thoughtful individual, I might be so grateful for their effort that I toss them a $20 bill in thanks for saving me 200 hours of work.

Where it gets a bit more morally murky is if my virus tracking app starts making $1M in monthly recurring revenue, and if the chart devs stopped maintaining their library, I could lose $100K in revenue, and then another $50K in development time to migrate to another library or try to build one in-house. The incentives are out of whack. It should be in ViralCorp's best interest to make sure that the chart devs are well compensated and not going to burn out or lose interest.

In no other industry would such large corporations depend so heavily on single individuals for no pay. Can you imagine a car manufacturer that gets an important cog in the engine from a guy down the street who just really likes making these cogs and leaving them out on this front porch in a "FREE, take as many as you want!" box, and has no backup plan if the guy keels over or decides to start making another thing? The accountants and shareholders would be shouting "OMFG RISK!!" from the rooftops. And yet that is how the software industry operates.

To me, the value of open source is in the time that it saves all of us to get an app off the ground and working. That profitable corporations should give back is a bit like corporations paying taxes because they built their business on the roads the taxes pay for... oops, bad analogy...they don't pay taxes either!

Donations are NOT the answer

This is the current model, and I don't even think this obvious fact warrants an argument.

The Spotify Model is NOT the answer

Some people suggest some system where you can pay $X every month to "some arbitrator?", and then every library in your package.json with 75 dependencies recieves $X/75 every month. This "by usage" model is how Spotify pays artists, and how Egghead pays its content producers. The problem is that this model incentivizes the tiny small utility, like the infamous leftpad, and disincentives complex logic that actually saves devs time.

Don't get me wrong; I love that I will never have to think about how to parse or format a query string ever again. I could write that function in a few minutes, but to write it properly with tests would be closer to an hour, and even then I'm certain I'd miss some edge case that I know for sure that query-string or qs has faced and addressed.

That said, a function that takes a string and converts it into an object does not deserve the same compensation as a complex calendar widget. I challenge you to find a website that doesn't contain some code from Sindre Sorhus. He deserves $1M in annual recurring royalties, but not $1B.

So if we can't divvy it up evenly, how?

There's the rub. I guess it would have to be by which libraries the devs that use them appreciate most. What I'm suggesting is that companies should provide their devs with "gift vouchers" or some sort of credits for them to distribute to open source libraries. Open Collective already supports vouchers, but I don't see why the Github Sponsors program couldn't create "GitBucks" or something. I think Microsoft, as the owner of NPM and GitHub, is uniquely positioned to make a difference in open source sustainability via gift vouchers.

Licensing is NOT the answer

A startup approached me recentlly, offering to handle all the recurring billing and access restriction for me to have two versions of my library, one free and open source, and a second one with more features that required a license to use. I listened to their spiel intently and then pointed directly to the Emperor's exposed genitals: "Who enforces this?" Their answer was, "Yeeeahhh, well.... it's up to the library consumer's internal legal team to remember that they have to pay you, which is why we only expect about 2% of your so-called 'paying' customers to actually pay." Wow! Roll. On. The. Floor. Laughing!

If I switched from MIT to GPL tomorrow, 80% of people wouldn't notice, 19% wouldn't care, and the remaining 1% would dump my library and migrate to another free one with a slightly worse API and larger bundle size, and yet, 100% would hate me. Open Source Licensing is a joke, at least as it currently stands. I wonder if Microsoft, as the owner of NPM and GitHub, is not uniquely positioned to make a difference in open source sustainability via licensing?


It doesn't take a report from the Ford Foundation to see that the status quo is broken; it sucks for the little guy, and it sucks for the corporate capitalist that's taking advantage of him even if they don't know it yet. I don't really have a solid course of action to suggest. I guess it's about awareness raising and asking your boss for some funding to go to libraries you use; you can frame it like insurance: you hope there's never a disaster, but you pay a little every month so that, if/when the disaster happens, it's not so bad. If anyone can think of a corporation uniquely positioned to help fix this, problem, let me know.


Editor guide
codemouse92 profile image
Jason C. McDonald

Eric Raymond, although I've lost all respect for him as a human being over his bigotry, did write the watershed work on this topic, to wit, The Cathedral and the Bazaar (the book), for which we (sadly?) have no comparable works. In the essay therein entitled The Magic Cauldron, he addressed this exact problem, and suggested several solutions.

Some of those have proven fairly effective in my experience, looking at the industry:

  1. Offering commercial licensing. You license the open source code under GPL or another restrictive free license. The Qt Company is one example of this. If your usage complies with the terms of the open source license, you can use it as such. If you cannot, you have to pay a license fee.

  2. Free the source, sell the support. Canonical and Red Hat do this, and it works out well for them. Anyone can use Ubuntu or Fedora, but if you want their help with stuff, especially in a commercial setting, you pay them for that.

  3. Free the source, sell the content. This works when you can make the source code open source, but the compiled version with the extra content costs money. Some games are like this.

  4. Free the source, sell the service. This works when your tooling is free, but access to your servers, API, or what have you costs money.

netanelmohoni profile image
Netanel Mohoni

As the CEO of xs:code - I totally agree with you :-)
I strongly believe that these models are the answer, so my team and I started the company to solve the OS sustainability and help developers monetize using these (and other) models.
Let's talk!

netanelmohoni profile image
Netanel Mohoni

The ongoing maintenance and growth of open source projects are clearly in the best interest of the software companies using them. And yet, raising money for an open-source project is difficult, and many developers struggle with finding the right sponsors for their open source projects. What is the best way to get the resources open source developers need to keep developing? here's an article I wrote about how to find the perfect sponsor for your opensource project:
Check it out.

pomber profile image
Rodrigo Pombo

Great read Erik.

What I'm suggesting is that companies should provide their devs with "gift vouchers" or some sort of credits for them to distribute to open source libraries. Open Collective already supports vouchers, but I don't see why the Github Sponsors program couldn't create "GitBucks" or something.

I think this is the most realistic path to make companies contribute a bit more to open source. Quoting myself:

I really like the concept of Open Collective gift cards, where the employer puts the money and the employee chooses the projects. Many companies give their employees a conference/training budget, so why not make OSS financial contributions part of that budget too?

-- from this post

sebastienlorber profile image
Sebastien Lorber

But how to make this happen.
No one wants to be the only company paying (unless there are marketing reasons). Giving 100$ to a project won't make it sustainable, we'd need to force companies to give those vouchers somehow, and ensure that others get "punished" if they don't.

What about crowd funding lib's versions? Like v1 is released, there are a few issues, now contribute to the v2 campaign or nothing will happen.

bernhardwebstudio profile image
Bernhard Webstudio

It distantly reminds me of e.g. Unity assets you have to pay for. Npm could become a Code marketplace. Problem would be that you would have to turn GitHub into a Code marketplace with it, otherwise another tool would emerge compying the code from GitHub. Also, some way would have to be found to prevent a simple clone of the code from being distributed freely... you cannot secure code using e.g. DRM

jsjoeio profile image
Joe Previte (he/him)

Great write up, Erik! I’d be curious to hear your thoughts on the Sponsorware approach. It doesn’t address the issues with big companies and open source, but I wonder if it could help with the funding.

benjam profile image
Benjamin Nickolls

great post, some points and a prompt:

pay $X every month to "some arbitrator?", and then every library in your package.json with 75 dependencies recieves $X/75 every month.

100% this will not work, but I disagree with your 'libraries devs appreciate the most' idea. I think what we're already seeing is that a small number of libraries with more exposure are starting to attract even greater support. People tend to pick the winners.

We could go down the line and say that there might be an algorithm that takes into account the cyclomatic complexity, usage and a dampening factor for current level of support. I would love to get there, and I have tried and failed in the past.

More and more I am thinking in terms of sustainability as a community of projects, rather than treating each project in isolation. Given the current programmes we have some projects will 'win' and others will lose. But what if we use that fact that some projects have that exposure and are able to generate 'revenues' (whether in paid for services, support or donations) to create a a sustainable future for themselves and those that they depend on? At what point should OS projects begin to support other OS projects?

wolverineks profile image
Kevin Sullivan

what were the arguments against using scarf?

erikras profile image
Erik Rasmussen Author

Basically just around the "implicit contract" I mentioned in the article. It feels "dirty" or "shady" or "creepy" to have a library force your computer to upload information about you (minimal as it may be) to anyone. The irony, of course, is that you're trusting NPM with this knowledge...basically as a requirement, since they have a monopoly in this space (No wonder Microsoft liked them! 🤣). Also, nothing about the npm install build process is secure. There's nothing stopping a library from adding a postinstall script that uploads ~/**/* to a server somewhere, and now you have no privacy. None of us are running our npm install commands from some permissions-restricted account, aside from the CI vendors.

wolverineks profile image
Kevin Sullivan

whats your opinion on? are either of those deal-breakers?

  • explicit / no opt out
  • explicit / opt out
Thread Thread
wolverineks profile image
Kevin Sullivan

and what would an acceptable opt-out mechanism?

  • go into node modules and flip a toggle?
  • 2 npm packages?
  • a branch sans scarf?
samsch_org profile image
Samuel Scheiderich

Hey Kevin, here's a write up of the main issues.

I acted as point person for pushing to get scarf dropped from libraries, so I'm an explicitly biased source. However, I did drop this for some review in the discussion channel on Reactiflux where a lot of conversation about this happened.

cra profile image
Chris Aniszczyk

I wrote about this last year:

At the end of the day, I think there is a difference between an open source project and a product. Most developers are currently building projects that are widely used, these aren't the things businesses traditionally want to buy. There's also the cruel reality that the market may be telling you something about the monetary value of your work :/

raphink profile image
Raphaël Pinson

Nice summary. I've tried GitHub sponsors myself, and so far have one sponsor (which I'm thankful for!) for Open Source contributions that I know is used by hundreds of large companies.

After reading a blog post on that subject yesterday evening, I just wrote an article about the idea of integrating a Sponsorware approach into

thtmnisamnstr profile image

I'm a marketer, so I'm planning to use GitHub Sponsors differently than intended. My team wants to award hackathon winners; give larger, 1x sponsorships to devs and projects we use or want to support; and generally use GitHub Sponsors to encourage engagement in open source work we care about.

This isn't directly related to open source sustainability, but I wanted to get opinions on this. Is this type of approach a net positive for open source?

jcolag profile image
John Colagioia

The big problem I see in the (important, no matter how pessimistic I sound) conversation around Open Source Sustainability is the "build it and they will come" mentality, the idea that, if we write useful code and make it available under licenses that allow big companies to yank it behind a paywall, they're going to finally realize their obligation to the community and Open Source developers around the world will be sitting on fortunes for their altruism.

The reality is that the big companies might hire a couple of developers to get what they want without training someone on their team. But after thirty years of explaining to lawyers that the BSD/MIT-type licenses mean that they can pretend their programmers wrote the code and not need to issue a purchase order, they're not going to spend money on software everybody can get for free.

That's one of the reasons I've become a copyleft hard-liner, even though I'm not producing anything important: If you want to pretend the code is yours or if you want to make changes that don't get pushed back to me, you need to negotiate with me for your own license. Otherwise, you're constrained by the AGPL, because I'm not interested in working for Apple without a salary...and probably not with a salary, either.

I keep wondering, though, if the flaw in "sustainability" is in assuming that it needs to focus on money. Don't get me wrong. Money is important to things like not starving. But in insisting that a sustainable system is a well-funded system where people quit their jobs, it seems like people are just creating companies that require design, marketing, sales, support, and accounting, leading the founders to burn out from the strain of trying to get money from other Open Source projects (the most likely entities to appreciate the work) to, in part, pay other Open Source projects.

I don't know. It often feels like we confuse hobbyist Open Source with "follow your dreams (and live off your savings)" Open Source and (worse) commodify your complements Open Source, and the result is a twisted mess where people are trying to figure out what's stopping the Big Five (Amazon, Apple, Facebook, Google, and Microsoft) from showering us all with money, since they all love Open Source.

Unfortunately, I don't have any legitimate solutions, beyond the deeply unsatisfying, "get a job, Hippie" accidentally implied by my rambling...

alexanderwende profile image
Alexander Wende

Great post Erik. I agree with a lot of the problems you describe here.

Just a few days ago, I posted an article about funding in open source here on as well. I wanted to know how the open source community feels about the current situation and started a survey on the topic of open source funding. Maybe you want to check out the survey:

miketalbot profile image
Mike Talbot

Very interesting, I just can't see me convincing my CFO to pay anything for something that has no contract of support associated. I can pay and the library could still go unmaintained.

Off the top of my head and with only a passing thought, how about a business based stewardship of library forks - paying the original developer if they continue to support it or using a pool of resources to continue if it goes unmaintained? Not sure I'd be happy to have my MIT libraries making other people money as a corporation without any real modification though.

wolverineks profile image
Kevin Sullivan

Are there currently any attempts at a spotify model?

sarajohn profile image

Your post is very informative and good suggestions :)

montogeek profile image
Fernando Montoya

Thanks Erik for this post!