Upstream development

Upstream development

Upstream development process

When talking about open source development, "Upstream" refers to all the non-distrubtion-oriented open source development. For example, the Linux kernel code that is maintained by Linus Torvalds is the "upstream version". Usually, upstream developers are not affiliated with any distribution vendor (there are exceptions), but are individuals who contribute as a hobby and for no financial gain. A nice article about the people who contribute to open source can be read here.

Who are the developers who contribute?

To most of the open source projects out there, anyone can contribute. All you have to do is usually read the FAQ, get a list of programming tasks (or create a task for yourself, e.g. fixing a bug that you found) and send the patch to the maintainer. Most of the projects have a maintainer who is the one responsible to decide what goes in the next version. Anyone can contribute code, but the maintainer isn't obliged to apply every patch she gets from the contributors.

Where is the development taking place?

There are no de facto standards either for source control tools or project management methods. Some popular ways include:

• Using an open source portal which offer a centralized location for open source products to be hosted in. A very popular example is SourceForge which hosts almost 100K projects. Another example is Savannah.
• A central CVS repository to which programmers are given a username and password. For example: TeXmacs.
• A maintainer (or a group of maintainers) are the only ones with access to the source tree and they apply patches that contributors send them. For example, the Linux kernel is developed using such a centralized scheme.

Output

Whenever the maintainer decides that the current version is stable enough she can freeze the code and publish the new version. Usually, the version is provided to the general public by means of a compressed tarball containing the entire source tree needed to compile the project. The tarball may also include documentation files, configuration files, a changelog from previous versions (if any) and additional resources (graphics etc.).

Case Studies

TBD

• • Main.AssafSagi - 31 Jan 2005

Topics Wp2

{metadata}