pupdates

Communities build out, not up

This is an expansion of On RubyGems & Governance. I recommend reading that first.

As I said in that post, I think this is the lesson to take away from recent events:

A system that assumes everyone is on equal footing, when placed in an environment where that is untrue, becomes a repeater for the inequalities that surround it.

And this is how we can act on that lesson:

Many programmers have no interest in formal governance processes, but letting people act and speak on our behalf without our input is what got us here.

The path forward is for the community to speak up and take direct ownership of what we make.

To put it another way: we should trust each other, but we need ways to act on that trust being broken that aren’t just going “what the fuck just happened?!” and rebuilding from the ground up.

Centralization is Dependence

To be blunt: we shouldn’t be relying on one specific group, and this explicitly includes any group I bet my reputation on.

Centralization makes this problem more likely to repeat, no matter how hard we try to defend against it, because a single group is easier to target than a dozen. Anyone who tells you otherwise is naive or benefits from your dependence.

The Ruby community is not a cohesive whole, it is a collection of many disparate groups that share ideas and technology. This is both our strength and why our conflicts get so loud. We have more “drama”, but we also reconcile and grow.

The technology we use needs to reflect this fact, not fight it.

Dependence is Vulnerability

I’ve seen a few people claim that additional gem hosts would “split the community.” But we already have multiple gem hosts. They tend to be run by companies that are using Ruby, but not releasing their code as open source.

However, the problems of centralization have been known for years. If you search rubygems.org for version:9001.0 you’ll find hundreds of gems that exist purely to avoid dependency confusion.

Dependency confusion is a side effect of RubyGems and Bundler not handling multiple sources well.

Companies are taking defensive action here because there is a high risk.

We’re trying to solve existing problems, not add new ones. So, while I want us to eventually have multiple community gem servers, I also want to be confident we’re installing what we intend.

We have some work to do

These are the problems that stand out to me:

  1. We need to figure out how to assign namespaces across multiple gem hosts, and it needs to work even if a gem host acts maliciously.
  2. We need to figure out how to determine an authoritative source for a gem, and a gem host shouldn’t be able to lie about it.
  3. The Gemfile and gemspec formats need to have support for these.
  4. The Gemfile and gemspec formats need to be standardized, so other tools can use them.
  5. These standards need to have well-defined behavior for dependencies without a specified namespace.
  6. RubyGems and Bundler need to support all of this.

There’s probably other problems, as well. If you write about them, let me know, and I’ll add a link here.

I want the community to rally around these ideas and all of the groups supporting them, not one specific group.