Considerations for selecting software

Selecting the right software to use for an organisation is an art, not a science. There are so many unknowns. In most cases, people simply "go with the flow" and pay lots for whatever proprietary software de jeur. That, however, is the worst possible approach.

The Ice Flow Analogy

Selecting software is seldom a "one-off" decision, where, like a durable good, it can be adopted and then used in perpetuity. Software is a depreciating asset like a car: which software is created at a point in time, the computing environment in which it exists is constantly evolving around it. You have to satisfy yourself that the value it allows you to generate exceeds the value it loses with each passing day.

Software cannot afford to sit still, because it will rapidly become obsolete, fail to meet user expectations, and vulnerable to whole new classes of security exploits. You can keep up-to-date with a particular software application, but over time, the underlying software paradigm on which any particular software application is built, will be superseded. At that point, you will almost inevitably have to migrate from one solution to another.

I think of selecting software like looking out at an ice flow - a sea dotted with blocks of ice, like those shown in climate-change photos with poor polar bears or penguins sitting on them, looking forlorn.

If you want to stay dry, you have to pick one that's nearby (jumping distance), and large enough to support you. It should be melting slowly, and, ideally, you should pick one which looks like it'll be passed by one or more other suitable ice blocks on the horizon before the one you're on melts out from under you... allowing you to anticipate your next leap.

Open Source vs. Proprietary

By limiting software selection to open source software, we provide substantial inherent benefits to our organisations and institutions:

• minimum risk - you can easily and cost effectively survey the various software options which might fit your organisation prior to committing. You can also do this without the politics of multiple vendors (because usually with proprietary software each vendor has only one product to offer in a particular functional niche, so trialling many requires many vendor relationships)
• minimum cost - you don't typically pay licenses for open source software. If not managed in-house, you would normally pay a fixed fee for a vendor to set up and maintain a software solution - but you costs would not typically go up based on the number of users you have. This is a huge planning advantage.
• choice of in-house or outsourced - with open source software, it is always possible to choose an in-house maintained solution or an external vendor supported solution. If you have access to suitably skilled people, in-house has many advantages including the ability to "tune" your software to your precise requirements, by people with a deep understand of them. You can always choose to outsource later (or pull previously outsourced support back in). The ability to make that choice should not be undervalued!
• staying up-to-date - with software it is always advisable to stay as current as possible - with proprietary software, customers often opt to remain with outdated versions of software due to the cost of upgrades (licensing, or other external cost disincentives, like compatibility concerns with other related proprietary software packages). With open source, it's typically part of "business-as-usual" maintenance to keep open source software up-to-date - this makes migration easier, too.
• protection against vendor lock-in - open source software has no incentive to "trap" you in a solution, because the software is not the source of value for whoever is selling it.
• relative ease of migration - unlike proprietary software, where the software itself is designated the source of value, and there's a strong incentive to use proprietary file formats, data schema, protocols, etc. which inhibit migration to new/different solutions. Open source has no such incentive. Creating and maintaining proprietary standards, however, is a cost to software developers, so with open source there's a strong incentive to use open standards where available. This increases the changes of a straightforward "compatibility" between incumbent software and the next generation. Open source isn't a silver bullet - any complex software implementation will require configuration (often substantial amounts) which will complicate migration, but it will be more tractable than migration from a proprietary product.
• potential for ongoing vendor relationships - if open source software is provided/supported by a vendor, and that vendor relationship is good, there is no need to shift vendors when adopting a new solution - often the same vendor will assist with a different open source project, and have the "institutional knowledge" required to minimise the cost and complexity of migration.
• protection from "orphaned works" - if a proprietary vendor goes out of business or chooses to discontinue a software technology on which you depend, you're out of luck (this happens remarkably frequently and with disastrous results). You have a painful forced migration to a new platform, without assistance from the previous vendor in many cases. With open source, as long as people depend on the software, they have the ability to maintain it (or pay someone else to do so for them). If they can collaborate with others in the community, they can combine forces to share the costs and even continue to advance the software.

The Opportunity and Threat of Cloud Services

Beware of "Cloud" services. They might seem to be equivalent to open source (they might even be a type of open source software) but realise that with cloud-based services you have to be very clear on what form your data takes if/when you want to get it away from a particular cloud vendor. The Cloud model has some attractive aspects - quick to get started, always up-to-date, data management is someone else's problem... but it's also the new "lock-in" opportunity for vendors. By making it difficult to get your data out in a usable form (like an open standard - don't accept "oh, you'll be able to export your data" type assurances. Consider the incentives for the vendor), they can effectively lock you in, and you won't realise it until you want to get out. So it's buyer beware.

You'll be safest if your vendor is using open source software under the "AGPL" license (i.e. strong user-focused open source license - as opposed to a weak/exploitation friendly one) which means that if you don't like what they're doing, you can request a data "dump" from the vendor, download the software they're using to provide the service, and get someone else (inhouse or outsourced) to create a new home for your data elsewhere using the same software, this time under your control.