In the learning & training world, open source software means more than just Moodle. As well as the ubiquitous Course Management System, there are open source content development tools (e.g. ExeLearning, Xerte), mind-mapping applications (e.g. Freemind), audio-editing tools (eg. Audacity), utilities (e.g. Filezilla, Firefox), content management systems (e.g. WordPress, Drupal and Joomla), and even OpenOffice, a full-blown competitor to Microsoft Office.
All of these, and many other open-source applications, are potentially useful for learning professionals – but how do you know that they are going to work in your organisation?
The software procurement rulebook
Rule 1: Will it do what you want it to do?
Rule 2: Will it fit?
Rule 3: Work out what it will cost
Rule 4: Will I be able to get help?
Rule 5: Is it sustainable?
Rule 1: Will it do what you want it to do?
That should be the easiest thing to work out. You come up with a set of requirements and the application vendor lets you know which of those things it will do.
Of course, life’s never as simple as that. I’ve seen far too many requirements that focus entirely on a list of functionality, with no regard for how that functionality is actually implemented within the software. So you could end up with a tool that will do everything you want it to, but no-one will be able, or want, to use it.
There are three approaches to finding out whether software will actually do what you need:
- Find someone who knows the software who can look at your requirements and explain how the tool will work in your context
- Read up all the product documentation that is available
- Try it out on a small scale
The open-source advantage
With closed-source (or proprietary) software you are usually tied to the vendor to get information about the product. Some vendors are excellent at providing information and demonstration versions to look at. Many are less so. Many vendors are happy to send a salesperson to see you – but usually they are biased towards the product.
With open-source software you may need to pay a consultant if you want someone to demonstrate the software and understand your requirements (particularly with a complex application). But at least you are more likely to get an independent view on things.
Also, with open-source software, there is nothing to stop you taking it and trying it out on any scale. Although you must remember that the more people are using it, and the more you rely on it, the more likely it is that you’ll need professional help to use it well. That does depend very much on the type of application though.
Rule 2: Will it fit?
What existing systems will the new software need to work with?
Will it work on your servers? Will you need additional server expertise or hardware? Where will you get that from?
Will it need to look like existing systems? Who will do that?
Will it need to collect data from your existing systems? Can your existing systems provide the data in a compatible format?
Will it need to supply data to your existing systems? Can it do that already, or will you need additional coding?
The open source advantage
In general, the major open source projects try to follow recognised standards and practices in coding and in linking to other applications. There’s no advantage to keeping data inside your particular application; strength is gained by the number of ways you can connect to other development teams and applications.
Rule 3: Work out what it will cost
Not just the license for using it, but in terms of:
- IT infrastructure – servers, bandwidth, faster machines to run it on
- installation – on a server or on every person’s desktop
- configuration – making sure it fits the way your organisation works, and looks the way you want it to look
- training requirements – for administrators, IT technical staff and for general users
- support and maintenance – making sure that the software keeps running and is updated frequently
- customisation – to make the software work exactly as you want it (but bear in mind that any customisation now comes with additional cost later when you want to upgrade the core software)
Basically, as more people begin to rely on the software, the more time and resource you need to use in deploying it.
The open source advantage
With open-source software you don’t need to invest vast amounts in the first instance. You can start small and scale up as required.
Rule 4: Will I be able to get help?
The best software companies (in my opinion) support their users in a completely open environment. This isn’t just true for open-source solutions. Examples in the closed-source world include Mindjet, Articulate and Salesforce. I have bought all of those products, partly on the strength of their customer support.
They will often provide online Frequently Asked Questions (FAQs), alongside manuals and examples of good practice.
Even better is when they open up online forums where users can ask questions which are then answered by both in-house and third-party experts.
If the software supplier themselves do not provide support, are there third-party organisations that will?
The open source advantage
Because the source-code is open, it means that anyone can have an in-depth understanding of the software. For the popular projects this usually means that you will have a range of options for getting support – from the software developers themselves, or from consultancies, training organisations and other service providers.
Beware of open-source products which don’t appear to have active user forums. It can imply that the software is not widely used.
Rule 5: Is it sustainable?
It’s all about the money – how will you be reasonably sure that development will continue?
With closed-source software it’s usually quite easy to determine how the software development is funded. Funding models for open-source development vary widely. But you need to make sure it’s going to happen somehow.
Information Week has identified five open-source business models:
- Sell support services
- Build (or run) hardware that uses your software
- Sell proprietary (closed-source) software that complements the open-source code
- Sell closed-source licenses for customers who prefer not to be bound by the open-source license conditions
- Sell advertising space
The most popular model by far is that of selling services. Usually it works like this:
- Initial code is created by a core team for their own purposes – often using chunks of code from other open-source projects
- The code is released as open-source and other people start to use it – often feeding back bugs, ideas, or additional bits of code – the “wisdom of crowds”
- Larger users may set up their own development teams to work with the code – these usually feed code back into the Core team.
- Experts in the software (including the Core team) may offer services such as consultancy, hosting, customisation or configuration
- Sometimes the Core team may have formal accreditation arrangements with service providers which means the Core get a share of any revenue.
The more popular an application, often the more formalised the development and accreditation processes become – such is the case with Moodle.
If there is no apparent business model for an application, then it may be that it’s being developed by enthusiasts, who want to make use of the “wisdom of crowds” effect inherent in open-source development.
If you want to be reasonably certain that development will continue, then you need to play a part in the ecology. That might mean purchasing services from organisations that feed into the development cycle. Or it might mean contributing towards the development cycle yourselves:
- Producing chunks of code
- Testing pre-release versions
- Supporting other users in the forums
- Producing documentation
- Feeding back on bugs and issues
The open source advantage
Open-source software has a complex set of business models – which don’t always sit comfortably alongside more a commercial cash-based economy. However it does mean that you can contribute to the ecology without necessarily having lots of cash.
Summary
Don’t discount open-source software when you’re looking at your procurement options. But be aware that the questions you ask of proprietary software vendors may not apply to open source software – and vice versa.
If you'd like to discuss this article, or how I can help you, get in touch.
Posted: 11 January 2013
Tags: Open source Advocacy Supplier selection