Editing Open-source software (section)

=== 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" />