5. Best practices for FLOSS adoption
From SME Guide
The migration and adoption process is a complex, multidisciplinary effort that touches different areas and require a complete understanding of how individual workflows are composed and executed and how people interacts with IT systems in their daily work. In this sense, a FLOSS migration is a major endeavor, and as most complex efforts can easily go wrong. There are several hurdles in the execution of a migration, and some of those hurdles can be avoided easily by using simple practices. Most of the difficulties are not really technical in nature, but organizational, and will require most effort from the upper management; another important aspect is the social impact of the migration (like user acceptance), that may require special attention.
Management guidelines
The main drive for a successful migration to FLOSS 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.
Be sure of management commitment to the transition
Management support and commitment have been repeatedly found to be one of the most important variable for the success of complex IT efforts, and FLOSS migrations are no exception. 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 public administrations where changes 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.
Prepare a clear overview of what is expected from the migration or adoption, 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. 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 judgment on the migration.
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 FLOSS 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.
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 FLOSS.
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.
Avoid “big switch” transition, and favor 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. Such a scheme can be depicted as: [KBST 06]
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.
Technical guidelines
A significant difference in FLOSS 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.
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. See the previous chapter on how to select and analyze a development project.
- 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”.
Create a complete survey of software and hardware that will be affected by the migration, and what functionality the company is looking for
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 fulfill 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).
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 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. Note that in many cases, it is not necessary to produce software or code, as most adaptations are related to selecting the appropriate package, change the graphical appearance, or providing templates and presets.
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 default install of 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.
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.
In selecting packages, always favor stability over functionality
Among the many potential packages available for every function, there is always a balance between functionality and stability. 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.
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.
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, especially in medium sized companies when user feedback is more difficult to collect. 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 analyzing 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.
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.
Social guidelines
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.
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).
It is important to provide enough information and support to be able to skip the “opposition gulf”: [IBM 06]
Troubleshooting point: when internal users believe that the migration is done to pay software less
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 FLOSS 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.
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.
