When discussing open source with colleagues, I tend to assume that they already know the basics. But, as open source becomes a standard part of all software development, and the number of people working with open source grows, this has become less and less true.

What follows is a minimal viable vocabulary, which I’m posting here so that I can link to it elsewhere when having these conversations, and attempting to assume a lingua franca.

Open Source

Open source refers to software which is developed and released under an OSI (Open Source Initiative) approved license. Open source licenses are those that comply with the Open Source Definition, which sets forth ten tenets which are mandatory components of a compliant license.

Within these tenets, there is a lot of room for variation, and thus there are many licenses that qualify as open source licenses, ranging from extremely permissive (“Do whatever you want with this code.”) to much more restrictive (“You must do these things with the code.”)

While, strictly speaking, “open source” is a legal definition of the license under which software is released, it also implies a project which is run under the guidelines of the Four Opens – Open Source, Open Design, Open Development, and Open Community. In reality, most projects fall short of that ideal in some way, but it is an ideal to be striven for.

Fork

A fork is a copy of an open source project, for the purpose of making changes to the source code. Usually, this is done with the intention of offering those changes back to the original (“upstream”) project for inclusion in future versions (See “PR/MR/Patch”)

A private fork is when this copy is made privately, inside a particular company or organization, without visibility to the upstream.

A public fork, as the name indicates, is done in public where everyone on the project can see what changes are being proposed. This is always preferable, as it allows the project community to comment and participate in these changes, rather than them being a surprise.

A hostile fork is when a project is forked with no intention to ever contribute back, but, rather, to continue to run a competing project indefinitely. This should be considered only in the most extreme of situations.

PR/MR/Patch

A PR (Pull Request), MR (Merge Request) or Patch, are all terms for offering a change back to the originating project (“upstream”), for inclusion in future versions of that project. The terms indicate different ways that the change may be submitted, but all refer to essentially the same thing – a proposed change.

A PR is the desired end-game on any fork. Forks should be short-lived, and have a specific proposed change in mind, rather than being long-running or permanent artifacts.

Upstream

An upstream project refers to the open source project from which you are building. That implies the existence of a downstream – a project, product, or service which inherits some or all of its code from that upstream. For example, Apache Kafka is the upstream for Amazon Managed Streaming for Apache Kafka (MSK). (Which, of course, implies that MSK is the downstream from Apache Kafka.)

The upstream/downstream relationship is symbiotic. That is, a project relies on users, and a product or service relies on the upstream’s health and sustainability. As such, a downstream product or service should do everything in its power to support and sustain the project which it depends on. And project, in their turn, should listen to customers and users, and be responsive to them.

Maintainer

A maintainer is someone empowered to make changes to an open source project, and/or to make releases of that project. Ideally, a healthy project will have multiple maintainers, and there will be healthy discussion and debate around changes that go into a project.

Single-maintainer projects, or single-vendor projects (ie, where all maintainers come from the same vendor/company/organization) pose a risk to the sustainability of that project, since the change in direction from one source can result in the user community being suddenly disenfranchised or surprised. Thus, it is an ideal of open community that there be a diversity of inputs in the pool of maintainers, to ensure that all voices are equally heard when changes are made.