The Flexibility of Open Source (Page 1 of 1)
Written by
Steve Lake
Posted on: Dec 26, 2007 at 11:56am
Section:
Editorials
Printer Friendly Version
Legacy URL
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.
|
Average vistor rating: 4.4 out of 5 (8 total votes) | |
|
Latest Articles
Upcoming Shows and Cons
Announcements
There are no current announcements.
How often do you change distros?
Latest Releases
(courtesy of Distrowatch)
More
|
