Click here to view the complete list of archived articles

This article was originally published in the Summer 2006 issue of Methods & Tools

---

Running an Open Source Software Project - Part 2

William Echlin, QaTraq Project Manager, www.testmanagement.com

Organising

The OSS team usually excels at this stage. The ability to bring together the team members, the tools, controls and communications methodsto get the job done are second nature to most OSS teams (partly because theyknow exactly where to turn to for OSS solutions to address these issues andpartly because that are no organisational restrictions imposed on theimplementation). A typical OSS team thinks nothing of implementing the toolsneeded to run the project efficiently. Setting up a defect tracking system, a forum and source code control in days if not hours.

The difficult, and perhaps crucial part, is how you open up these tools to the community. Do you open up your defect tracking system toabsolutely everybody? Thereby exposing yourself to perhaps hundreds of poorlywritten, invalid defect records which all need sorting through. Do you provideeasy access for new members of the development team to the source coderepository? People who have no track record on the project could make critical changes to the code base.

I witnessed a recent exchange on an OSS project forum where a new member had been busy checking in code changes to the CVS repository. He hadrenamed fundamental aspects of the application because he thought he knew betterabout the terminology that should be used. This demonstrated how easily extra,unnecessary work can be created if you don’t get the project controls right.It is difficult to get it right as to whom, how, when and where you open up yoursource code repository. Yet getting it right is essential to the success of the project.

It is essential to get the balance right between restrictive controls and the freedom that helps motivate the team. If your controls aredraconian you stifle enthusiasm and motivation. If you loosen controls you mayfind it easier to develop the levels of motivation. Giving your team moreresponsibility makes a big difference to the project and can be incrediblymotivating. There is nothing complicated with principals, but never underestimate the importance of getting the balance right for your project.

It comes down to making the right decisions in involving the community you are serving and keeping the control and direction of the projecton the right path. Like many things in life, the solution usually lies somewherebetween the two extremes and can depend largely on the maturity of the project.Never forget though, that passing on more responsibility can be a powerful motivator.

Executing

You would think that the coding stage would be a walk in the park for most OSS projects. After all, we're all supposed to be good at this thepart. Yet the success of this part of the project is largely dependent on thefoundations built in the previous stages of the project. If you don't have aclear understanding of the problem you are solving or your prioritisation of thework was short of the mark, you limit the chances of success. Good coding alone doesn't make a successful project.

Assuming that the foundation stages have gone well, it is this stage where the "release early and often" approach is often citedas being the key to a successful OSS project. However, I would argue that an OSSproject that relies solely on the community for its unit and system testing isasking for trouble. I recently upgraded to the latest version of a popular Linuxoperating system. Maybe it was my fault for not reading the release notesproperly, but by the time I realised that they’d stop supporting a populardatabase that I relied on it was too late. Yes they released early, but I hadalways found previous early releases reliable and became complacent whenupgrading. This taught me a valuable lesson regarding complacency and the deployment of OSS.

There is a balance to get right here, especially now that more and more people are starting to rely on OSS. If you continually release buggy software in today’s environment, you risk losing users. You can't expect users to test everything for you. With so much choice around now (I’ve lost count of the number of Linux distributions now), users will remain loyal only if you reach a certain level of quality before release. If you abuse the loyalty of those users, then you’ll have fewer users to further support your testing efforts. With fewer users you have less testers and you enter a slow but lethal spiral of death. Get it right though and you can expect a faithful, loyal following of users.

Feedback from users is another absolutely crucial aspect to the execute stage. Few OSS projects enjoy the privileges of a dedicated test team that is paid to give you feedback. This presents two key problems

1. the test team / users won’t be physically located near you
2. the users / testers aren't obliged to give you feedback.

To a large extent the feedback you get is down to two things

1. how easy you make it for people to provide feedback
2. how supportive you are to those people when they provide feedback.

This bit isn't difficult to understand. If they can't provide you with feedback (i.e. you don't give them a usable feedback channel) you won't get any feedback. If you don't thank your users/testers or you aren't grateful, then they won't provide you with feedback a second time round. More than commercial projects, OSS projects live and die by the feedback they receive from users, because they have no internal feedback mechanisms or internal test team to rely on.

Forums are among the best feedback channels and the most powerful motivators for OSS projects. Forums are so powerful that I find it difficult to understand why commercial projects don't use of them more. Perhaps it’s the thought of airing your dirty washing in a forum that puts commercial projects off using forums. Yet, if a developer in a commercial project receives negative feedback about his/her work in a forum, you can almost guarantee that he/she will feel motivated to do something positive about it. We all crave for feedback and recognition. Feedback through forums can satisfy those cravings.

Take, as an example, the last time you ate at a restaurant and complimented the waiter for a really delicious meal. The chef cooked themeal but we compliment the waiter. How do we know that the compliment was sentback to the chef? Wouldn’t it be more rewarding for the chef if he wascomplimented in person? It’s no different in software development, as forumscan provide that direct channel between the users and developers. A forum islike standing up in the restaurant after finishing your meal and shoutingthrough to the chef in the kitchen that you thought the meal was delicious. Notonly does the chef receive your complement directly, but you’ve also told therest of the dinners in the restaurant what you thought about the meal. That’s a huge motivator for the chef.

Closing

Of all the stages, this is the one that is very different to that of a commercial project. Getting it right can make a huge difference to theoverall image of the project. You don't have to provide documentation. You don’thave to provide any support. You don’t have to make sure all defect fixes areverified before release. In a typical commercial project, you will not achievesign off until all of these aspects are complete. Yet many people fail torealise that if you don’t complete these aspects with OSS projects, you areforcing your users to jump though many unnecessary hoops, which is likely to mean less users.

The Apache foundation is a really good example of completing the documentation successfully. People actually come forward to volunteer towrite documentation for this project, because they receive kudos and recognitionfor their efforts. In smaller and less successful projects, this can be howeveran extremely difficult step to complete. Nonetheless, without good documentationit is very difficult to call an OSS project a success. Users are so dependent onwell-written documentation. Imagine trying to use CVS without a well written user guide... it wouldn't be impossible but it would be far more difficult.

It is also during this phase that the feeling of achievement comes from knowing you’ve solved the problem defined at the start of theproject. This is why it is so important to define the problem in the firstplace. When members of the team know they’ve solved the problem defined at thestart, they know they’ve been part of a successful project. It’s importantto remember that a successful project is defined as much by the members of the team working on the project as it is by the end users.

Conclusion

Recognition, responsibility, advancement and a feeling of achievement all play a crucial part in keeping a team motivated. It is thatmotivation that plays one of the biggest parts in making a project a success. Noamount of project definition, planning and organising will achieve anything ifyour team isn’t motivated. Yet every stage of a project presents opportunitiesfor you to motivate your team. Whether you are running an Open Source project ora commercial, closed source, project, you should take every single one of theseopportunities to motivate you team because this will ultimately create successful projects.

Page 1   Back to the archive list