Open source on Windows -- an unholy alliance?

I have a confession to make. Sometimes, when I’m trying out an unfamiliar open source component, I cheat. Even if the software I’m working on will deploy to Linux, I’ll sometimes develop it on Windows first.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft

Why? Because on Windows, an open source component is likely to come with an installer that just works. That’s a huge advantage. The game of software development is dominated by the evaluation of available components and the selection of those that best meet needs. To play well you must be able to evaluate and select as easily and quickly as you can.

On Unix/Linux systems, component tire-kicking often isn’t so easy or so quick. There may be binary installers for individual components, but when you start combining things, you’ll often need to build from source.

Now, I have the utmost respect for the release engineering that enables what’s called the “configure, make, make install dance.” During this dance, a component learns about its environment and then builds itself accordingly.

It’s an extraordinary thing to see, and when it works — as it quite often does — I marvel at the mind-boggling complexity that is being managed in this way. But the dance can also veer down a slippery slope. I have spent more hours than I care to admit ferreting out dependencies and adjusting build scripts.

Companies such as SourceLabs and SpikeSource are now tackling that problem, and I expect they’ll do well. I don’t mind tackling it myself when the effort is an investment in something I’ll use over the long haul. In those cases, I feel empowered knowing that I can tweak the source code — something I’ve done only rarely, but that was critical on those few occasions. I feel even more empowered knowing I can rebuild for another environment.

It’s disheartening to invest such effort in a component that turns out not to be one you’re going to use. So, I cheat when I can. Or perhaps — if Larry Wall is right when he says that the three great virtues of a programmer are laziness, impatience, and hubris — I am just admirably lazy and impatient. Either way, if the Windows culture of instant gratification offers the fastest route, I’ll take that shortcut.

I’m agnostic, mind you. Any shortcut will do. When I first began working with the combination of libxml2 — a popular XML toolkit — and Python, Windows was the path of least resistance. Nowadays there’s an RPM (Red Hat Package Manager) package that makes things equally easy on many RPM-based systems. The odd man out, ironically, is OS X.

When it comes to instant gratification, the Macintosh generally outshines Windows. But little of that shine reaches the basement where open source developers dwell. If you want to use libxml2 and Python together, OS X may be the most awkward place to do so. No less a wizard than the XML god James Clark has struggled with the procedure, and it was the Web page he felt compelled to write that got me up and running on a new PowerBook.

Although LAMP (Linux, Apache, MySQL, Perl/Python/PHP) is often synonymous with open source, Windows can be a solid leg supporting the platform. The rising popularity of PHP on Windows servers is one indication of this trend. To zealots in both camps this may look like an unholy alliance, but I live in both camps and it makes perfect sense to me.