Imagine a world where software is free. For the moment, let's not split hairs about this. In this imagined world software costs virtually nothing to obtain. And you are free to do things with this software - free to study how it works (which means getting access to the underlying code, not just the binaries or executables); free to modify that code to suit your needs and/or improve it; free to re-distribute that modified code. And everyone else is free to obtain, study, modify, and redistribute software as well as you.
This is not the world you live in.
You live in a world in which some software is free in the sense described above. Most of the other software - and this category might cover the full range of your experience - you pay to use. That is, you pay for the right, in the form of a licence, to use the software. The licence sets the limits on your use. Typically, you are not free to study how the software does what it does. You will almost certainly only have received compiled, executable files with your licence. It follows you do not have a right (and more importantly your licence probably explicitly states this), to modify the software and redistribute your derived program. What you have is a right to use the software for whatever time agreed by the licence. (Some licences require you to pay to renew them on a yearly basis.) And you have the right to use that software roughly in the manner envisaged by the company that produced it.
There is a struggle going on between those who wish the imagined world to become the real world and those who would prefer it not even to be imaginable. That struggle, its manifestations and ramifications, is not the subject of this article.
Rather, the subject of this article is software choice, and more specifically the critical choice factors that go in to institutional IT decision-making.
OSS Watch  is the national open source software advisory service for UK Further and Higher Education established by the Joint Information Systems Committee (JISC) to provide unbiased advice and guidance on free and open source software . We aim to help senior IT decision-makers, IT managers, technicians and academic end-users to understand and work with free and open source software.
It is important to make clear at the outset that OSS Watch is not an advocacy group. There are many advocacy groups about on all sides of the software debate . They serve a valuable purpose representing and lobbying for the interests of their constituencies. OSS Watch, for good or ill, must walk the narrow path between them all. We have no ideological or financial stake in the software decisions made by UK institutions. Our sole interest is to aid our stakeholders in UK HE and FE gain a better understanding of the issues at hand. As Colm Butler, Director of the Information Society Policy within the Department of the Taoiseach, noted at the recent Open Standards and Libre Software in Government conference organised by FLOSSPOLS, there is much to be done to help promote understanding through clarity . OSS Watch is part of that project.
If we are clear both on what OSS Watch is and what it is not, it is also sensible to establish from the outset what we understand by the terms free and open source software as a precursor to sensible discussion of software choice in UK institutions. When 56% of HE and 82% of FE IT strategies in the UK do not even mention free and open source software , it seems doubtful that the full range of options are in fact being considered in an effective manner, if at all.
For our purposes open source software is software distributed under an open source licence. The open source licences available are those that meet the 10 criteria laid out in The Open Source Definition . The definition itself is maintained by the Open Source Initiative (OSI)  which has certified more than 50 licences which do in fact meet these conditions.
The expression free software refers to software that meets the conditions of The Free Software Definition . The Free Software Foundation (FSF)  maintains its own list of licences  which qualify as free software licences, distinguishing between those that are compatible with the GNU General Public License  and those which are incompatible.
It is not surprising to find licences at the root of one view about what free and open source software is. Software is copyright material. (I am deliberately setting aside some rather momentous decisions being taken at the moment in Europe concerning software patents .) Along with other copyright material, when you receive a copy of the item in question you also receive some direction as to what can be done with the item. The licence spells out the range of actions you may perform or are prohibited from performing. The latest bestseller at the newsstand clearly indicates that all rights are retained by the copyright holder. You have no right to copy, alter or redistribute the text. The licence on most proprietary software is similar. You have the right to use the software, and that is about all. All open source licences give you considerably more freedom. Freedom to view and learn from the source code of the program. Freedom to give a copy to your neighbour. Freedom to run the program for any purpose. Freedom to improve the program and share your improvements with others.
The four freedoms of the Free Software Definition find their expression among the 10 criteria of The Open Source Definition. Together the software licences they recognise mark out a new range of activity (or perhaps a rebirth of practices which were present in the software industry at an earlier age). And this is why, despite being a simplification, it is true to say that if it is not distributed with an open source licence, it is not open source software.
You may not be terribly concerned by how software is developed. What matters to you may be that it does what you expect it to do. Moreover, you may feel that since you will not be involved in development, there is no need for you to acquaint yourself with such esoteric matters.
I sometimes fear that this is precisely the view adopted by some of those who have been burdened with making important IT decisions for their institutions. The problem with being excessively short-sighted is that one tends to bump into walls. It is doubtful whether one could seriously consider open source alternatives without some comprehension of either how they have been developed or may continue to develop. Indeed, for the latter, whether the development community around an open source project is vibrant and ongoing is a vital criterion for evaluating open source software. How the software gets developed and will continue to be developed does matter.
Eric Raymond famously characterised the open source development methodology as the bazaar . Software, as the computer science departments had taught, and as the proprietary software industry practised, was constructed like a brilliant cathedral from the elaborate blueprints created by engineers reconciling user requirements, functional requirements, financial requirements, and so on. The blueprint for the cathedral establishes both what will be created and provides a clear test for whether what has been created meets the requirements. Open source software, Raymond argued, is not developed that way. It often has no blueprint other than a tentative sketch. It could develop in many different ways, ways which are never fully determined in advance. Here, the builders themselves, to the follow the metaphor, shape the ongoing design of the building. The effect is more like the raucous exchange of goods in a market, or bazaar, than the ethereal realm of cathedral building.
There does seem to be something different about the way open source software gets developed. Indeed, however it may have been developed, once it is released with an open source licence it may begin to take on the characteristics of the bazaar. But the world of open source development is vast, and while Raymond's bazaar captures an aspect of it, there are also plenty of projects with detailed blueprints and even with functional requirements. The point is that open source development is unconstrained. When evaluating open source software, we really do need to look into the development community for the project because each one is different. Each is organised along different lines, with different mechanisms for leadership, dispute resolution, delegation and more.
The range of development communities leads nicely on to my third fundamental view of free and open source software: community. Whereas open source licences have criteria which proprietary licences cannot meet, and the nature of the open source licence lends a bazaar-ness to the ongoing development of open source projects which would be difficult to mimic in proprietary software development, community need not be a uniquely distinguishing characteristic of open source software. There is nothing in the nature of community that limits it to the world of open source. Indeed there are plenty of cases from the recent past and the present where communities have formed around the use of proprietary software applications. User support groups are common. Why then does community often get associated with free and open source software?
Perhaps it has to do with the circle of development.
End-users of software are not isolated from the developers in the way that they can be in some proprietary software. Their observations on how the software functions, its limitations, even bugs, are fed directly back into the development stream. Of course it does not necessarily follow that all end-users will in fact make direct contributions to development. But they can. It is part of what they get with their licence. And if they felt strongly that the software was not developing in a way they wished, they could take the source code and form their own development community to take it in their preferred direction. Forking, as this is called, in fact happens far less frequently than might be expected .
Equally important is the community that forms around the code. It is said that there are more than 10,000 developers around the world contributing to the Linux kernel. Most of course are not contributing huge junks of code. Rather what they are doing is taking advantage of their freedom to study the code and to learn from it. This is a remarkable resource. It has been speculated that if the entire kernel had to be rebuilt from scratch, it would take less than six months. A speculation we do not really want to put to the test, but it is what triggers the claim that it is the community that is important, not the code.
Educational institutions in the UK exist within a nexus of legislation, government policy, funding bodies, market forces and more. When OSS Watch conducted its initial scoping study in November 2003 it was clear that market forces had already produced a mixed economy. Many institutions were deploying open source solutions, either in niche areas or more broadly. 53% of FE respondents identified cost as the most important reason for choosing open source solutions. For HE the most important consideration was interoperability, with cost a close second.
Between 2002 and 2004 the UK government conducted trials on open source use within government . The results of these trials were very positive. The report stated that
Open source software is a viable and credible alternative to proprietary software for infrastructure implementations, and for meeting the requirements of the majority of desktop users.
The policy established through consultation and as a result of the trials was published on 28 October 2004 . The key point for UK HE and FE in that policy is the following:
UK Government will consider OSS solutions alongside proprietary ones in IT procurements. Contracts will be awarded on a value for money basis.
There are other points concerning open source licensing of publicly-funded software development that are also important, but perhaps the procurement point is most significant in the present context. Where government leads, educational institutions are likely to follow (sometimes). But given the statistic I gave at the outset on the percentage of institutions that do not even mention free and open source software in their IT strategies, there is some way to go.
Fortunately this is not a government policy without a forward action plan. It comes as no surprise that the JISC is explicitly mentioned as one of the three groups, along with the Department for Trade and Industry (DTI) and the e-Government Unit (eGU), charged with disseminating information on open source licences, development and exploitation. OSS Watch is merely one of JISC's instruments for carrying this work forward.
At the outset I said that this article was about the critical choice factors that go in to institutional IT decision-making. These are many and various. Your choice of which software solution to adopt for a particular situation depends on your local situation and your goals. It is highly unlikely that any one solution will suit all cases. Moreover it is self-evident that given the range of factors that go into IT decision-making, there will be plenty of room for both proprietary and open source solutions.
The challenge, of course, is how to compare them. Certainly no single marker will suffice. Free and open source solutions will almost certainly win any comparison based on cost of software acquisition. Market lead sounds like a significant factor, but how do we determine market lead for software which may be deployed without being registered on an institution's licence register?  Institutions do a very good job of tracking the licences they are paying fees for, but a very bad job of tracking the licences for which no financial transaction appears in the ledger.
There are two routes forward, both of which fortunately can be taken at the same time.
As institutions begin to rethink their IT strategies in order to include consideration for open source solutions, they will also want to re-examine the principles that guide their strategy. These include a commitment to interoperability, a desire to make choices that militate against vendor lock-in, a step-wise movement toward modularity. Modularity here means creating the environment where a decision in one area does not dictate decisions in other areas. Each of these principles might be glossed as part of the effort to ensure freedom for institutions.
So, there is plenty of work to be done there on thinking through IT strategies. But equally there is practical work to be done comparing specific solutions. Fortunately, JISC has already been thinking along these lines. 2005 will see the release of an important study conducted by The University of Strathclyde on how to compare proprietary, in-house, and open source software solutions .
Free and open source software represents a viable alternative to proprietary software and UK institutions will be increasingly exploring the former in the next few years. To do this well, and fairly, they need to be equipped with both some fundamentals - so as to be clear about their terms - and some practical guidance. OSS Watch is working with colleges and universities across the country to answer their queries, raise awareness about free and open source software, and to develop the kinds of guidance materials that will assist with the difficult IT decisions that lie ahead.
Editor's note: readers may not have seen Support Models for Open Source Deployment
and OSS Watch Inaugural Conference: Open Source Deployment and Development.