One of the things that has been a strong point of Open Source Software (OSS) for years, even if it hasn't been held at the forefront of the battle, is the flexibility that OSS offers. This is something I think needs to be said more these days as our world becomes ever more dynamic, requiring software to be ever more flexible in order to keep up with our ever changing lives.

One recent example of this flexibility at work is with the announcement that Linux isn't Y2K(38) compatible. As of right now this is a non-issue as 64 bit Linux will resolve this completely by the time it actually becomes an issue. However, it wasn't too long ago that simple natural software advancement was the cure for a problem.

Almost everyone alive today can remember the huge issues presented to the world in general, and not just the OSS community, by the Y2K bug. For years there was talk about it, then worry, a lot of stalling, then doomsaying, and finally only three years from the deadline, action as things started moving towards fixing this bug, with a lot of companies finishing just a few months before the clocks rolled over into the year 2000. Only a few random companies and groups actually suffered any harm from the Y2K bug in the end, none of which were OSS related.

Interestingly enough, it was the OSS communities that lead the Y2K compliance charge to get everything upated so as to properly weather this "Perfect Storm" of the computer world that was looming on the not too distant horizon. Most OSS projects actually completed the needed changes long before most of the proprietary vendors even got started with theirs. But what about those end users who were using older, out of date software that was no longer supported? It varied, depending on the type of software they were using.

Those that were using OSS applications, or Unix or the BSD's or any other open platform found that they were able to quickly and easily update their software, even if it was no longer supported. Access to source code allowed hired consultants to quickly update the code, make the needed changes, and put the various companies and institutions back on their feet in record time, even if the application they were using was obsolete and no longer supported by its developers. Users of proprietary software found themselves in a slightly less rosy condition.

Take Windows for example. Even back in 1999, Microsoft Windows had one of the biggest user bases of any desktop OS of the time, yet Microsoft was very lax in updating its Windows OS to deal with the bug, waiting until May of 1999 to release its patch. But this didn't properly solve the problem. So they were forced to release a second patch, which arrived a scant 4 months before the end of 1999. To me that's cutting things far too close for comfort. Especially if large firms had to deploy the patch over thousands of machines before the end of the year. To make matters worse, they even withheld information about a planned Y2K patch from Windows 95 users in an apparent effort to scare them into upgrading to Windows 98. From what I gather, they almost waved off even making a Y2K patch for 95. But customer pressure forced them to.

But they're not the only vendor who did this. Oracle waited until at least December 20th, 1999 to release at least one of its Y2K patches for an important database function in their Oracle database system. That's cutting it awfully close in my opinion. Now as for Linux, just like Unix and BSD, Y2K was never a problem. This is because Linux, Unix and BSD are natively Y2K complaint, given that they track time through the use of an ever growing integer number that is not dependent upon physical dates. Time on a Unix, Linux or BSD system is derived from this integer number that represents the number of seconds that have passed since the Unix epox on December 31st, 1969. Even so, the system that converts that integer number into the standard date/time format we use every day wasn't ready for the changeover.

That however was quickly fixed and I believe all Linux, Unix and BSD distributions reported full compliance no less than a year before the deadline. Now there is evidence that some OSS projects came dangerously close to the deadline, and a few went past it, but that was because a lack of manpower delayed or greatly slowed their responce to this crisis. It was never a question of if they could do it, but rather how fast they could do it with their limited resources.

Another big area in which OSS shows its benefits is security. Firefox has been an excellent example of this. Their average turn around time for serious bugs is mere hours, not days or weeks or even years. Hours. There are examples of quick turn around times in the proprietary software world as well, but they're more the exception rather than the rule. Some bugs in the proprietary software world seem to be flat out ignored, despite their critical nature and are never addressed or even fixed ever, going so far as to find their way into newer versions because of this. Now there are of course exceptions here too, the biggest being that of OpenSSH and the encryption technologies used by many users, companies, government agencies and security firms to secure local data and internet communications.

It's a well known fact that it could take as much as 1-3 months or more from discovery of a critical security flaw to the time in which it's patched. But why is this? Shouldn't this be something that is addressed almost immediately given the sensitive nature of the things these security technologies protect? Well, yes, it should. However, in order to be fully accepted in the world of security, you have to abide by several industry standard systems put in place to provide a checks and balances system that helps avoid unscrupulous parties from inserting trojans, backdoors, and other security compromising changes into the system. Every change that is requested in a given industry approved system must be taken before a committee, reviewed thoroughly, and approved by a majority before it can be subsequently implemented.

The bureaucracy of this system severely hampers the ability for groups like OpenSSH to react quickly to severe security issues. However, that reduction in response time also ensures that when the new system is approved and the patches applied, that the security it creates is just as trustworthy and reliable as before.

Now here's something that might surprise you even more. Despite taking over a month or more to fight any new changes through the security bureaucracy, OpenSSH can implement those changes within hours after the final changes are approved. Yet proprietary organizations, knowing that these flaws exist and a fix has been reviewed and approved, may wait as long as six months to a year before posting any patches or changes to address these issues. In some case they may even wait until the next version of their software before they address this problem.

Another great example of the flexibility of OSS is the IM wars from a few years back. Within hours of a protocol change deployed by networks such as AOL or MSN to lock out all 3rd party IM clients, almost every single OSS IM client had a patch out that would fix this incompatibility. The proprietary vendors could take weeks or months before they'd address it, if they addressed it at all. The only exception to this came from the makers of Trillian, and even they grew tired of the battle after a while and slowed down their release schedule for patches because of this.

Yet the OSS community fought on. And eventually it broke the back of the big IM vendors, finally causing them to give up the war and allow, although begrudgingly, all or most 3rd party IM clients to connect to their networks. If it hadn't been for the OSS community being so proactive about answering this challenge, there's no telling how long the war could have gone on or even if it ever would have ended. And if it had, it would likely have been after all the proprietary vendors had long since thrown up their hands in surrender.

And those are just a few examples. There are thousands more. Now this isn't to say that all proprietary software is bad and all OSS software is good, because that's just not the truth. It's certainly the majority rule, but not the absolute rule. In truth, there's a lot of good proprietary software out there, and there will be for quite some time. Proprietary software by no means will ever go away. However, it will most certainly change its role in the near future from it's current place as the dominant source of applications to more specialized roles, filling in the gaps and spaces in the software world left untouched or incompletely filled by the OSS community.

In fact, I predict that instead of being the staunch rivals of OSS like they are today, the proprietary software world will eventually become stong allies with OSS, ultimately creating a partnership that will benefit everyone. Only the most staunch separatists or greedy technologists won't embark on this grand union of ideologies and worlds. But there place in the world will be thankfully small. It is the flexibility and willingness to adapt that has brought OSS this far, and it will be that trait which will drive OSS full speed into the future.