FoundationDB logo

Last week, Wired ran an article called “What Happens When Apple Buys a Company You Depend On?,” which tells the story of how FoundationDB was acquired by Apple and subsequently threw their customers under the bus.

This is a developer’s worst nightmare. The realization of their worst fears when they choose a technology to build on top of.

Imagine yourself in this scenario: you took a chance on a product or open-source project, invested time with your team to learn what it is and how it works, and figured out to use it to further your mission. You counted on it to be reliable, and wanted it to power your systems for years to come.

And then it gets abandoned, discontinued, or re-licensed, and all your work that depends on this technology is lost.

Anyone whose production systems depend on FoundationDB today is going to have to spend real dollars and real hours replatforming off of it. That’s time and money they could be investing into new development, but instead those resources have to be used to recover. That sucks.

How else could this acquisition occurred, assuming that Apple has no interest in continuing work on FoundationDB?

Ideally, the acquisition of FoundationDB by Apple would not mean the end of FoundationDB from a community standpoint. It could play out like this:

Once Apple acquired the founding company, other talented people could continue to use, contribute to, and improve the technology.

The projects and businesses that depend on FoundationDB wouldn’t be at risk. They wouldn’t need to change database platforms in order to move forward with their businesses.

Other companies or individuals would emerge to fill the void left by FoundationDB and provide leadership for the project. Other companies could step up and provide commercial support for the FoundationDB users who want to be able to get top-notch help on the phone when they run into trouble.

Except they can’t. Because FoundationDB was never open-sourced, and Apple shows no signs of open-sourcing the database now that they’ve acquired the company that created it.

(And Apple could easily open-source FoundationDB. C’mon Apple, step up. Even if the company plans to use FoundationDB internally, making it OSS would only improve the tool for them. This should sound familiar, because it’s exactly the case with Cassandra, which Apple is the world’s largest user of.)

Closed-Source Vs. Open-Source Software

The situation created by the acquisition of FoundationDB speaks to the heart of the gap between closed-source and open-source software (OSS). If FoundationDB was OSS, then everything outlined above would be possible. But since it was always closed-source, now it’s game over for customers and users.

The fact that FoundationDB’s founders allowed this possibility to occur when Apple acquired them speaks volumes about their attitude towards their users.

FoundationDB made the decision that getting bought by Apple was more important than everyone who trusted them.

They made the decision that getting bought by Apple was more important than the trust of everyone who had built their products on top of FoundationDB. They let Apple dictate that they’re not going to support the product anymore; that there will be no open-sourcing of the closed-source product; and that their users are shit outta luck.

Remember that FoundationDB is a database, meaning that it’s foundational infrastructure for everyone who uses it. It has all their critical data. And their data is your business.

In a sad bout of ironic naming, FoundationDB has now jeopardized the foundation of every single one of their customers products.

While we hope that Apple will do the right thing and open-source the database, we want to take this opportunity to discuss how we (Petabridge) view our relationship with Akka.NET, Helios, and other future OSS projects we’re going to both create and support.

Why is this important to talk about right now? It’s important because some in the community have wondered about our relationship with Akka.NET in light of FoundationDB, similar previous situations in .NET (e.g. RavenDB), and the fact that Akka.NET just hit v1.0.

Petabridge Can’t Succeed Without OSS

Here’s Petabridge’s mission statement, which we recently rewrote:

We believe the future is something we create right now. And in order to create a better future than the one we have today, we must look beyond what we already know.

We do this by creating visionary technologies, collaborative communities, and the space for possibility.

We just happen to make software development platforms.

We’re still working with the language to get it just right, but notice that we specifically call out collaborative communities in the “how we accomplish our mission” portion.

In case it’s not clear, “collaborative communities” means open source communities.

Everything we hope to accomplish as a business, which includes some pretty audacious goals, depends on being able to earn and keep the trust and support of open-source users and contributors.

Our business depends on you being able to reliably run YOUR business on top of Akka.NET, Helios, and the other frameworks that we haven’t invented yet.

We’re doing all of this on the backs of open-source instead of proprietary, licensed technology because we believe that the OSS model yields more effective results and most importantly, more effective and engaged technology communities.

It’s this magic combination of community and technology that helps developers discover solutions to problems they couldn’t even imagine before.

What does this mean for our future?

It means that we will not tolerate the possibility of a FoundationDB happening in our future, or in the future of Akka.NET, Helios, or any future OSS projects we work on.

Our Commitment to You

Here is our solemn promise to you, the Akka.NET / Helios / future project user. Our word to the companies who depend on us for their production systems. To future investors and to anyone wanting to partner with or acquire us.

Petabridge’s Commitment to Open-source Is Non-negotiable. We Will Never Allow What Happens to Our Company to Jeopardize The Work Of Those Who Trust Us. Full Stop.

That bears repeating: We will never put you in a position where what happens to our company jeopardizes yours.

No matter what happens to our company, we will not break the trust of the people who depend on what we create or contribute to.

While we may create proprietary tooling on top of OSS projects in the future (e.g. premium cluster management / deployment / monitoring tools), the core frameworks themselves will always be OSS, and will exist under an OSS-friendly license such as Apache 2.0.

We get an acquisition offer from a company that won’t honor our OSS commitments? We’ll pass, thanks.

We get acquired by a company that changes their minds about our OSS commitments after they’ve bought us? We (Aaron & Andrew) will quit on the spot.

We have an investor or a board member who wants us to shift all of our effort into a proprietary fork of Akka.NET and stop giving back to the OSS community? They can go to hell. We don’t have any investors as of writing this, but that may change one day. And they’ll be asked to read this first before meeting with us. And if this scares them off, then they’re not the right investors for us.

Your trust is not and will not be for sale in any deal or acquisition.

We’re not saying this out of some naïveté about how the “real world” works. This is not our first rodeo in startupland or softwareland. We’re saying this precisely because we HAVE been out in the real world, and have seen what can happen to the communities around technologies without such commitments.


Aaron Stannard & Andrew Skotzko
Co-founders, Petabridge

If you liked this post, you can share it with your followers or follow us on Twitter!
Written on March 31, 2015


Upcoming Petabridge Live Akka.NET Webinar Trainings

Get up to speed on the bleeding edge of large-scale .NET development with the Petabridge team. Each training is done remotely via webinar, lasts four hours, and will save you weeks of trial and error.

Get to the cutting edge with Akka.NET

Learn production best practices, operations and deployment approaches for using Akka.NET.