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.
Having seen other comments you've made throughout this process, I really think you're overstating the importance of having been involved with something for 4 years. Seniority does not and never has demanded respect in all but the most draconian of organizations. On the other hand, being at the head of a failing organization usually means you need to be removed in order for proper recovery to occur.
Simply put, the quality of one's work should be judged by the quality of the outcome, not the time put in. Otherwise you end up in a situation where newcomers are never welcomed. You end up in the situation we're in now. And I've yet to come across a project that hasn't benefited by a smart, driven guy providing new insight and perspective. Marginalizing that feedback to save an ego is a major disservice to all.
You missed the point. It's not about seniority at all. It's about knowledge of a very complex system. I don't want to see that fly out the window so that we can spend another couple years learning what Eric has. Rescue projects suck, and this doesn't have to be one.
> ...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.
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.
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.
To qualify my friendship with Ryan and Eric, it consists of meeting them at conferences once in a while and having some positive conversations with them. That said, I am absolutely biased here, I like them despite their flaws in the way they manage projects and their tendency to easily get embroiled in unnecessary personal conflicts.
I left a more detailed comment on your blog, but I don't think we need to have a meta-personal conflict, so I'll leave this rest here.
> If Loren can be part of that solution, I'd love to see him working for RubyGems rather than against it, for sure.
I know you're trying to be a diplomatic bridge for the RubyGems team, however saying things like that just makes me shake my head.
I appreciate James' appeal. As an outsider to the situation, I wonder why not just let Loren do his thing without comments like that? I'm also saying this with respect to Eric and Ryan's work.
I've been giving slimgems grief but not Loren, I've actually been in regular, productive dialogue with Loren since this started. But actually, you're right, my public presence may not reflect that and it's time for me to change strategies. Here's what I plan to do instead now:
http://blog.majesticseacreature.com/rubygems-peace-rally-vs-...
Sorry if I don't reply to this comment, but I just wanted to make sure that folks here see that I've heard their thoughts and decided to act on them.
I'm nobody special, to the Ruby community, so I'm not going to claim my opinion carries a lot of weight, here. That being said, you have to see how characterizing Loren's work as a "hostile fork" isn't the most neutral thing to say.
It would appear to me that you've definitely moved past the role of mediator, but when you say things like "I must at least strongly consider the opinions of the current maintainers of RubyGems" it sounds as though you're now casting yourself in the role of judge, instead.
You're doing great things with RMU -- we thank you for it, and I'd hate to see the fallout from the role you're attempting to play here overshadow your great contributions to our community thus far.
As a mediator, I never intended to cast myself as non-biased about SlimGems. I started my involvement by specifically calling SlimGems a really bad idea, and I still stand by that point. Here's my first post:
What I said is that I'd collect the concerns of the Ruby community and present them to the maintainers and try to get changes made on their behalf. I've done that, and will keep doing that.
As for no longer being a mediator, I also already made it clear that I can't be unbiased about this, because after investigating, I've seen enough to form some strong opinions:
In the end, I'm not worried about how this makes people who think a hostile fork is a good idea feel about me. I've received more thanks than criticism, but most of it was quiet and private, rather than loud and public. I believe in the work I'm doing, and will keep it up, but hopefully through more code and less talking.
I hope you realize that by titling your first piece on the matter "RubyGems: Nerd rage is optional (and discouraged)" and then following up with "RubyGems drama" that you were never really mediating. Maybe you brought people together over Skype and got some discussions going. Maybe you were just trying to be sensational. But I immediately discounted everything said from that point forward, as did many others I know, for the simple reason that you continued with the same attitude that we were all tired of. You were perpetuating the very thing we wanted to see changed.
The RubyGems matter isn't a technical one; SlimGems effectively dispelled that notion. It's a personnel matter. It's a cultural matter. The only way I'm ever going to have faith in that project again is when the guys running it value running, working software over theoretical, idealistic improvements. And I simply don't believe that will be the case until Eric & Ryan leave or are otherwise removed.
The sad part is RubyGems is so critical to the ecosystem that it really started making me question the value in using or relying on Ruby at all. The egos didn't help either. I can take a certain amount of crap if the system works and I can put up with broken software from nice, responsive people. I can't deal with both failings. In that regard, SlimGems has done more to restore my confidence in the Ruby ecosystem than anything else.
It was forked because while performance improvements are great to have, API breakage with no replacement for long-standing APIs is not.
At the end of the day, people need a working environment and not everyone has the time of day to be updating every library out there that used a previously stable RubyGems API to use the new "better" ones (though I've yet to see a case where the API changes were little more than renaming a class and adding a couple class methods).
I know little about the API changes, but have been burned by just about every single release since 1.3.7. So much so that I now have to patch RVM every time I bring up a server so I can lock down the version. One could argue I should have been doing this right along, but I don't think it's entirely unreasonable to believe that new versions of your library loading software will continue to load your libraries.
However, it's hard to realistically expect one to go from being the maintainer of a hostile fork ...
Greg, "hostile fork"? I read Loren's blog post about the release of SlimGems and the motivations, and really got no sense at all of any hostilty.
As best I can tell, much like with YARD Loren decided he wanted to see some key part of the Ruby dev environment behave a certain way and wrote working code to make it so. I can only applaud that.
Having spent at least a little time chatting with Loren about YARD (he was terrific in clearing up dozens of questions at a MWRC) I'd be surprised if there was any anger or malice behind any of his projects.
It may be that the offering of these things in turn creates some annoyance for some people, but I doubt that's the intent.
I would much prefer to see more people code out their issues than complain on a mailing list or HN.
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.
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.
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...
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.
I'm not sure I follow. Most of the posts I see are against the guy who did the fork, who appears to just want to do something, which he does. The posts also seem to advocate a social fix, and social fixes won't work without communication.
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?
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.
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.
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.