Using open source software brings with it many benefits: rapid improvements, help from a strong community, lower costs, the ability to hack right into the code to fix problems, and more. Unfortunately, there's a certain attitude that often comes with it that is rather less than helpful to those in corporate situations.
David Gewirtz covers the issue. The gyrations he goes through to get his Apache installation to work after upgrading left my jaw hanging open. Full disclosure: I am not an IT professional – and if I've ever entertained thoughts in that direction, Gewirtz's description would have talked me out of them in short order.
To start, Gewirtz has been running Apache since 1996. He currently runs Apache 2.2, with Linux on a virtual machine under Windows Server 2008 R2. “I know, you Linux kids think that's horrible, but being able to RDP into a real server environment, with a real GUI – and not have to fight terrible documentation and inconsistent configurations for every single feature – is a godsend,” Gewirtz explained. He tests his code locally on his Windows 7 laptop using the XAMPP WAMP stack; this setup has been working well for several years.
The task that sets the stage for the rest of this is porting a major CMS. To do this, he has to rewrite nearly 100,000 URLs on the fly. So he uses the Apache mod_rewrite module with a RewriteMap, which lets him run a Perl script to read the incoming URL, look it up in a database, and redirect appropriately. He developed and tested this on his laptop before uploading it to the live server, and it worked just fine.
It may well have kept working – until he decided to invest in a newer, faster laptop last month. Naturally, he had to reinstall all his software on it, including XAMPP. But XAMPP moved from version 1.7x to version 1.8. Now XAMPP 1.8 uses Apache 2.4, not the older Apache 2.2 that Gewirtz has been using. “I probably could have checked the versions,” he admits, “but Apache is Apache is Apache, right? Wrong!”
Apache 2.4 changed the way the Rewrite system works – and “the new version completely breaks the old version,” Gewirtz notes. This meant that everything he had formerly set up to handle those 100,000 URLs in his development environment no longer worked. In short, an Apache upgrade seriously broke things. As this hapless IT professional explains, “when I installed the new XAMPP on my laptop and tried to start Apache with my old configuration files, it wouldn't start. Digging in resulted in my finding an error saying it didn't know anything about this 'RewriteLock' thing.”
It took Gewirtz an hour of searching to discover that RewriteLock had been deprecated in favor of something called “mutex.” The error message he got when his system failed to start did not inform him of this change. Worse, when he read the document on upgrading to 2.4 from 2.2 (http://httpd.apache.org/docs/2.4/upgrading.html), it simply told him that “Directives AcceptMutex, LockFile, RewriteLock, SSLMutex, SSLStaplingMutex, and WatchdogMutexPath have been replaced with a single Mutex directive. You will need to evaluate any use of these removed directives in your 2.2 configuration to determine if they can just be deleted or will need to be replaced using Mutex.”
Gewirtz toasts the open source mindset inherent in the lack of helpfulness from both the error message and the upgrade document. You're expected to do the research yourself, and just figure it out. Can't make it work? You shouldn't be using it then. There's no transition path at all, no notes that say “Well, if you're using this old directive, code it this way.”
In a commercial environment, you can't put all of this on your customer's shoulders; they're putting out enough fires just running the business. Gewirtz notes that a company putting out commercial software would have considered each deprecated feature carefully, and provided a clear upgrade path for every one of them – even emulated them with the new technology so the system wouldn't break when it got upgraded.
Contrast that with the lack of product management evident in the open source mindset. “If there's a better technology or a cooler way to implement something, they just do it,” Gewirtz observed. “Even if that means killing a bunch of installations, that doesn't matter. Even if that means inconveniencing users or leaving them without direction, so what? After all, if you really want to know how it works, the source code is available. Go read it.” This, Gewirtz maintains, is why so many websites run out-of-date software; the updates break too much.
For Gewirtz, this means downgrading his development environment back to the older versions. This also means that he can't upgrade his production servers to Apache 2.4 without spending serious time figuring out how to rework his complex rewrite system...without the help of documentation to guide his upgrade path.
It may be nice that the creators of open source software respect your intelligence enough to open things up and believe that you'll figure out problems yourself. It would be even nicer if they'd respect your time by providing more thorough documentation and a more complete transition path. Have you experienced these kinds of problems with open source software? Feel free to comment below.