Jump to content

Open-source software development: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Line 44: Line 44:
There are several ways in which work on an open source project can start:
There are several ways in which work on an open source project can start:


# Someone who senses the need for the project, publicly announces the intent to develop the project in public. He and others may then proceed to work on the code.
# 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 works on a limited but working [[codebase]], and releases it to the public as the first version of an open-source program. Then he or she continue to work on improving it, and possibly joined by other developers.
# 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 of a mature program is released to the public, after being developed, without its source's public availability, as [[proprietary software]] or [[inhouse software]].
# 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 is [[Fork (software development)|forked]] by several developers to start a new project, whose source code then diverges from it.
# 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.


[[Eric Raymond]] observes [http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s10.html in his famous essay "The Cathedral and the Bazaar"] that the first way of announcing the intent for the project is usually inferior to the second.
[[Eric Raymond]] observes [http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s10.html in his famous essay "The Cathedral and the Bazaar"] that the first way of announcing the intent for the project is usually inferior to the second.


==Participants in OSS development projects==
==Participants in OSS development projects==

Revision as of 21:02, 2 May 2006

Open source software development is the process by which open source software (or similar software whose source is publicly available) is developed.

Types of open source development

There are several different types of tasks that are generally associated with the development of Open source software. These are:

Source 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 on what falls under the umbrella of open source development.

Documentation

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.

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.

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) 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.

Translations could also involve the translation of the program's documentation.

Packaging

Open source software by its nature is often deployed on a large number of operating systems, and distributions. Packaging involves preparing a working source or binary package for the program, so it can be more easily deployed on such systems.

Bug reports and feature requests

This type of development involves reporting software bugs, or asking for Feature Requests to the developers who then register it somehow, for further resolution.

Infrastructure

This involves 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.

Answering questions

This type of development involves a knowledgeable person answering a question about the project as raised by another person who is trying to use the open source project. (See also the "How To Ask Questions The Smart Way" document).

Other types

There may possibly be other types of activities that fall under the umbrella of open source development.

Types of open source projects

One can distinguish among several types of open source projects. At first there are normal software programs or libraries, which are standalone pieces of code. They are possibly dependent on several dependencies to build or run, but otherwise serve a certain purpose and fill a certain need. Examples for this include the Linux kernel, the Firefox web-browser and OpenOffice.org.

Other types of open source projects are "distributions". These are collections of software that are distributed from the same source with some amount of integration between them. Probably the most well-known type of distributions are distributions of entire OSes. 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 ActivePerl, the Perl programming language for various operating system, and the OpenCD or cygwin distributions of open-source programs for Microsoft Windows.

Other open source projects, like the BSD derivatives, maintain the source code of the 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.

Another type of project is a book or a similar standalone document that is not shipped as part of the software package. The Linux Documentation Project hosts many such projects that document various aspects of the GNU/Linux operating system. There are many others available elsewhere.

Starting an open source project

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 the project in public. The individual may receive offers of help from others. The group may then proceed to work on the code.
  2. 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.
  3. The source code of a mature project is released to the public, after being developed as proprietary software or inhouse software.
  4. A well-established open-source project can be forked by an interested outside party. Several developers can then start a new project, whose source code then diverges from the original.

Eric Raymond observes in his famous essay "The Cathedral and the Bazaar" that the first way of announcing the intent for the project is usually inferior to the second.

Participants in OSS development projects

(copied from the Open source software article)

Participants in OSS development projects fall broadly into two categories. There are the Core and the Peripheral.

The Core or Inner Circle are developers who modify codes that constitute the project.

The Peripheral are usually made up of users who use the software. They report bugs, and suggest fixes.

The participants may then be further divided into the following.

  1. 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.
  2. 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 maintain different aspects of the project
  3. Everyday users who perform testing, identify bugs, deliver bug reports, etc. (Periphery)
  4. Posters (Periphery) who participate frequently in newsgroups and discussions, but do not do any coding.

Projects, and even if they are of international interest, often exhibit an early geographical trend. For example, most of the core founders of the KDE Desktop Environment were German.

Tools used for open source development

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.

E-mail

E-mail is one of the chief forms of communication among open source developers and users. Often electronic mailing lists are used to make sure an e-mail message arrives to all of the interested people at once, and thus at least one of them can reply to it (in private or also to the mailing list).

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:

  • Announce - a small-volume mailing lists dedicated for project announcements, and usually with a restricted and/or moderating who-can-post policy.
  • Commits - a mailing list in which all the check-ins to the revision control system are sent for verifications by the peer developers.
  • Devel - 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.

Instant messaging

In order to talk in real time, many projects use IRC or other instant messaging methods. IRC is especially suitable because the project can set up one or several IRC channels for discussion among its participants, and for users to get help. The Freenode IRC network has been especially popular for hosting channels for open source projects and technologies, but there has been a lot of activity in other networks, some of which are also dedicated to open-source projects. Sometimes a project has communication channels in more than one network.

Sometimes the developers of projects also communicate by using clients of other instant messaging protocols, but IRC is usually preferable due to the transparency in which the multi-person chatrooms are formed and populated.

Web forums

Web forums have recently been a common way for users to get help with problems they are facing in a project. To a lesser extent, they have been useful as ways for developers to communicate regarding development of the core code. This is due to the fact most hardcore and/or experienced devlopers tend to prefer e-mails and other methods in preference to web forums.

Wikis

Wikis have become common as a communication medium for developers and users, who use them to edit documents and keep track of other resources, collaboratively. 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 can potentially be. Otherwise, wikis often pose problems as a communication channel, because it is harder to have an electronic dialog using them, and so they are often dedicated as a resource for having easy-to-modify collaborative documents.

Software engineering tools

Version control systems

Copied from Open source software

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.

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.

The Subversion revision control system (svn) is an intended CVS replacement which is quickly gaining ground in OSS project version control.

Bug trackers and task lists

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

O'Reilly Net, Linux Weekly News, IBM developerworks, etc.

Mailing lists