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
|
