| About InfoWorld : Advertise : Subscribe : Contact Us : Awards : Events : Store |
 |
||||
|
||||
 |
||||
 |
|
|||
 |
||||
|
|
|
||
|
|||||||||||||||||||||||||||||||
 COLUMN
IT manager's nightmare ON OCT. 19, a very simple e-mail announced the release of Version 1.0.5 of the Nautilus graphical shell and file manager. There were a few new features in the latest release, but nothing earth-shattering. In fact, the release was entirely unremarkable except for one small fact: Eazel, the company that created Nautilus, ceased operations more than three months prior to this release.
If this were the world of closed-source software, this event would have been devastating to customers. Any customer who had employed this software would be scrambling to find a replacement. Plans and cost estimates would be hastily constructed to migrate to a different product. And then there would be the questions to be answered from senior management, "How could you let this happen to us? How could you let us rely on such a fragile company?" A software supplier that closes its doors is the nightmare of every IT manager, but that rule no longer applies in the open-source world. The loss of a company does not necessitate the loss of a software solution. When code is open source, it develops a life of its own even after the demise of a software provider. The source code is available for continuation of the product. In the case of Nautilus, for example, some of the original Eazel developers are still involved in the project, as well as many of the open-source developers who were active before Eazel's demise. The official Nautilus mailing list used by developers has had more than 2,500 messages since the company closed. And Nautilus has grown to be a popular addition to the latest Gnome desktops on new Linux releases. Not bad for the product of a defunct company. Now, had Nautilus proven to be unpopular (and how many organizations really bet the business on unpopular software in the first place?), customers would still have full access to the source code. They could still fix bugs in-house or through contractors, and they would then be free to migrate to different software whenever it served their needs, or continue to develop Nautilus for their own use. This worst-case scenario for open-source solutions parallels the best-case scenario for closed-source solutions. I know of customers who demanded their closed-source software suppliers place the source code in escrow. That way, if the supplier failed, the customer would gain access to the source code. I also know of many customers who were not so diligent or so lucky. When their supplier bit the dust, so did the source code. Even at its worst, open source gives the customer more control over their own destiny than closed source. This is one of the essential elements of open source: The customer receives power that is normally reserved for the software provider. Why would you want it any other way? Russell Pavlicek is an independent open-source consultant. Contact him at pavlicek@linuxprofessionalsolutions.com.  RELATED SUBJECTS  Enterprise ApplicationsDiscuss this article in our online forums MORE > SPONSORED WHITE PAPERS 
SPONSORED LINKS
|
|||||||||||||||||||||||||||||||
|
||||||||||
|
||||||||||
