Open Source: Keep It Current Or Suffer The Consequences

While traveling last week, I shared a meal with a friend whose company is considering incorporating open source code, both to improve his project's economics and its resultant quality. Our conversation reminded me of one of my more popular (and controversial) writeups of times past, a piece entitled 'Visibility = Vulnerability' that I was compelled to write after the out-of-date FTP client on my server appliance got cracked.

Judging from the feedback, a lot of people misunderstood the point of my past diatribe (or maybe there are just a lot of Linux fanboys out there). I wasn't, and I'm still not, against open source….quite the contrary, in fact. Open source development can create quite solid and impressive products, although I must say that both the industry studies I've perused and my personal experiences lead me to conclude that on average, open source projects are inherently no less buggy than closed source ones of similar complexity, and that open source bugs don't get fixed any faster than closed source ones.

But not every eyeball inspecting open source code for flaws has honourable intentions. Crackers are also searching for vulnerabilities, which they then exploit on unpatched systems such as my Toshiba SG10. Online tools such as Google's Code Search (here's a followup Slashdot post) not only simplify the means by which you find open source software applicable to your project, they also assist crackers in finding out how widely a surmountable piece of code has spread through cyberspace, thereby identifying more potential victims.

That was the point of my earlier writeup (which predated Google Code Search), and of this followup. Want to use open source? Fine. But keep it current, and employ an update distribution scheme that's straightforward for your customers to implement. The crack of my server appliance came about because its manufacturer had stopped maintaining the code base even though the company hadn't yet formally obsoleted the product, thereby leaving me with a false sense of its security.

Some respondees to my earlier writeup claimed the circumvention was my fault because I had dared to expose the FTP port to the Internet. That's a ridiculous deflection of the core issue, and a distortion of the fundamental point of a server appliance. Others claimed the upkeep of the SG10's code was my responsibility, an equally ludicrous stance….that is, unless open source advocates are content with their products only being used by a small cadre of power users who are capable of personally compiling and merging code patches into a larger software build.

When I as a consumer buy a product, I assume that I've also bought an assurance that noteworthy flaws in its software will be fixed by the manufacturer at least through its production lifetime (and hopefully for some time thereafter). And I assume that I'll be easily able to install those updates. Open source or closed source? I really don't care, particularly if the manufacturer has used open source as a means of bolstering its profit margin versus enabling it to lower the product price versus a closed source alternative. And if the closed source product is more maintainable (assuming, of course, that the product is inherently vulnerable to potential code flaws….a fair bet in this increasingly network-connected world of technology), I'll vote for closed source with my wallet.

Asbestos suit donned; flame away, open source fanboys!