Tonight I had my first meeting with Eric and Ryan to discuss the areas of greatest tensions with the current state of RubyGems. The meeting was quite productive and my personal impression is that despite the intense drama in recent weeks, that both Eric and Ryan realize that there are issues that need addressing and are willing to make concrete steps to ease tensions. The following list outlines specific changes that they plan to make happen:
- Rubygems 1.8.4 has been released, disabling deprecation warnings for default_executable. This should greatly cut back on the number of warnings people are seeing, because the vast majority of them come from this one method call. Additionally, Ryan will work to make the other deprecation warnings less intrusive, possibly removing them entirely and favoring an error message when attempting to upgrade to a version of RubyGems that may cause problems. However, the exact details on how this will happen need to be thought about more before they can commit to a particular solution.
- A major source of the problems surrounding RubyGems is a lack of a centralized, easily accessible source of information about updates to RubyGems and what they mean to users. In the coming weeks, this will be resolved by creating a blog or announcements feed on rubygems.org or some other very prominent location, which will be the offical place to look for any important information about what is changing in RubyGems.
- There have been instances in the past in which folks have tried to develop plugins for RubyGems, but were unable to figure out how to build what they wanted without monkeypatching the core Rubygems system. This is something that leads to problems, and so needs to be dealt with. While the plugin system for RubyGems is going to be as simple as possible, it is important that it is able to support a reasonable amount of extensibility for anything that does not go against the core purpose of what RubyGems is meant for. While we have not discussed specifics, Eric and Ryan have agreed with me that a stable, well supported plugin system is important and that they will do what they can to assist those who are trying to write plugins against RubyGems. If this is something that has caused problems for you before, you might consider revisiting any issues you were having, because it sounds like you'll find better support this time around.
- One major complaint from users and contributors is that they feel that RubyForge is a poor choice for a bug tracker. It is important to keep in mind that RubyGems is a complex project that has more than the average needs from a bug tracker, and that Eric and Ryan have invested some time into building tooling around RubyForge to help them manage issues. However, they recognize that this is a pain point for the community, and will seriously re-evaluate whether it'd be possible for them to transition to a more modern system. If it turns out that isn't something that will work, they will provide some technical explanation as to why that is the case, so that it is no longer a big mystery.
- I asked both Eric and Ryan if they like working with RubyGems users and contributors. Both of them said that they are happy working with a majority of people they've interacted with. They do recognize however, that their reactions to certain users and contributors can be quite harsh, and that this both causes folks on the sidelines to view the project in a negative light as well as makes the individuals they have had conflicts with unlikely to want to work on RubyGems. However, there are other people experienced enough with RubyGems who would be able to interact with thes individuals in a more productive way. This would help ease tensions among users and contributors to RubyGems that for whatever reason, find themselves unable to work with Eric and Ryan due to personal issues.
While it's really unfortunate to think that this sort of buffering might be a necessity, I can say that I've been in these shoes before on my own projects. It was much harder for me to focus on my positive interactions when I was the only developer working on the Prawn PDF generation library. As we expanded our core team of developers, we found that our relationship with the community improved a whole lot as soon as I could let other folks answer questions or deal with people that might rub me the wrong way. I think that model could work for RubyGems as well.
In addition to the above, a major concern I received feedback on was that people feel releases are happening too frequently, that there is a lack of a clear roadmap, and that there isn't sufficien communication going on about what to expect when you upgrade RubyGems. The points discussed above should help with that, but I've also set up plans to do a followup meeting with Eric and Ryan to discuss release management in particular. At a minimum, within a few weeks it should be clear what the policies are for releasing RubyGems, and why they are done the way they are. Because I've not gone over this in detail with Eric and Ryan yet, I don't have more news on this front, but it's something that is on our radar.
These are the results so far. I think this is a large amount of progress in just a few days time. What I'd ask is for the community to give me a few more weeks to keep trying to mend some fences. Everything I've called out on this list is discrete and actionable, so I'll be the first to admit that things didn't work out if none of this stuff ends up happening. But until that happens, please suspend your disbelief and give these guys a chance.
