Editing Open-source software (section)

== Open-source software development ==
{{Main|Open-source software development model}}
{{See also|GitHub}}

=== 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.<ref name=":9" /> Raymond likens the development of software by traditional methodologies to building a cathedral, with careful isolated work by individuals or small groups.<ref name=":9" /> He suggests that all software should be developed using the bazaar style, with differing agendas and approaches.<ref name=":9" />

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

The bazaar model, however, is different.<ref name=":9" /> In this model, roles are not clearly defined.<ref name=":9" /> Some proposed characteristics of software developed using the bazaar model should exhibit the following patterns:<ref name=":11">{{Cite book |title=2006 22nd IEEE International Conference on Software Maintenance |url=https://ieeexplore.ieee.org/document/4021360 |access-date=2023-11-21 |doi=10.1109/icsm.2006.25 |date=2006 |last1=Robles |first1=Gregorio |chapter=Empirical Software Engineering Research on Free/Libre/Open Source Software |pages=347–350 |isbn=0-7695-2354-4 |s2cid=6589566 }}</ref>

''[[Crowdsourcing|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.<ref name=":11" /> Furthermore, users are encouraged to submit additions to the software, code fixes for the software, [[bug report]]s, documentation, etc. Having more co-developers increases the rate at which the software evolves.<ref name=":11" /> [[Linus's law]] states that given enough eyeballs all bugs are shallow.<ref name=":11" /> This means that if many users view the source code, they will eventually find all bugs and suggest how to fix them.<ref name=":11" /> Some users have advanced programming skills, and furthermore, each user's machine provides an additional testing environment.<ref name=":11" /> This new testing environment offers the ability to find and fix a new bug.<ref name=":11" />

''[[Release early, release often|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.<ref name=":11" />

''[[Continuous integration|Frequent integration:]]'' Code changes should be integrated (merged into a shared code base) 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.<ref name=":11" /><ref name=":24">{{Cite book |last1=Napoleao |first1=Bianca M. |last2=Petrillo |first2=Fabio |last3=Halle |first3=Sylvain |chapter=Open Source Software Development Process: A Systematic Review |date=2020 |title=2020 IEEE 24th International Enterprise Distributed Object Computing Conference (EDOC) |chapter-url=https://ieeexplore.ieee.org/document/9233046 |publisher=IEEE |pages=135–144 |doi=10.1109/EDOC49727.2020.00025 |isbn=978-1-7281-6473-1|arxiv=2008.05015 }}</ref> Some open-source projects have nightly builds where [[Continuous integration|integration is done automatically]].<ref name=":11" />

''[[Software versioning|Several versions:]]'' There should be at least two versions of the software.<ref name=":11" /> There should be a buggier version with more features and a more stable version with fewer features.<ref name=":11" /> The buggy version (also called the development 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.<ref name=":11" /> The users can then act as co-developers, reporting bugs and providing bug fixes.<ref name=":11" /><ref name=":10" />

''[[Modular programming|High modularization:]]'' The general structure of the software should be modular allowing for parallel development on independent components.<ref name=":11" />

''[[Dynamic decision-making|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.<ref name=":11" /> Compare with [[extreme programming]].<ref name=":11" />

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.<ref name=":10" /> This is established by communicating with the OSS community through avenues such as [[bug tracking system|bug reporting and tracking]] or [[mailing list]]s and project pages.<ref name=":10" /> 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]].<ref name=":10" /> The developer then begins to develop and commit the code.<ref name=":10" /> The code is then tested and reviewed by peers.<ref name=":10" /> Developers can edit and evolve their code through feedback from [[continuous integration]].<ref name=":10" /> Once the leadership and community are satisfied with the whole project, it can be partially released and user instruction can be documented.<ref name=":10" /> If the project is ready to be released, it is frozen, with only serious bug fixes or security repairs occurring.<ref name=":10" /> Finally, the project is fully released and only changed through minor bug fixes.<ref name=":10" />

===Advantages===
Open source implementation of a standard can increase adoption of that standard.<ref name="dod16">{{cite web|last1=US Department of Defense|title=Open Source Software FAQ|url=https://dodcio.defense.gov/Open-Source-Software-FAQ/|website=Chief Information Officer|access-date=22 July 2016|archive-date=28 August 2016|archive-url=https://web.archive.org/web/20160828150638/http://dodcio.defense.gov/Open-Source-Software-FAQ/|url-status=live}}</ref> This creates developer loyalty as developers feel empowered and have a sense of ownership of the end product.<ref name="Sharma2002">{{cite journal | first=Srinarayan | last=Sharma | author2=Vijayan Sugumaran | author3=Balaji Rajagopalan | title=A framework for creating hybrid-open source software communities | journal=Information Systems Journal | volume=12 | year=2002 | pages=7–25 | url=http://www.cin.ufpe.br/~in953/lectures/papers/ISJAFrameworkForCreatingHybrid-OpenSourceSoftwareCommunities.pdf | doi=10.1046/j.1365-2575.2002.00116.x | s2cid=5815589 | access-date=8 September 2008 | archive-date=30 October 2008 | archive-url=https://web.archive.org/web/20081030014215/http://www.cin.ufpe.br/~in953/lectures/papers/ISJAFrameworkForCreatingHybrid-OpenSourceSoftwareCommunities.pdf | url-status=live }}</ref>

Moreover, lower costs of marketing and logistical services are needed for OSS.<ref name=":21" /> OSS can be a tool to promote a company's image, including its commercial products.<ref>{{cite journal | title=Profiting from Open Source | first=John | last=Landry |author2=Rajiv Gupta | journal=[[Harvard Business Review]] |date=September 2000 | doi=10.1225/F00503 |doi-broken-date=1 November 2024 }}</ref> The OSS development approach has helped produce reliable, high quality software quickly and inexpensively.<ref name=":21">{{cite journal | title=Open Source, Open Standards, and Health Care Information Systems | last=Reynolds | first=Carl |author2=Jeremy Wyatt | journal=[[Journal of Medical Internet Research]] |date=February 2011 | doi=10.2196/jmir.1521 | pmid=21447469 | pmc=3221346 | volume=13 | issue=1 | pages=e24 | doi-access=free }}</ref>

Open source development offers the potential to quicken innovation and create of social value.<ref name=":35" /> 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.<ref name=":35" /> 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.<ref name=":35">{{Cite journal |last=Nagle |first=Frank |date=3 March 2019 |title=Government Technology Policy, Social Value, and National Competitiveness |url=https://www.cin.ufpe.br/~in953/lectures/papers/ISJAFrameworkForCreatingHybrid-OpenSourceSoftwareCommunities.pdf| journal=Information Systems Journal| volume=12| language=en| doi=10.2139/ssrn.3355486 |ssrn=3355486 |s2cid=85509685 }}</ref>

OSS can be highly reliable when it has thousands of independent programmers testing and fixing bugs of the software.<ref name=":11" /> Open source is not dependent on the company or author that originally created it.<ref name=":55" /> Even if the company fails, the code continues to exist and be developed by its users.<ref name=":55" />

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.<ref name=":11" /> The mix of divergent perspectives, corporate objectives, and personal goals speeds up innovation.<ref>{{cite journal | first=Hal | last=Plotkin | title=What (and Why) you should know about open-source software | journal=Harvard Management Update |date=December 1998 | pages=8–9  }}</ref>

Moreover, free software can be developed in accordance with purely technical requirements.<ref name=":36" /> It does not require thinking about commercial pressure that often degrades the quality of the software.<ref name=":36" /> 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.<ref name=":36">{{cite journal | first=Christian | last=Payne | title=On the Security of Open Source Software | journal= Information Systems Journal|date=February 2002 | volume=12 | issue=1 | pages=61–78 | doi=10.1046/j.1365-2575.2002.00118.x| s2cid=8123076 }}</ref>

===Development tools===
In open-source software development, tools are used to support the development of the product and the development process itself.<ref name=":10">{{Cite book |last1=Napoleao |first1=Bianca M. |last2=Petrillo |first2=Fabio |last3=Halle |first3=Sylvain |chapter=Open Source Software Development Process: A Systematic Review |date=2020 |title=2020 IEEE 24th International Enterprise Distributed Object Computing Conference (EDOC) |chapter-url=https://ieeexplore.ieee.org/document/9233046 |publisher=IEEE |pages=135–144 |doi=10.1109/EDOC49727.2020.00025 |arxiv=2008.05015 |isbn=978-1-7281-6473-1}}</ref>

[[Version control]] systems such as Centralized Version control system (CVCS) and the [[distributed version control|distributed version control system]] (DVCS)  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.<ref name=":16">{{Cite journal |last1=Zolkifli |first1=Nazatul Nurlisa |last2=Ngah |first2=Amir |last3=Deraman |first3=Aziz |date=2018 |title=Version Control System: A Review |journal=Procedia Computer Science |language=en |volume=135 |pages=408–415 |doi=10.1016/j.procs.2018.08.191|doi-access=free }}</ref> CVCS are centralized with a central repository while DVCS are decentralized and have a local repository for every user.<ref name=":16" /> [[Concurrent Versions System]] (CVS) and later [[Subversion (software)|Subversion]] (SVN) and [[Git (software)|Git]] are examples of CVCS.<ref name=":16" /> The [[Repository (version control)|repositories]] are hosted and published on [[Comparison of source-code-hosting facilities|source-code-hosting facilities]] such as [[GitHub]].<ref name=":16" />

Open-source projects use utilities such as issue trackers to organize open-source software development. Commonly used [[Bug tracking system|bug tracker]]s include [[Bugzilla]] and [[Redmine]].<ref name=":10" />

Tools such as [[mailing lists]] and [[Internet Relay Chat|IRC]] provide means of coordination and discussion of bugs among developers.<ref name=":10" /> Project web pages, wiki pages, roadmap lists and newsgroups allow for the distribution of project information that focuses on end users.<ref name=":10" />