As the lead for one of the most dependency-heavy packages on RubyGems,
I'd just like to say that its totally solveable to create packages
that work both in gems and non-gems form. Rails is always released as
both gems and as a tgz package.

With all due respect to the repackagers of the world, I share Austin's
ambivilence about the desire to "upgrade" living projects in order for
them to fit under some repackaging scheme. From my experience dealing
with the consequences, it only brings on another world of pain when
you have multiple packaging schemes layered on top.

Anyway, I must admit that I view the reservations to having RubyGems
in the core as somewhat academic and with few practical implications.
That's not to say that RG can't improve, or even that it shouldn't fix
some outstanding issues before imminent inclusion, just that I dread
_not_ having RG in the core much more than dealing with any of its
current "flaws".

RubyGems is in my mind instrumental in making Ruby available to a much
larger audience in a much more pleasant fashion. I dream of the day
where "gem install rails" is a command that can be executed with a
fresh install of Ruby on any system. Holding back that ease of use is
definitely something that should be weighed against concerns over
implementation.

While popularity is no overriding deciding factor, I do believe that
its worthy to note that almost half a million Rails-related gems have
been shipped over the counter since Rails went on that (110K for the
Rails package itself). In comparison, the tgz version has "only" seen
~19K downloads.

Thus, I strongly recommend that the core team decides to include
RubyGems as soon as possible. It has long since proved itself by its
extended use and usefulness.

-- 
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework