Saturday, May 10, 2003
The Open Source community is distinguished by the fact that the projects handled by the developer teams are usually based on the concept of distributed development. Distributed and globalised development strategies are one of the major reasons for project agility. Yet such distributed paradigm requires some rigorous methods to be followed. This article proposes to lay down some basic rules (ground rules) that can be implemented by the teams involved in such projects.
1. Specify the objective - a whole host of projects suffer from generalisation of the stated goals. The aim and objectives of the project must be explicitly stated and quantified.
2. Lay down the law - the first step to a distributed development effort is getting the project team in place. Choose the lead developers, the early adopters and the evangelists (you'll need a good number of them). But most importantly choose a Project Lead. This has to be the person who will take the critical decisions as to project systems implementation, technology adoption and adaptation and product releases. Once chosen, unless relinquished, fix this in concrete.
3. Put a number to those stages - project/product development passes through a number of stages. Depending on the Systems Development Life Cycle methodology involved, these can be linear or cyclical (iterative) or even cascading. The important point is to put a number to those stages. In the later stages of the game, after innumerable fixes and patches, it helps to hyperlink back to the stage in question.
4. Weighing the progress - far too often good projects fail to realise the necessity of putting a weightage to the progress of the project. A progress bar looks good on eye-candy, but numbers help hard-sell the project. Put a number to the progress made, either in percentage terms or in terms of files (or anything that suggests the amount of work done/effort put in). And then provide each and every member involved with a monthly update - progress motivates volunteers like nothing else in this world.
5. Blow the trumpet - nothing said is nothing heard. This adage is even more imortant for group development projects. Set up the mailing lists keeping in mind the different members that form part of the project. There should be a 'discuss', a 'core', an 'announce' and a 'bugtrack' atleast to handle the different type of topic. A properly conceived write-up on the project detailing the aims and objectives along with strategies help push the project along.
6. Write that idea down - great software but where's the documentation ? how often has one come across such situations ? it is a sad fact that given the mad rush to go through the development cycles, documentation always falls a step (and sometimes more) behind. Each project should have a dedicated documentation expert keeping tab on the development process so as to ensure that these two aspects remain in sync. A collaborative book and/or a WiKi helps in creating a global scratchpad from which ideas and thought processes can be collected and collated. Begin the process from Day 0 and perhaps the strain of keeping pace will be a bit eased.
7. Release small, release steady - small iterative releases beginning with a working prototype that mirrors the project functionality ensures that the project concept can be provided a tangible shape. Iterative releases help incorporate bug fixes faster than monolithic version revisions. Functionally scoping the project leads to greater understanding of the end-user requirements and this in turn leads to the project keeping itself sheltered from ' scope creep and feature creep '.
8. Set up the channels - distributed project development requires as a primary resource properly setup communication channels. Getting these in place at the functional level is a major step ahead.
9. Be agile, be nimble - technological hindrances and hurdles will require to be addressed by practical decision making ability and decisive action. Adoption of technology, creation and implementation of standards require agility and the ability to be flexible. Yet suppleness should not be a cause of chaos.
10. Lower entropy, push progress - chaos though sometimes facilitating creative output, more often than not contributes in the reverse. Get a grip on the chaos and disorder through delegation of authority and allocation of responsibility. Hand out roles and motivate people to stick to them at the same time contributing on a niche basis on different project aspects.
The ten points above are not the entire spectrum of group/community-based development strategies. However, they are a step in a direction that leads to proper project layout and meeting project deliverable schedules. Adhering to projected time-frame enhances the credibility as well as conveys an image of a well controlled development shop. Every Open Source project differs from the other by means of the uniqueness of the goal. As such some of the points may or may not be applicable in the other cases. The project teams are advised to keep in mind their unique locales and adapt to the situation. Yet one thing is common to all community based projects - hope for the best and prepare for the worst, commitment and delivery on promises means greater recognition.
Sankarshan Mukhopadhyay is a Free Software enthusiast and a member of iLUG-Kolkata. His blog 'Random Thoughts' can be found here, he can be reached at sankarshanm@softhome.net
- posted by sankarshan @ 5/10/2003 06:08:00 AM
