Before You Build
Open SourceStill Online

FoundationDB

FoundationDB is a distributed database that later became open source. Its 2015 post-acquisition download and repository interruption shows how developer tools can create dependency-continuity risk even when the technology is strong.

Visit product

Product snapshot

What it was

FoundationDB provides a distributed datastore with global, cross-row ACID transactions and a scalable key-value core.

Who it was for

backend developersinfrastructure teamscompanies needing scalable transactional storagedevelopers evaluating NoSQL systems

Problem / value

It reduced the tradeoff between distributed scale and data correctness for teams building reliable data systems.

Core workflow

Developers use FoundationDB as a transactional distributed storage layer, then build higher-level data models or systems on top of its core.

Core dependency

The ecosystem depended on durable access to downloads, repositories, licenses, documentation, installers, and vendor-controlled distribution.

Product form

commercial database software before acquisitioncommunity/downloadable version before acquisitionopen-source core after 2018developer documentationGitHub source codebinary installers

Pricing model

Public sources describe paid and community versions before acquisition, but do not disclose pre-acquisition revenue, paid conversion, renewal rates, or support pricing.

Competitors or alternatives

NoSQL databasesdistributed databasescloud-managed data storesopen-source databasescommercial infrastructure tooling

What happened

Summary

After Apple acquired FoundationDB in 2015, database downloads and repository access were interrupted before the core project became open source in 2018.

Outcome

FoundationDB is now online and open source, but the acquisition-era access gap created a developer dependency-continuity warning.

Core risk

Developer tools can be technically strong and still expose users to access risk when distribution is controlled by one owner.

Timeline

  • FoundationDB built a distributed transactional database product.
  • TechCrunch reported Apple acquired FoundationDB in March 2015.
  • TechCrunch reported FoundationDB stopped offering downloads after the acquisition.
  • InfoWorld reported repositories were removed or privatized after the reported purchase.
  • In April 2018, GeekWire and FoundationDB announced the core database was released as open source.

Before you build

Why it matters

Databases, SDKs, APIs, and infrastructure tools become embedded in production systems. If downloads, repositories, licenses, or support disappear after acquisition or strategy change, users inherit operational risk.

Primary check

Before building or adopting a developer tool, database, SDK, API, or infrastructure product, verify governance, license durability, export paths, and what happens if ownership or distribution changes.

Checklist

  • What production dependency would break if downloads stopped?
  • Who controls repository and release access?
  • Is the license durable enough for user trust?
  • Can users build a fallback path before adopting?
  • Does the business model support continued maintenance?
  • Can users keep using the tool if the company is acquired?
  • Are downloads and repositories guaranteed or mirrored?
  • What license rights survive a pivot or shutdown?
  • Can users export, migrate, or self-host critical workloads?
  • What customer communication happens before access changes?

Relevant if

  • You are building a database, SDK, API, developer tool, plugin platform, open-source core, or infrastructure service.
  • Users may depend on your tool in production.
  • Your adoption depends on a community or free edition.

Less relevant if

  • Your tool is disposable, stateless, or not part of production systems.
  • Users can fully export or self-host without relying on your company.
  • Governance and licensing are already independent of a single vendor.

Pre-build tests

  • Document a continuity policy before launching a community edition.
  • Test migration and export paths with early production users.
  • Publish a clear governance model for repositories, releases, and licenses.

Transferable lessons

  • Make availability promises explicit before production adoption.
  • Clarify what happens to community editions after acquisition or pivot.
  • Publish export, migration, and self-hosting paths when users build on your tool.
  • Do not treat free developer adoption as low-stakes if users rely on it operationally.
  • For dependency choices, evaluate governance and license durability before technical fit alone.