Today, we are releasing the first version of COSS Glossary, a set of definitions of commonly used terms in the open source technology world. The motivation behind this document is to help remove the confusion and conflation that often occur when different stakeholders discuss open source, with or without a commercial angle, and make open source more accessible to newcomers. While people we've been working in open source for a long time may find these terms "obvious", it's sadly not the case for new developers who are creating projects or contributing to open source for the first time. And they are popping up around the world every single day.
Without a common set of precisely-worded definitions of the fundamental concepts, it's difficult, even counter-productive sometimes, to have second-order discussions on topics like: how do I build a vibrant community? which license should I choose to maximize adoption? how do I position my commercial offering vis-a-vis the open source community version? The list goes on...
This list of definitions is compiled by the team at OSS Capital, and we will continue to add and update it as time goes on. We welcome the community to participate by commenting, adding new terms, and proposing edits, so this glossary can evolve into a foundational document that can help all open source stakeholders establish a common set of understanding, in order to have more fruitful discussions. Please do so in our GitHub repo.
Terms and Definitions
Open source (common short-hand: OS): A transparent technology creation, development, collaboration, and distribution model, where the source, deliberation, decision-making, and roadmap of the technology are all presented and conducted publicly. It is not a type of company, business, or business model.
Open source software (common short-hand: OSS or FOSS--Free and Open Source Software): Software made generally available under a copyright license that meets the Open Source Definition, as defined by the Open Source Initiative.
Source Available Software: Software made generally available in source code form under a copyright license that does not meet the Open Source Definition. This type of license is also called a limited source code license.
Example: MongoDB under the Server Side Public License (SSPL), MariaDB under the Business Source License (BSL).
Commercial open source software (common short-hand: COSS): A category of companies or business units that commercializes open source technology. The existence of COSS depends on the existence of the corresponding open source technology but not vice versa. Often times, these businesses are founded or led by the core maintainers and committers of the open source technology from which they are built. (See different definitions of "Maintainer" and "Committer" below)
Example: see the Commercial Open Source Software Index (COSSI), a list of COSS companies that have reached $100 million USD in annual revenue.
Public Domain Software: Software made generally available with no copyright license conditions at all.
Example: SQLite
Open Core: A business model, or subset of the COSS company category, where an open source project is the foundation (or “core”) from which a commercial product is built and copyrighted under a proprietary license (as opposed to an open source license). The proportion of open and proprietary in a product offering, depends on the particular use case, technology, and business value. (See below different definitions of "Project" and "Product". See this post for a more detailed discussion of “open core” implementation.)
Single-Vendor: A term that describes when an open source project is primarily developed and commercialized by a single business entity, commonly known as a vendor.
Multi-Vendor: A term that describes when an open source project is developed and commercialized by more than one business entity.
Project: A piece of technology that is created, developed, and maintained based on open source methodology and can be independently used for its functionality. It is not commercially licensed or sold directly, but are often supported or serviced via commercial agreements between user and service provider.
Product: A commercially licensed product built on top of an open source project that are packaged, distributed, and sold to customers of the COSS entity that built this product. It is a discreet but related piece of technology to its open source project base.
Benevolent Dictator For Life (common short-hand: BDFL): An open source community governance model where a single person, typically the creator of the project, makes most of the major decisions associated with the project.
Maintainer: A developer whose main responsibility is to drive and manage the roadmap and development of an open source project by engaging in activities such as code review, roadmap, governance, and community and ecosystem building. It’s typically considered a community position with the most responsibility and power. It is also often used interchangeably with "Committer" (see below), because both roles have commit access to the project and can review and merge changes from a "Contributor" (see below).
Committer: A developer whose main responsibility is to build core features and improvements of an open source project and conduct code review of other contributions. It’s typically considered a community position with the second most responsibility and power, but it's also often used interchangeably with "Maintainer" (see above), because both roles have commit access to the project and can review and merge changes from a "Contributor" (see below).
Contributor: A developer who makes either regular or ad-hoc contributions to the code base of an open source project, reviewed and merged by either the maintainer or committer. The scale and difficulty of contributions vary widely, from fixing major bugs or developing a feature, to fixing typos and formatting in the documentation.
Governance: A set of rules and procedures, similar to a corporation’s bylaws or a country’s constitution, that outlines how an open source project makes technical and community decisions, and how individual developers become maintainers, committers, contributors, or other community roles. These rules and procedures typically exist in a public document in either the project’s code repository or website.
Foundation: A not-for-profit entity that hosts open source projects inside a neutral organization, separated from any commercial entities that monetize the projects. The foundation is typically responsible for the governance, legal, trademark, and other administrative work associated with managing an open source project. It also engages in marketing, educational, and ecosystem-building activities for the projects it hosts.
A foundation often plays a key role in ensuring the sustainability and longevity of open source projects, independent of whether the projects are being monetized or commercialized by companies.
Code of Conduct: A set of community policies and norms articulated and applied as the basis to manage, moderate, and adjudicate the behaviors of and communications between members of an open source community. It is usually in the form of a public document in either the project’s code repository or website.
Top comments (3)
There's a bunch of open source software that doesn't meet the OSI definition, though. Just saying that's how you're going to use it doesn't help, because it's not enforceable.
Thank you for your comment! Your perspective is one of the core reasons why we decided to put this glossary together, because there's a lot of confusion around what is "open source" from a legal/licensing angle and what is "open source" from a marketing angle. There are quite a few non-open source projects that are portrayed as "open source" still because they used to be open source until a licensing change that makes it them not so. The definition reflected here is along the legal/licensing angle as enshrined and indeed still enforced by the OSI.
This distinction is important for developers for two reasons:
if you are using a given open source project, especially inside a company for say your employer, whether the project is/isn't "open source" based on its licensing directly impacts how you can use the project, and may even trigger a discussion with your legal/compliance department (no one likes that!). Certain organizations now have dedicated "open source programs" that deal directly with this type of issues. See a list of such companies on the TOGO Group website.
if you want to commercialize an open source project, either by building a commercial open source software company around the project or provide service/support around it, whether project is definitionally "open source" from the legal/licensing angle directly impacts how/if/how widely the project will be adopted, which impacts the future potential of your company.
To be clear: this is not to say non-open-source or formally open source projects are lesser technologies. They aren't. They should be used for their proper use case just like anything else. But a project that's no longer "open source" definitionally speaking but still called "open source" when being marketed publicly might cause unpleasant surprises for developers who use them, and we want to help them steer clear of that as much as possible.
One someone was talking about on here recently was Kirby which is open source but the license is restrictive, and you're not allowed to deploy it anywhere without paying. It's not something that used to be open source and then changed, this is their model.