On February 18, 2009, Platform as a Service (PaaS) vendor Coghead announced that it is to stop operating. In an email addressed to Coghead’s clients, CEO Paul McNamara quoted the challenging fundraising climate in the difficult economic environment as the reason for the decision to discontinue Coghead services.
On the following day, in a separate release, SAP disclosed that it had acquired Coghead’s intellectual property but not its customer obligations or relationships. SAP’s plans are yet to be revealed; however, considering that SAP Ventures was one of the Coghead investors, this appears to be a technology-motivated opportunistic acquisition.
While the current economic environment is hardly conducive to success, it is highly likely that the economic downturn only served to exacerbate the structural difficulties that Coghead was experiencing. Datamonitor does not believe that access to additional venture funding was the primary reason behind Coghead’s demise. After all, other enterprise technology vendors are proving able to obtain further rounds of venture capital funding. Instead, Datamonitor suspects that a combination of the usual problems facing enterprise technology start-ups, such as market positioning, execution and cash management, accounted for Coghead’s demise.
In the initial letter explaining the winding-down procedure, McNamara confirmed that existing customers would be able to access, run and export Coghead applications and data until the end of April 2009. SAP has acquired Coghead’s intellectual property and the bulk of its engineering staff; however, it has already stated that it does not intend to continue providing the service. This leaves Coghead’s customers and ISV partners with 71 days to find an alternative solution for the applications developed and running on the platform. While both application data and metadata can be exported, application metadata is non-executable and cannot be run in another application environment.
Put simply, the data can be recovered but the application logic will be lost. This leaves customers with an option to drop their Coghead applications altogether or re-write them on another platform. Luckily for Coghead customers, several PaaS vendors, namely Caspio, Zoho, TeamDesk, TrackVia, and Intuit QuickBase, were quick to offer a range of tailored services. These promotions span from a free consultation to free application porting. While such safe harbor programs may solve the immediate problems, many will use Coghead’s dissolution and its subsequent fallout in order to fuel the concerns regarding the adoption of PaaS.
However, the problem is not that Coghead ceased operations. The problem is that Coghead’s PaaS adopted both a proprietary development language and a proprietary application execution platform. Such a strategy severely curtails clients’ options, particularly once SAP acquired the intellectual assets without being willing to support the service or to make the source code available to those that may choose to run the Coghead platform on their own infrastructure.
Unlike Coghead, many other PaaS vendors have already adopted strategies that would have mitigated the problems emerging from the company’s closure. For instance, Rollbase and BungeeLab Connect offer source code through licensing or escrow arrangements, while applications developed on ZoHo Creator can be executed on Google Application Engine. Moreover, a growing number of vendors offer PaaS services based on widely adopted languages that could also be executed locally. Google Application Engine supports Python, Heroku runs Ruby, and Microsoft Azure promises to deliver seamless .NET execution on the desktop and in the cloud.
Content from our partners
In order to maintain a higher degree of platform stability and foster adoption among non-developers, Salesforce.com, the most prominent SaaS vendor and another PaaS trailblazer, has also made the decision to adopt a proprietary language, albeit one modeled on Java, for its Force.com platform. Of course, it is imperative to stress that Salesforce.com has built up a critical mass in terms of scale, financial stability and a development ecosystem that Coghead never achieved. While this renders the repeat of Coghead’s experience far less likely, it is not entirely inconceivable that at some point in the future similar lock-in problems may occur with the Force.com platform.
The lesson for enterprises is that both the cost of migration following service provider failure and the likelihood of such a failure need to be factored into any PaaS adoption decisions. PaaS vendors, on the other hand, need to understand that catering for the long tail of demand for situational applications by non-developer audiences requires a proprietary development language that in turn necessitates a customer migration strategy.
Given the negative customer experiences in the wake of Coghead’s failure, the vendors that do not present clear risk mitigation plans may suffer in the face of increased scrutiny by their potential customers. Should a PaaS vendor opt for a proprietary architecture, the vendor needs to either make the execution platform source code available through escrow arrangements or open-source licensing, render both the data and the application logic portable, or ensure run-time interoperability with other PaaS platforms or on-site infrastructures.
