Advertisement
The developers' conference: Userspace, kernelspace, and Xspace
Weekly Edition
Return to the Front page| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
The EU Open Source Migration Guidelines
Much of this document will seem like basic common sense to many readers. Remember, however, that the target readership is high-level management, and one should not make too many assumptions with that crowd. Thus, for example, we have suggestions like "have a clear understanding of the reasons to migrate," "start with non-critical systems," and "ensure that there is active support for the change from IT staff and users." All of which is undoubtedly good advice.
The guidelines repeatedly suggest that, even if no changes are foreseen in the near future, it is still a good idea to avoid doing things that would make such a change harder in the future. Thus, web pages should be written to work with all browsers, excessive use of scripts and macros in documents should be avoided, standard file formats should be used, etc. This suggestion, by itself, would make life a lot easier for many people even if they never switch to free software.
The guidelines make specific suggestions for software to migrate to. These include OpenOffice.org (best Office replacement, can run on Windows), Evolution, Galeon (or Mozilla if it has to run on Windows too), MySQL, Exim (Postfix is "an acceptable alternative"), PhpGroupWare, Apache, and Zope. The report recommends GNOME over KDE ("netproject considers that [GNOME] has a better architecture and believes it has a better future").
A great many migration scenarios are provided; here the guidelines begin to resemble a system administration book. If you are looking for instructions on how to export your Access data for ingest into MySQL or how to convert your Word templates, this document has something for you. As a general rule, the information provided will not be sufficient for those who do not already have some expertise in making this sort of transition. It does, however, show that the transition is possible and highlight some of the potential pitfalls.
The document concludes with 50 pages of appendices. There is a lengthy list of available case studies, a detailed description of how mail systems are put together, some fairly useless tables of package versions, a Red Hat kickstart file for installing systems using the French language, and a glossary.
The Open Source Migration Guidelines may well prove to be a useful document for managers trying to plan (or decide on) a change to free software in their organizations. Its real value, however, may be found in a different area. What the Guidelines provide is a convincing demonstration that this transition can be done, and that the required tools exist. And that may be what many people pondering free software need more than anything else.
(Log in to post comments)