What have they found so far? What makes the transition work well? Are there steps one can take to improve user acceptance and ease transitional issues? He told me some of what they found, and I asked him if he'd be willing to elaborate on the findings for Groklaw, and he graciously agreed.

Official results of the study will be available later. This is a sneak peek, from his point of view, of what they have learned so far, plus some personal observations and tips to reduce migration shock. If you are considering a large-scale migration to either OpenOffice.org or all the way to a GNU/Linux desktop, I think you'll find the data illuminating and his realistic and practical suggestions valuable in making it a smoother experience.

They found that a number of simple steps encourage user acceptance. For example, just changing the default application for .doc, .xls, and .ppt to OpenOffice.org resulted in significantly faster user acceptance of OOo.org, even when Microsoft Office was simultaneously available. Interestingly, the study was in OOo 1.1.x, not in the just-released and improved 2.0, yet acceptance and voluntary switching to OpenOffice.org was a marked finding. He explains how to solve font issues, how to make use of hardware too old for XP by making the switch to GNU/Linux, offers links to tools and notes four significant technologies he's found useful in easing the stress of a large-scale migration. They also have developed some training materials for OOo in flash and sxi format that is available under a Creative Commons license.

Since 1999, Carlo Daffara has been the Italian representative to the European Working Group on Libre Software, the first IST-supported working group to deal with Open Source and Free/Libre Software. The group was created at the initiative of the Information Society Directorate General to analyze FOSS, create a set of recommendations, and write a paper to be presented to the Commission.

He coedited with Jesus Gonzale Barahona the resulting white paper [PDF], presented at IST99 in Helsinki. Since 2000, he has been a member of the Internet Society (ISOC) working group on public software as part of the group committee, and contributed to the Open Source part of the article presented by ISOC to UNESCO on global trends for universal access to information resources. Currently Mr. Daffara is head of research of Conecta, an Open Source consulting company.

***************************

An Overview of Initial Results of a Large-Scale Migration Project
by Carlo Daffara

We have the luck of having quite a large number of different administrations, from a high-specialization Irish hospital to provinces and municipalities from all over Europe, and a large number of external observers. The migration steps are actually two: the first one from proprietary office suites to OpenOffice.org, and the second one is from proprietary operating systems to GNU/Linux. We already have performed a few thousands migrations to OOo (which is ongoing), and just started the Linux one; evaluation of acceptance and productivity has been done using surveys, questionnaires and automated tools that (with the express consent of the user) register some activity statistics in an anonymous way.

Now, the obligatory disclaimer: the opinions expressed here are not those of the European Commission, and the results are preliminary and based on an initial sample; we hope to be able within the end of the year to publish some official deliverables with more consolidated results.

What we have found up to now:

The number of different processes (or workflows) within public administrations is extremely high, and practically all of them require an ICT tool in at least one step. Not considering custom software, the most important desktop tools used are in this order: word processing tools, spreadsheets, and relational databases. (For this reason, the consortium has also developed a set of porting tools from proprietary databases to open ones like PostGreSQL. You can check here for the COSPA-developed Oracle-to-Postgres migration tool, that rewrites the PL/SQL and implements many non-standard extensions to make the code runnable on Postgres; and it's released under the GPL).

In the initial survey group, the number of difficult-to-convert documents (for example containing complex macros or office-related functionality not available on OOo) was very small. In another (non EU-sponsored) migration project, we have found that macros were contained in the internally developed base document templates used throughout the target administration; the effort for migrating those to OOo was relatively small and was the only instance of significant macro usage. Recently developed tools, like Sun's migration toolkit (part of StarOffice enterprise edition) can be used to automate a significant part of this initial effort).

User acceptance is in several situations related to habit; just changing the default application for .doc, .xls, .ppt to OOo raised significantly the usage percentage, and after a few weeks, practically all users switched to OOo exclusively. Training intensity was not very high, and the training material that we have been developed (and that is distributed under a CC license) has been considered sufficient.

In the initial target group, of all the interviewed users, roughly half found that OOo 1.1.x was feature-wise comparable to the commercial version of Office used, while the other half found it less powerful but sufficient to finish all tasks (it is my personal guess that OOo 2.0 would have made it a much smaller percentage). Also, the number of processed document was not dependent on the kind of word processor used. In some cases, more problem were reported by users that had access to both OOo and Office, because they were expecting exactly the same behavior from both applications. Removing Office reduced significantly the complaint rate.

Flexibility is definitely a plus; one of the PAs reported that several very old PCs were in use, and for budget reasons had to be kept in use (166 MHz pentiums with 96M of ram, unable to run XP for example). Using XFCE allowed the administration to put those machines to good use, making an upgrade unnecessary.

And now for some non-COSPA related results I have collected during these years of performing migrations:

It is possible to classify the difficulties of the migration under three different areas: procedural (or managerial), social, and technical. In general, the technical difficulties are not as prevalent or significant as some commercial vendors would claim; in our experience user acceptance (a social issue) is much more important.

Some steps can be significantly simplified with some attention to the user "ecology"; for example, it is easy to identify the "local experts" within a company or an administration -- those experts may be in many cases happy to have such a recognized (albeit in a non-official way) higher technical status among their colleagues, and are usually called for informal help on technical questions. Targeting those users with higher-level courses and training has a limited impact on costs but raises morale and helps in maintaining a positive attitude that is then spread to all the other people performing the migration. Examples of procedural problems have been found by some partners while ordering PCs without Windows, and discovering that it was much more difficult and (paradoxically) costlier than the default acquisition process.

Many problems are related to trivially solvable things; for example, on Linux, font issues arise when importing documents and can be solved with free fonts (NOT the WebFont pack from Microsoft, I wish to stress -- there are very good font alternatives developed by third parties, like for example the Microsoft-like fonts made by the Munjoy Linux project, using the Vera fonts as a base.)

Other reported problems were solved by changing the default margins in OOo, or installing separate components to adapt to the local environment, or in some cases using Wine to run Internet Explorer (while waiting for the adaptation of the web interface to Mozilla or khtml-based browsers).

By the way, this adaptation effort can be seen in many municipality-developed Linux distribution, mainly based on Debian and slightly adapted to reduce the initial impact; some examples are MAX (Madrid Linux), Munich's LiMux, Vienna's Wienux and so on. Within COSPA we have also performed a comparative analysis of more than 40 distributions to help in the initial selection by the PAs that are performing the Linux migration, and we have found several quite suitable to be used as a regular desktop (the main remaining problem seem to be related to hardware support for some WiFi chipsets or some graphic cards).

There are also several packages that are not that commonly used but are quite important in a commercial or public administration setting; for example, we had found the wonderful tn5250j (a java-based terminal emulator for IBM minicomputers) that has more features than commercial equivalents. We collected in the beginning of 2004 some screens and flash videos of them, if someone is interested, at http://desktop.conecta.it/screenshots.html.

There are four significant technologies that can greatly reduce the migration shock, and those are remote computing (like Microsoft terminal services, Citrix ICA, Sun's Tarantella, NX/FreeNX and plain X11) that allow to consolidate and redistribute still unported applications across heterogeneous platforms, web interfaces (both plain vanilla or AJAX-based) that are becoming the norm for most applications within public administrations, web-deployed rich clients (like JNLP or flash-based interfaces delivered through the web, or Eclipse-RCP based) and as a last resort emulation (using non-free tools like VMware or Qemu/Kqemu/qvm86). These can be seen as long-term trends in general, as they reduce the maintenance cost of handling a large number of desktops, and so I am expecting this to continue independently of the Open Source/Open Document push.

And last: don't try a migration just because it is something that seems nice; a migration (any migration -- just ask large companies that switched on WinXP Service Pack2) is a complex endeavour that requires some planning and realism. It may be better to do a shifted migration (not all at the same time), creating non-migrated islands to help in the transition, or phase in new technologies in a progressive way. The nice thing is that Open Source is flexible, and once you have a stable result you can start enhancing or improving a solution in an incremental way quite easily.