One of the more indisputable advantages of the Internet as it exists today is the abundance of software on it that is ‘free‘. It is free in the sense that it is available to download and use without a financial fee. Some software, as well as being free, is also ‘open-source‘ meaning that the source code is freely available and can be changed for bespoke purposes – something that is obviously anathema to commercial software.
Why free software should exist at all is an interesting point in itself and has perhaps more to do with philosophy than anything to do with economics or information technology.
Even allowing for the fact that there are all sorts of variations and practicalities to this, the reality is that my job would be impossible without the benefits that this type of software gives. Indeed, working in a not-for-profit academic environment with limited financial resources and building software applications for education often means that software packages are available for me to utilise and distribute that just wouldn’t be available if I was working in a more commercial environment. It’s no exaggeration to say that without GNU and Apache software, many academic IT services just simply wouldn’t function, especially in areas of academia that are focused on research and teaching, like university faculties.
The other side of the coin is that some universites are unhappy with relying on software like this for ‘mission-critical’ administrative IT services like accounting and student record systems and shell out large budgets for big commercial software packages from the likes of Microsoft or Oracle to support this.
My experience is that there is little to differentiate between these two approaches when it comes to the quality of the actual code (i.e. how many bugs are in it, how well structured and re-usable it is, and the level of functionality it encapsulates); however if you use the more formal definition of what ‘software’ actually is, then differences do appear.
Software, as a strict term, includes all the things that go into making code usable, and this really means documentation and technical support that accompanies the code. Code in free software sometimes performs better than code in commercial software, but it is often very difficult to implement or maintain, because the documentation is non-existent or very poor. When you pay money for software, the reality is that you’re not paying for the code, you’re paying for a service that lets you use the code without tearing your hair out.
Universities often attract people who don’t mind working with software that is poorly documented and has no formal support structure; they like being independent, relish a challenge and are willing to spend days digging around in the recesses of the Internet or deep in the guts of a software application to understand it and make it do what they want it to do. Universities possibly aren’t even aware that their budgeting is only possible thanks to cowboys like this who don’t spend much of their money.
It’s very common that within a single university both models of software usage are incorporated, often within the same department. These different approaches (or even perhaps, ideologies) can at times give universities a patchwork appearance – in one office, everyone will wear suits, work from 9 to 5 and use Microsoft software; in an adjoining office everyone will wear jeans and tshirts, work from 10 till 6 and have Linux machines on their desks. Not surprisingly this can cause divisons, but it is important to understand the disadvantages and advantages of both worlds.
Most of my time in academia has been firmly spent living on the ‘open-source’ planet, but I have spent some time living on the ‘corporate’ planet too. There’s no contest as to which is the better world to live in as far as I am concerned, but to even things up, I will mention a specific example of living on the open-source planet which wasn’t so idyllic.
My department had decided to implement an Intranet/document management system for use internally. Because we had no budget or software engineering resources for this, we looked for an application that was free and ready to use. We chose Plone, which is free, but not exactly ready to use, as we had specific requirements that meant we would have to customise our installation of the application. This meant relying on the open-source nature of the application so that we could add our own code. Plone is also a straightforward and intuitive user-friendly application if you are simply a recipient of the web-based interface it offers and wish to to have a place to easily store and access content, and this was obviously a strong attraction.
The problems started when it became apparent that installing, maintaining and customising Plone at the ‘back-end’ would not be easy due to its esoteric architecture (it uses Zope, which is in many ways the most incomprehensible piece of software I have ever encountered), and the fact that the documentation that was available for it was out of date, fragmentary and badly written, as is often the case with free software; you can’t really complain about this if you’re not paying any money.
To get Plone to do what we wanted it to do (offer access to ‘team’ areas to authorised staff members only, display bespoke personal information about individual members of staff) turned out to be much more difficult than it appeared, and took much more software engineering resources than expected (the novelty of Plone and Zope to the existing knowledge base within our organisation meant that there was an ‘experience curve‘ involved), which impacted unexpectedly on other things that were planned at the same time.
The lesson from this is that no software comes without a resource price. It may be a financial price, but perhaps less obviously, it may also come with a temporal price. Software that costs no money may take a long time to meet the particular needs of an organisation or individual, and may require dedicated software engineering resources (i.e. time) to achieve this.