(This page uses style sheets.)
There are a number of considerations which can ease the introduction of OSS.
Many of the OSS applications will work on proprietary operating systems and this gives the opportunity to introduce these applications without having to totally change the environment. For instance OpenOffice.org, Mozilla and Apache will work under Windows and so can be used as a replacement for Office, Internet Explorer and IIS respectively. Apart from being less disruptive, this approach means that user reaction can be gauged on a small scale and plans for user training can be made based on real experience. In addition, problems such as converting file formats, macros and templates can be eased if the old application is kept available for a little while.
This approach does mean that the choice of application in the final target environment will be limited to those which work in the current one. For instance the target browser may be Galeon but Mozilla is the only one which will run on both Windows and GNU/Linux.
Make changes in the first instance which will not disrupt the user population. This means making changes on the server first. These will then provide a platform for the introduction of client changes later. Many of the server side changes will be compatible with the current environment as well, so the disruptive effect will be minimised.
For instance, DNS name servers, DHCP servers and back-end database servers with proprietary databases such as Oracle could all be candidates to be replaced with an OSS equivalent and still interwork with the rest of the current systems as before. The detail of this is discussed later.
There are applications such as Samba, which would not be used in a pure OSS environment, but which allow the co-existence of the old proprietary environment and OSS. The early use of these can be very effective in partitioning the environment into manageable chunks.
Do as little as possible now that will make future migration more difficult. For instance:
Insist that all web development done either in-house or by contractors produces content that can be viewed on all current web browsers, in particular OSS browsers. This should be good practice in any case as Administrations shouldn't require specific software to view their content. Tools such as weblint are available to assist in checking the compatibility of web pages.
Discourage the indiscriminate use of macros and scripts in documents and spreadsheets; find other ways of providing the functionality. This again should be good practice since the use of these is a common way in which viruses infect systems. Also, macros can be easily used to steal data and to subvert documents, for instance they could make the document say different things depending on who is viewing it and another thing if printed.
Insist on the use of open standard file formats, for instance Postscript and PDF.
There is some debate over whether Postscript and PDF are open standards or not. This is more of a debate over strict definitions and in particular who controls the standard. In reality these are the only standard file formats which are widely used at the moment, have publicly available definitions and can be used without significant restriction.
Attempts are being made to create truly open standard file formats based on XML and the OpenOffice.org one is a contender. However just because a file is XML based it doesn't mean it will be open.
In particular do not use proprietary file formats for files which are only intended to be read, and not edited, by the recipient. Again this should be good practice because such files are a common way of spreading viruses. Using such formats means that the Administration will be locked into the vendor for a considerable time. Also these proprietary formats can include considerable quantities of metadata, including in particular, previously deleted text, which if viewed by others, could be embarrassing to the Administration. Viewing this metadata is not difficult.
When writing documents in collaboration with others use the lowest common denominator format. For instance make use of Word 97 format rather than the Word 2000 one. This will increase the likelihood that OSS applications can participate.
Make use of open standard protocols. Open standard protocols are defined as those which are free from patents and with an OSS implementation. There are various national sets of standards such as E-gif in the UK, OSOSS in The Netherlands and SAGA in Germany. The focus and content of these frameworks is slightly different but in general they should be adhered to.
Develop systems which are based on at least a 3-tier model (see Section 8.1) where the application code is independent of the human interface and data access methods. For instance, if possible, have a browser interface which can be used on an OSS browser. Building applications in this modular way will make it easier to migrate bit by bit. This will not only reduce the scale of any phase of migration but will also reduce the risk of failure. Traditional monolithic client applications are notoriously difficult to handle.
Insist that all new applications are written to be portable. This includes using portable standardised languages such as ANSI C, Java, Python and Perl, and using only cross-platform libraries and GUI toolkits such as wxWindows (http://www.wxwindows.org/) and the FOX toolkit (http://www.fox-toolkit.org/). Avoid architecture specific languages and APIs. Avoid building applications which require the presence of other proprietary applications.
Move users away from proprietary mail readers which use proprietary mailstore formats and communicate with servers using proprietary protocols. Most mail applications will store mail using IMAP. If possible find a way of storing address book and calendar information in an open format.