

Why RubyGems Needs Loren Segal - techpickles
http://jamesgolick.com/2011/6/1/why-rubygems-needs-loren-segal.html

======
sandal
James makes a great appeal for Loren in this post, and there's no denying that
SlimGems has made us all think, and brought many interesting issues to light.
However, it's hard to realistically expect one to go from being the maintainer
of a hostile fork to the maintainer of the project they forked overnight.

But that having been said, Loren is one of the few people qualified to really
speak on these issues. He's studied the internals of RubyGems, he is aware of
many of the problems with the previous ways of doing things. In particular,
he's a proponent for stable APIs so that breakage becomes a thing of the past.
I've spoken with literally hundreds of people over the last two weeks about
this issue, and I'll be the first to admit it's one that needs to be solved.
The question now is not whether it must be done, but when and how the changes
need to be introduced.

These are questions that I feel I must at least strongly consider the opinions
of the current maintainers of RubyGems on, because for example, Eric Hodel has
been the core team for 4 years and knows more about RubyGems than anyone on
the planet. There is no denying that Eric+Ryan have had personal conflicts
with Loren, which would make an immediate appointment of Loren on the core
team unrealistic.

However, Evan Phoenix (another of RubyGems maintainers) and I are trying to
see if we can find a way to solve this problem outside of RubyGems first
through a compatibility gem, in a minimally invasive way to users. We have
already talked with Loren some, but I hope that dialogue continues so that he
can possibly help us with our ideas and build something that everyone can be
happy with. This to me would be much better than the division that would be
caused by a fork, and is something I think we should at least try before we
make any sweeping changes in leadership.

I've promised to back off the diplomacy and start hacking to solve the
problem, and that's what I'll do in the coming weeks. But I felt it was
necessary to share my thoughts here simply because I've been listening to so
many people about what their concerns are with RubyGems, and that makes me
really want to find a solution that works. If Loren can be part of that
solution, I'd love to see him working for RubyGems rather than against it, for
sure.

~~~
jamesgolick
> hostile fork

What's hostile about proving points with code?

> ...the division that would be caused by a fork...

You still haven't explained what the problem with this "division" is. Why will
this be different than the rails/merb fork? Honest question: are you afraid of
division or of your friends losing control of the project?

> There is no denying that Eric+Ryan have had personal conflicts with Loren...

As well as just about anybody else who has tried to work with them.

> However, Evan Phoenix...

Evan is a great and brilliant guy, but let's be honest here. He's another
personal friend of the current maintainers and (former?) Seattle.rb member. We
need fresh blood.

~~~
dudleyf
Merb was never a fork of Rails. It was a separate project, initially created
to address a particular shortcoming of Rails (file uploads, IIRC), and grew
into a competing implementation that solved a lot of the same problems that
Rails did in a simpler, more elegant way. The Rails core team realized that
Merb did a lot of things better and absorbed most of that goodness.

SlimGems isn't Merb. It's not new, it's not doing anything better. The only
thing it has going for it is "Hey, it's not being run by these same assholes."
Well, that doesn't help me much. SlimGems isn't going to ship with Ruby 1.9.3,
and it doesn't solve any problems that RubyGems doesn't solve. Loren could be
making a better RubyGems, but instead he's making an older RubyGems.

~~~
nirvdrum
Well, the other thing it has going for it is that it works. So far I've had no
problems with SlimGems on the half dozen or so projects I've tried it with.
The same cannot be said for RubyGems 1.8 and most of the releases since 1.3.7.

------
msie
All of a sudden, there's some drama concerning RubyGems. For me, it's one of
the best things about the Ruby ecosystem. That and the fabulous gems for web
development. There's a lot of bleeding edge development of the Ruby language
and the ecosystem, but that's also a downside in a lot of breakage due to api
changes. Ruby was supposed to make my life as a programmer easier. I need more
stability. I think I'm too old for this stuff.

~~~
nasmorn
I second that. Gems are great and even though this whole rdoc, ri stuff is
slow to build it is certainly not the dealbreaker in rubyland. When someone
spends too much time with something like rubygems they tend to overestimate
the importance of this or that feature. The importance of rubygems still
working on the otherhand cannot be overestimated. When I try to get a company
to accept ruby in lieu of PHP the last thing I need is installation upgrade
nightmares with the sysadmin there because I can't figure out how to bring his
server to run some library I use.

------
cachemoney
Ironically, the guys who maintain rubygems also wrote
<http://rubyhitsquad.com/>, in which they vocally slam another mainstream Ruby
project.

------
jrockway
I don't use Ruby, but... if people have so much time to whine about deprecated
APIs, fork RubyGems, blog about it, and spam HN three times a day... can't
they just fix the gems that use the deprecated APIs and move on with their
lives? It's not as dramatic as creating Internet Drama, but it's probably much
better for the community.

The Ruby community seems to have a lot of people with time on their hands (and
strong opinions), but it seems that these people with time on their hands just
rewrite the same shit over and over and over again. Move forwards, not
sideways...

~~~
ericb
The reason Rubygems causes so much ire is that it is at a choke-point in the
ruby ecosystem. Not every gem is actively maintained, so _just fix the gems_
is easy to say, harder to do.

The rubgems maintainers are in a position to practically destroy Ruby's
usefulness overnight by making frequent changes and deprecations, causing
every installation to become a debugging nightmare and destroying millions of
man-hours. To be sure, the emotional drama is boring, but the stakes are real.

------
cldwalker
rubygems doesn't need loren segal but it could use new leadership. It's great
that Evan has stepped up but will it be permanent given he's already got a
handful with rubinius?

~~~
sandal
Remains to be seen, I don't think evan has made a permanent commitment. But I
believe that if anyone is best to handle whatever transition period is to
come, it'd be him.

------
danohuiginn
background, somebody? Who is Loren Segal?

~~~
zapnap
Loren created YARD, which is easily the best Ruby documentation generator out
there. His attention to detail and concern for release management is pretty
much unparalleled within this community. He's also a recipient of a Ruby Hero
award.

Full disclosure: Loren and I have collaborated on projects before. We co-
authored the current version of rubydoc.info, the online doc host for Ruby gem
and Github projects. So yes, I'm biased, but I've also seen the quality of his
work first-hand.

