The “Open Source” in CockroachDB

What makes CockroachDB free and open source software?

• The source code is available online.
• There is an open source license for a large, functional, autonomous subset of the software. The specific license, the Apache License, makes this subset of CockroachDB fully free.

What makes CockroachDB an open source project?

• The software is open source (see above).
• There are clear and reproducible instructions on how to build CockroachDB from source in new environments.
• Online help is available to help with building, installing and using the software.
• The project is welcoming of external contributions.

Classical and simple FOSS governance

In the first category, projects are created to either scratch the hacker’s itch or for public good. The authors and, if applicable, the funding organization, give birth to an entity with the aim upfront to have its community self-organize and decide its governance. Most, if not all, have as founding principle that the project’s governance is, nominally at least, open to the public via a documented and transparent process. A newcomer to the project can legitimately assume upfront that the project is partly theirs and that their influence on the project is guaranteed to grow in proportion to their contributions.

There is a pitfall where such a born-FOSS project becomes funded by a single for-profit organization, and evolves to serve primarily the interests of that organization instead of that of its community (LLVM/Clang is an example of this vis-a-vis Apple, more on that below) because the livelihood of most core contributors depends on that organization. Nevertheless, this is more an exception than the rule, and so far I have found that most healthy FOSS projects are careful to ensure that many of its core contributors are supported by different organizations.

In the second category, there is a business building new software more or less in private, in any case with a big entry sign in front of its door: “this product is ours, and you must give us money before we allow you to use it” (nowadays the money can be in the form of advertisement-receiving eyeballs, but the idea remains the same). There is initially no pretense of shared ownership, and the users are reminded regularly that they do not have any participatory rights.

Then, at some point, the business changes and abandons moral ownership over the software. This event can occur for a variety of reasons (bankruptcy, pivot, leadership change, whatever) which are not relevant here; instead, I want to focus on the observation that there is then a pivotal event where a community of users is handed the keys to a kingdom previously guarded, with a fundamental guarantee that the king has left the premises and is not coming back—usually via suitably irrevocable FOSS license, but it can also be organized via a copyright reassignment to a non-profit organization with an open charter. What happens then is that both existing users and some of the previous contributors gather and decide to create a new governance. In reaction to the previous closed ownership, the new governance is, again, nominally at least, open to the public via a documented and transparent process.

This was the story of e.g. StarOffice opening itself as OpenOffice and finally LibreOffice.

The result is organizationally similar to that described above, but the dynamics of the interaction between newcomers and a late-freed project are rather different. To understand why, consider this analogy: a born-freed FOSS project is like a social group building their shared home together on top of a vacant plot of land; a late-freed FOSS project, instead, is like a group moving in a giant mansion inherited from an old, quirky relative. There is outdated upholstery to get rid of; there are poorly maintained pipes to renovate at yet-undetermined costs, and, foremost, the overall architecture of the mansion was fundamentally built for someone else, not for the new inhabitants. Newcomers can legitimately feel that the project is partly “theirs” and that their influence can grow with their contributions, but there are days that bring reminders of the previous owner, much like ghosts of a haunted mansion.

Hybrid FOSS governance—spectrum of influence

The third category, where one can find RedHat and Ubuntu Linux, Go, Rust and now CockroachDB, is quite different. I’ll call them “hybrid” FOSS projects.

In this case, there is a for-profit organization who bankrolls the development. Meanwhile, the source code is public and there is an open source license, even a FOSS one usually. Forks and other reuses of the FOSS code are permitted, but the name and/or the brand is trademarked, such that an individual or a third party organization cannot derive a new project from the same sources with the same name.

The governance model, in particular the process available to an external contributor to become acknowledged as part of a steering group, further depends on the structure of the business around the FOSS project. As for most things, there is a spectrum.

At one end of the spectrum, if the organization is merely building FOSS as an instrument to create a community on top of which it can sell services or other professional services, i.e. where the FOSS and/or related IP is not a leveraged asset of the for-profit, then the governance is usually public. Steering groups and/or “core teams” meet on public channels, the membership process is transparent, public and open to all, and the parent for-profit typically only acts in an advisory role. Ubuntu Linux was created in that way by Canonical, its parent company.

At the other end of the spectrum, the software is a core asset of the for-profit, which the for-profit expects to directly leverage for income (by selling deployment licenses or subscriptions, or by proposing it as a gateway drug to a more expensive, proprietary product). Out of business necessity, the steering is exclusively reserved to the for-profit, and the core team is closed to the public. The existence of the FOSS license is seen as a source of undesirable extra costs (support and communication with the community) and merely supported or tolerated for the free advertisement it generates. External contributions are accepted and integrated from external contributors under the condition that they relinquish their copyright to the parent organization, and there is no compensation in the form of participatory rights in the steering activities. Arguably, MySQL belongs more to this category.

And then there is a range of various FOSS projects between these two extremes. Where they belong is, again, a function of their governance model: how external contributions are welcomed, how external contributors can raise in the community to gain steering powers, and all in all how individual users and contributors can legitimately feel the software is “theirs”.

The Rust project, currently bankrolled by Mozilla, is much more like Ubuntu Linux than it is like MySQL. All development occurs in public, including all the project steering. Any external contributor is given the opportunity to contribute to the project’s steering via the RFC process—how much influence can be exercised this way being only a function of the contributor’s own technical acumen and their reputation, as opposed to opaque decision making by the community. What distinguishes the governance in this case from the laissez-faire in Ubuntu’s case, is that the FOSS project is steered primarily to support a core business in the parent organization: Firefox’ Servo in the case of Rust, the IT services in the case of RedHat.

In contrast, one would find the Go project closer to MySQL on that spectrum than Rust. While development occurs in public, the steering process is opaque and driven solely by Google’s own internal (non-public) uses of the Go language. While external contributions are welcome and the parent organization supports the community by funding events, etc., there is no process by which an external contributor can ascend in a steering position; changes to the core project (the language and the compiler) are still gated by the parent organization.

Where does CockroachDB fall on this spectrum? Currently, a bit in the middle: the project is a bit more open to external influence than Go, but less so than Rust.