Wild Webmink

T-Shirts Available 🙂

I’ve written previously about the freedom to leave, but there’s another value delivered by the liberties open source provides, one which it would even be worth paying extra to get. When your vendor changes direction, what do you do? Traditionally there are five options:

• reimplement your system to use your vendor’s new strategy
• reimplement your system using a different vendor’s product
• use your vendor’s locked-in support contract
• use an escrowed version of the source code (which you wisely demanded from your vendor during the original purchase) and engage specialists to carry on with your existing software at your own risk until it no longer works as the environment evolves
• just keep going regardless and hope nothing goes wrong

All of these are, to say the least, sub-optimal. Most of the victims of vendor abandonment that I have encountered have taken one of the first two options, some using one of the last two as a bridging strategy. All of them have found the experience very expensive.

While superficially appealing, the value of escrow as a safety measure is questionable. With the best will in the world, the source code to a complex proprietary product is not going to be easy to engage even with plenty of warning and resources, let alone in an emergency on an unmodified budget. Finding anyone sufficiently familiar with the source code to navigate it, let alone safely modify it, is very unlikely, and doing so on demand verges on the impossible.

With open source software, there’s a sixth option. As long as it’s really open source and not compromised in some way, the community around the free-software commons can just “Rehost And Carry On“. Another company can step in to take the lead – as my own company ForgeRock has done with OpenAM and OpenDJ – or in the case that the project was already a truly diverse co-development community like PostgreSQL or an Apache community, there will already be a choice of alternatives available.

I call this extra option “community escrow”. For the end user of open source it is another valuable and under-recognized benefit.  Like the fact open source software needs no user license compliance tracking, community escrow has been carefully excluded from the frame commentators have allowed to be placed over open source. Proprietary marketeers like to say that “there’s no-one there to back you up” in connection with open source, but once again the four freedoms – to use, study, modify and distribute – deliver differentiating value for open source software.

So what happens when your supplier leaves the market or is taken over and the new owners deprecate the product you depend upon? If you’re using proprietary software, it’s usually end-of-story. Competitors will gleefully crow about “migration offers” but the truth is you face enormous cost. It’s not a lot better if your supplier is acquired. They will probably accept the responsibility to support you to the end of your contract, but the key staff may well leave and you’ll find the quality of support degrade. The acquirer might well decide that litigation is preferable to the cost of delivering support and just go silent, neither officially deprecating the product nor actually delivering value.

The story can easily be different with open source. If there is a market demand large enough to justify starting a new business to take on the code, as was the case for ForgeRock, it’s entirely possible there will be someone ready to provide seamless continuity. Otherwise, the businesses who have been working in the community are likely to have solutions for you. The fact they have been free to study and modify the code means they will have skills that only the staff of the vendor can have in the case of proprietary software. They may be able to provide continuity; at a minimum they will be able to support you as you plan a graceful migration.

What can prevent this option existing? A community escrow option can only exist if your software freedoms have been respected and the sorts of measures in addition to open source licencing that Andy Updegrove mentions have been taken. If the product was “open core” – with the key commercial features kept proprietary – it will be very hard for anyone to provide continuity. This is especially true if you are using the software as a service, because the critical know-how to make the software reliably run in the cloud is unlikely to be included in the open source project. If your vendor scorns co-developers, there may well be no-one out there ready to step in. It’s thus not a matter of mere philosophy to check your software freedoms are protected; your ability to use community escrow to manage a vendor failure may be at stake.

[First published on ComputerWorldUK]

This essay is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
While you are not compelled to do so, the author would welcome notification of derivatives, especially translations which will be gladly posted here. If your intended use is commercial, please do ask for permission as it is usually granted; it is  withheld because of past abuses.