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.
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.)
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.
2. Just run a headless VM to run your development in, since you don't have to deploy on Windows.
* 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.
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 :)
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.