Have you ever noticed that the people declaring Linux inappropriate for the corporate environment seem to be invariably those who've never actually tried doing it?
Meanwhile, over and over, we hear others who have done it lauding the incredible stability of their Linux systems (often while they're finding NT or other systems much less stable), and raving about the speed and quality of the Linux community as an alternative to traditional "support".
Then we hear from people who took the conservative approach, got a system from a big company (maybe a Solaris or NT box), paid top dollar for "support" from that big company... only to discover just how frustrating that "support" can really be. As someone said: "Vendor support is a myth."
Horror stories about vendor support abound, while the applause is light and sparse. While corporations get warm fuzzies from support contracts because they have accountability, all too often they have to fall back on that accountability because the support sucks so badly as to be inexcusable.
While Linux isn't backed by an enormous company like Sun or Microsoft, or indeed any single company, there are companies (like Caldera) that do stand behind their versions of Linux and offer traditional vendor support. This is often overlooked by those who jump to the conclusion that Linux is "unsupported" just because most things are fixed by the Linux community in general rather than a specific vendor who is held accountable for all Linux systems in the world.
Also overlooked by those who don't actually try it is the point that most important bug fixes and security patches often get fixed for Linux long before traditional vendors get around to releasing a patch, assuming they even bother to patch it at all.
How many bugs are deemed too insignificant for the vendor to bother fixing, or get "fixed" in an unsatisfactory fashion, or a damagingly untimely fashion? What recourse do you have? Sue the vendor for failure to live up to the support contract? Even if this does work (and I doubt it's common), that doesn't fix the problem. The "accountability" of a vendor support contract guarantees you have someone to blame the lack of a fix upon. It does not guarantee that the fix you want will materialize. Given the choice, which is more important? Having someone to blame when they can't or won't fix your problems? Or getting the problems fixed?
At least with Linux, you can pay someone to fix a specific bug that matters to you, or even take a stab at it yourself if you have the skills. If it bothers enough people, there's a good chance that someone else will take the trouble, in which case you get it for free. (This is how much of the "Linux support" actually works.) If you're largely alone in caring about the problem (or viewing it as a problem to begin with), then you can always pay a qualified consultant to fix the problem your way. That's simply impossible with a proprietary vendor system. You're not tied to the whims of a vendor when you have the source code available.
Linux started out as a student's small toy project started out of pique at the cost of buying MINIX for educational and personal purposes. It would have remained an obscure footnote in history, just another student project, but for one crucial distinction.
Out of simple pragmatism and common sense, Linus Torvalds managed to develop an entirely new and enormously powerful development and debugging paradigm for Internet-based software development.
Building on Richard Stallman's initial success with the Free Software Foundation and the GNU project, Linus also uncovered a flaw in the FSF's approach. It wasn't any special genius; he was just being pragmatic rather than idealistic.
Look at the results. In a few short years, Linux has evolved from a small, Intel-centric experimental Unix-like student project to one of the most widely-ported, featureful, efficient and robust Unix systems in the world, well-suited to mission-critical applications despite the misgivings, fears and prejudices of the uninformed.
The difference between the FSF approach and the Linux approach was observed by Eric S. Raymond, verified by him on a smaller project (not just a fluke), and then described in his now-landmark paper, "The Cathedral and the Bazaar".
Eric's paper, in turn, was a key factor in Netscape's audacious decision to release the source code to their world-class web broswer, against all conventional wisdom. They did this on March 31, 1998, true to their announcement on January 22, 1998. It's a daring move, but I believe it will pay off handsomely for Netscape. In fact, I expect it will revolutionize the entire software industry over the coming years.
Why do I believe this? Several reasons. Linux has already demonstrated the enormous power of the "bazaar" development model. Netscape's browser is the perfect product for the logical next step -- applying the most powerful development model ever seen to traditional commercial software. While Netscape's move is arguably an experiment, it is nevertheless a pioneering experiment.
This is one of the highest profile experiments that could have been possibly been chosen. Fortunately, this is an application that is enormously popular worldwide, already considered to be top-quality by traditional commercial software quality standards, and one that freelance programmers have been dying to get their hands on anyway. Thus it is the perfect pioneer for a revolution in the software industry; Netscape has performed an invaluable service to the world, and cannot be praised highly enough for the selfless risk they're taking. (Some call it desperation, but I call it inspired.)
Also, because this is such a high-profile experiment, the Net community can't overlook the crucial importance of making this experiment work. Were it to fail, the consequences would be severe, and easily set back the open-source movement by a decade or more. This danger will motivate people that much more than the sheer joy of working on a world-class commercial application with some of the best minds in the world, who will be similarly motivated.
I really don't see how this can fail; there are simply too many developers in the Linux community alone that will be drawn to this project like a magnet, and the programming attention donated to this project will be just as enormous as the public and industry attention to the outcome of this experiment.
When this experiment succeeds and we see Microsoft's Internet Explorer lag further and further behind Mozilla in features and stability (since even Microsoft's legendary might is no match for the entire Net community), other companies will follow Netscape's example. And the first vendor in each niche to follow suit will have an enormous advantage over their followers, which provides great incentive, once this curious new business model is proven.
Once it becomes an industry trend, Microsoft will be presented with the same dilemma that the rise of the Internet did. They will either jump on the bandwagon late in the game or be marginalized as the market moves forward without them. Either way, it spells the doom of Microsoft's endless plans for worldwide domination; open-source software can't be defeated by hiring more programmers. The Internet was a force too powerful for Microsoft to deny, and the open-source trend will be the same.
Okay, I could be wrong here. I could be misreading the situation or overestimating the importance of these factors. Today is April 3, 1998. It's early in the game for world domination. But I think the open-source trend will revolutionize the world (entirely for the best), and we all have a fairly short list of key players to thank when the game is over:
P.S. Although Netscape couldn't release SSL cryptographic code in the Mozilla source, an open-source version of SSL was integrated with the open-source Mozilla code in under one day. It's a sign.
Copyright 1998 by Deven T. Corzine. <deven@ties.org>