When enterprise customers negotiate license deals with software companies, source code escrow agreements are commonplace. These agreements are three-party contracts between the vendor, the purchaser and a 3rd party escrow agent in which the agent stores the licensed source code, to be released if the vendor goes bust, or otherwise fails explicitly in its maintenance obligations (many shades of grey here!) I've been at companies that have had to invoke escrow terms to recover and maintain source code from a failed vendor. Of course, it's painful, but it's not disastrous.
We learned last week that Coghead, a platform-as-a-service (PaaS) vendor, has collapsed, citing difficult economic and fundraising conditions. Coghead customers have no such escrow arrangements. Far from it.
Customers should download their data that is available through my.coghead.com before 3:00 p.m. Pacific time on April 30th. However, Customers should not attempt to copy, modify, reproduce or reverse engineer any portion of the software that is part of, or used in the delivery of, the service.
(Extract from Coghead's "you're dumped" letter to its customers)
So all that development time, spent customizing UI layouts, workflows, business rules, and making integration work vanishes in a "cloud" of smoke. It puts a whole new spin on Fred Brook's concept of "plan to throw one away". Some Coghead customers will create better applications with the experience they've gained. But learners were not Coghead's core market. They were the DIY business person, the overstretched IT folk needing a solution for a quick situational application.
This post by former Coghead partner, Michael Topolovich, is an extended but fascinating view on the promise and problems at Coghead, and required reading for anyone on either side of the PaaS business. Apart from business execution problems that can sink any company, what's highlighted by Topolovich's post is the crucial requirement for a platform to have a thriving ecosystem of developers and 3rd parties. Topolovich's company, Delivered Innovation, is now offering a Coghead to Force.com migration special offer.
SAP has picked over the entrails of Coghead, slurping up IP and staff, but:
SAP did not assume any of Coghead's customer relationships or obligations and, at this point in time, SAP does not have plans to continue offering the Coghead service commercially.
(Letter from the Coghead chairman, Paul McNamara.)
Why not support those customers? There seemed to be magnetism between SAP and Coghead, for example SAP Ventures participated in the 2nd round of Coghead funding and the companies announced a partnership 9 months ago. If I were both an SAP and a Coghead customer, I would be looking to SAP to provide some level of support, or at least a transition plan to a new platform. SAP could grab this as an opportunity, and a cheap one I'm sure, to bootstrap a PaaS business with a ready-made customer base.
This post isn't intended to be schadenfruende laden; innovative companies go bust for many reasons, and I am an advocate of PaaS for the right situations (more on the right situations later). My overriding recommendation is that if you are going to use PaaS, make sure you have an exit strategy. Rob Styles has practical advice for mitigating the development risk, which I summarize here:
1. Keep the application URLs within your own domain.
2. Take regular exports of your data
3. Make sure you can export the application to run on-premise in some form.
This ability, or lack thereof, to "download your application" is the crux of the risk around completely proprietary off-premises PaaS approaches like Coghead, unlike hybrid open/on-premise/off-premise approaches such a Google AppEngine and Microsoft Azure.
Comments