Open Source SW: myths and realities

Laurent Lachal, Senior Analyst

The business and technology press is awash with headlines announcing new and extended open source initiatives in the public sector. The trend spans all continents and all levels of public sector organisations: from local public sector bodies (in cities such as London or Munich), to states (such as California and Oregon), national governments (Denmark, Peru, the UK, and many more) and regional bodies such as the European Commission. Governments are also teaming up to share experiences or engage in common projects. For example, the Japanese, Chinese and Korean governments are negotiating the development of a local version of Linux. Governments look at open source from two perspectives of course: as major purchasers of software and as policy makers. The profound influence of the public sector on the evolution of open source software reflects this dual role. In the case of open source software on the desktop, success or failure will largely depend on how far and how quickly public sector expressions of interest and pilot projects turn into firm commitments to implement.

Focusing on benefits and not the myths of open source software

Ovum believes that there are real advantages in using open source software but that public sector organisations should avoid taking an idealistic view on the benefits and should not close their eyes to the disadvantages. Instead, they should take a pragmatic approach based on a close scrutiny of the current `myths' that surround open source software, including: Low cost. It is important to remember that open source software is not `free' as in `free of cost' but free as in `free to use and share'. Moving to open source software can be costly in terms of integration, migration, management and training. Do your maths and take a long-term view of open source costs based on a clearly defined overall software strategy and IT architecture. Source code access and change Open source software is open to scrutiny and modification, but this is mostly of benefit to vendors. Most user organisations, including public sector ones, do not have the resources and knowledge to take advantage of this feature. Even if they do, they should have more pressing priorities.

Community support

The open source community consists of two distinct groups: experts who contribute to the code base (actually a relatively small group many of whom for company's such as IBM, RedHat and Novell/Suse) and the wider user community with various levels of knowledge: thousands of beta testers (rather than coders) and regular contributors to hundreds of different newsgroups. These people have created an enormous support network surrounding open source software. This network means that systems administrators and developers can gain access to valuable advice, usually within hours. However, this support is not as consistent or timely as professional support. Also, community-based support is not limited to open source. Microsoft for example, which for the past ten years has provided the best developer support in the industry, actively promotes online Usenet forums.

Aside from the prospect of lowering costs, open source is also attractive to governments because it offers a way of exploiting or sharing the significant investments they are making in software development. It certainly makes sense for public sector organisations to consider acquiring the full rights to code that they procure. But "value for money" is as important a test here as it is in making the procurement decision itself. In many cases suppliers will be competitive because of existing intellectual property that they have developed, which can be reapplied to the current project. It is not reasonable to insist that they give up that intellectual property in order to win a contract. Where the development work is substantially "all new", government's should also consider the potential value of shared exploitation agreements. In its simplest form a shared exploitation agreement builds in a discount, sometimes substantial, on the understanding that the supplier will be free to commercialise the resultant software.

In many cases this type of approach will continue to offer the government the best value for money. When an OSS licensing approach is considered appropriate, it is important to remember that there are different classes of OSS licence: there may well be cases where a BSD-style licence (which allows code to be commercially exploited) would be more appropriate than a "strict" OSS licence like the GPL. There also remain question marks over the legality of the GPL model (which SCO is currently challenging in the US). There may also be issues related to the impact of local (non-US) legislative frameworks on the status of open source licensing models. The increasing number of open source licensing models confuses all organisations. Again it pays to do your own homework: adopt a proactive licensing policy that merges the skills and knowledge of business managers, legal advisors and technologists and considers both open source and proprietary software licensing policies.

A stick to beat Microsoft?

As far as Microsoft is concerned do not reduce open source software to a simple negotiation tool. Unless you are serious about it Microsoft will not budge. In many cases, the company refuses outright to change its practices and only do so only when the open source project it has been threatened with is under way. On the other hand, do not totally cave in when Microsoft comes back with a contrite approach and a significant discount. First, why stop at cost-related issues? Try and get the company to adopt more flexible licensing terms. Secondly, scale the open source project down, by all means, but do not scrap it: it will certainly help you next time you negotiate with Microsoft. It will also help you develop your own view on the benefits of

open source compared to other proprietary software products (not just those from Microsoft).

Sourced from: Ovum