Dave Richards is an IT administrator for a city government. The city has been using OpenOffice.org for about six years. Dave's a Linux guru, and helps run an elegant, efficient Linux network with a nice big server and lots of fairly old dumb terminals running OpenOffice.org at a very acceptable speed.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
The city government
Richards is proud of the fact that the city has never officially used Windows. He started in 1993. At the time, they were using character-based WordPerfect on VAX and SCO Unix. It worked just fine, and they upgraded through WordPerfect 6, the first graphical version, and then to WordPerfect 8, which ran in X Windows. Life was good for the IT department; administration of the Unix network was easy and powerful, and everyone used WordPerfect.
What triggered the migration: A single office suite that runs on Linux
In the late 90s, WordPerfect stopped supporting their Unix version. The city tried out a WordPerfect version on Java, but it was far too slow. To make things more complex, some users had Excel and PowerPoint on a few Windows computers, rather than the Corel spreadsheet. In short, this was making things complicated with too many operating systems, some computers off the network and lots of different applications to support.
The city very much wanted to keep running Linux and to support just one office suite. They evaluated StarOffice, but there were problems, especially in relation to remote display from the server to thin clients. However, OpenOffice.org was announced later and, because of the open source nature of the development, city IT employees were able to work closely with the OpenOffice.org developers. The developers put in fixes to improve performance in the multi-workstation environment. The developers and city employees also put in a lot of work on the WordPerfect import filters. Conversion of old documents was the hardest technical issue.
At this point, OpenOffice.org was a usable solution. They had found what they considered a good solution: an application with equivalents for WordPerfect, Excel and Powerpoint that ran in a multi-workstation Linux environment. After a year of testing, they officially switched to OpenOffice.org in 2003.
Transition process: Training and conversion
The city brought in an external training company, who learned the program and provided training over a period of two weeks. The entire time span, from the beginning of the transition to when users were expected to use OpenOffice.org exclusively, was six months.
One fact of life in the public sector is the requirement that they keep many documents. Upon switching, the city had at least 15 years of WordPerfect documents, some created in the character-based version, to convert. The libwpd tool that helped with conversion and Richards wrote a script that simply scoured the network, looking for WordPerfect documents and creating converted copies. Conversion wasn't perfect by any means; some documents opened correctly, some had problems because the conversion didn't work correctly, and some simply looked a lot different because they were created by users who weren't experts with word processing tools.
OpenOffice.org on a Linux network with shared memory
The city IT infrastructure essentially runs from one big Linux server. Dave can get 300-400 people running OpenOffice.org from one server, given enough memory on that server. Shared memory is the key to this. For instance, when user "Jill" logs in, she uses 200 MB of memory to run OpenOffice.org and 10 MB of memory for her documents. Then, when John starts OpenOffice.org a minute later, he is simply connecting to the running program, not starting it. He just needs the memory for his documents.
Richards acknowledges that frankly, it wasn't easy. "The perception is that if you only had Word, there would be no problems," he said. While not everything worked the same way or with the same ease, there was almost always a way to do something in OpenOffice.org.
The technical issues were less of a problem than "hearts and minds." Users were attached to their software, whether WordPerfect from use on the job or Microsoft Office from use at other jobs or at home. Advanced users generally made the switch without too much trouble, though a fair number raised issues about macros and advanced Excel features. Richards found that in almost all situations, however, he could find a way to do in Calc what had been done in Excel.
Users with limited computer skill sets made progress more slowly; this was due in part to unfamiliarity with OpenOffice and resistance to learning the program. Luckily, the city administration was fully behind the change. Users often made statements to IT that just weren't true, says Richards. These statements ranged from claiming that a feature didn't work, when it did, to saying that a feature was much simpler in Word when it often wasn't.
Richards zeroes in quickly and frankly on the essentials. "Get the administration 100% on board, or they won't put up with the complaining. If you don't, you're doomed. Set expectations, with the administration and with users, of 95% success."
He also lists the following items that he would recommend to anyone else converting to OpenOffice.org:
- Farm out document conversion. It's a big job, and users' negative attitudes toward the transition were colored, in part, by the prospect of fixing converted documents, on top of their regular jobs.
- Make training mandatory. The city provided training during the transition, and continues to do so. However, the IT department faced a frustrating combination of providing training, then getting numerous complaints and questions from people who could have but didn't attend the training. Sometimes, users were signed up, but either complained to their managers and were allowed to skip, or simply didn't show up.
- When working with users and troubleshooting, determine the goal and work from there; don't simply answer the question that's being asked. For instance, if a user is having trouble writing a macro, find out the goal. It's likely that there is a feature or function that accomplishes the goal.
- Get the IT employees involved in OpenOffice.org. There are mailing lists, bug submission sites, beta releases and other ways to get involved in the software development process and giving feedback.
- Understand and try to get users and administration to understand that problems with document conversion are not problems with OpenOffice.org. Many attributes of a document are based on the available features of the version of the operating system you're using, the version of the office suite you're using and even the printer you're using. A document shouldn't take advantage of features that depend so specifically on one environment that when it is in a different environment, problems are going to occur. Try to make documents as environmentally independent as possible by restricting options such as fonts and printers.
Richards notes that OpenOffice.org runs very well on a centralized Linux network. However, he warns, if you're going to switch to OpenOffice.org and a centralized Linux system, don't do it all at once. Make a five-year-plan and do one thing at a time. Switch the office suite and get that working; then, switch the operating system. Once you've completed the application migration, then switch to a centralized system.
The city has been using OpenOffice.org, counting the initial conversion, for four years. They are, by and large, happy with the program, and happy to have retained their Linux infrastructure. "Linux and, more specifically, OpenOffice.org require virtually no ongoing attention. I have cron scripts that delete temp files, and the servers are on a reboot schedule just to refresh fragmented memory."
"I'll put it this way," Richards adds, "There are seven hundred users on this network, and I haven't been beeped at home in a year."