Recently, Twitter curtailed Meerkat’s access to its graph. There was a lot of buzz about why and whether Twitter should just compete on its own merits with its recent acquisition Periscope. Twitter was not the only platform to do so. Look at the following example from a recent Apple acquisition featured on Wired.

Travis Jeffery is a software developer who’s been using a database system called FoundationDB for a project at his startup. Earlier this week, he noticed that the software had been pulled from the web. He soon received a terse email confirming that the software had been taken down intentionally, but little else. “We have made the decision to evolve our company mission,” it read. “And as of today, we will no longer offer downloads.”

Hours later, TechCrunch reported that FoundationDB had been acquired by Apple. Neither company has responded to our request for confirmation, and FoundationDB hasn’t updated its Twitter account since Monday. The only public acknowledgement the company has made of any changes came is a notice posted to the company’s support site featuring the same text that Jeffery received by email. He still hasn’t heard anything else from the company.

FoundationDB’s apparent shutdown won’t ruin Jeffery or his company. Other FoundationDB users might not be so lucky, however, if support for the technology really is being tanked. Sure, they can still use the copies of FoundationDB they’ve already downloaded and installed. But there won’t be a company providing support, updating the database to work with newer operating systems, or providing security patches.

It’s yet another a cautionary tale about putting too much faith in unproven companies offering proprietary platforms that could go away at any time—especially when a behemoth like Apple swoops in to buy it up. Often, such acquisitions are purely to hire new talent or integrate a startup’s technology into a new or existing product. In FoundationDB’s case, it’s unlikely that Apple wants to get into the business of selling enterprise database software.

That leaves companies that depended on that platform out of luck. And when startups suffer, so does innovation.

No Foundation

Like other NoSQL databases, FoundationDB offered a way to build databases that spanned hundreds or thousands of different servers, often housed in geographically distant data centers. That’s fine for many applications, such as messaging. It’s not a big deal if the occasional message accidentally gets delivered twice, especially if it’s only apparent for less than a second. But for other applications, such as financial systems, any discrepancy is a huge problem. You just can’t debit a customers bank account twice for the same transaction. FoundationDB promised a way to provide scalability without sacrificing performance — a truly rare combination of features.

It’s not clear why Apple would have acquired the company, but there are several possibilities. It might want to use FoundationDB’s technology to power its own web infrastructure, which ranges from iCloud to the AppStore to its mobile advertising service. Or it could just be acquiring the company in order to have its employees build new infrastructure for Apple to use internally. Or, perhaps, it’s both.

Had FoundationDB been open source, the community could have picked up where the parent company left off.

In the meantime, nothing is certain for FoundationDB’s existing customers. It’s conceivable that it could become part of the company’s developer tool offerings, or be open sourced at a later date. But in all likelihood the project is dead.

We’ve seen a number of similar situations in recent years. For example, cloud storage company Nirvanix which provided storage services for IBM’s cloud service, shut down in 2013, giving customers just two weeks to migrate their data.

Open Source’s Saving Grace

Former FoundationDB users will now have to choose between either continuing to use a piece of software that won’t be supported and won’t receive any security updates, and migrating to a new database. That won’t necessarily be easy since there are so few databases that work like FoundationDB. Had FoundationDB been open source, the community could have picked up where the parent company left off. There are examples of this happening elsewhere.

For example, a company called Couchio (later called CouchOne) was founded in 2009 to provide support for the open source database Apache CouchDB. In 2011, the company merged with Membase, another open source database company. The new company called itself Couchbase, and set to work created a new database that combined elements of both projects. A few months later, Couchbase announced that it would stop contributing to the original CouchDB project altogether.

Had CouchDB been a proprietary product, that would have been the end of it. Developers and companies who used CouchDB to power their software would have no choice but to either use an unsupported piece of software or migrate to the new Couchbase database. But since CouchDB was open source, other developers were able to continue its development.

There’s no guarantee that FoundationDB ever would have had the level of community involvement to make that happen, but by developing its product as a primarily closed-source system, it never even had the chance to build an outside community of developers to maintain it.

Regardless, Apple and FoundationDB could have handled the acquisition with more grace. Even though Jeffery’s company wasn’t using FoundationDB for anything critical, having to replace the system is still a pain. “We’re excited for them, and as users of Apple products, we look forward to seeing how Apple makes use of their technology and talent,” Jeffery says. “That said, we would have appreciated some more notice.”

Jeffery might not be bitter, but any users who were more invested in FoundationDB are probably feeling less forgiving right about now.

Platforms and Pseudo-platforms

Some have termed what happened to Meerkat and Travis Jefferey “platform risk,” and it is, but one must be willfully naive to consider ad-monetized social graphs like Facebook and Twitter to be ‘platforms’. I would rather consider them as ‘pseudo-platforms’

Amazon Web Services (AWS) is a ‘platform’. That is, you can count on it even if you use it to compete with its parent company Amazon. Netflix still uses AWS in their tech stack even as Amazon Instant Video is spending over a billion dollars on content to battle it out with Netflix in the video streaming space, to name one example, and I’ve yet to hear of any company of any size getting bounced from AWS because they were competitive to Amazon. You could even start a retail company and use AWS. It’s a utility like the power company.

The reasons why lie in both Amazon’s business model and philosophy. AWS isn’t free. This is crucial because Amazon makes money off of its AWS customers regardless of what business they’re in. As for AWS’s philosophy, you can call it altruistic or just pragmatic or both, but if Amazon wants to compete with a company that uses AWS, Amazon will try to beat them in the marketplace. If they can’t, they still get a bite of that competitor’s income through AWS fees. It’s a win either way, and considering AWS is a fast-growing platform that’s a critical piece of the world’s technology stack, it’s more than a minor one.

Compare this to free tech platforms offered by companies like Facebook and Twitter that make money off of ads targeted at their social graphs. If a company like Meerkat comes along and piggybacks off the Twitter graph to explosive growth and captures a unique graph, in this case around live video-casting, Twitter doesn’t make any money. On the contrary, since the network effects of graph-based products tend to lead to “winner takes all” lock-in, Twitter just ends up having armed a formidable competitor that it might have to spend a lot to buy or compete with later. It’s a no-win situation.

Facebook has similar ambivalence as a platform. Anyone familiar with the tech space in recent years can name more than one company that rode the Facebook graph and News Feed to explosive growth only to plummet off a cliff when Facebook turned a knob behind the scenes or just cut off access.

None of this should be surprising unless you’re some “don’t be evil” idealist. Take a more pragmatic view of tech and put yourself in Twitter and Facebook’s shoes. Would they want developers to build off of their platforms?  The most ideal developers on their platforms would be apps and services that publish lots of great content into Facebook’s News Feed and Twitter’s Timeline such that users spent more time in either service seeing ads.

The worst kind of developer would be one that used either the News Feed or Timeline just as a captive notification stream to build their own competitive social graph. Meerkat is guilty of at least one part of that. Meerkat leaves random links in Twitter that take users out of Twitter’s timeline to some other app to experience content, and Meerkat’s stale links just sit in Twitter timelines like branding debris or worse, as spam.

For all its press these past few weeks, Meerkat’s graph is relatively shallow. However, the potential for being first to get traction as another near real-time medium of note was rising with every live broadcast notification from another tech influencer. As Twitter knows better than anyone, it’s not necessarily how many users you convert in the beginning of your journey to create a high-value graph, it’s who you convert, and Meerkat had captured the imagination of some real luminaries. Furthermore, Meerkat is actually more real-time than Twitter, which lays claim to being the best publicly available real-time social network.

Notifications are the most valuable communication channel of the modern age given the ubiquity of smartphones, and Facebook and Twitter are among the most valuable information streams to tap into given their large user bases and extensive graphs. Email is no longer the summit of the communication hierarchy, and both Facebook and Twitter want to avoid the spam issue that polluted email’s waterfalls.

This conflict of interest is why I refer to Facebook and Twitter as pseudo-platforms. Unless they change their business model, any developer trying to build some other graph off of Facebook or Twitter should have a second strategy in place in case of explosive growth because access won’t persist.

Even before Facebook and Twitter, this type of platform risk from ad-supported businesses lay in wait to trap unsuspecting companies. Google search engine traffic is one of the more well-known ones. Google’s PageRank algorithm is, for the most part, a black box, and I’ve encountered many a company that fell on hard times or went out of business after Google tweaked PageRank behind the scenes and turned off the bulk of a their organic traffic overnight. As Google enters more and more businesses, that platform risk only escalates.

Alternative platforms do exist, even if they’re not perfect, and that matters because AWS, as developer friendly as it is, doesn’t offer a useful graph for companies looking for viral growth.

The most important such platform to date might be Apple’s contact book. It’s certainly one of the largest graphs in the world, and Apple doesn’t rely on advertising to those users for income. The App Store is not completely open, but it’s reasonably so, and once you’re approved as an app it’s rare that Apple would pull the rug out from underneath you the way Facebook and Twitter have.

Phone numbers were the previous generation’s most accessible and widespread key for identity and the social graph, and Apple’s iOS and Google’s Android operating systems and the rise of the smartphone suddenly opened a gateway to that graph. Many messaging apps bootstrapped alternative or parallel social graphs just that way. I doubt the telcos were looking that many moves ahead on the chess board, and even if they had, I’m not sure they would have had much recourse even if they had wanted to prevent it from happening.

Meerkat is a very specific situation though, and the reason I still think of Twitter and Facebook as valuable platforms, is that both developers and Twitter and Facebook can benefit from lots of other more symbiotic relationships with each other. These relationships are possible specifically because of the nature of Twitter and Facebook primary ad unit.

Both companies could do a better job of clarifying the nuance of just what types of relationships qualify. This would head off more developer frustration and prevent them from just writing off those two platforms entirely, as many already have. Given how many developers have been burned in the past, distrust is high, but I believe a lack of clear and predictable rules makes up more of the platform risk here than is necessary.

P.S: Adapted from Eugene Wei‘s post on Platform risk


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s