Background: open-source software

Open-source software (OSS) is computer software whose source code is publicly available, allowing users to use, study, modify, and distribute it — in contrast with proprietary (closed-source) software. These abilities are typically granted through open licenses or, more rarely, by dedication to the public domain. The development of open-source software can be based on open collaboration, a decentralized model of production. It is commonly defined according to the Open Source Definition of the Open Source Initiative, but the precise meaning of "open source" remains contentious.

Open-source software offers a range of benefits, but also presents specific risks and challenges. It can provide improved accessibility through lower and shared costs, greater adaptability through customization, transparency with auditable code, better interoperability via open standards, and independence from vendor lock-in, among others. Due to its ubiquity in modern software, open-source software raises major cybersecurity concerns, as well as significant maintenance challenges.

Open-source software has become the backbone of the global digital infrastructure, powering domains such as web servers, cloud computing, supercomputers, mobile devices, artificial intelligence, and Internet of Things. A 2022 estimate suggests that between 80 and 96 percent of the code making up software on the market today, including proprietary software, is of open-source origin.

Its adoption has grown steadily across public institutions, the private sector, and academia, driven by motivations of cybersecurity, digital sovereignty, and independence from proprietary software, with significant geopolitical implications. Organizations are increasingly setting up Open Source Program Offices to manage their strategies.

Definitions and controversies

Open source software is mainly defined according to the Open Source Definition (OSD) established by the Open Source Initiative (OSI). To qualify as open source under this framework, software must provide its source code and be distributed under a license meeting the ten OSD criteria, notably including non-discrimination against persons, groups, or fields of endeavor — enabling anyone to use, modify, and redistribute it for any purpose. The definition was based on the Debian Free Software Guidelines, written and adapted primarily by Bruce Perens and Eric S. Raymond..

The OSI maintains a list of approved licenses that conform to the OSD.

However, the OSI holds no legal authority over the term 'open source' and its definition is a matter of social convention. With its non-discrimination criteria having generated for decades what is described as a 'culture war' within software communities over the very meaning of open source — the OSI can be seen by some actors as an oppressive dogma. It occurs because developers have never learned about this history, or don’t care about it, or actively think it’s irrelevant, involving a form of intergenerational conflict. These disputes are driven by ethical and commercial concerns.

As a result, the term 'open source' can be used in ways that do not conform to the OSD, ranging from unintentional misuse to deliberate rejection of its authority.

Public-domain software is a source of disagreement as to whether it qualifies as open source software, carrying no formal licence and granting rights that vary significantly depending on the jurisdiction. The OSI itself has expressed diverging views on the matter, claiming both that "it is accurate to say that such software is effectively open source" and "it is incorrect to treat public domain software as open source".

"Open" versus "free" versus "free and open"

Free and open-source software (FOSS) or free/libre and open-source software (FLOSS) is openly shared source code that is licensed without any restrictions on usage, modification, or distribution. Confusion persists about this definition because the "free", also known as "libre", refers to the freedom of the product, not the price, expense, cost, or charge. For example, "being free to speak" is not the same as "free beer".

Conversely, Richard Stallman argues the "obvious meaning" of term "open source" is that the source code is public/accessible for inspection, without necessarily any other rights granted, although the proponents of the term say the conditions in the Open Source Definition must be fulfilled.

"Free and open" should not be confused with public ownership (state ownership), deprivatization (nationalization), anti-privatization (anti-corporate activism), or transparent behavior.

Software ownership

Open-source software is owned by its authors who retain the copyright, from which they confer the right to use, modify and redistribute the software through the use of license. Without external agreements, contributions are owned by their authors resulting in copyright being shared among contributors. In this legal context, some projects use Contributor License Agreement (CLA) or a copyright assignment agreement to keep control over the copyright of the project, providing the ability to relicense the software under different terms.

Some types of open source software are therefore described as proprietary software.

Development model

In his 1997 essay The Cathedral and the Bazaar, open-source influential contributor Eric S. Raymond suggests a model for developing OSS known as the bazaar model. Raymond likens the development of software by traditional methodologies to building a cathedral, with careful isolated work by individuals or small groups. He suggests that all software should be developed using the bazaar style, with differing agendas and approaches.

In the traditional model of development, which he called the cathedral model, development takes place in a centralized way. Roles are clearly defined. Roles include people dedicated to designing (the architects), people responsible for managing the project, and people responsible for implementation. Traditional software engineering follows the cathedral model.

The process of Open source development begins with a requirements elicitation where developers consider if they should add new features or if a bug needs to be fixed in their project. This is established by communicating with the OSS community through avenues such as bug reporting and tracking or mailing lists and project pages. Next, OSS developers select or are assigned to a task and identify a solution. Because there are often many different possible routes for solutions in OSS, the best solution must be chosen with careful consideration and sometimes even peer feedback.

The developer then begins to develop and commit the code. The code is then tested and reviewed by peers. Developers can edit and evolve their code through feedback from continuous integration. Once the leadership and community are satisfied with the whole project, it can be partially released and user instruction can be documented. If the project is ready to be released, it is frozen, with only serious bug fixes or security repairs occurring. Finally, the project is fully released and only changed through minor bug fixes.