Introduction File Formats The Desktop O/S
I've long been a fan of open source software. It offers high quality at a low cost. That said, until recently I would not have recommended a general deployment of an open source O/S on business desktops. Lack of applications, lack of support, and general ease of use concerns, all conspired to make it a risky proposition at best. However, the balance is shifting. Projects like Mozilla and OpenOffice are at a stage where they offer acceptable alternatives to the Windows products they compete with. The fact that they work on Windows, and interoperate with Microsoft products, offers businesses a great starting point for a migration. Building dual-boot systems, with access to Windows files from the second O/S, further eases the transition, (and offers a way out), and is now a routine operation, rather than a black art. Support from big names like IBM and Oracle, coupled with the growth of open source specialists such as Red Hat, Mandrake and SuSE, validates open source as a mainstream proposition, rather than the choice of maverick IT managers. On the server side, cross-platform file, print and authentication projects, (samba in particular), make it possible for an open source server to serve Windows clients in a transparent way. In almost all other areas, open source server software is first class. The time, cost and effort involved in a switch to an open source desktop should not be underestimated. That said, the quality of the technology, and the availability of support, finally makes the switch a viable option. Oddly enough, my ideal desktop changeover strategy begins on the server - the mailserver to be specific. In my opinion, the notion that an organization needs to consolidate all user mail storage on centralized mail servers, (usually of the Exchange variety), is total MS BS. I would estimate that 80+% of all stored mail is complete and utter garbage. My preferred solution would involve centralized qmail mailservers, with "local" storage of user mail, ("local" is in quotes because it may make sense to store mail on shared nfs- or samba- mounted fileservers for backup and control purposes). Once mail is localized, and using standard protocols, switching the mail client application becomes significantly easier. For mail that genuinely requires centralized storage, (projects, planning, etc.), I would use ezmlm, (qmail's mailing list software). Setting up a mailing list is not as complex as you might think. By default, qmail and ezmlm will allow any user to set up a mailing list with a single command. This includes fully automated subscribe, unsubscribe and help email aliases. Since each list gets its own storage folder, it's easy to ensure that important lists are stored on central servers. Adding a simple web based interface in front of an important mailing list will ensure that the appropriate corporate search engines can index it. The cost and risk involved on the server side in this kind of changeover are significant. However, client side changes, including retraining users to familiarize them with mailing lists that are accessible via corporate search engines, should not be too difficult, since users who are familiar with browsing should find the new approach very intuitive. File Formats When considering a change to open source software, Microsoft's proprietary and ever-changing file formats are probably the biggest obstacle for most businesses. Switching file formats, (and associated applications), is not an area where you can take a back seat, waiting for open source filters and converters to achieve full compatibility with Microsoft products. If you do, you will be waiting forever. As long as Microsoft has a majority share of the market, it is in their own commercial interests to keep evolving file formats so that competing products have to play catch-up. In my opinion, filters are now good enough to facilitate a switch for most common business applications. However, making any switchover a success will still require careful planning and execution, and, maybe more importantly, total commitment from staff and management at every level. I would recommend a two-step approach. In the first step, Microsoft file formats and products are retained, but constructs and features that are not handled well by open source replacements are phased out of all active, and key historical, documents. In the second step, open source file formats and applications supplant their Microsoft equivalents. New documents are saved in the new formats. Old documents are converted as required. Microsoft products are retained, (at least on strategic PCs), to handle the inevitable unforeseen conversion difficulties. It would be foolhardy to underestimate the difficulty of this changeover. It should be undertaken while the desktop is still running Windows, and should not overlap with other steps in the overall conversion strategy. The Desktop O/S So far, my suggested conversion strategy has concentrated on application software. The final step in a migration should be the conversion of the actual desktop O/S itself. The choice of O/S, (one of the BSD's, or a Linux distribution), is largely a matter of personal choice - all the major distributions support most common hardware and open source software. Aside from cost and support considerations, it would be advisable to test potential O/S candidates against as much legacy hardware as possible, as support for old or unusual hardware will vary. It is important to manage expectations during the transition. The switch will involve sacrificing some functionality, at least until alternatives can be put in place. Being open, (excuse the pun), about the long-term cost savings and the reduced dependency on a single vendor, is essential to ensure that employees understand why they are being asked to accept this reduced functionality. One final consideration: Presumably, you will have ensured that all critical business needs are met by the new O/S. However, it is also worthwhile considering non-essential, and even "recreational", applications. For example, if employees are allowed to listen to CDs or private mp3's while they work, taking the time to ensure that sound drivers and applications are installed will be worth the effort. Failure to do so may engender resentment toward the new O/S among users who do not have the skill to install the necessary software themselves. Assuming you can get your organization this far in the conversion process, I doubt you will ever look back. |
