One could argue that the issue of openness is the most divisive issue in the software industry today. Unlike many software debates, it's even having an impact on the general populace. On the left, there are those who essentially argue that all information, including the code that makes up computer software, should be freely accessible to anyone at little to no cost. On the right, software companies with their armies of attorneys can think of no worse nightmare. They would much prefer that you purchase their (often expensive) applications, which they worked hard to build, on-line.
While in another time the subject might have been relegated solely to discussion amongst academics, hidden from a wider audience, a curious sequence of events began to bring the issue of openness to the forefront of the news in the late 1990s. The so-called "browser wars" began with the introduction of Microsoft Internet Explorer 3.0, the first serious contender to rival Netscape Navigator. For a while it seemed as though Microsoft was the clear victor, and then Firefox, Netscape's lost third cousin-once-removed, arrived on the scene. Firefox, they said, was open-source. Clearly, it was better.
And so it was. Yet despite the fact that Firefox was far from the first open-source project—and not even the first to make headlines (Linux had already been doing that for years)—it was the first open-source software application to really take off. It became the darling of the press, inspired hordes of users to donate to its cause, and gave everyone who had ever visited a web site reason to form an opinion about whether or not software should be open. So, here's mine.
It doesn't matter.
It's not that open-source software as a whole isn't important, or that it only matters in the short term. Open-source software is important, and has made a clear impact on our society that will shape things to come. Rather, what I don't care about—in fact, what no end-user I have ever met really cares about—is that open-source software is open-source.
Software of all varieties, whether shareware, freeware, "enterprise" or "personal," has been around for longer than most of the people who create it today, including myself. Accordingly, it has a history: there have been some good programs, and a lot of bad ones. Over time, the process of sorting the "good" from the "bad" has become more difficult, as software has grown astoundingly in complexity. User interface is one of the most important criteria for evaluating software, but one also has to take into account speed, aesthetic design, supported platforms, security, and customer support. Yet despite the proliferation of all of these factors, whether or not one can personally view the source code does not directly affect the operation of a program—nor has it ever.
"Wait!" critics should shout right now. "It does affect the design! I could change code to make the program operate differently!" To this, there is a response: maybe you could (it is another matter entirely how many actually do), but you could also get in touch with a software company and ask it to add or change a feature. After all, companies are made up of people, too. A worthy counterpoint would be that Corporate America is rarely so accommodating of customer input, but then the problem seems to be business-related, not a problem with the software development methodology itself.
Though the overall differences between open and closed-source programs usually end up being minimal, the two methodologies have developed comparative advantages of sorts. When code is open, there is generally a lot of feedback on efficiency (how efficiently the program operates at a technical level) and usually not much on design (the look and feel of the program). It is said that this attention to technical detail has indirectly made open-source packages relatively more secure, though the notion that all open-source programs are completely secure is just as much a myth as the notion that Windows never crashes. The uneven weight of feedback in favor of efficiency results from the self-selecting nature of those offering feedback in the first place: if you can't understand source code, you probably aren't going to try and read it, let alone correct it. This also explains why small open-source projects, and even some large ones, have abysmal user interfaces.
On the other hand, when source code is closed, no one except for a handful of programmers has any idea how efficient the code is, so most of the feedback from customers pertains to design. Problems with efficiency are corrected in minor version updates, if at all. Without feedback on efficiency, even the best closed-source applications, such as the Adobe line of products, get fatter and fatter, but they're at least easy to use for the average person.
These advantages and disadvantages eventually balance each other out, as do the exceptions to each rule. Bloated, insecure open projects such as phpBB are irritating for all the same reasons that the past three obese versions of Microsoft Word have been. At the same time, my closed-source text editor, TextPad, is as lean and fast as I could ever desire, just like the MySQL database, a champion of the open-source community. Not to mention that some of the most "secure" web sites on the internet are actually insecure because you can always view HTML source code.
On a broader scale, the fine distinctions blur, and the two types of software begin to look strikingly similar. As they grow, small projects certainly have the same financial needs as startups, and sometimes, they even look for suitors to buy them—just like startups. Google and Yahoo are both financing Wikipedia at the moment, though I would guess that neither quite knows why, aside from wanting to piggyback off of the hype that comes from supporting all things "open."
So, instead of focusing hype on open software, why not try focusing hype on good software? Whether it's open or closed, most of the software that ultimately emanates from the black box that is the development process is mediocre, but there are good programs out there. We as developers should spend a lot less time bickering about which way works "better," and a lot more learning from those in both camps who know what they're doing.
