Accusing the ruby-core folks of a lack of candor in their handling of the previous round of vulnerabilities isn't really fair. Once the issues were effectively documented and explained, they released updated versions of Ruby 1.8.6 and 1.8.7 quite quickly.
The problem was simple that the core team doesn't use Rails, so they didn't test the patches they produced with non-trivial Rails apps. When other people did that testing, they got segfaults, freaked out, and basically tried to tell the core team that their release process was shit, and that they should let a bunch of outsiders tell them how to manage their releases.
Personally, I was embarrassed to be part of the English-speaking Ruby community during that entire episode.
I think that there are problems on both sides of this.
On the Ruby side, it makes a lot of sense to have Rails be part of the testing process, simply because it is such a prominent Ruby application framework. This doesn't mean that the Ruby people need to fix Rails, just that they should be aware when a core update breaks it.
On the Rails side, a bit more understanding, and a willingness to jump in and help, would go a long way.
Agreed. I'm a big fan of Ruby, but when millions of people are using your product, you need to put some thought into the engineering process behind it, and that includes putting some forethought into how you're going to handle security problems.
you need to put some thought into the engineering process
behind it, and that includes putting some forethought into
how you're going to handle security problems
Again, the ruby-core crew aren't thoughtless, or inexperienced; they have processes in place for both normal releases and security advisories, and have a pretty damn good track record for getting updates into the hands of the folks who need 'em.
There are now far too many versions of Ruby out there in the wild for the core team to effectively predict who is going to be affected by a particular issue. Every Linux distro and release of OS X has a slightly different bundled Ruby runtime, and most people don't seem to bother tracking the stable release from the core team until something like the last round of security updates leaves them scrambling to keep up.
The problem isn't the core team failing to handle security issues, it's the community not giving a shit about the code that makes up the 'ruby' binary until something goes wrong, and then not having any clue how to update their systems and do basic compatibility testing.
I stand corrected; I was under the impression that the big problem with the last release, was that it broke core functionality that had been available in all previous stable releases.
If the author doesn't want to put the appropriate processes in place to handle security problems, bug fixes, and the what, than this is of course his prerogative, but he should find it no surprise when he gets roasted on a spit by the user community that surrounds him.
People get angry when tools that they depend on don't work, regardless of whether or not they had to pay for those tools. A cavalier attitude towards the user-base will only incense them further, and while it may not matter to the tool-maker that people are going elsewhere, rather than use his free tools, the negative press can easily destroy a career or ten.
I'm not saying that this is right; merely that this is the way things are.
I agree that as a developer of an open source project, it helps your project to be ... helpful. But at some point, after it's clear that your project is essential, you can defer some of that work to the user community.
Want that feature? Send a patch (because, yeah, that's a good feature... but I don't need it and I don't feel like writing it.)
Judging the amount of detail they've provided on this news post alone I'd say they're off to a better start.