Building a Collaborative Environment for Open Source Projects

There has been a major rise in the number of open source software projects (i.e. software packages whose source code is freely distributed under a license to the community) in the last couple of years. Even though free or open source projects always had an appeal among programmers, the consumer and developer market for these has grown manifold in the past few years and this trend does not seem to slow its pace with a larger community realizing it's positives and scope.

In order to build successful open source projects, the developer community requires advanced communication and collaboration systems to be able to learn, develop and maximize their contributions to such projects. Almost every open source project which depends on contributions from the developer community around the world, rather than just passive observers, seeks to deploy a collaborative web environment which allows sharing, discussion, development information and tracking, exchange, learning etc. Such an environment plays a very crucial role in determining the audience of developer community it wishes to reach out to, and eventually involve in development and knowledge sharing. This may, at the end of the day, be the factor differentiating successful projects from those which always wanted to be.

In the words of Eric Raymond, "Every good work of software starts by scratching a developer's personal itch". As this clearly implies, the founder has an inner motive or a personal greed which becomes the basis of his/her/it's work towards a software. The purpose of writing the software or initiating may simply lye in the fact that the founding developer wants a community of developers to work together to solve a personal problem. This developer could be an individual, a group of individuals, or an organization (including for-profit organizations). But to make this happen, the founder needs to accomplish the twofold task of acquiring users and developers.

Developers argue that they do not Graphic User Interface is of least importance to them. But its interesting to note that they learn about an open source project by the way the website has been designed and laid out, and that "this information is absorbed before any of the actual content on the site is comprehended...". Thus, the first and most important idea for a great collaborative setting is a well designed website. This website may be written from scratch, but developers prefer open source content management systems (CMSs), blog engines and/or frameworks such as Ruby on Rails. Popular content Management Systems include Drupal, Mambo, Joomla etc. while Wordpress and TextPattern are examples of famous blog engines.

Irrespective of the frameworks adopted, they usually have an infrastructure for web area, version control, bug tracking, download area, chat forums, FAQs etc. These are few the major components of open source software project websites. These all are always not found on every collaborative setting and thus it is often fine to leave one or two of them which may not be extremely essential.

The components of the web environment

A well stated mission statement always guides the developers in the direction of the goal of the project.

Developers are made aware of the features and requirements by a list including details such as computing environments and platforms required for development and a quick summary of it's current features.

Space on the website is essentially dedicated to the Development status which lists the project's short-term goals and needs. It presents a true picture of where the software stands, so that developers know where they need to contribute from. It may also include history of the past releases. Trying to portray a flowery image for a faulty code does no good to the founding developers because "a reputation for instability or bugginess is very hard to shake, once acquired".

While an alpha stage refers to the stage when the software running with integrated functionality with known bugs, the software is known to have a beta stage when it hasn't been tested enough, although it is free from bugs. In regular computing vocabulary, alpha stage would usually imply a testing stages within the developers of the organization building a software, while beta stage would mean testing by outsiders and computing community. But with open source projects evolving the way of looking at collaboration of software, alpha and beta stage are most or less similar. This is the reason why many projects bring out Release Candidates (RCs) as developments in the beta stage.

The software is available for download for developers as source code in standard formats which makes it easy for them to develop in. While a badly designed download repels potential contributors, a good distribution mechanism is one which is convenient, standard and low-overhead. These downloads are available are after being packaged with the necessary documents and source code required for developers.

A well designed version control system enables the developers to keep track of the latest version packages of the software and provides real-time access to the latest resources.

The project's bug tracker is another important component of the project website. This system tracks the bugs in the current versions, in tune with the version control system. "The number of bugs recorded really depends on three things: the absolute number of bugs present in the software, the number of users using the software, and the convenience with which those users can register new bugs".

An extremely vital part of such a system is the communication channels. No community project collaboration system is complete without great communication system involving mailing lists, IRC channels, and other forums where developers involved in the project communicate and move towards common aims.

Developer guidelines are essential guidelines for developers to get started with development for the project. They are more social than technical, as they explain how developers are expected to communicate with each other.

FAQ (Frequently Asked Questions) documents are a great investment to projects as they answer most of the questions developers may ask in most circumstances. An addition to this system may be the ticket submission system, which allows developers, in particular, to submit queries recorded as tickets which are answered either by other developers or the administrators.

"Developer Documentation is written to help programmers understand the code, so that they can repair and extend it." It is technical in nature and guides the developers to get started and work on the code development right away.

The Developers / Programmers

In order to have committed developers, project administrators make sure that the developers do not feel discriminated at any time and always feel that their contributions are being valued.

To support an active community of developers, contextual feedback and online collaboration, discussions and comments on the content must be enabled at all times.

Private discussions and insulting behavior is discouraged at all times, in order to build a better and healthier development and collaborative environment.

REFERENCES

1. Producing Open Source Software http://producingoss.com/producingoss.html
2. Guido Hertel (2007). Motivating job design as a factor in open source governance. Journal of Management & Governance, 11(2), 129-137. Retrieved October 24, 2008, from ABI/INFORM Global database. (Document ID: 1296851961).
3. Using open source software to design, develop, and deploy a collaborative Web site, Part 1: Introduction and overview http://www.ibm.com/developerworks/ibm/library/i-osource1/
4. A Neus, P Scherf. (2005). Opening minds: Cultural change with the introduction of opensource collaboration methods. IBM Systems Journal, 44(2), 215-225. Retrieved October 22, 2008, from ABI/INFORM Global database. (Document ID: 846106161).
5. Justin P. Johnson, Collaboration, peer review and open source software, Information Economics and PolicyVolume 18, Issue 4, , November 2006, Pages 477-497.
(http://www.sciencedirect.com/science/article/B6V8J-4KXWJMB-1/2/31c2a0921af61d4d68430 4ad251fe7eb)
Keywords: Open source software; Transactions costs; Authority; Peer review; Career concerns
6. Open Source 2.0: The Continuing Ev0olution, 2005, O'Reilly Media, Inc, CA
7. Shahriar Haque (founder of SnowFox - open source semantic indexer)