Open-source software

Open-source software is computer software that is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose. Open-source software may be developed in a collaborative, public manner. Open-source software is a prominent example of open collaboration, meaning any capable user is able to participate online in development, making the number of possible contributors indefinite. The ability to examine the code facilitates public trust in the software.
Open-source software development can bring in diverse perspectives beyond those of a single company. A 2024 estimate of the value of open-source software to firms is $8.8 trillion, as firms would need to spend 3.5 times the amount they currently do without the use of open source software.
Open-source code can be used for studying and allows capable end users to adapt software to their personal needs in a similar way user scripts and custom style sheets allow for web sites, and eventually publish the modification as a fork for users with similar preferences, and directly submit possible improvements as pull requests.

Definitions

The Open Source Initiative's definition is recognized by several governments internationally as the standard or de facto definition. OSI uses The Open Source Definition to determine whether it considers a software license open source. The definition was based on the Debian Free Software Guidelines, written and adapted primarily by Bruce Perens. Perens did not base his writing on the "four freedoms" from the Free Software Foundation, which were only widely available later.
Under Perens' definition, open source is a broad software license that makes source code available to the general public with relaxed or non-existent restrictions on the use and modification of the code. It is an explicit "feature" of open source that it puts very few restrictions on the use or distribution by any organization or user, in order to enable the rapid evolution of the software.
According to Feller et al., the terms "free software" and "open-source software" should be applied to any "software products distributed under terms that allow users" to use, modify, and redistribute the software "in any manner they see fit, without requiring that they pay the author of the software a royalty or fee for engaging in the listed activities."
Despite initially accepting it, Richard Stallman of the FSF now flatly opposes the term "Open Source" being applied to what they refer to as "free software". Although he agrees that the two terms describe "almost the same category of software", Stallman considers equating the terms incorrect and misleading. Stallman also opposes the professed pragmatism of the Open Source Initiative, as he fears that the free software ideals of freedom and community are threatened by compromising on the FSF's idealistic standards for software freedom. The FSF considers free software to be a subset of open-source software, and Richard Stallman explained that DRM software, for example, can be developed as open source, despite that it does not give its users freedom, and thus does not qualify as free software.

Open-source software development

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, people responsible for managing the project, and people responsible for implementation. Traditional software engineering follows the cathedral model.
The bazaar model, however, is different. In this model, roles are not clearly defined. Some proposed characteristics of software developed using the bazaar model should exhibit the following patterns:

Users should be treated as co-developers: The users are treated like co-developers and so they should have access to the source code of the software. Furthermore, users are encouraged to submit additions to the software, code fixes for the software, bug reports, documentation, etc. Having more co-developers increases the rate at which the software evolves. Linus's law states that given enough eyeballs all bugs are shallow. This means that if many users view the source code, they will eventually find all bugs and suggest how to fix them. Some users have advanced programming skills, and furthermore, each user's machine provides an additional testing environment. This new testing environment offers the ability to find and fix a new bug.
Early releases: The first version of the software should be released as early as possible so as to increase one's chances of finding co-developers early.
Frequent integration: Code changes should be integrated as often as possible so as to avoid the overhead of fixing a large number of bugs at the end of the project life cycle. Some open-source projects have nightly builds where integration is done automatically.
Several versions: There should be at least two versions of the software. There should be a buggier version with more features and a more stable version with fewer features. The buggy version is for users who want the immediate use of the latest features and are willing to accept the risk of using code that is not yet thoroughly tested. The users can then act as co-developers, reporting bugs and providing bug fixes.
High modularization: The general structure of the software should be modular allowing for parallel development on independent components.
Dynamic decision-making structure: There is a need for a decision-making structure, whether formal or informal, that makes strategic decisions depending on changing user requirements and other factors. This is in comparison with extreme programming.

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.

Advantages

Open source implementation of a standard can increase the adoption and long-term viability of that standard. It often fosters developer loyalty, as contributors feel a greater sense of participation and ownership in the development process and the end product.
Moreover, lower costs of marketing and logistical services are needed for OSS. OSS can be a tool to promote a company's image, including its commercial products. The OSS development approach has helped produce reliable, high quality software quickly and inexpensively.
Open source development offers the potential to quicken innovation and create of social value. In France for instance, a policy that incentivized government to favor free open-source software increased to nearly 600,000 OSS contributions per year, generating social value by increasing the quantity and quality of open-source software. This policy also led to an estimated increase of up to 18% of tech startups and a 14% increase in the number of people employed in the IT sector.
OSS can be highly reliable when it has thousands of independent programmers testing and fixing bugs of the software. Open source is not dependent on the company or author that originally created it. Even if the company fails, the code continues to exist and be developed by its users.
OSS is flexible because modular systems allow programmers to build custom interfaces, or add new abilities to it and it is innovative since open-source programs are the product of collaboration among a large number of different programmers. The mix of divergent perspectives, corporate objectives, and personal goals speeds up innovation.
Moreover, free software can be developed in accordance with purely technical requirements. It does not require thinking about commercial pressure that often degrades the quality of the software. Commercial pressures make traditional software developers pay more attention to customers' requirements than to security requirements, since such features are somewhat invisible to the customer.

Development tools

In open-source software development, tools are used to support the development of the product and the development process itself.
Version control systems such as Centralized Version control system and the distributed version control system are examples of tools, often open source, that help manage the source code files and the changes to those files for a software project in order to foster collaboration. CVCS are centralized with a central repository while DVCS are decentralized and have a local repository for every user. Concurrent Versions System and later Subversion are examples of CVCS, whereas Git is a DVCS and the most widely used version control software. The repositories are hosted and published on source-code-hosting facilities such as GitHub or Gitlab.
Open-source projects use utilities such as issue trackers to organize open-source software development. Commonly used bug trackers include Bugzilla and Redmine.
Tools such as mailing lists and IRC provide means of coordination and discussion of bugs among developers. Project web pages, wiki pages, roadmap lists and newsgroups allow for the distribution of project information that focuses on end users.