The Future of Ruby Library Distribution: The Gemcutter Interview
When GitHub phased out Ruby Gem building a few weeks ago, they recommended the Gemcutter project as a replacement Gem host for folks who weren't already using the default source, RubyForge. The big news earlier this week is that the RubyForge and RubyGems teams are also getting behind Gemcutter, which will become the default gem host for the entire Ruby community (as rubygems.org).
To shed a little more light on the nature of these changes and what they mean for the future of Ruby package distribution, I sat down with Nick Quaranto , the original creator and maintainer of Gemcutter.
NP: Can you tell us briefly about how Gemcutter improves upon the existing RubyGem distribution system that's currently in place?
NQ: I started Gemcutter off around the time when I was just getting into publishing gems for Jekyll. It seemed to me that RubyForge, although it’s the center of our community for getting gem releases, was starting to feel outdated and no one really was motivated to improve it. From a gem publisher’s standpoint it did work, but approving your project took a while (this was fixed recently), and it took even longer for your gem to be published. I also felt that a much better job could be done for making a real home for gems so developers didn’t have to waste time making special project pages or documentation sites.
GitHub was another great option, especially since it allowed a hands-off way to publish personalized gems. However, there was something about the user namespacing (qrush-jekyll for instance) that causes confusion to those new to the community and also for projects with lots of forks.
I saw this missing part in our community for a better gem hosting service that could that could be fast, written in Ruby, and would actually assist in both publishing and finding gems. I think Gemcutter has lived up to that so far.
NP: Gemcutter itself is a very different service than RubyForge, much more streamlined and simple. Will some of the RubyForge features ultimately find their way into Gemcutter? Or will they continue to be separate but complimentary services?
NQ: I'm going to try my best to keep some of the "bloat" that RubyForge had away from Gemcutter. Personally, I would like to see more human-centric features in Gemcutter, such as a recommendation system for gems. The great part is that we can actually implement these and try them out now since it's all in Ruby.
There's been some recent discussion about features that the community may still need on Tom Copeland's blog, even as a backup or alternative to other popular services as GitHub or Google Groups. I never intended Gemcutter to kill RubyForge as a whole, and I think some parts of the site will be necessary to maintain going forward. The bad parts should be pruned away, and I think it's great that Gemcutter has been a catalyst to do this.
NP: It's (almost always) difficult to supplant an existing system with a completely new alternative implementation like this. Can you talk a little bit about the process of working with the RubyGems / Ruby Central team and any obstacles to adoption that were encountered in your discussions?
NQ: My motivation has been to make the experience of using the site awesome for developers, and that alone would draw them in. I knew from the start simply talking or blogging about my idea would do nothing compared to coding and getting the site out there, and getting feedback from fellow developers has helped immensely. As for approaching the community leaders with the proposal to take over RubyForge's gem server, I think the largest factor was to really show the purpose of the site was a positive change for every Rubyist going forward.
NP: So, you've taken advantage of the (relatively recent) RubyGem Plugins in a pretty ingenius way to bootstrap adoption. Can you describe to our readers how this works? Do you think this (the fact that newer RubyGems versions are required) is a barrier to adoption when the time comes for the official switch? Or a good motivator to get people to modernize.
NQ: Gemcutter uses a neat feature that's in RubyGems versions 1.3.3 and up that allows gem authors to add their own 'gem' commands. Basically, this allows developers to use "gem push mygem-1.0.0.gem" to release their gem to Gemcutter. I don't think it can get easier than that to release their code.
I think upgrading RubyGems shouldn't be too much of a problem, especially since it's built in with `gem update --system`. The main issue seems to be really old versions of RubyGems and some OS distributions that don't play nice. The Gemcutter gem plugins will be getting merged in RubyGems soon to make them available to everyone and lower the barrier to gem publication even further.
NP: What is the timeframe for the official turnover? And what specifically do gem developers need to do to prepare for the transition?
NQ: We're shooting for RubyConf, so November 19th. The current plan is encourage gem developers to upgrade RubyGems to get the built-in plugins instead of using the Gemcutter gem, which will basically be deprecated. As for gem consumers, nothing much should have to change. All 3 available indexes (http://rubygems.org, http://gems.rubyforge.org, http://gemcutter.org) will be pointing to the same place once the transition occurs.
NP: Unlike RubyForge, Gemcutter is an open source project. I feel like this is an important thing, for a critical community resource, to really have the power to make real change in the infrastructure we all use. Care to elaborate on your decision to go this route?
NQ: I knew from the start that this should be an open, community effort to improve a core part of the Ruby world. I'm really glad that we can now use Ruby to improve and adapt this core part of the Ruby ecosystem.
As for managing contributors, I've modeled Gemcutter after the Rubinius project: anyone who has an accepted patch can ask for commit access to the main repository. I think this really instills a sense of trust and better communication amongst the lead developers of the project, and it serves to lower the barrier for jumping in even further. So far we've had over 20 contributors, and I'm sure that number will only go higher as more developers use the site.
NP: GitHub's position as a RubyGem host was unique because it was an easy and immediate workflow to fork pre-existing gems and create your own. Will Gemcutter be supporting gem forks, and if so, what is the strategy (and timeframe) for implementing that?
NQ: I think it's up to Gemcutter to provide a way to support this same workflow. We currently support gem forks in the GitHub fashion, since once you push up a gem, say as 'someuser-somegem', that namespace has been reserved for you to use. However, I feel this style is flawed, and after much deliberation on the subject the solution I've settled on is to allow users to register subdomains. The subdomains would start off with a blank gem index that the user can push any gem they'd like to.
Subdomains come with a new set of concerns, however: if you're installing/using a gem from a subdomain, it must be something you can trust completely, since it may have custom modifications or tweaks. The general idea is that if you should be lobbying to get your changes back into the main gem, and if not, consider breaking off the project into something separate so as not to confuse future users. This problem is a lower priority compared to the RubyForge transition and migration of user accounts right now, and I hope to focus on it again once that's done.
NP: What do you think the biggest challenge is with the future of gems and Ruby library distribution in general?
NQ: The biggest challenge is not going to be a technological one, but it'll be a social one. There's been a lot of innovation even in just this past year in the RubyGem ecosystem, and I feel developers should be working together on making Ruby more enjoyable for everyone. Improving RubyGems and making sure it meets the needs of the community will be essential going forward, especially since it's included with Ruby 1.9.
Thanks to Nick for taking the time to answer our questions, and congratulations to him and the other contributors for this accomplishment. For more information on the Gemcutter project and the status of the transition, see the official Gemcutter project page and wiki on GitHub.