OPEN SOURCE PROCESSES – A SHORT FLOSS HOW-TO
TECHNOLOGY A PROJECT NEEDS
Fogel (2005) cites a variety of technical infrastructure necessary for an Open Source project. Fortunately the cost to acquire and use these is minimal.
Web site – a one-way funnel from the project team to the general public.
Mailing Lists – the primary method for team members to contact one another. Fogel strongly recommends using list management software.
Version control – as in any typical production shop. Every aspect of the Project is under version control: source code, documentation, web pages, FAQ, and any other crucial project files as appropriate. Fogel recommends either Concurrent Versions System (CVS) or Subversion (SVN). This also greatly increases transparency to the project.
Bug tracking – also functions as a project management central clearing house.
Real-time chat for quick and dirty issues among team members as well as the public.
SOCIAL AND POLITICAL INFRASTRUCTURE
Fogel discusses the various forms that successful Open Source projects have employed. One seeming paradox of constant scrutiny and peer review is the desire to remain consistent in order to avoid project “forks”. This is the ability of anyone, at any time, to take (not steal!) all the work to date, copy it to another competing project, and go off in a new direction. This tends to induce a spirit of flexibility and cooperation among project team members, much more so than any authority or monetary directives one might find in a typical company. One popular model is that of the Benevolent Dictator, who has increased authority through common consensus. As a project matures, Fogel indicates that they often evolve into a more democratic model.
The involvement of Open Source project members may be strictly voluntary, or it may in fact be their paying day job at a corporation. Many corporations are beginning to appreciate the benefits of long term endorsement of OS projects. Fogel elaborates on several models for financial contribution:
Sharing the burden – multiple companies can cooperate to create common resources, but with less burden on each individual company.
Augmenting services – the OS project provides added value to the company’s main selling point.
Supporting sales of hardware – hardware is useless without quality software to run on it; and high quality well supported software that is free adds a great deal of value.
Competition with other companies in their sector – this is a natural extension to the point about supporting hardware sales.
Marketing – increases brand perceived value and visibility.
Dual licensing – OS projects can be leveraged into traditional proprietary licenses.
Donations – Fogel recommends careful transparency about how any funds or materials donated to a project
are utilized. COMMUNICATIONS
Fogel makes a strong case that communication skills trump advanced technical skills in an Open Source project. He cites the case of a valuable contributor who, when pressed, could not obtain corporate copyright permissions because he was thirteen years old! High quality communication speaks volumes and produces great leverage in an OS framework. This involves paying close attention to writing style, proper spelling and grammar, and especially attending to the emotional tone.
PACKAGING, RELEASING, AND DAILY DEVELOPMENT
There are many differences between an Open Source project and the typical corporate structure, which is usually oriented to the master schedule (often at the expense of such minor matters as software quality or work-life balance). Open Source projects tend to have multiple threads running in parallel, not the monolithic approach many corporate teams employ.
While project members are always working with the latest (bleeding edge) version of the software, Open Source projects follow the same major/minor version release cycle of most software development. OS projects usually evolve into the practice of producing release branches: