Though a glimmer of hope still remains for CloudRail, the German startup has misaligned its market approach to the needs and mindsets of the developers it's targeting with its one-SDK-to-rule-them-all technology. Currently, and in my opinion, the risks of using the company's proprietary technology greatly outweigh any benefits. Whether or not it can pivot far enough to change that opinion remains to be seen. In a move that resulted in the demise of his previous startup (a smart contact solution called Liboco) the company's CEO Felix Kollmar has already pivoted CloudRail's technology once before. According to his LinkedIn profile, certain "parts of the CloudRail technology" were extracted to form this latest venture (which still operates under the Liboco name).
Core to CloudRail's philosophy is the idea that developers --- particularly mobile and IoT developers --- have too much complexity and bloat to manage once the apps they're writing start to depend on multiple SDKs. For example, if a single app needs to authenticate with Facebook, then save something to Dropbox, mail something via Mailchimp, send a notification via Twilio and so on. In Kollmar's view, working with multiple dissimilar SDKs and APIs is daunting enough that developers would rather work with a single SDK instead; one that essentially multiplexes access to just those resources from only those APIs that an app needs to function. CloudRail refers to this concept as "a single API for everything."
In principle, it's an awesome concept. Instead of bloating-up an app on 10 SDKs, each of which has its own syntax and structure for accessing its companion API, the idea is to go with a single significantly "skinnier" SDK that's optimized to access the same underlying APIs, but only the parts of those APIs that you need (and with a common syntax and structure that cuts across all of them). Today, CloudRail outputs such Frankenstein SDKs for Java SE and Android-flavored Java. iOS and Node are on tap for 2016Q1.
But all awesomeness aside, on its current path CloudRail is, in my opinion, doomed to fail, perhaps taking some early customers and hundreds of developers with it.
For starters, CloudRail uses a proprietary, machine-readable description language in order to generate these highly bespoke SDKs. This description language, according to Kollmar, is necessary in order to deconstruct APIs down into their smallest components such that one or more of those components (just the ones that a developer needs) can be extracted and refactored into new, optimized bespoke SDKs along with similarly extracted components from other APIs. Once those APIs have all been sufficiently described using CloudRail's description language, refactoring them into a single SDK relies the creation of a special configuration file; essentially a recipe for what parts of what APIs to mix and match into the final output.
According to CloudRail, only 22 public APIs have been curated using this process in such a way that their resources and methods can be picked and plucked and refactored any which way but loose. The list includes Philips Hue, Nest, Dropbox, Box, Sendgrid, Facebook, LinkedIn, Uber, Stripe and other popular APIs. The company realizes this is hardly enough critical mass and that it can't move fast enough to cover the entire API economy. So it is counting on its community of developers to crowdsource the descriptions of the other thousands of APIs that are out there. In jumpstarting this community, CloudRail envisions itself as a sort of Github of machine-readable API descriptions (also a cool idea).
For example, if for an app, you need a few resources from the API for Atlassian's JIRA Project Management System and JIRA's API has yet to be described in part or in full by CloudRail or its community, you can use CloudRail's definition language to describe the subset of JIRA resources that you need. Once defined, you can submit that definition to the CloudRail community. Similar to the idea of forking source code on Github, the community might take that subset as a starting point, and extend it to include some of the other resources from JIRA's API. Regardless, when I'm ready to refactor those newly described resources into an SDK, along with resources from other APIs, I must create the aforementioned configuration file (the so-called "recipe").
Kollmar claims that community, which currently consists of hundreds of developers (soon to cross the 1000 threshold), is currently adding new descriptions at a pace of about one new API per day.
Only there's a big problem; an elephant in the room.
One of the reasons developers flock to Github in droves is because pretty much all of the source code that's publicly available through the site is available under the various Open Source Initiative-approved open source licenses. However, in the case of CloudRail, there is no way for developers to license the descriptions or SDK configuration files they've created which in turn begs all kinds of questions. For example, if I create some description and configuration files, who owns the the copyright to that source material? Me? Or can I open source them? And what rights does CloudRail have to that material?
You shall retain all rights on the contents provided by you, but by uploading or providing content in the Services, you grant CloudRail an unlimited, non-exclusive, perpetual, irrevocable and free license to publish, use, duplicate, transfer, edit, exploit, sub-license and make publicly available worldwide these contents in the Services and make these contents accessible to third parties. This license shall survive a termination of this agreement for whatever reason. Please remember before you upload and share any content that the upload feature in our Services is meant for sharing content with other Developers who should be able to implement the shared content in their software and to rely on the persistence of their right to do so. You will be able to benefit from the uploaded content of other Developers in the same way.
Then, should you author an SDK using CloudRail, Section 10.1 says the following about who owns that SDK:
CloudRail is the exclusive owner of the rights to the Web Service and the SDK.
Furthermore, section 10.2 says:
CloudRail has also limited IP rights in the configuration files and combined APIs that will be the result of the use of the Services.
However, it does not go into sufficient details as to what the limitations are.
Finally, at the time this article was published, section 10.4 says the following (exactly):
CloudRail grants you the non-exclusive, non-transferable and revocable right to use the Web-Service limited to the term of this agreement for the purpose of creating combined APIs for third party services to simplify the implementation of such third party services into software developed by you. Furthermore CloudRail grants you the non-exclusive, perpetual, transferable and
"And" what? Who knows?
And, if the licensing issue isn't enough to scare you away, then perhaps CloudRail's apparent tone deafness to the API economy will.
The idea of using a description language to generate SDKs isn't new. For example, although they don't deconstruct and refactor APIs the way CloudRail does, another startup -- APIMatic -- can not only generate SDKs, it also supports most of the API description languages such as RAML and Swagger that are already out there. This is no easy feat because the minute you support more than one, you probably have to come up with your own description language as a lingua franca to which all others can be reduced. And once you do that, you can also start up a little side business translating one description language to the others as APIMatic has done with APITransformer.
The point is, in CloudRail's case, the only description language that's supported is CloudRail's description language. Now, in fairness, regardless of what description language they've used to describe their APIs, most API providers don't offer their API descriptions for public consumption. So, if an API expert wants to use CloudRail to work with an existing public API, it's not like he or she is guaranteed access to the underlying description anyway. A new machine-readable description might have to be created from scratch. So on first blush, it doesn't seem too problematic if a developer has to create such a description in CloudRail's description language. That is, unless the developer is an expert with one of the existing description languages which is more than likely the case. Then, it's a problem because that developer can't work with something more widely known that he or she has already invested their time in.
Finally, the icing on the cake.
CloudRail is completely free. Where Kollmar says he hopes to generate revenue is in offering advanced services on top of the CloudRail platform to enterprises. For example, in addition to paid consultative services, Kollmar says that enterprises may want an on-premises version of CloudRail (versus the cloud). Maybe he'll call it PremRail. Presumably, CloudRail could be used to mix, match, and refactor all the APIs that live behind an enterprise firewall: all the APIs that have probably already been described with one of the existing description languages, that is. In other words, to use CloudRail, a lot of work might have to be redone.
As I said earlier, in principle the idea is cool. But the company needs to make a lot of changes before I would recommend using it as a solution.