Jump to content

Open-source software development: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
Lulu-lists (talk | contribs)
300 edits
Further reading
 
(351 intermediate revisions by more than 100 users not shown)
Line 1: Line 1:
{{Short description|Freely accessible creation and refinement of computer programs}}
'''Open source software development''' is the process by which [[open source]] software (or similar software whose source is publicly available) is developed.
'''Open-source software development (OSSD)''' is the process by which [[open-source software]], or similar software whose [[Source Code Management|source code]] is publicly available, is developed by an '''open-source software project'''. These are software products available with its source code under an [[open-source license]] to study, change, and improve its design. Examples of some popular open-source software products are [[Mozilla Firefox]], [[Chromium (web browser)|Google Chromium]], [[Android (operating system)|Android]], [[LibreOffice]] and the [[VLC media player]].


== History ==
== Types of open source development ==
In 1997, [[Eric S. Raymond]] wrote ''The Cathedral and the Bazaar''.<ref name=Raymond>Raymond, E.S. (1999). ''The Cathedral & the Bazaar''. O'Reilly Retrieved from http://www.catb.org/~esr/writings/cathedral-bazaar/. See also: [[The Cathedral and the Bazaar]].</ref> In this book, Raymond makes the distinction between two kinds of software development. The first is the conventional closed-source development. This kind of development method is, according to Raymond, like the building of a cathedral; central planning, tight organization and one process from start to finish. The second is the progressive open-source development, which is more like "a great babbling bazaar of differing agendas and approaches out of which a coherent and stable system could seemingly emerge only by a succession of miracles." The latter analogy points to the discussion involved in an open-source development process.
There are several different types of tasks that are generally associated with the development of Open source software. These are:


Differences between the two styles of development, according to Bar and Fogel, are in general the handling (and creation) of bug reports and feature requests, and the constraints under which the programmers are working.<ref name=Barfogel>Bar, M. & Fogel, K. (2003). ''Open Source Development with CVS'', 3rd Edition. Paraglyph Press. ({{ISBN|1-932111-81-6}})</ref> In closed-source software development, the programmers are often spending a lot of time dealing with and creating bug reports, as well as handling feature requests. This time is spent on creating and prioritizing further development plans. This leads to part of the development team spending a lot of time on these issues, and not on the actual development. Also, in closed-source projects, the development teams must often work under management-related constraints (such as deadlines, budgets, etc.) that interfere with technical issues of the software. In open-source software development, these issues are solved by integrating the users of the software in the development process, or even letting these users build the system themselves.{{Citation needed|date=November 2014}}
=== Writing Code ===
This task involves working on the source code of the program - fixing bugs, adding new functionality, [[refactoring]], etc. This task is probably the most prestigious of what falls under the umbrella of open source development.


=== Documentation ===
== Model ==
{{distinguish|Open-source model}}
This task involves documenting open source programs or libraries. It either involves creating a full-coverage reference documentation, writing a [[how-to]], writing tips or tutorials, or other types of documentation.
[[Image:Process-data diagram of open source software development.png|thumb|250px|Process-Data Model for open-source software development]]


Open-source software development can be divided into several phases. The phases specified here are derived from ''Sharma et al''.<ref name=Sharma>Sharma, S., Sugumaran, V. & Rajagopalan, B. (2002). ''A framework for creating hybrid-open source software communities''. Information Systems Journal 12 (1), 7 – 25.</ref> A diagram displaying the process-data structure of open-source software development is shown on the right. In this picture, the phases of open-source software development are displayed, along with the corresponding data elements. This diagram is made using the [[meta-modeling]] and [[meta-process modeling]] techniques.
=== [[Localization]] and translations ===
This task involves translating the message emitted by the program or the ones that the user uses in the program's [[graphical user interface]].


=== Starting an open-source project ===
It should not be confused with [[internationalization]], in which the not-necessarily localized program is adapted to be able to process text in different (mainly non-[[English language|English]]) human languages. Assuming the program is not already internationalized, then internationalizing it usually requires modifications to the code (and so falls under actual programming). This is while translations and localizations can be done without involving much programming.


There are several ways in which work on an open-source project can start:
Translations could also involve the translation of the program's documentation.


# An individual who senses the need for a project announces the intent to develop a project in public.
=== Packaging ===
# A developer working on a limited but working codebase, releases it to the public as the first version of an open-source program.
Open source software by its nature is often deployed on a large number of [[operating system]]s, and distributions. Packaging involves preparing a working source or binary package for the program, so it can be more easily deployed on such systems.
# The source code of a mature project is released to the public.
# A well-established open-source project can be [[Fork (software development)|forked]] by an interested outside party.


Eric Raymond observed in his essay ''The Cathedral and the Bazaar'' that announcing the intent for a project is usually inferior to releasing a working project to the public.
=== Bug reports and feature requests ===
This type of development involves reporting [[software bug]]s, or asking for Feature Requests to the developers who then register it somehow, for further resolution.


It's a common mistake to start a project when contributing to an existing similar project would be more effective ([[Not Invented Here#In the free software community|NIH syndrome]]){{Citation needed|date=October 2019}}. To start a successful project it is very important to investigate what's already there. The process starts with a choice between the adopting of an existing project, or the starting of a new project. If a new project is started, the process goes to the Initiation phase. If an existing project is adopted, the process goes directly to the Execution phase.{{Original research inline|date=October 2019}}
=== Infrastructure ===
This involves the various tasks of dealing with the project's online or offline infrastructure: managing the project's web-site, download area, [[bug tracker]], [[version control]] system, arranging physical meetings of the developers, etc.


== Types of open-source projects ==
=== Answering questions ===
{{see also|List of free and open-source software packages}}
This task involves providing knowledgeable answers to questions raised by the people who are trying to use the open source project. (See also [http://www.catb.org/~esr/faqs/smart-questions.html the "How To Ask Questions The Smart Way" document]).


Several types of open-source projects exist. First, there is the garden variety of software programs and libraries, which consist of standalone pieces of code. Some might even be dependent on other open-source projects. These projects serve a specified purpose and fill a definite need. Examples of this type of project include the [[Linux kernel]], the Firefox web browser and the LibreOffice office suite of tools.
=== Other types ===
There may possibly be other types of activities that fall under the umbrella of open source development.


Distributions are another type of open-source project. Distributions are collections of software that are published from the same source with a common purpose. The most prominent example of a "distribution" is an operating system. There are many [[Linux]] distributions (such as [[Debian]], [[Fedora Linux|Fedora Core]], [[Mandriva]], [[Slackware]], [[Ubuntu]] etc.) which ship the Linux kernel along with many user-land components. There are other distributions, like [https://web.archive.org/web/20160331201814/http://www.activestate.com/activeperl ActivePerl], the [[Perl|Perl programming language]] for various operating systems, and [[Cygwin]] distributions of open-source programs for [[Microsoft Windows]].
== Types of open source projects ==
One can distinguish several different types of open source projects. First, there is the garden variety of software programs and libraries. They are standalone pieces of code. Some might even be dependent on other open source projects. These projects serve a specified purpose and fill a definite need. Examples of this type of project include the [[Linux kernel]], the [[Mozilla Firefox|Firefox]] web-browser and [[OpenOffice.org]] office suite of tools.


Other open-source projects, like the [[Berkeley Software Distribution|BSD]] derivatives, maintain the source code of an entire operating system, the kernel and all of its core components, in one [[revision control]] system; developing the entire system together as a single team. These operating system development projects closely integrate their tools, more so than in the other distribution-based systems.
Distributions are another type of open source project. Distributions are collections of software that are published from the same source with a common purpose. The most prominent example of a "distribution" is an operating system. There are a large number of [[Linux]] distributions (such as [[Debian]], [[Fedora Core]], [[Mandriva]], [[Slackware]], etc.) which ship the Linux kernel along with many user-land components. There are also other distributions, like [http://www.activestate.com/Products/ActivePerl/ ActivePerl], the [[Perl|Perl programming language]] for various operating system, and event the [http://www.theopencd.org/ OpenCD] and [[cygwin]] distributions of open-source programs for [[Microsoft Windows]].


Finally, there is the book or standalone document project. These items usually do not ship as part of an open-source software package. The Linux Documentation Project hosts many such projects that document various aspects of the Linux operating system. There are many other examples of this type of open-source project.
Other open source projects, like the [[Berkeley Software Distribution|BSD]] derivatives, maintain the source code of an entire operating system, the kernel and all of its core components, in one [[revision control]] system; developing the entire system together as a single team. These operating system development projects closely integrate their tools. More so than in the other distribution-based systems.


== Methods ==
Finally, there is the book or standalone document project. These items usually do not shipped as part of an open source software package. The [http://www.tldp.org/ Linux Documentation Project] hosts many such projects that document various aspects of the GNU/Linux operating system. There are many other examples of this type of open source project.


It is hard to run an open-source project following a more traditional software development method like the [[waterfall model]], because in these traditional methods it is not allowed to go back to a previous phase. In open-source software development, requirements are rarely gathered before the start of the project; instead they are based on early releases of the software product, as Robbins describes.<ref name=Robbins>Robbins, J. E. (2003). ''Adopting Open Source Software Engineering (OSSE) Practices by Adopting OSSE Tools''. Making Sense of the Bazaar: Perspectives on Open Source and Free Software, Fall 2003.</ref> Besides requirements, often volunteer staff is attracted to help develop the software product based on the early releases of the software. This networking effect is essential according to Abrahamsson et al.: “if the introduced prototype gathers enough attention, it will gradually start to attract more and more developers”. However, Abrahamsson et al. also point out that the community is very harsh, much like the business world of closed-source software: “if you find the customers you survive, but without customers you die”.<ref name=Abrahamsson>Abrahamsson, P, Salo, O. & Warsta, J. (2002). ''Agile software development methods: Review and Analysis''. VTT Publications.</ref>
== Starting an open source project ==
There are several ways in which work on an open source project can start:


Fuggetta<ref name=Fuggetta>{{cite journal|first1=Alfonso|last1=Fuggetta|title=Open source software––an evaluation|journal=Journal of Systems and Software|date=2003|pages=77–90|volume=66|issue=1|doi=10.1016/S0164-1212(02)00065-1}}</ref> argues that “rapid prototyping, incremental and evolutionary development, spiral lifecycle, rapid application development, and, recently, extreme programming and the agile software process can be equally applied to proprietary and open source software”. He also pinpoints [[Extreme Programming]] as an extremely useful method for open source software development. More generally, all [[Agile programming]] methods are applicable to open-source software development, because of their iterative and incremental character. Other Agile methods are equally useful for both open and closed source software development: [[Internet-Speed Development]], for example is suitable for open-source software development because of the distributed development principle it adopts. Internet-Speed Development uses geographically distributed teams to ‘work around the clock’. This method, mostly adopted by large closed-source firms, (because they're the only ones which afford development centers in different time zones), works equally well in open source projects because a software developed by a large group of volunteers shall naturally tend to have developers spread across all time zones.
# An individual who senses the need for a project announces the intent to develop the project in public. The individual may receive offers of help from others. The group may then proceed to work on the code.
# A developer working on a limited but working [[codebase]], releases it to the public as the first version of an open-source program. The developer continues to work on improving it, and possibly is joined by other developers.
# The source code of a mature project is released to the public, after being developed as [[proprietary software]] or [[inhouse software]].
# A well-established open-source project can be [[Fork (software development)|forked]] by an interested outside party. Several developers can then start a new project, whose source code then diverges from the original.


== Tools ==
[[Eric Raymond]] observed [http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s10.html in his famous essay "The Cathedral and the Bazaar"] that announcing the intent for a project is usually inferior to releasing a working project to the public.
{{unreferenced section|date=May 2013}}


=== Communication channels ===
==Participants in OSS development projects==
(copied from [[Open-source software#Participants in OSS development projects|the Open source software article]])


Developers and users of an open-source project are not all necessarily working on the project in proximity. They require some electronic means of communications. [[Email]] is one of the most common forms of communication among open-source developers and users. Often, [[electronic mailing list]]s are used to make sure e-mail messages are delivered to all interested parties at once. This ensures that at least one of the members can reply to it. In order to communicate in real time, many projects use an [[instant messaging]] method such as [[Internet Relay Chat|IRC]]. Web forums have recently become a common way for users to get help with problems they encounter when using an open-source product. [[Wiki]]s have become common as a communication medium for developers and users.<ref name=":0">{{cite magazine|url=https://www.wired.co.uk/magazine/archive/2014/03/web-at-25/tim-berners-lee|title=Tim Berners-Lee on the Web at 25: the past, present and future|magazine=Wired UK}}</ref>
'''Participants in OSS development projects''' fall into two broad categories: the Core and the Peripheral.


=== Version control systems ===
The Core or Inner Circle are developers who modify the primary code that constitutes the project.
{{Main article|Revision control}}


In OSS development the participants, who are mostly volunteers, are distributed amongst different geographic regions so there is need for tools to aid participants to collaborate in the development of source code.
The Peripheral usually consists of users of the software. They report bugs, submit fixes, and suggest changes.


During early 2000s, [[Concurrent Versions System]] (CVS) was a prominent example of a source code collaboration tool being used in OSS projects. CVS helps manage the files and codes of a project when several people are working on the project at the same time. CVS allows several people to work on the same file at the same time. This is done by moving the file into the users’ directories and then merging the files when the users are done. CVS also enables one to easily retrieve a previous version of a file. During mid 2000s, [[Apache Subversion|The Subversion revision control system]] (SVN) was created to replace CVS. It is quickly gaining ground as an OSS project version control system.<ref name=":0" />
The participants can be divided into the following:
#Project leaders who have the overall responsibility (Core). Most of them might have been involved in coding the first release of the software. They control the overall direction of individual projects.
#Volunteer developers (Core / Periphery) who do actual coding for the project. These include:
#*Senior members with broader overall authority
#*Peripheral developers producing and submitting code fixes
#*Occasional contributors
#*Maintainers who work on different aspects of the project
#Everyday users (Periphery) who perform testing, identify bugs, deliver bug reports, etc.
#Posters (Periphery) who participate frequently in newsgroups and discussions, but do not do any coding.


Many open-source projects are now using distributed revision control systems, which scale better than centralized repositories such as SVN and CVS. Popular examples are [[git]], used by the [[Linux kernel]],<ref>{{Cite web |title=The Greatness of Git - Linux Foundation |url=https://www.linuxfoundation.org/blog/blog/the-greatness-of-git |access-date=2023-08-25 |website=www.linuxfoundation.org |language=en}}</ref> and [[Mercurial]], used by the [[Python (programming language)|Python]] programming language.{{citation needed|date=November 2014}}
Projects often exhibit an early geographical trend, even if there is international interest. For example, most of the core founders of the [[KDE|KDE Desktop Environment]] were German.


=== Bug trackers and task lists ===
== Tools used for open source development ==
{{Main article|Bug tracking system}}
=== Communication channels ===
Developers and users of an open source project are not all necessarily working on the project in proximity. They require some electronic means of communications.


Most large-scale projects require a bug tracking system to keep track of the status of various issues in the development of the project.
==== E-mail ====
[[E-mail]] is one of the chief forms of communication among open source developers and users. Often, [[electronic mailing list]]s are used to make sure e-mail messages are delivered to all interested parties at once. This ensures that at least one of them can reply to it (in private or to the whole mailing list).


=== Testing and debugging tools ===
Often a project has only one mailing list, but often it has several mailing lists, each for a different purpose. Common mailing lists purposes include:


Since OSS projects undergo frequent integration, tools that help automate testing during system integration are used. An example of such tool is Tinderbox. Tinderbox enables participants in an OSS project to detect errors during system integration. Tinderbox runs a continuous build process and informs users about the parts of source code that have issues and on which platform(s) these issues arise.<ref name=":0" />
* Announcements - a small-volume mailing lists dedicated for project announcements, and usually with a restricted or moderated who-can-post policy.
* Commits - a mailing list in which all the check-ins to the [[revision control]] system are sent for verification by the peer developers.
* Development - a mailing list dedicated to discussing the development of the code itself, as opposed to making use of the product.
* User - a mailing list dedicated to helping users of the product with their problems.


A [[debugger]] is a computer program that is used to debug (and sometimes test or optimize) other programs. [[GNU Debugger]] (GDB) is an example of a debugger used in open-source software development. This debugger offers remote debugging, what makes it especially applicable to open-source software development.{{citation needed|date=November 2014}}
==== Instant messaging ====
In order to communicate in real time, many projects use an [[instant messaging]] method such as [[Internet Relay Chat|IRC]] (although there are many others available). IRC is especially suitable because the project can set up one or more IRC channels for discussions among its participants as well as for users to get help. The [[Freenode]] IRC network has been especially popular for hosting channels for open source projects. There has been a lot of activity on other networks, some of which are also dedicated to open-source projects. Sometimes a project will use communication channels on more than one network.


A memory leak tool or [[memory debugger]] is a programming tool for finding [[memory leaks]] and [[buffer overflows]]. A memory leak is a particular kind of unnecessary memory consumption by a computer program, where the program fails to release memory that is no longer needed. Examples of memory leak detection tools used by Mozilla are the [[XPCOM]] Memory Leak tools.
Developers communicate using other instant messaging protocols, but IRC seems to be prefered. Many developers like the ease and transparency of IRC's multi-person chatrooms.
Validation tools are used to check if pieces of code conform to the specified syntax. An example of a validation tool is [[Splint (programming tool)|Splint]].{{citation needed|date=November 2014}}


==== Web forums ====
=== Package management ===
Web forums have recently become a common way for users to get help with problems they encounter when using an open source product. To a lesser extent, they have been useful as ways for developers to communicate regarding the development of the core code, but most hardcore and experienced devlopers still tend to prefer e-mails over web forums.


A [[package management system]] is a collection of tools to automate the process of installing, upgrading, configuring, and removing software packages from a computer. The [[RPM Package Manager|Red Hat Package Manager]] (RPM) for .rpm and [[APT (software)|Advanced Packaging Tool]] (APT) for [[deb (file format)|.deb]] file format, are package management systems used by a number of Linux distributions.{{citation needed|date=November 2014}}
==== Wikis ====
[[Wiki]]s have become common as a communication medium for developers and users. They are used to collaboratively edit documents and keep track of other resources. Since the web was a somewhat late introduction to the open source development scene, and wikis even more so, the concept is still not as common as it could potentially become. Wikis often pose problems as a communication channel, because it is harder to have an electronic dialog using them. They are often dedicated as a resource for having easy-to-modify collaborative documents.


=== Software engineering tools ===
== Publicizing a project ==
==== Version control systems ====
Copied from [[Open-source software#Source code revision control|Open source software]]


Software directories and release logs:
{{main|Revision control}}
# The [[Free Software Directory]]
In OSS development the participants, who are mostly volunteers, are distributed amongst different geographic regions so there is need for tools to aid participants to collaborate in the development of source code.


Articles:
[[Concurrent Versions System]] (CVS) is a major example of a source code collaboration tool being used in OSS projects. CVS helps manage the files and codes of a project when several people are working on the project at the same time. CVS can allow several people to work on the same file at the same time. This is done by moving the file into the users’ directories and then merging the files when the users are done. CVS also enables one to easily go back to a previous version of a file and retrieve it.
# [[Linux Weekly News]]
# IBM developerWorks


== See also ==
[[Subversion (software)|The Subversion revision control system]] (svn) was create to replace CVS. It is quickly gaining ground as an OSS project version control system.
{{Portal|Free and open-source software}}
{{cmn|colwidth=30em|
* [[Business models for open-source software]]
* [[Government Open Code Collaborative]]
* [[Open-source software security]]
* [[Software composition analysis]]
* [[Software development process]]
* [[Release management]]
* [[Software engineering]]
* [[Metamodeling]]
}}


== References ==
==== Bug trackers and task lists ====
{{Reflist}}
==== Build tools ====
=== Other tools ===
==== Web sites ====
==== Download areas ====
== Common development methodologies ==
=== Refactoring ===
=== Rewrites ===
=== Automated tests ===
== Publicizing a project ==
=== Software directories and release logs ===
Freshmeat, directory.fsf.org, etc.


=== Articles ===
== Further reading ==
* {{Cite book |last=Kavanagh |first=Paul |title=Open source software: implementation and management |date=2004 |publisher=Elsevier Digital Press |isbn=978-1-55558-320-0 |series=Software development |location=Amsterdam Boston}}
O'Reilly Net, Linux Weekly News, IBM developerworks, etc.
* {{Cite book |title=Perspectives on free and open source software |date=2005 |publisher=MIT Press |isbn=978-0-262-06246-6 |editor-last=Feller |editor-first=Joseph |location=Cambridge, Mass}}
* {{Cite book |title=Free, open source software development |date=2005 |publisher=Idea Group Publ |isbn=978-1-59140-370-8 |editor-last=Koch |editor-first=Stefan |location=Hershey, Pa.}}
* {{Cite book |last=Fogel |first=Karl |url=https://www.worldcat.org/title/ocm62322583 |title=Producing open source software: how to run a successful free software project |date=2005 |publisher=O'Reilly |isbn=978-0-596-00759-1 |edition=1st |location=Beijing ; Sebastopol, CA |oclc=ocm62322583}}
* {{Cite book |last=Muir |first=Scott P. |title=Open Source Software |date=2005 |publisher=Emerald Publishing Limited |others=Mark Leggott |isbn=978-1-84544-877-6 |series=Library Hi Tech |location=Bradford}}
* {{Cite book |last=Feller |first=Joseph |title=Open Source Development, Adoption and Innovation: IFIP Working Group 2. 13 on Open Source Software, June 11-14, 2007, Limerick, Ireland |date=2007 |publisher=Springer |others=Brian Fitzgerald, Walt Scacchi, Alberto Sillitti |isbn=978-0-387-72485-0 |series=IFIP Advances in Information and Communication Technology Ser |location=New York, NY}}
* {{Cite book |url=https://www.worldcat.org/title/ocm84838909 |title=Emerging free and open source software practices |date=2008 |publisher=IGI Pub |isbn=978-1-59904-210-7 |editor-last=Sowe |editor-first=Sulayman K. |location=Hershey |oclc=ocm84838909 |editor-last2=Stamelos |editor-first2=Ioannis G. |editor-last3=Samoladas |editor-first3=Ioannis M.}}
* {{Cite book |last=Fogel |first=Karl |title=Producing Open Source Software: How to Run a Successful Free Software Project |date=2009 |publisher=O'Reilly Media, Inc |isbn=978-0-596-00759-1 |location=Sebastopol}}
* {{Cite book |last=Engard |first=Nicole C. |title=Practical open source software for libraries |date=2010 |publisher=Chandos publishing |isbn=978-1-84334-585-5 |series=Chandos information professional series |location=Oxford}}
* {{Cite book |last=Tucker |first=Allen B. |title=Software Development: An Open Source Approach |last2=Morelli |first2=Ralph |last3=de Silva |first3=Chamindra |date=2012 |publisher=Chapman and Hall/CRC |isbn=978-1-4398-1290-7 |series=Chapman and Hall/CRC Innovations in Software Engineering and Software Development Ser |location=Boca Raton}}
* {{Cite book |last=Haff |first=Gordon |title=How Open Source Ate Software: Understand the Open Source Movement and So Much More |date=2021 |publisher=Apress L. P |isbn=978-1-4842-6799-8 |edition=2nd |location=Berkeley, CA}}


=== Mailing lists ===
== External links ==
{{Software engineering}}
== External link ==
* [http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/ Software Release Practice HOWTO] by [[Eric Raymond]]


{{DEFAULTSORT:Open Source Software Development}}
[[Category:Free software]]
[[Category:Free and open-source software|Development]]

Latest revision as of 19:55, 16 December 2024

Open-source software development (OSSD) is the process by which open-source software, or similar software whose source code is publicly available, is developed by an open-source software project. These are software products available with its source code under an open-source license to study, change, and improve its design. Examples of some popular open-source software products are Mozilla Firefox, Google Chromium, Android, LibreOffice and the VLC media player.

History

[edit]

In 1997, Eric S. Raymond wrote The Cathedral and the Bazaar.[1] In this book, Raymond makes the distinction between two kinds of software development. The first is the conventional closed-source development. This kind of development method is, according to Raymond, like the building of a cathedral; central planning, tight organization and one process from start to finish. The second is the progressive open-source development, which is more like "a great babbling bazaar of differing agendas and approaches out of which a coherent and stable system could seemingly emerge only by a succession of miracles." The latter analogy points to the discussion involved in an open-source development process.

Differences between the two styles of development, according to Bar and Fogel, are in general the handling (and creation) of bug reports and feature requests, and the constraints under which the programmers are working.[2] In closed-source software development, the programmers are often spending a lot of time dealing with and creating bug reports, as well as handling feature requests. This time is spent on creating and prioritizing further development plans. This leads to part of the development team spending a lot of time on these issues, and not on the actual development. Also, in closed-source projects, the development teams must often work under management-related constraints (such as deadlines, budgets, etc.) that interfere with technical issues of the software. In open-source software development, these issues are solved by integrating the users of the software in the development process, or even letting these users build the system themselves.[citation needed]

Model

[edit]
Not to be confused with Open-source model.
Process-Data Model for open-source software development

Open-source software development can be divided into several phases. The phases specified here are derived from Sharma et al.[3] A diagram displaying the process-data structure of open-source software development is shown on the right. In this picture, the phases of open-source software development are displayed, along with the corresponding data elements. This diagram is made using the meta-modeling and meta-process modeling techniques.

Starting an open-source project

[edit]

There are several ways in which work on an open-source project can start:

  1. An individual who senses the need for a project announces the intent to develop a project in public.
  2. A developer working on a limited but working codebase, releases it to the public as the first version of an open-source program.
  3. The source code of a mature project is released to the public.
  4. A well-established open-source project can be forked by an interested outside party.

Eric Raymond observed in his essay The Cathedral and the Bazaar that announcing the intent for a project is usually inferior to releasing a working project to the public.

It's a common mistake to start a project when contributing to an existing similar project would be more effective (NIH syndrome)[citation needed]. To start a successful project it is very important to investigate what's already there. The process starts with a choice between the adopting of an existing project, or the starting of a new project. If a new project is started, the process goes to the Initiation phase. If an existing project is adopted, the process goes directly to the Execution phase.[original research?]

Types of open-source projects

[edit]
See also: List of free and open-source software packages

Several types of open-source projects exist. First, there is the garden variety of software programs and libraries, which consist of standalone pieces of code. Some might even be dependent on other open-source projects. These projects serve a specified purpose and fill a definite need. Examples of this type of project include the Linux kernel, the Firefox web browser and the LibreOffice office suite of tools.

Distributions are another type of open-source project. Distributions are collections of software that are published from the same source with a common purpose. The most prominent example of a "distribution" is an operating system. There are many Linux distributions (such as Debian, Fedora Core, Mandriva, Slackware, Ubuntu etc.) which ship the Linux kernel along with many user-land components. There are other distributions, like ActivePerl, the Perl programming language for various operating systems, and Cygwin distributions of open-source programs for Microsoft Windows.

Other open-source projects, like the BSD derivatives, maintain the source code of an entire operating system, the kernel and all of its core components, in one revision control system; developing the entire system together as a single team. These operating system development projects closely integrate their tools, more so than in the other distribution-based systems.

Finally, there is the book or standalone document project. These items usually do not ship as part of an open-source software package. The Linux Documentation Project hosts many such projects that document various aspects of the Linux operating system. There are many other examples of this type of open-source project.

Methods

[edit]

It is hard to run an open-source project following a more traditional software development method like the waterfall model, because in these traditional methods it is not allowed to go back to a previous phase. In open-source software development, requirements are rarely gathered before the start of the project; instead they are based on early releases of the software product, as Robbins describes.[4] Besides requirements, often volunteer staff is attracted to help develop the software product based on the early releases of the software. This networking effect is essential according to Abrahamsson et al.: “if the introduced prototype gathers enough attention, it will gradually start to attract more and more developers”. However, Abrahamsson et al. also point out that the community is very harsh, much like the business world of closed-source software: “if you find the customers you survive, but without customers you die”.[5]

Fuggetta[6] argues that “rapid prototyping, incremental and evolutionary development, spiral lifecycle, rapid application development, and, recently, extreme programming and the agile software process can be equally applied to proprietary and open source software”. He also pinpoints Extreme Programming as an extremely useful method for open source software development. More generally, all Agile programming methods are applicable to open-source software development, because of their iterative and incremental character. Other Agile methods are equally useful for both open and closed source software development: Internet-Speed Development, for example is suitable for open-source software development because of the distributed development principle it adopts. Internet-Speed Development uses geographically distributed teams to ‘work around the clock’. This method, mostly adopted by large closed-source firms, (because they're the only ones which afford development centers in different time zones), works equally well in open source projects because a software developed by a large group of volunteers shall naturally tend to have developers spread across all time zones.

Tools

[edit]

Communication channels

[edit]

Developers and users of an open-source project are not all necessarily working on the project in proximity. They require some electronic means of communications. Email is one of the most common forms of communication among open-source developers and users. Often, electronic mailing lists are used to make sure e-mail messages are delivered to all interested parties at once. This ensures that at least one of the members can reply to it. In order to communicate in real time, many projects use an instant messaging method such as IRC. Web forums have recently become a common way for users to get help with problems they encounter when using an open-source product. Wikis have become common as a communication medium for developers and users.[7]

Version control systems

[edit]
Main article: Revision control

In OSS development the participants, who are mostly volunteers, are distributed amongst different geographic regions so there is need for tools to aid participants to collaborate in the development of source code.

During early 2000s, Concurrent Versions System (CVS) was a prominent example of a source code collaboration tool being used in OSS projects. CVS helps manage the files and codes of a project when several people are working on the project at the same time. CVS allows several people to work on the same file at the same time. This is done by moving the file into the users’ directories and then merging the files when the users are done. CVS also enables one to easily retrieve a previous version of a file. During mid 2000s, The Subversion revision control system (SVN) was created to replace CVS. It is quickly gaining ground as an OSS project version control system.[7]

Many open-source projects are now using distributed revision control systems, which scale better than centralized repositories such as SVN and CVS. Popular examples are git, used by the Linux kernel,[8] and Mercurial, used by the Python programming language.[citation needed]

Bug trackers and task lists

[edit]
Main article: Bug tracking system

Most large-scale projects require a bug tracking system to keep track of the status of various issues in the development of the project.

Testing and debugging tools

[edit]

Since OSS projects undergo frequent integration, tools that help automate testing during system integration are used. An example of such tool is Tinderbox. Tinderbox enables participants in an OSS project to detect errors during system integration. Tinderbox runs a continuous build process and informs users about the parts of source code that have issues and on which platform(s) these issues arise.[7]

A debugger is a computer program that is used to debug (and sometimes test or optimize) other programs. GNU Debugger (GDB) is an example of a debugger used in open-source software development. This debugger offers remote debugging, what makes it especially applicable to open-source software development.[citation needed]

A memory leak tool or memory debugger is a programming tool for finding memory leaks and buffer overflows. A memory leak is a particular kind of unnecessary memory consumption by a computer program, where the program fails to release memory that is no longer needed. Examples of memory leak detection tools used by Mozilla are the XPCOM Memory Leak tools. Validation tools are used to check if pieces of code conform to the specified syntax. An example of a validation tool is Splint.[citation needed]

Package management

[edit]

A package management system is a collection of tools to automate the process of installing, upgrading, configuring, and removing software packages from a computer. The Red Hat Package Manager (RPM) for .rpm and Advanced Packaging Tool (APT) for .deb file format, are package management systems used by a number of Linux distributions.[citation needed]

Publicizing a project

[edit]

Software directories and release logs:

  1. The Free Software Directory

Articles:

  1. Linux Weekly News
  2. IBM developerWorks

See also

[edit]

References

[edit]
  1. ^ Raymond, E.S. (1999). The Cathedral & the Bazaar. O'Reilly Retrieved from http://www.catb.org/~esr/writings/cathedral-bazaar/. See also: The Cathedral and the Bazaar.
  2. ^ Bar, M. & Fogel, K. (2003). Open Source Development with CVS, 3rd Edition. Paraglyph Press. (ISBN 1-932111-81-6)
  3. ^ Sharma, S., Sugumaran, V. & Rajagopalan, B. (2002). A framework for creating hybrid-open source software communities. Information Systems Journal 12 (1), 7 – 25.
  4. ^ Robbins, J. E. (2003). Adopting Open Source Software Engineering (OSSE) Practices by Adopting OSSE Tools. Making Sense of the Bazaar: Perspectives on Open Source and Free Software, Fall 2003.
  5. ^ Abrahamsson, P, Salo, O. & Warsta, J. (2002). Agile software development methods: Review and Analysis. VTT Publications.
  6. ^ Fuggetta, Alfonso (2003). "Open source software––an evaluation". Journal of Systems and Software. 66 (1): 77–90. doi:10.1016/S0164-1212(02)00065-1.
  7. ^ a b c "Tim Berners-Lee on the Web at 25: the past, present and future". Wired UK.
  8. ^ "The Greatness of Git - Linux Foundation". www.linuxfoundation.org. Retrieved 2023-08-25.

Further reading

[edit]
  • Kavanagh, Paul (2004). Open source software: implementation and management. Software development. Amsterdam Boston: Elsevier Digital Press. ISBN 978-1-55558-320-0.
  • Feller, Joseph, ed. (2005). Perspectives on free and open source software. Cambridge, Mass: MIT Press. ISBN 978-0-262-06246-6.
  • Koch, Stefan, ed. (2005). Free, open source software development. Hershey, Pa.: Idea Group Publ. ISBN 978-1-59140-370-8.
  • Fogel, Karl (2005). Producing open source software: how to run a successful free software project (1st ed.). Beijing ; Sebastopol, CA: O'Reilly. ISBN 978-0-596-00759-1. OCLC 62322583.
  • Muir, Scott P. (2005). Open Source Software. Library Hi Tech. Mark Leggott. Bradford: Emerald Publishing Limited. ISBN 978-1-84544-877-6.
  • Feller, Joseph (2007). Open Source Development, Adoption and Innovation: IFIP Working Group 2. 13 on Open Source Software, June 11-14, 2007, Limerick, Ireland. IFIP Advances in Information and Communication Technology Ser. Brian Fitzgerald, Walt Scacchi, Alberto Sillitti. New York, NY: Springer. ISBN 978-0-387-72485-0.
  • Sowe, Sulayman K.; Stamelos, Ioannis G.; Samoladas, Ioannis M., eds. (2008). Emerging free and open source software practices. Hershey: IGI Pub. ISBN 978-1-59904-210-7. OCLC 84838909.
  • Fogel, Karl (2009). Producing Open Source Software: How to Run a Successful Free Software Project. Sebastopol: O'Reilly Media, Inc. ISBN 978-0-596-00759-1.
  • Engard, Nicole C. (2010). Practical open source software for libraries. Chandos information professional series. Oxford: Chandos publishing. ISBN 978-1-84334-585-5.
  • Tucker, Allen B.; Morelli, Ralph; de Silva, Chamindra (2012). Software Development: An Open Source Approach. Chapman and Hall/CRC Innovations in Software Engineering and Software Development Ser. Boca Raton: Chapman and Hall/CRC. ISBN 978-1-4398-1290-7.
  • Haff, Gordon (2021). How Open Source Ate Software: Understand the Open Source Movement and So Much More (2nd ed.). Berkeley, CA: Apress L. P. ISBN 978-1-4842-6799-8.
[edit]
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Open-source_software_development&oldid=1263458189"