DEV Community

Cover image for Open Source Sustainability
Erik Rasmussen
Erik Rasmussen

Posted on • Updated on

Open Source Sustainability

This post has moved to erikras.com.

Top comments (22)

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

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.

Collapse
 
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!
xscode.com

Collapse
 
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

Collapse
 
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

Collapse
 
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.

Collapse
 
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:
blog.xscode.com/736/the-right-spon...
Check it out.

Collapse
 
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.

Collapse
 
thtmnisamnstr profile image
Gavin

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?

Collapse
 
wolverineks profile image
Kevin Sullivan

what were the arguments against using scarf?

Collapse
 
erikras profile image
Erik Rasmussen

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.

Collapse
 
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?
Collapse
 
samsch_org profile image
Samuel Scheiderich

Hey Kevin, here's a write up of the main issues. gist.github.com/samsch/c38f3109701...

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.

Collapse
 
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 dev.to 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: opensourcefunding.github.io/

Collapse
 
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?

Collapse
 
cra profile image
Chris Aniszczyk

I wrote about this last year: aniszczyk.org/2019/03/25/troubles-...

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 :/

Collapse
 
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.