An essay on the roles and responsibilites of users and community members in an open source project.
Participation in the development of an Open Source Project is in almost all cases voluntary and traditional management cannot apply. Open Source developers are not therefore typically driven by financial motivation. Instead, consciously or not, peer esteem and a desire to acquire new skills are the driving factor.
Of course most importantly they all want to have fun. Nobody can be forced to work on tasks that don't interest them and everyone wants to work on sexy new code. As a result bug fixing and documentation often take a back seat and it is down to the Project Leader to charm and cajole the team to complete unpopular but essential tasks. So a project's success or failure is dependent on its leadership who must lead by force of persuasion and charisma alone. The pathways of software development are littered with failed and closed projects due to the inability of the leader to keep the developers and community motivated.
The globally distributed nature of Open Source developers places extra strains on the Project Leader, who must juggle multiple time zones, overcome language barriers and create relationships based on trust with people with whom he has never met or spoken to beyond the ether of cyberspace. These social interactions are crucial to the long-term viability of an Open Source Project and are achieved through multiple media, from mailing lists and discussion boards through to developer conferences and social gatherings.
When it stops becoming fun that is when problems occur.
Every user of a project is a consumer and as in every walk of life the most vocal consumers are often the minority, but place demands on the majority of the developer's time. This vocal minority believe they are entitled to the fruits of the developers labour without contributing anything themselves.
The majority of users care only about the final product and if it will satisfy there needs. It is when the balance between the vocal minority, the silent majority and the developers own aims break down that motivation is lost, the fun disappears and a project stagnates and dies.
Users are the most important part of any Open Source Project.
They show that the developers are serving a need and that they've done something right. More importantly, with the right encouragement, they can become co-developers.
There are two choices presented to a user when they address a problem with the project. If they have the skills to fix it themselves they can either fix it for their own benefit or package their fix in a format that can be shared by others. By contributing back to the community they open their code to others to adapt and improve. There is also the possibility that their code may be included in the core removing the need to apply these changes in future releases. By adopting this strategy the user becomes a contributor that will provide status and recognition among their peers in the project.
When considering the strengths of an Open Source Project release frequency, user input and community interaction are often mentioned. An Open Source project is an organic entity and does not follow a strict regime for product releases and new developments.
Developer communication with the users is essential and can be achieved by either regular progress reports or more valuably user access to work in progress.
This open access increases the potential for feedback and bug fixing from the widest number of users. By providing access to the developmental version of the project, through CVS/SVN or unstable releases, the developers are opening the doors to the user community and inviting feedback. By opening the code to inspection the user community provide the developers with the widest test base possible and the combined experience of the whole community. As a result the user community are rewarded with rapid bug fixes and quicker development.
In a traditional commercial software project this access is closed. The user base does not participate in the development of the product and product development is slowed. The peer review enabled by open development drives a project forward. Often the user community may identify a problem that had not been considered by the developers, at other times the positive feedback provided by the community provides the encouragement for the developer to continue.
The final constituents of the Community are the supporters. These people may not contribute any actual code to the project but they are there to participate in discussions, answer questions in forums, provide tutorials and documentation for new users and generally promote the project to the wider community.
Of course in any community there are difficulties and conflicts that may arise from time to time.
It may sometimes appear that the spirit of openness and friendship that existed had disappeared but this is rarely true. A trip through cyberspace, just like a walk in the real world, will turn up evidence of hostility, selfishness and nonsense. Unfortunately for us all some people seem to enjoy being hostile to others and for these individuals the anonymity of the Internet only encourages this. It is important to remember that such people are a minority whose main aim is to elicit a response. Responding to such comments, no matter how inflammatory, only feeds the flames.
Above everything involvement at any level in an Open Source Project should be fun. Experience shows that fun and enjoyment are the most efficient and productive routes to creative work.
This article was first published at www.mamboserver.com Thursday, 10 June 2004
