As more businesses become curious about running or engaging in open-source initiatives, a realistic approach to managing such efforts is needed. Open team project management can be difficult, and when trying to collaborate with developers who are apt to vote with their feet, anything can change at any moment.
Standard project management methodologies are not always applicable, and open-source endeavors spanning huge geographic areas make critical collaboration points, such as version control, bug tracking, and communication forums, essential to the cohesiveness of a team. Successful guidance of a team in an open environment requires diplomacy, experience, and an unwavering focus on direction. If you fail to supply the right amount of each, your project could take unexpected turns, with desired functionality left incomplete, or the project may be abandoned altogether.
Life in the Bazaar
Eric S. Raymond's famous work, "The Cathedral and the Bazaar," discusses two distinct approaches to developing software. On the one hand, the Cathedral represents a well-architected, planned approach to projects where few variables are left unassigned and a complete picture of the final product is achieved before a single line of code is written.
At the other end of the spectrum you find the Bazaar, which is meant to describe the nature of many open source projects in which activity is rampant and seemingly random. However, a common goal is inevitably achieved through each participant's efforts and initiative.
In many open environments, software isn't so much built as evolved, and many projects are described as having an organic quality, in which additions are kept or not kept in a seemingly Darwinist manner. Directing the flow of these features and ideas is a difficult task.
The role of OSS project manager
The approach to managing an open source software (OSS) project differs from a tightly controlled situation in many aspects, but not all. The same aspects of project communication and management required for the success of conventional (i.e., commercial) solutions also dictate the ultimate success or failure of an OSS project. Recognizing this fact is the first hurdle that OSS managers must overcome. Efforts from every facet of a project must be tracked and coordinated like any other project, perhaps with even more vigilance due to the constant turnover many groups experience.
Another requirement for managing an open project is dedication to a goal. In many cases, he who opens or creates the project manages it. As a result, individuals with various backgrounds (generally developers) are sometimes tasked with running an initiative much larger than most corporate endeavors. In many cases, this arrangement works well, considering that traditional corporate development methodologies are limited in their ability to create a framework for a project in a constant state of flux. Since OSS projects are developer-driven, the project manager must avoid becoming bogged down with egotistical, but passionate, contributors. If an OSS project manager does not keep his eye on the prize, he could wind up making decisions affecting the team that are good for the solution in the short term, but could threaten long-term success. A manager must put his personal feelings aside (a difficult thing for hard-working volunteers to do) and maintain an objective, big-picture view of the project's status.
Diplomacy is required to keep developers with varying backgrounds happy and productive. Goals, conventions, and procedures must be clearly outlined and kept up to date, or a project may become fragmented. What some managers don't realize is that by taking on a project, you must essentially remove yourself from the developer's chair whenever the community needs your attention. Responsibility has to be delegated and information shared, or the bustling Bazaar will become a headless mob that could kill the project.
Along with juggling project requirements, keeping the team(s) on track, and making sure the community goals are being met, an OSS project manager has to be able to survive the scrutiny of unforgiving development volunteers. Self-confidence, resolve, and thick skin are needed to prevent project issues from becoming personal, and to persevere in the face of dissension in the ranks. Defending a goal can be taxing when members of a community disagree, and caving in to demands or letting stress overwhelm you will endanger a project more easily than in a corporate environment.
When any one of these considerations is missing from an OSS project's leadership, problems can arise that will prevent the envisioned solution from being achieved.
In the open source community, experience, reputation, and recognition serve as currency. People join projects for a number of reasons, but no matter why someone is involved, high expectations are placed on receiving fair credit for work and on a person's performance. There is no tolerance for overstating ability, self-serving actions, or ambiguous intentions. A true leader will set an example for the community by providing clear communication and actionable items, and will put measures in place to maintain the integrity of development work.
While it is true that people of all skill levels get involved in OSS projects, the leader is expected to ensure that high-quality work is not undermined by novice inadequacies. There is a natural pecking order among the ranks, and protocols must be in place to prevent unknown agents from destroying the community's long-term achievements.
When a new developer joins an open source community and is not preceded by a lofty reputation, some sort of promotion system should be in place. For example, new members can be introduced to an existing code base and simultaneously prove their worth through bug fixing, quality assurance, forum moderation, and documentation. Dedicated and talented individuals will be recognized by those who depend on these support efforts and be given specific coding assignments. Opinionated and vocal volunteers can still be heard, but are less likely to steer efforts in a counterproductive or tangential direction.
In a true Bazaar setting, a project manager can be pulled in many directions at once due to essentially political views from factions within the team who each claim to know what the proper approach to the problem is. This is one source of trouble with open source product development that can only be overcome by thoughtful consideration of suggestions and keeping sight of the projects goals and deliverables.
That being said, many issues regarding development can be overcome through ample, accurate, and clear documentation. Find one location for each type of collaboration, and keep it consistent. A lot of shuffling around of information leads to conflicting instructions and makes it difficult for volunteers to know where and how to communicate with the community. Keep current status reports publicly available, and maintain a single, stable location for distribution and tracking systems.
If it were meant to be...
An OSS manager must be focused on productive work and strive to be more than just a firefighter. Open source projects tend to be organic in nature, leading to emotional and political involvement from volunteers trying to do their part to direct the evolution of the solution. To produce usable, useful software, project maintenance systems have to be upheld, and a solid communication structure will allow a Bazaar-style project to grow and change within a stable infrastructure.