Only when you leave: Exit Strategies and Pre-Nups

FOSSBazaar is no longer being updated. The information on this site is preserved for your convenience but may be out of date. Please visit Linux Foundation's Open Compliance Program for current information and activities.

Andrew Grant's picture

Regular readers will be aware that lock-in is a favourite topic for comparing and contrasting with Open Source licensing schemes. Lock-in can occur in a number of ways from the subtle to the insidious. Making the move from an existing vendor to FOSS may be the beginning of a beautiful new relationship but also could mean a breakdown in the formerly cosy relationship with your previous partner. Indeed it's only when you leave that that you can see the value of a well thought through exit strategy and maybe even a pre-nup. As always, let the buyer beware – and here are a few examples of lock-in to consider.

Perhaps your software doesn't always do what it says on the tin, and the initial promise hasn't been fulfilled. In testing, one new app struggled to be performant – generating 10x more data than its predecessor and with resulting data loading times in excess of the available window (we're talking several hours here) and a concomitant delay to reporting systems which ironically meant worse performance than the system it was replacing. Cue a wait of over nine months for the vendor to get around to reworking the product – because lock-in meant that there was nowhere else viable to go. In the FOSS world there would have been no hang time because access to the code would have allowed a rewrite and the ability to offer the result back to the community.

Beware also “bait and switch” in its many guises. A great example being up-front discounts against “rate-card” but when you need a specific adapter to integrate with other systems then the cost per seat can be astronomical for what can be a relatively simple piece of software.

In other instances, having to pay a further fee to access a license you already hold because you are using another vendor's product to do so can seem an unjustifiable expense (except of course if you are the vendor).

So too can the moment a once-cherished relationship breaks up and your company moves on - perhaps to a piece of cutting edge FOSS. At this point the vendor's strategy can be to extract every last cent from you as there is no future in the relationship.

The moment before you sign a contract is the moment of greatest leverage. A split second after, the balance of power has changed. When you sign on the line you really are putting yourself on the line.

What happens when you leave? Plan for this eventuality and build it into the contract from the start as a pre-nup - not as an afterthought. Next, consider the whole life-cycle costs of the contract and what can happen at each life-stage.

This is more relevant than ever in the Cloud Computing/SaaS paradigm – who owns what in the event of a messy divorce (parting of the ways). This is particularly pertinent if you have invested your own cash to have particular features developed or have had custom work done. (Pimp my ride anyone – you may have paid for the go-faster stripes but who really owns the car?) Only when you leave do the arguments start and the difficulty of extracting your data begins. The contractual zen is in the detail and RTFM applies, or in this case RTFC (Read The Contract First) and work through the implications of the exit and what penalties may apply. In the case of Intellectual Property issues, check your understanding and clarify any eventualities. “Trust but verify” as the saying goes.

When you head for the exits, make sure you know whether you've been locked-in from the start.