Earlier this week, Rip quietly made its way into the world. It's a "next generation" Ruby packaging system, clearly meant to both work around some of the problems with RubyGems and also introduce some fresh ideas of its own. If you want to immediately jump and learn more, check out the official About us page for a tour.

Rip comes from the Github and Sinatra stables with the primary contributors being Chris Wanstrath, Jeff Hodges, Tom Preston-Werner, John Barnette, Blake Mizerany, Ryan Tomayko and Pat Nakajima. This is no "crazy renegade" project, although the developers are keen to stress the existing version is only a "development alpha" to be tested and built upon - not used in production.

Rip has a number of compelling features that make it worth considering for the future. Firstly, it provides another level of abstraction above existing RubyGems, Git repositories, and file structures, in the form of packages. It also supports the creation of virtual environments that can exist simultaneously but wherein different sets of libraries can be installed. Taking a cue from Git, Rip is also decentralized. There's no canonical server for Rip packages - they'll be retrieved from wherever the library developer specifies. This means you won't be able to do anything quite as simple as gem install library, but we're already used to using URLs for other forms of content, so why not library files?

Basically, Rip's a new tool with a whole new way of looking at Ruby packaging and library distribution, but it has a killer team behind it, some solid ideas, and it could well supersede RubyGems in many ways in the near future. We've had rapid tool switches before in the Ruby world (think how quickly Git became entrenched) so I wouldn't be surprised if Rip becomes a big deal over the next several months..

Also worth seeing.. Beginning iPhone Programming Workshop For Rubyists. A companion class to the FutureRuby conference. Toronto, July 9-10, $1200 $699.