4 ms·

Although lots of comments are about the Ruby language, I think this post can be applied to just about any open source project out there. It's always easier to

by catch23 18y ago

Although lots of comments are about the Ruby language, I think this post can be applied to just about any open source project out there. It's always easier to complain to the maintainer than to try to fix the problem yourself and distribute the fix as a patch to others. Open source doesn't work well if there's only one person who fixes all the problems. I think it could also be a newbie developer mentality. Newbie developers are more likely to use libraries that are completely plug-and-play; if something doesn't work right, they'll complain rather than try to fix it themselves.

nir 18y ago
I think this is related to Ruby in the sense that there aren't that many Ruby coders. The whole "scratch an itch" thing is a numbers game - maybe %1 of the people who have a problem would actually contribute a patch that fixes it, so the more people use a language/project the higher the chance the original author would get some outside help. As for newbie devs, I'm not sure I agree... as a non-newbie, I still like to get a solution that works. I might be able to dive into the code and fix it, but I don't want to do this - I prefer to focus on my app rather than figure out why certain libraries don't work. (For some reason this view seems to be common in Ruby. A prominent example was the web server - until Passenger came along (surprising everyone) you were supposed to figure out how to deploy with lighttpd, then mongrel - instead of simply working with Apache which most of the world already knew how to install, scale and tune.)
- mattmcknight 18y ago
  I think the reason it's a Ruby problem is the c - extensions to Ruby are hard to cross compile across platforms. Windows is a particular problem because the c compiler situation is not consistent. There are still a lot of people using Visual Studio 6 to compile this stuff.... As far as deployment goes, when you can run Windows services for the mongrels, do you even need capistrano? I've been doing Rails for years without it and don't feel like I need help deploying....
  - nir 18y ago
    Isn't the C extension issue the same for other languages, eg Python or PHP? (I really don't know, I'm not that familiar with Ruby internals) I think this issue, like Capistrano's, would benefit from having more Ruby coders, which in itself might require a more newbie-friendly approach from the community. (BTW I hope it doesn't seem like I'm criticizing Jamis' choice - actually I think he's doing the right thing in the current situation, just that if there were more Ruby coders around he might not be forced into choosing this path)
    - catch23 18y ago
      The C extension issue in Ruby is the same as Python afaik. There probably aren't as many windows developers using Ruby though.
mpk 18y ago
It's also a problem with Windows itself. It really is a nasty environment for coding non-MS-based software on. If I want to support Windows I have to setup a (virtual) machine with a license code just to have any basic functionality. As someone who doesn't work with Windows anywhere, this is a huge hurdle. Then there's the hoops I'd have to jump through just to get a decent shell and a compiler ready. Oh, but the fun doesn't end there. Which version of Windows are we talking about? More than one? Ah, well, each of these will require its own machine (virtual or otherwise). With matching keys, of course. Supporting Windows is a pain and when it's not required for what I want to do, I'm simply not going to do it. Period. I have better things to do with my time. Letting people who want this code running on Windows do it themselves and having them submit patches upstream is a perfectly valid choice.
- Maascamp 18y ago
  What if I'm an anything else coder and I want to support Mac? Forget license, I need to buy a new machine. Linux is the only really painless platform to support if you're not using it.
  - Niten 18y ago
    But if you support any sort of *nix, then you quite possibly work on OS X already. If not, there's still probably minimal work to do. It's not like going from Unix to Windows, where you have an entirely different access control mechanism, system API, filesystem structure and path separator, etc.; it's just going from one Unix to another. So the author only has to accept a couple patches from his Mac-using colleagues, and then he's basically set for OS X. On the other hand, debugging a Unix app on Windows can become a full-time job, and may be more work than you can reasonably expect a few random patch contributors to accomplish.

by catch23 18y ago

nir 18y ago

I think this is related to Ruby in the sense that there aren't that many Ruby coders. The whole "scratch an itch" thing is a numbers game - maybe %1 of the people who have a problem would actually contribute a patch that fixes it, so the more people use a language/project the higher the chance the original author would get some outside help. As for newbie devs, I'm not sure I agree... as a non-newbie, I still like to get a solution that works. I might be able to dive into the code and fix it, but I don't want to do this - I prefer to focus on my app rather than figure out why certain libraries don't work. (For some reason this view seems to be common in Ruby. A prominent example was the web server - until Passenger came along (surprising everyone) you were supposed to figure out how to deploy with lighttpd, then mongrel - instead of simply working with Apache which most of the world already knew how to install, scale and tune.)

mattmcknight 18y ago
I think the reason it's a Ruby problem is the c - extensions to Ruby are hard to cross compile across platforms. Windows is a particular problem because the c compiler situation is not consistent. There are still a lot of people using Visual Studio 6 to compile this stuff.... As far as deployment goes, when you can run Windows services for the mongrels, do you even need capistrano? I've been doing Rails for years without it and don't feel like I need help deploying....
- nir 18y ago
  Isn't the C extension issue the same for other languages, eg Python or PHP? (I really don't know, I'm not that familiar with Ruby internals) I think this issue, like Capistrano's, would benefit from having more Ruby coders, which in itself might require a more newbie-friendly approach from the community. (BTW I hope it doesn't seem like I'm criticizing Jamis' choice - actually I think he's doing the right thing in the current situation, just that if there were more Ruby coders around he might not be forced into choosing this path)
  - catch23 18y ago
    The C extension issue in Ruby is the same as Python afaik. There probably aren't as many windows developers using Ruby though.

mpk 18y ago

It's also a problem with Windows itself. It really is a nasty environment for coding non-MS-based software on. If I want to support Windows I have to setup a (virtual) machine with a license code just to have any basic functionality. As someone who doesn't work with Windows anywhere, this is a huge hurdle. Then there's the hoops I'd have to jump through just to get a decent shell and a compiler ready. Oh, but the fun doesn't end there. Which version of Windows are we talking about? More than one? Ah, well, each of these will require its own machine (virtual or otherwise). With matching keys, of course. Supporting Windows is a pain and when it's not required for what I want to do, I'm simply not going to do it. Period. I have better things to do with my time. Letting people who want this code running on Windows do it themselves and having them submit patches upstream is a perfectly valid choice.

Maascamp 18y ago
What if I'm an anything else coder and I want to support Mac? Forget license, I need to buy a new machine. Linux is the only really painless platform to support if you're not using it.
- Niten 18y ago
  But if you support any sort of *nix, then you quite possibly work on OS X already. If not, there's still probably minimal work to do. It's not like going from Unix to Windows, where you have an entirely different access control mechanism, system API, filesystem structure and path separator, etc.; it's just going from one Unix to another. So the author only has to accept a couple patches from his Mac-using colleagues, and then he's basically set for OS X. On the other hand, debugging a Unix app on Windows can become a full-time job, and may be more work than you can reasonably expect a few random patch contributors to accomplish.