decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


To read comments to this article, go here
Management Guidelines on Migrating to Open Source/OpenData Standards Software, by Carlo Daffara
Monday, June 05 2006 @ 03:26 AM EDT

Guidelines on Migrating to Open Source/Open Data Standards Software

~ by Carlo Daffara*

1. MANAGEMENT GUIDELINES

The main drive for a successful migration to Open Source and Open Data Standards software(OS/ODS) always starts with a clear assessment of the IT landscape, a clear vision of the needs and benefits of the transitions and continual support. The differences of OS development models and support may require a significant change in the way software and services are accounted for and procured, and in general a shift of responsibility from outside contractors to in-house personnel.

1.1 Be sure of management commitment to the transition

Management support and commitment have been repeatedly found to be the single most important variable for the success of complex IT efforts, and OS/ODS migrations in particular. This commitment must be guaranteed for a time period sufficient to cover the complete migration; this means that in organizations where IT directors are frequently changed, or where management changes in fixed periods of times (for example, in Pas where election happens frequently) there must be a process in place to hand over management of the migration. The commitment should also extend to funding (as transitions and training will require resources, both monetary and in-house). The best way to insure continued coordination is to appoint a team with mixed experiences (management and technical) to provide continuous feedback and day-to-day management.

Troubleshooting point: If the only people working on planning the migration is from IT/MIS, there may be insufficient information in upper management and financial planning for continuing the migration after the initial step.

1.2 Prepare a clear overview of what is expected from the migration, including measurable benchmarks

The transition can be started for several reasons, including better control on IT costs, independence from suppliers, flexibility or support of open data standards. To be sure that the migration is effectively producing benefits or is going accord to the migration plan, it is fundamental to know beforehand what indicators will be used to evaluate the progress.

For example, to insure that the quality level offered to the user is equal or improved, a set of measurement similar to those taken with the COSPA PROM tool may be used (number of documents worked per day, time per document, number of completed workflows per unit of time). Those requirements must be realistic, in particular expectations of TCO reductions must be compared with publicly available data for comparison.

Troubleshooting point: If the only perceived advantage is that “the software comes from the net for free”, there may be a set of wrong assumptions that will probably lead to a final negative judgement on the migration.

1.3 Make sure that the timetable is realistic

The introduction of a new IT platform will always require a significant amount of time; as a rule of thumb the time to perform a full transition to OS/ODS may be considered to be comparable to that of the introduction of a new company-wide ERP (enterprise resource planning application); for smaller transitions, time effort should be scaled accordingly.

Troubleshooting point: When migration time is measured in days, and no post-migration effort is planned, the process may be forced to a stop after the planned resources are expended.

1.4 Review the current software/IT procurement and development procedure

As implementation effort is shifted from commercial to open source software, the procurement and development process needs to be updated accordingly. In particular, the focus may change from acquisition to services, as less software is bought “shrink-wrapped” (commercially bought), and this change may require changes in how the internal IT budget is allocated.

Internally developed software will require a porting or a rolling transition to new software that is either multi-platform or accessible using standard interfaces (for example, web applications), and this should be taken into account in the overall IT plan.

Troubleshooting point: When no change of procurement and development is planned, the management may have not understood the scope of changed required for the adoption of OS/ODS.

1.5 Seek out advice or search for information on similar transitions

As the number of companies and administrations that have already performed a migration is now considerable, it is easy to find information on what to expect and how to proceed. In this sense, the COSPA project has developed an online knowledge base that is accessible through the main COSPA site ( http://www.cospa-project.org); public administrations can also contact their local Open Source Competence centre, that will provide information and support in the migration process. A list of those centres may be found in the IDA Open Source Observatory site at the address http://ec.europa.eu/idabc/en/document/1631/471

1.6 Avoid “big switch” transition, and favour incremental migrations

Most large scale migrations that are performed in a single, large step (involving the abrupt change from one IT environment to the other) are usually marred by extremely high support and technical costs. While the need to support more than one environment does increase support and management cost, “gentle” or incremental migrations usually bring a better overall experience for the users and result in minimal disruption on business processes. An example of gentle migration can begin with the migration of server side applications, that are usually standards or network-based and thus easier to replace, leaving desktop and user-facing applications last.

1.7 Assign at least a person to interacting with the OSS community or the OSS vendor, and try to find online information sources

A significant advantage of OSS is the availability of online free resources, in the form of knowledge bases, mailing lists, wikis (collaborative sites) that may provide a substantial support in many cases comparable to commercial offerings. The biggest problem is the identification of such knowledge sources; in this sense assigning a resources to find, categorize and interact with such sources is a way to reduce the cost of support; a common way to provide a unified source of information is by setting up a small intranet web page with links to online resources.

Troubleshooting point: When no one knows where to find information on the tools that are in use, or when everyone has to search on web sites on their own for finding usage tips.

2. TECHNICAL GUIDELINES

A significant difference in OS/ODS adoptions is the different development model adopted by most open source projects, and the difference in delivery of updates and support. This requires a change in the way adoption and updates are handled, to reduce as much as possible interoperability problems.

2.1 Understand the way OSS is developed

Most project are based on a cooperative development model, with a core set of developers providing most of the code (usually working for a commercial firm) and a large number of non-core contributors. This development model does provide a great code quality and a fast development cycle, but requires also a significant effort in tracking changes and updates. The adoption of an OSS package should be suggested when:

  • when the project itself is “alive”, that is it does have an active development community. In this sense, independent ratings like OSMM (Open Source Maturity Model) and BRR (Business Readiness Ratings) may be useful to help in assessing the liveness and maturity of OS software.

  • when there is a clear distinction between “stable” and “unstable” software. In many projects, there are two distinct streams of development, one devoted to integrating the latest changes and addition, and another focused on improving stability and bug fixes; periodically, the developers will “freeze” development to turn the unstable version into the stable one, and create a new development, bleeding-edge version. This distinction allows the developers to satisfy both the users willing to experiment with the latest functionality, and those using the software for day-to-day operations, but requires an extra effort in collecting information and new versions.

If new functionalities or fixes are necessary, it may be easier to ask for a commercially supported version of the software; in many cases, the commercial vendor will also contribute financially to the open source project.

Troubleshooting point: When the IT manager or the developers think that OS is some kind of commercial software that someone has put for free on the net, and that it “just works”.

2.2 Create a complete survey of software and hardware that will be affected by the migration

There can be no successful migration when the initial situation is not known. Most companies and administrations have no process in place for auditing software and hardware platforms, and thus are unable to quantify the number of tools and software that needs to be replaced or integrated in an OSS migration. The survey process must also take into account the number of concurrent users, average use across the organization, and whether the software uses open or closed communication protocols and data formats. This survey will be the basis for the decision of what users will be migrated first, and for taking into account the cost of software re-development or migration to a different data format. Automated software inventory tools are readily available, and may reduce the cost of performing the inventory and allow for a stricter control on installed software (thus reducing the maintenance cost).

Some of the aspects that should be surveyed are:

  • used data format, both at the document exchange level, database and network protocol level

  • list of used applications, including those internally developed, macros and active documents

  • available functionality

  • shortcomings and problems of the current infrastructure

It is fundamental that the migrated software can fullfill the same functional requirements of the current IT infrastructure, and usually improve on that in functional terms or in inherent quality (like availability, reliability, performance).

Troubleshooting point: when the only inventory is some spreadsheet listing individual PCs, the inventory methodology is probably not in place.

2.3 Use the flexibility of OSS to create local adaptations

The differentiating thing of OSS is the flexibility and freedom that it gives to users and developers in creating new versions or adapted versions of any package. This flexibility can greatly enhance the perceived value of OSS, for example it is possible to create customized packages that contain local configurations, special fonts and other supplemental material like preset macros and templates commonly used in the public administration or company. Also, custom look and feel may significantly improve user acceptance, both by presenting a nicer looking desktop, and by maintaining common links and menu entries.

These customization can be integrated in a simple way in the most used Linux distributions, or by creating a local repository of software.

2.4 There is much more software available than what is installed by default

Licensing or design issues limit substantially the amount of software that is usually included in the most used Linux distributions. For example, only a few include playback capability for the most commons audio and video format, due to licensing and patent issues; for the same reasons, some packages that may be of interest to only a minority of users are not included in the default installs.

For this reason, it is important to research and include in the default installs additional package that may help in the transition period; such packages include additional fonts, multimedia tools, and other packages that may be useful in a mixed environment. For an initial list of useful tools, it is possible to consult the COSPA D2.1 deliverable.

2.5 In selecting packages, always favour stability over functionality

Among the many potential packages available for every function, there is always a balance between functionality and stability. This replicates the development model discussed in point 4.1, and thus requires a careful choice for the IT administrator. In general, among the potential candidate packages that satisfy the functional requirements for the migration the preference should be given to the one that is more stable, thus having a longer real-world usage (and thus more information available for the administrator) and lower variability between different releases.

Troubleshooting point: When the IT administrator wants the latest version of everything on user's desktop.

2.6 Design the workflow support infrastructure to reduce the number of “impedance mismatches”

Every transition from an ICT infrastructure to another leads to some “impedance mismatch”, that is to small differences and incompatibilities; this can be observed for example by translating documents from one data format to another. The overall infrastructure should reduce the number of such transition points, for example by redesigning the document templates in the ODT open format instead of reusing previously developed versions made using proprietary tools. This reduces greatly the formatting and style differences that arise when one format is translated into another.

Troubleshooting point: When no document gets rewritten in the open data standards, there is probably no attention to the formatting quality of documents or in reducing the translation effort.

2.7 Introduce a trouble ticket system

A difficulty of every new IT deployment is the assessment of user satisfaction and the degree of acceptance of the new solution. An online trouble ticket system may provide an easy and simple way to collect weak points in the deployment, and can help in identify users that may need additional training by analysing the per-user submission statistics. It may also point to weaknesses in the deployment, for example by pointing to several trouble tickets related to a specific area.

2.8 Compile and update a detailed migration workbook

A large scale migration effort requires a coordinated action, and clear and updated information. The best way to provide this information is through a “migration workbook”, a single information point that provides the collection of documentation prepared for the migration (including the rationale, the detailed plan and the technical documentation) and the timetable, updated according to the project progress. This also simplifies project management when there is a change in the team performing the migration.

3. SOCIAL GUIDELINES

3.1 Provide background information on OSS

A significant obstacle of OSS adoption is the acceptance by the user, that usually has a very limited knowledge of open source and open data standards. In many cases, OSS is perceived as lower quality as it is “free”, downloadable from the internet like many shareware packages or like amateur projects. It is important to cancel this perception, and to provide information on how OSS is developed and what is the rationale and business model that underlie it. The COSPA deliverable D8.2 provides a complete overview of OSS-based business models and can provide an initial reference manual.

3.2 Don't force the change on the users, provide explanations

The change of IT infrastructure will force a significant change in how the users work and use internal resources; this change may cause resistance by the users. Such change may be simplified by explaining clearly why and how the change will happen, and what benefits will be introduced in the long term both internally (like lower cost, better flexibility and security) and externally (openness, adherence to international standards, less burden on external users).

Troubleshooting point: When internal users believe that the migration is done to pay software less (this may also be related to point 5.1)

3.3 Use the migration as an occasion to improve users skill

As training for the new infrastructure is required, it may be used as a way to improve overall ICT skills; in many companies and public administrations for example little formal training is usually performed on users. This helps not only in increasing confidence, but can also used to harmonize skills among groups and in general improve performance.

This may rise some resistance from the so called “local gurus”, that may perceive this overall improvement as a lessening of their social role as technical leaders. The best way to counter such resistance is to identify those users, and suggest them to access higher-level training material (that may be placed in a publicly accessible web site, for example).

Also, it may be useful to identify local “champions”, that is local OS/ODS enthusiasts, that can provide peer support to other users, and offer them additional training occasions or management recognition. In general, it is useful to create an internal intranet accessible page that provides links to all the different training packages (there are many of them available for free, like those developed for the COSPA experimentation), to complement traditional class-based training with self pacing.

3.4 Make it easy to experiment and learn

The licensing freedom that is the main point of OSS allows for free redistribution of software and training material; in this sense, providing users with Linux live-CDs (that require no hard disk installation) or printed material that can be brought home may help in overall acceptance.


*Carlo Daffara reported the results of a European research project called COSPA, Consortium for Open Source in the Public Administration, that is performing a controlled study on the adoption of Free/Libre Open Source software (FLOSS) and open data standards on the desktops of several European public administrations: "An Overview of Initial Results of a Large-Scale Migration Project". 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.

Copyright © 2006 Carlo Daffara


  View Printable Version


Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )