Does 'Open Source' Lack Proper Gate-Keeping?


I was in a chat with Xah Lee and we ended up talking about “open source” for a short while. The trigger was that he shared quotes by Richard Stallman, one of which boiled down to: packages outside of GNU’s own package repository are not really part of Emacs.

I appreciate the context of the quote: folks should be preserving packages by putting them under the GNU stewardship. Then there’ll always be at least access to the package from the foundation’s maintainers. This should help prevent dead packages without updates for 10 years and no merged patches/PR’s. That’s a heart-warming idea.

What I cannot get behind is the dismissive implication that the world-wide ecosystem of hobbyist contributors sharing stuff on the web is “not part of Emacs”.

I mean, technically that’s right, their stuff doesn’t ship with Emacs. But I take “being part of” as a phrase of identifying with Emacs. Like fans of football (soccer for the less civilized folk) clubs identify with “their team”, even though they cannot kick a ball into the goal successfully if their life depended on it. So they are clearly not part of the football team of players. Yet they are part of something that’s closely associated, part of the fan base. And the team usually appreciates the dedication of their fans. There’s interaction between these groups. – In this sense, RMS’s statement sounds dismissive because it plays down the importance and impact of all the experiments that happen in code bases all over the world.

That’s where the chat between Xah and me started.

Open source culture changed

I really hope that Xah Lee writes up a linkable blog post/essay/article with his position so I can properly connect the pieces of the discussion for context.

Until then, since I don’t want to quote someone by their abbreviated chat messages, here’s my understanding of two larger branches of topics he brought up that could be totally missing his point:

  • Corporations benefit from open source (without paying back) and have incentives to get more people to do more work for free.
  • The open source culture changed for the worse
    • It used to be that ‘hackers’ knew how to code and appreciated all the work involved in maintaining and creating stuff.
      • This is associated with knowledge and respect of the craft.
    • GitHub trivializes collaborating on code.
      • Instead of knowledgeable hackers, you now have laypeople messing around.
        • Respect is gone, because everyone’s a contributor now?
      • GitHub made forking easy by prominently placing “Fork” buttons everywhere.
        • “Forking” used to be considered rather rude.
        • Now you’re encouraged to take code by forking any time.
        • This reduces respect.

There’s probably way more I’m missing in the outline, but it’s a chat, and it’s hard to elaborate there.

The “it used to be that only hackers contributed” line of thought sounds elitist to me. Again, I could be missing nuance. Let me explain why I think that’s an elitist position, how gate-keeping comes into play, and why I ultimately think it’s irrelevant.

It is elitist to wish the old days return by re-installing hurdles

What’s making it elitist?

  1. For one, it’s not just a description of a change of things. This is mostly a description: it used to be just hackers, now everyone has internet and a computer and clicks around on GitHub.
  2. But here, value statements are attached: the way it used to be was better. Now it’s worse, not just different.
  3. What makes it worse? The forking and lack of respect for the craft. What was the basis of respect? You had to know a lot more before you could participate. (E.g. send patches on mailing lists that nobody knows how to operate nowadays, and hope the maintainers apply your patch.) Now code is widely accessible.

The last point gives it an elitist spin: it’s not good that it’s simpler to participate. Knowledge and skill hurdles are/were useful. It’s bad that they are gone or lowered.

A term for this is gate-keeping. There clearly is value in gate-keeping in general: e.g. I wouldn’t want to hire the next best applicant for a job that requires skill, I want to screen applicants first and see if they fit, and gauge what they can achieve at the moment, then pick the best. There’s no point in demanding that anybody should have a chance at getting a particular job; there are requirements, formal and informal, that have to be met. So not all gate-keeping is bad. (Flip side: Not all gate-keeping is good, either.)

The open source love story of Marko

I personally think gate-keeping is not useful in the case of open source contributions, though. I applaud that my friend Marko now has a GitHub account and maintains a JavaScript plugin for a digital table top gaming system. He’s not a certified programmer, he’s a recently self-taught JavaScript/FoundryVTT author. People who want to help him improve the plugin aren’t coders, programmers, hackers, either – he gets PR’s on GitHub from laypeople who cobbled together something with questionable quality and style. I’m happy to help him figure out conventions of what’s useful, what helps keep code maintainable, and how to deal with GitHub PR’s that do 10 things at once but of which you only want to keep 2. It’s amazing that complete strangers self-organize on the internet to create this together.

Now that he tasted blood and enjoys the fiddling and customizing and coding, I’m pretty sure he’d continue maintaining his plugin if GitHub would shut down and people moved back to mailing lists. It’s more effort. It’s harder to keep taps on things. – There’s a reason online issue trackers evolved; they help organize stuff. And if nothing else, GitHub makes it easy to see patches/PR’s in context. Not every email app would be able to show patches or diffs properly. It’s way less convenient. And thus Marko might stay, but lots of other hobbyists might abandon ship because it’s too weird, too much trouble, whatever.

Modern tools make it easier, and thus make it possible to reach more people. In other words, it’s less scary to try to contribute in code.

Gate-keeping is a valid option for every project

I’m reading Working in Public, but didn’t yet process the book to take notes. It’s a treasure trove of citations I’d like to use in this context, but I’m keeping it vague for the moment until I had the time to extract all that.

In the book, maintainers of a popular open source repository eventually moved to GitHub because it was ‘expected’, since everyone used that instead of mailing lists. It doesn’t matter which repo that was. It’s just a stand-in for a compromise people make.

The compromise is: do I want to keep the process ‘pure’ and bare bones, or do I want to onboard more people? If I want more contributors, then I’m incentivized to use a popular code hosting platform. Nobody’s forced to do it. If you want to screen for 1337 haxx0rs, don’t use those platforms. So there is choice, and you as a maintainer can decide. Do you want to identify with people who self-compile their programs, or do you prefer to get more input (but also have more work dealing with that) by a more diverse range of people?

For example, org-mode’s code is self-hosted on a platform with similar convenience to GitHub and GitLab at Then there’s the updates overview site that aggregates mailing list messages, including support inquiries, but also [PATCH] and [BUG]-tagged messages that live outside of the self-hosted code platform (where issues, PR’s, etc. are disabled.)

Ironically, by the way, the self-hosted git app they use, Gogs, hosts its code on GitHub. Unlike GitLab, which dogfeeds its application, but also keeps a mirror on GitHub for whatever reason.

GitHub dominates, but it’s not the only thing that exists. Its dominating role makes it more likely that interested would-be contributors are well-versed working on GitHub and have a tough time sending you patches via email. With its critical mass, GitHub’s pull only gets stronger.

My personal values regarding all this

This is a blog, not a formal essay, so here’s my opinion.

I think the new tools produce a good change in the culture. They enable stories like Marko’s, where laypeople can collaborate and share the love for their hobby and get more proficient in the process. The learning curve has flattened a bit.

Since I like to code, and since I like to share, it pleases me that other people can do the same.

And I think that’s all there is to it: preference. We can choose which kind of collaboration we want.

Mailing list-based collaboration isn’t dead. It just pales in comparison to GitHub traffic. If you potentially want that level of attention, use popular platforms. (It’s the same with posting videos on YouTube vs other platforms. Your potential for more eyeballs is higher on YouTube.)

None of this implies that I’m okay with an attitude of entitlement towards maintainers. There are plenty of open source stories where strangers walz into a GitHub project page and demand changes to the code for their use case, then get angry and flame maintainers if nothing happens for a while. This is a flip-side of not appreciating the effort anymore. Angry trolls were on mailing list in the 90’s, too. Everyone with an email address can make a GitHub account and begin complaining. This is a problem we collectively need to figure out how to solve. It’s annoying, and maintainers who are affected by this can become disheartened. I do not think this is deserved; but it’s not easy to grow such a thick skin that you can shrug off the complaint and delete reactions like these.

Is there a problem gate-keeping would solve?

Say you maintain an open source project since the 1980’s and don’t want to change infrastructure. There’s nothing stopping you. You’re not inviting everyone and their grandmother to contribute by making browsing, reading, and patching the code less convenient. Your call.

Let’s return to the metaphor of football clubs and their fans: it doesn’t hurt the team if their fans put on their football dresses and meet once a week to kick a ball on a field. It’s amateur sports at best, it’s not pro football. It’s not the real thing, the thing that’s valued highly.

If laypeople can assemble projects on GitHub and invite similarly unskilled friends to participate, who’s being hurt?

Some pros and amateurs are using the same tools. (Same with ball-kicking, actually.) Doesn’t make the tool any worse. Your owning a good Japanese saw doesn’t devalue a carpenter’s saw.

There appears to be no real problem the way I understand things.

Am I missing something?

Are there other important factors I blatantly overlooked?

Please share in the comments below, respond via email, or on your own blog and send me a link.

Receive new .