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.
Mail
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 BSDs, 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 mp3s 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.
Category:
- Migration