J_K9 @ Linux

Open Source Project Management: Common Pitfalls

September 19, 2007 on 3:16 pm | In Programming, Software |

Many people have innovative ideas about projects they would like to implement but simply do not have the programming expertise to realise them. So, in order to produce the application and still guide its development, they turn to the Open Source community for help.

I am such a person. I have a lot of experience with web development, but when it comes to developing software for the desktop I am absolutely hopeless. The Open Source community, however, has many individuals—developers—who are willing to give up their free time to help a worthy cause and to build the codebase for such applications under the guidance of a project manager. This is advantageous for both parties because the project manager gets to realise his creative concept and the developers receive some fame and recognition for their work, particularly in the Open Source community. They may also be offered incentives such as a share of the donation money; a steady source of income out of gratitude for the work they have accomplished.

However, many Open Source projects fall apart before they see the light of day, mostly due to management reasons. You are receiving this directly from someone who has had an Open Source project disintegrate (by the name of HyperGet) and has had to pick up the pieces, so the common pitfalls listed below are frighteningly genuine and happen to the most motivated of project managers. They all, ultimately, result in developer dropout and thus the death or dormancy of the project.

1. Lack of Infrastructure

   One of the first things you, as an Open Source Project Manager (OSPM) absolutely must do, even before seeking developer support, is to set up a solid infrastructure for the development team. This not only includes a homepage to promote the project and a download distribution centre but also a good bug tracker, a wiki to store documentation, a mailing list to communicate, a web forum to provide support to users and, of course, a Version Control System such as SVN or Bazaar which the developers can use to collaboratively work on the project’s code. I hope to explain this infrastructure in more detail in a later post, with examples of Open Source software which you may use as components of the infrastructure.

2. Lack of Continued Support

   Many OSPMs often show a lot of interest and motivation at the start. They find lots of developers, bring them up to speed on their idea (in detail), then sit back, pick their feet up and think “We’re off!” It just doesn’t work that way. Without the OSPM constantly motivating the developers and helping them in their tasks, the developers will think that the project is dead and will leave without notice, moving onto a more active project. Therefore, you should regularly gather your project’s developers for a team meeting, whether online or offline, in order to keep the developers active and to inform them of where to go next. These real-time meetings should also be used to design upcoming features and components together, as a team. You should also contribute frequently to the mailing list in between meetings in order to inquire into the progress made and to contribute ideas and opinions on upcoming feature implementations, so as to keep communication and development flowing smoothly.

3. Lack of Developer Interest

   Your project has to be interesting. Many developers work on Open Source projects merely because of the challenge which they provide. There is always room for improvement or expansion in an Open Source project; make this clear to the developers, set them targets and ask them if they can achieve them. Sure, it’ll be difficult and it will take time, but as long as they have something to aim for they will continue to show interest in your project and so will keep contributing.

4. Lack of Documentation

   All developers enjoy coding. Most developers hate writing documentation. So, it’s up to you to co-ordinate the documentation process and to make sure that the documentation is always kept up to date.

   One area of documentation involves the explanation of the code and its structure. A great way of keeping this section of the documentation “in the loop” (haha) is to encourage your developers to use JavaDoc syntax in their comments—this will allow you to automatically generate documentation based on these comments. Very cool.

   Another area of documentation is the “blueprints” section—this is where you explain in detail every major component in the application and write detailed design proposals for upcoming features. You will usually have to write this section yourself—at least initially—by communicating with the developers and discussing what they intend to code next and how they plan on implementing it, although the developers will do much of this work themselves because they know where they want to take their code next and that, in order to receive approval and a helping hand for the next improvement, they need to let everyone else know what they are doing.

   Finally, there is user documentation, which explains to the user how to use your application as efficiently and effectively as possible. You can either write this documentation yourself and update it with each new release or, alternatively, seek the help of an Open Source writer. Do not forget to visit this often untapped resource of helpers—an Open Source writer can lighten your burden greatly and can allow you to concentrate on other, more important tasks.

5. Lack of Incentives

   Sometimes, the challenge of coding for your project isn’t enough to keep developers hooked. Whether this is because your project isn’t as interesting to them as it once was or because of the problems and pressures of life and work, most developers will eventually get bored of your project and leave to find something more inspiring. A simple solution to this is to offer them incentives. If you have access to funding, whether through support from a parent company or private resources, offer your developers a low salary for what it essentially a part-time job. If you do not have access to funding, find it: set up promotional schemes to receive monetary support from the public and from users of your software, or dance around like a monkey with Barbie Girl blasting behind you in the middle of Leicester Square. Incentives will encourage your developers to keep working on your project and will improve your relationship, because they will be justly and consciously rewarded for their contributions.

6. Lack of a Lead Developer

   Last but certainly not least is the need for a Lead Developer in every project. The lead developer is your most effective way of communicating to the other developers in a language that is precise and which they can fully understand (and which you cannot ). If you tell the lead developer, in vague terminology, that what you want is “a window with three buttons,” she will co-ordinate to her team which widgets to use, where to place them and what functions need to provide their back-end functionality.The lead developer will also play a great part in keeping the other developers active and in keeping the project alive, and is a necessary addition to your team. Your lead developer should be a confident person with a competent knowledge of the programming language and libraries in use and with a firm understanding of the application’s design and aim.

There are a variety of other possible pitfalls, but these are the most prominent ones which I have encountered in my projects and in those of others and which must be avoided at all costs. If not, your project will die before it is fully fledged and both you and your developers will have wasted a lot of valuable time.

You can learn quite a lot about Open Source project management and how it works from articles such as this, but the best way to learn is to get your hands dirty and to gain experience the hard way. If you want your project to succeed, it will—but you have to spend a lot of time nurturing it and giving it an encouraging push in the right direction.