Long term…

If the "only" thing which comes out of the #Ruby Central debacle is we end up with officially decentralized gem hosting along with namespace support at the package level,

that's actually a huge win.

But I'm positive we're going to see other innovations.

It's a lie that growth only comes from top-down BDFL-style orgs. Not only that, it's often the opposite. Innovation comes from—oh yeah, here we go—diversity.

Ever heard of Loose Coupling? Works for culture not just codebases.

@jaredwhite
> decentralized gem hosting along with namespace support at the package level

We already have it. Host your own small index. Gems are namespaced to `source`.

@pointlessone
That’s not entirely accurate, at least regardless to what I think @jaredwhite ment with namespaces.
Say you have two sources A and B and a gem named G hosted on both of them. These gems might totally different. Say you have a different gems J and Y both with a dependency on G. Which do they mean, how can we use both G(A) and G(B) at the same time?
AFAIK, there’s work done to get this using Namespaces. But we don’t have it yet.

@fnordfish @jaredwhite Yeah, I see what you're saying but until we get Namespace in Ruby there’s no way to implement gem namespaces.

The main issue is that gem namespaces have to be globally unique in order to avoid collisions you described. Two sources can have same namespaces in them and gems with same names in them. That is, you still can have ns/G(A) and ns/G(B).

Sources as gem namespaces is kinda the best we can have as URLs are unique already.

Granted, this messes a bit with mirrors and caches (e.g. Artifactory) that assume only one source exists. Caching proxies are still immediately useful. Mirrors can solve this by hosting multiple sources at different URLs. E.g. gem-mirror.com/rubygems/, gem-mirror.com/gem-coop/

@pointlessone yah. Let’s see what will happen.
But I agree with the notion, that this debacle might be just the right push we need to get this done "the right way"