litany against fear

coding with spice ¤ by nick quaranto

On Gem Forking

published 09 Oct 2009

So, GitHub has recommended Gemcutter as an alternative to hosting gems on GitHub. Of course, there seems to be an outcry, for three main reasons that I can see:

1) Effort must be made to move documentation and install instructions
2) Gem forking is not possible with the new site
3) GitHub gave no warning on this

As for #1, you’ve got a year to update your user base and get gems off GitHub. I’d assume that any actively maintained project has figured Gemcutter out by then. And for #3, at least we’ve got a new service that works and can meet the same needs.

Regarding RubyGem forking, I’d like to state that this statement is false. Gemcutter accepts built gems, so you simply need to mimic the actions that GitHub’s gem builder did: Open your .gemspec up, append your username to the gem name, and save. gem build, gem push, and done.

I think an important distinction must be made here: gem forking != scm forking. GitHub made it easy for anyone to automatically push modifications to gems, but there’s a bigger picture to think of here. Hopefully at some point, the changes you made will be brought back into the mainline gem. As David Dollar so eloquently puts it:

I think the general idea is that gem forks should be a huge special case. I’m somewhat of the mind personally that making gem forks too ‘easy’ causes a great deal of unnecessary fragmentation in the community. It seems reasonable to me, that if your project is going to depend on a gem fork, that the dependency resolution not be automatic, and your installation instructions can tell the user how to get the forked dependency. If a fork is going to be long-term, or a true alternative, it should probably be reregistered under a new name as a different project.

Like I stated above, ‘gem forking’ is still supported just because of the nature of how Gemcutter works. I felt there needed to be a longer term solution for this in general, since now the community has grown used to it. This lively discussion ensued, and after some deliberation we’re going to use subdomains in order to solve the problem.

The idea is this: you’ll be able to register your own subdomain on, such as, and we’ll give you a completely blank index to push to. Hopefully you’ll be able to add others like the gem owner system works now. I feel this feature needs to be used in the following ways:

1) Subdomain use should be infrequent. It’s for trial/forked gems that shouldn’t be relied on for production.
2) Use prerelease versions for development snapshots (version numbers like 1.0.0pre, gem install yourgem --prerelease)
3) Don’t add someone’s subdomain as a source, unless you can completely trust anything they toss there. (like, your own for example)
4) Consider as the main, canonical repo that you can trust.
5) Start looking into gem signing/cert since it’s the way we can really trust gems

Of course, none of this subdomains stuff works yet, but it seems like the best way forward. It’s also spawning new, awesome ideas like password protected, private subdomains. If you’re interested in contributing to the project, please fork away or hop in #gemcutter on Freenode to see what’s happening.

This is our gem host now, let’s make it awesome.

email twitter github