4 ms·

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 tha

by donw 18y ago

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. Here's to hoping they get it right this time...

jrockway 18y ago
when millions of people are using your product, you need to put some thought into the engineering process behind it When millions of people are using your work for free, they should realize that they aren't entitled to anything.
- donw 18y ago
  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.
  - jrockway 18y ago
    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.)
rcoder 18y ago
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.
- donw 18y ago
  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.

by donw 18y ago

jrockway 18y ago

when millions of people are using your product, you need to put some thought into the engineering process behind it When millions of people are using your work for free, they should realize that they aren't entitled to anything.

donw 18y ago
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.
- jrockway 18y ago
  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.)

rcoder 18y ago

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.

donw 18y ago
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.