Open source is better off without FoundationDB

When FoundationDB mysteriously folded, some people thought it was an indictment of open source. On the contrary, the episode shows why open source is needed

young man standing in front of open doorway white background
Credit: Shutterstock

Database startup FoundationDB mysteriously vanished at the end of last month, along with both the downloads of its proprietary database and its open source projects.

As it turned out, Apple bought the company for internal use. I was interested in how this was perceived. When Ben Kepes of Forbes initially wrote about the purchase, for example, he erred in characterizing FoundationDB as all open source. It was an easy mistake; the company used the language of developer communities. Many of us assume "open" when we hear "community" because open source is so much the default these days.

But as a reader pointed out to him, the only open source code FoundationDB offered (as is clear from the now-deleted FAQ) was helper code mainly intended to draw you into its sphere of influence. If you used the code for your own project, you can carry on doing so as long as you kept a copy, but the central repository is gone -- as is FoundationDB.

This looks to me like a classic example of open-washing -- with "free versions," "gradual opening," "community projects," and "open source parts," yet without delivering open source code for the whole offering. This sleight of hand is dangerous for customers, and I've been accused of extremism for saying this sort of thing. "Businesses have to make money," I'm told. "It's their code, they can do what they want," people add.

They certainly can. They have the liberty to choose a business model that denies you yours. But if you care about the flexibility of your business, you'll also want to protect your liberty. Open source does not inherently need monetizing; choosing to do so is only one of the options open to developers. It's possible to release substantial open source code in full without reserving special privileges. Facebook and Twitter do it all the time, for example.

The lesson to draw, in my view, is that companies like FoundationDB who wrap themselves in the flag but actually have no intention of delivering the four freedoms should be avoided at all costs. It's important to check that the liberties to deliver customer flexibility are present, every time.

By contrast, genuinely open source code -- even when delivered questionably -- can always be forked and sustained, like Forgerock did with Sun's identity middleware, as my colleague Gilles Gravier wrote about recently. It's also desirable that it be managed by an independent community entity -- a "foundation" -- but what matters first is having the full source code to the entire project under an OSI-approved copyright license.

The word "free" is deceptive to English speakers. In this case, it establishes a frame that allows an incorrect conclusion to be drawn about the community. Open source communities are purely about liberty and code; money is orthogonal, and we should not let it cloud the issue of community freedoms. Getting "free code" is not the same as getting code with freedom.

While I remain a proponent of anchoring open source communities in not-for-profit, community-accountable entities, foundations don't protect code -- being fully, genuinely open source does. The role of a foundation is to sustain that protection. FoundationDB was not flawed because it was not in a nonprofit entity; it was flawed because it delivered at best partial software freedom. As it turns out, software freedom is your best guarantee of business value.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies