Peter Krautzberger on the web

Privilege-based Open Source

(Another one from the drafts.) A while back I ranted on twitter about privilege-based open-source and Patrick Honner asked me what I meant with it.

A surprisingly large number of open-source software (OSS) projects is run by volunteers. And I don’t mean that “hello world” code you pushed to GitHub (which probably makes up 99% of all OSS repositories), I mean the many successful open-source projects that provide the fertile soil other (small and large) software projects are built on.

In other words, the majority of OSS is run by people privileged enough to spend hours on end to produce something that they then give a way for free. Whether or not OSS developers do it out of conviction, it’s often a problem when people end up using privilege-based OSS without realizing it.

Houston, we have a problem

The most obvious problem is that privilege-based OSS can essentially go away at any moment. You don’t have to look to extreme cases (left-pad, anyone?) to see this happen; projects simply slowly die. You might praise OSS for the fact that anyone can pick up the code and fork it if need be, but in reality dead, privilege-based OSS is more like an unfinished construction site; it’s easier to start from scratch and thus the cycle repeats.

However, this is so obvious, it’s not really a problem, I think. In any case it’s not what I mean.


There’s a lot to be said in favor of developing OSS out of conviction. It frequently helps people and adds diversity to the ecosystem. The trouble is that privilege-based OSS can be highly toxic.

One toxic variant is “Silicon Valley style OSS” where developers do not act out of conviction but more out of necessity to get ahead in a questionable job market (“GitHub is your resume”-kind-of-thing). If your hipster company hires people only due to their volunteer OSS credentials, then you are effectively hiring them by their privilege, creating a toxic environment and reducing diversity.

Reversely, you have the toxicity of people relying on OSS software not being willing to contribute to the development of OSS because privileged people make it work. Just the other day I was talking with a potential client who described how they use pandoc in production. If you do this at scale, then you’re basing the integrity of your production workflow on how much John MacFarlane could procrastinate over the years.

For OSS developer, this can turn into a toxic reality because users often think they deserve access to the developer’s privilege. That is, they can become highly aggressive when they find a bug in the OSS software they’re using, especially when it impacts them. This gets extreme when we’re talking about companies and use of privilege-based OSS in production. Company employees quickly try to exert pressure on OSS projects to fix things – yet refuse to actually contribute to development any which way or even acknowledging the work that went into a piece of software that they themselves chose to build upon.

Obviously, there are other ways of doing OSS software development. There’s transparency-driven OSS (e.g., security related tools, browsers), there’s shared-burden OSS (e.g., joining forces to lower costs), there’s donation-based, crowd-sourced, and bounty-driven OSS and many others – Nadia Eghbal lists a few in her lemonade-stand on GitHub. Also ask about governance models.

Long story short, if you’re using open-source software, especially in a professional context, make sure to check what model it’s based on. Also, don’t be toxic.

Reading list

These thoughts were far from original.

Wider scope