simon_phipps
Columnist

LibreOffice on every desk: A 10-step plan

analysis
Mar 29, 20136 mins

Document Foundation has good advice for companies migrating to open, interoperable document formats and open source tools

As the experience of the City of Freiburg in Germany showed, it’s not enough to decide to use open source software — you need a workable migration plan too. Freiburg’s effort seems to have failed because of a lack of investment in the migration and a lack of determination to complete it. As part of the celebration of Document Freedom Day this week, the nonprofit Document Foundation released a white paper with advice on how to perform a migration and standardize on Open Document Format (ODF).

The report, titled “Migrating to LibreOffice to promote software and document freedom,” includes a strong focus on acting purposefully. It’s important to “make users aware of the rationale and objectives of the migration project, so that it is not perceived as a mere solution to budget-related issues.” Why? Because under those circumstances the inevitable challenges that arise from a migration will be seen as a cost of economizing rather than as mitigated by new strengths.

[ Also on InfoWorld: 13 killer open source admin tools | Review: LibreOffice 4 leaves you wanting more | Track the latest trends in open source with InfoWorld’s Technology: Open Source newsletter. ]

What are the strengths of a move? According to the paper, the most important strength is a “significant improvement in document interoperability.” These are delivered in part by extra capabilities of LibreOffice (such as the Hybrid PDF format, which allows all document recipients to see a guaranteed-faithful view of the document via PDF while also allowing editing via LibreOffice) and in part by appropriate defaults — for example, open source fonts being preferred and available on all platforms, or saving as ODF by default so that all software packages can edit files. The paper also mentions the new support for the Content Management Interoperability Services (CMIS), which provides a standard, open interface for auditable document management rather than requiring a single-vendor solution.

The migration guide condenses the hard-won experiences of a number of community contributors who make their living consulting on office productivity migrations. It walks through a 10-step plan:

Step 1: Comprehensive analysis is the essential precondition. Possibly with help from a specialist consultant, a survey of your business use of office tools will reveal third-party applications, plug-ins, templates, and macros in use across your organization. You’ll be surprised by what shows up. The survey will also identify the categories and skill levels of usage across your company.

Step 2: With that information, devise a pilot project. As the paper says, using “a different application with specific strengths and drawbacks … might trigger specific workflow and interoperability issues.” A pilot project will provide management with key proof points and lessons that translate the survey from step one into an action plan.

Step 3: At this point the paper recommends establishing a companywide rule that new dcuments will be circulated in the ISO-standard Open Document Format. My own experiences would augment this advice by telling staff to change their approach to documents and only circulate editable formats — ODF of course — when they know the recipient will need them, and to use Hybrid PDF format in all other cases. This will guarantee interoperability even if different parts of the company are at different stages of migration.

Step 4: Next, the paper recommends installing LibreOffice on every computer in the company, whether or not it’s expected to be immediately used. This is a smart move. It ensures every user can try it out if they want; they will then be able to come to the training later in the process with a little experience and practical examples.

Step 5: Moving on to the actual migration, the paper wisely recommends identifying a cross-function group of “technology leaders” — employees with a knack for using the company’s systems and to whom peers already turn for advice and help about using their computers. These people will be drawn from all levels and functions in the company. They will serve as vanguards for change, as communicators and advocates for the benefits of migration, and they will need to be rewarded appropriately with recognition, status, and perhaps practical incentives. They should be given access to the company’s decision makers and together form the action team for the migration.

Step 6: At this stage, the paper recommends a comprehensive training course for all staff. Offering training is critical; omitting it was a key cause of the failure in Freiburg. My own experience suggests not all staff need the same training. A tiered approach — with basic, advanced, and online training all available for different groups — is more appropriate and less costly. Whichever strategy you prefer, investing in training is a critical success factor.

Step 7: While all this is happening, capture everyone’s observations and questions in a comprehensive FAQ. A shared memory of the experience is an important factor in the success of a migration.

Step 8: While you may have assumed that open source means cutting costs, particularly in regard to “support,” nothing could be further from the truth. Take the money you would have spent on licenses and invest it in professional support. You may well have your own user-facing (level one) and technology-facing (level two) support in-house, but it is important to invest in access to third-level support as well. When you do this, you also invest in the open source community and guarantee the longevity of the code you’re migrating to. Unique among open source projects, the Document Foundation is devising a certification scheme to help you identify third-level support organizations.

Step 9: A critical success factor you may not have otherwise considered is the staff who are not migrating. Your survey from step one will have identified a small population of staff who will have strong business reasons to stick with Microsoft Office. Those people also need training and support in their roles and responsibilities in the new environment. They need to respect the interoperability priorities of the company, stick with standard fonts, and use ODF and PDF to communicate with others. Microsoft Office supports ODF too.

Step 10: Finally, a focused, cross-company communications strategy is needed for the migration. The paper includes a full sample messaging schedule. Surprisingly, it doesn’t highlight one of the easy wins of a migration to open source: Your staff are free to take the software home and use it on their own PCs and Macs, and to give it to the whole family if they want.

The growing importance of the open Web and interoperability underscores the relevance of this week’s Document Freedom Day celebrations. The Document Foundation’s white paper is a useful tool that may just make the difference for your company in migrating to open formats and open source tools. It deserves serious consideration. What company can afford to be locked in to any single vendor strategy any more, even for office tools?

This article, “LibreOffice on every desk: A 10-step plan,” was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

simon_phipps

Simon Phipps is a well-known and respected leader in the free software community, having been involved at a strategic level in some of the world's leading technology companies and open source communities. He worked with open standards in the 1980s, on the first commercial collaborative conferencing software in the 1990s, helped introduce both Java and XML at IBM and as head of open source at Sun Microsystems opened their whole software portfolio including Java. Today he's managing director of Meshed Insights Ltd and president of the Open Source Initiative and a directory of the Open Rights Group and the Document Foundation. All opinions expressed are his own.

More from this author