Burning out on Capistrano (Jamis Buck)
groups.google.com
groups.google.com
At Euruko (European Ruby conference) earlier this year, I raised the topic of Windows and.. most of the audience couldn't care less. They were mostly of the opinion that if Windows people wanted to use Ruby, they had to do the legwork. (FWIW, I'm an OS X user who doesn't care too much for Windows either, but I recognize there's a massive userbase there)
Windows is in the third-world of operating systems when it comes to Ruby - so Jamis' standpoint is less than surprising.
However, once I've investigated the claims, have permission, and got more of a story together, I'll be posting on Ruby Inside about it. There may or may not be a story, of course :)
* EventMachine for network I/O
* Win32API for FFI
* ActiveRecord for persistence
A lot of 3rd party Ruby libs won't work on Windows, of course, because they're build around Unixisms. But that's true of every other language too; it's just less obvious in Python because it has such a sprawling stdlib.
I switched to OS X and I'm happier with my computer than I ever have been in my life.
And Rails works awesome.
(I'm still running Cap 1.4.2 because it only took one line to make compatible. If I upgraded I would have to fix everything again.)
What flavor are the bugs? Usually, it ends up being a weak link in filesystem paths, SVN integration, or SSH integration. What causes these issues? Much respect for the folks who code them, I understand you do not owe anybody anything, but any honest assessment points to platform chauvanism.
"I do not use Windows, nobody I know uses Windows, true Ruby hackers are too cool to use Windows, begone ye Microsoft-infested slimeball"
The community (which I generally like and, let me note, actively contribute to) positively drips with this sentiment. DHH mentioned that 37signals wouldn't hire a Windows programmer (though he later backed down, somewhat), and the reasons were essentially tribal more than anything else.
And a big -1 to everyone who says that the Windows API is getting in the way of compatibility. Really folks? The Windows API being opaque made you hard code the path separator? The Windows API being opaque made parsing the results of a call to ls the more obvious choice than using the built-into-the-standard-library cross-platform way to get the contents of a directory? (To name just two implementation choices I've seen in Ruby libraries.)
2. Just run a headless VM to run your development in, since you don't have to deploy on Windows.
An awful lot of developers are just writing a library or application to solve a problem they have, and they write it to function on the platforms which they deploy to. They don't own Windows licenses, and don't have the time or the desire to test their work on Windows. I imagine that usually it simply doesn't occur to them! And why should it? They're not writing code that doesn't work on Windows; they're writing code that does work on the platforms they develop on and deploy to. That it doesn't work on Windows is merely an unfortunate (and probably accidental) side-effect.
Clearly you have a big problem with the attitude of many members of the community towards Windows developers and the Windows environment. This may not be unjustified. But to claim that "any honest assessment points to platform chauvanism [sic]" seems short-sighted and unfair.
I guess my response to that would be that Microsoft is quite opaque regarding Ruby. By being such a closed system, Windows doesn't do anything to help developers improve Ruby library compatibility.
Compare this to Apple. Apple builds Ruby into its operating system, contributes patches upstream, and is even supporting the development of MacRuby, which more tightly integrates Ruby into the Mac OS X operating system.
So the opaqueness goes both ways in my opinion.
Due to this, I am very impressed that Ruby even has the level of support in Windows that it currently enjoys. I would say that Windows hackers should keep up the good work and submit substantive patches as often as possible.
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.)
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....
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)
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.
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.
(Funnily enough, there's a competing app that is not open source or free, and they're still not doing a great job of updating the app and adding requested features for paid customers either..)
Anyway, my two cents is that people shouldn't expect donations to make the developer(s) scratch their itches. A donation is a donation. Maybe some devs and projects would be more willing to look into things for you after one, but unless they explicitly have such a policy, I wouldn't expect it to happen.
If you publish some code and go around claiming it does this and that, you are absolutely responsible for making good on those claims. Your reputation is at stake. How much you are getting paid is irrelevant. Besides, there are plenty of indirect ways to profit from making free software.
Also, there are implicit claims in every piece of software that doesn't say otherwise, namely that it is secure, won't trash your data, follows best practices, is not full of bugs, etc.
If you want to publish "as is" software, that's fine, but it should be made explicity clear to what degree you stand behind the quality of your code.
Users have no business complaining because you won't add some feature they came up with or your pre-release version isn't solid. But it is quite reasonable to complain if an open source project does not live up to its own pretenses.
That's what this whole Capistrano situation seems like to me (sadly, I didn't even think cap worked on windows). People are irate because a project is dropping support for a platform it never seemed to work well on to begin with. Have the developers ever promised windows support? I always thought their main claim was that it's a tool to automate deploying (mostly rails) apps, and I think it works well in that regard. I didn't think those promises extended to platform support as well.
As for this case.. well, Capistrano is a Ruby lib and Ruby libs tend to work on any platform Ruby does, unless otherwise specified. Plus, it used to be supported, which means people invested their time, thinking it would continue to be. It's a weak complaint but it deserves at least a little recognition.
But the attitude bothers me more than the action. Read that message again and then look at this sunshine enema: http://www.capify.org/
Can you put that site online and then claim you're not beholden to anyone? Questionable.
For what it's worth, what would bother me is if this wasn't explicitly announced and the dev just didn't feel like working on the project anymore, or if it was a core feature of the tool that was going to be ignored in the future. Now that's something to complain about, and then go do something about if it mattered that much to me.
I've personally been in a similar hellhole of a situation (who hasn't?) doing some dev work for a nonprofit where less than 5% of the users both by number and usage completely wasted my time trying to convince me I should bring back support of older browsers and platforms for absolutely no legitimate reason other than a lack of willingness to upgrade on their part, even though the nonprofit had existing volume and discounted licenses that would effectively make the software free for them. Make a lazy <5% happy by doing LOTS of extra work possibly eschewing working on features for the other >95%, and still deliver what may be a subpar experience (think windows 98 when everyone else is running Vista) while billing them for it at the same time? No thank you.
I don't understand why this is even an issue.
Not caring about adoption rates is another story altogether.
I love Ruby, do most of my work in it now and haven't owned a Windows machine since 2001, but if Ruby's answer to Windows users is "just switch to Ubuntu" it's not surprising they decide to just choose another language.
I can't give up Photoshop for the type of work I do and I can't afford a macbook yet so I just installed andLinux and have all of the abilities of Rails and Linux while still using Windows. All you really need for Rails is the command line, I use Intype in Windows for my editor and I am cruising. andLinux only uses about 100mb of a RAM at any given time so it's barely noticeable when it's running in the background.
It seems the incompatibilities come from things like capistrano which are quite close to the metal. And that seems reasonable to me. However, expecting new users of your language/framework to delve into the internals just to make their basic app work isn't going to happen. Maybe it should, but it isn't.
If you're using Windows to develop for RoR, you're just lazy and you don't deserve to be supported.