If its market penetration continues to grow, the open source software movement promises to narrow the gap between the computer industry and computer science. As larger companies such as IBM and Sun continue with open source initiatives, more and more smaller companies may follow suit and attempt to exploit the financial savings promised by this increasingly popular software development model.
If your definition of open source encompasses the public release of source code by a commercial organisation for others to use or enhance as they see fit, then current software development practices need not be greatly affected.
Many well-known open source projects operate on a different model where software is developed through a collaborative project driven by volunteers working as part of a loose consortium. This collaborative model presents a range of unusual challenges for even a seasoned IT project manager. Here are some tips on meeting the challenge.
Tip 1: Task allocationIn a situation where programming work is being supplied on a volunteer basis, the issue of who-does-what is less within your control than it normally would be. To get the best from your teams, you need to remember that volunteer programmers will be most productive (and they can be hugely productive) when working in areas that naturally interest them. As in any project management situation, you will need to identify the major software components required by the project. Your more detailed technical planning phase will then break down these components into more detailed code deliverables. Once the deliverables are known, you can ask your volunteer programmers to express their preferences for task allocation. Naturally, it rarely happens that all tasks will find a keen volunteer, and you may have your own reasons for wanting particular people assigned to particular tasks. In this context, there is a delicate balance to be maintained between preserving your necessary authority as project manager, and preserving the great asset that is your programmers' enthusiasm. A "semi-democratic" system works well here; ask for each coder's top three preferences and do your best to assemble teams that reflect at least some level of natural interest. Keep a note of those who "miss out" completely on their expressed preferences, and make it clear that you will try to assign them tasks of personal interest in the next phase of task allocation. Tip 2: Channels of communication
Working with distributed programming teams is a challenge in the best of times. In a situation where there may be limited budget for travel and you may be relying on programmers you've never met, keeping communication channels open is critical. Online communication tools come into their own here. It's rarely a good idea to rely solely on e-mail, however. Too often, e-mail discussions go "back channel" and drag on behind the scenes between a limited number of participants. This means that you as the project manager can miss out on important deliberations, or may be prevented from smoothing out conflict between team members or steering the project in the right direction. Make it a priority to set up a Web-based forum such as a wiki for online discussion and document storage, supplemented by occasional e-mail broadcasts for the most time-critical issues. Make sure that your forum is well publicised and used consistently; e-mail discussions or debates that arise spontaneously should be gently redirected to the forum. It's easy for such forums to become cluttered and disorganised if they're not well maintained, so consider the information architecture of the forum carefully when it is first set up. Consider adding the job of forum maintainer to your list of tasks, or you may appoint a willing volunteer to help here. Tip 3: Revision control
Source revision control, including the maintenance of a definitive source repository at a single location, will be critical to the success of your distributed open source project. Most popular revision control systems support distributed access. CVS, for example, is popular choice in the open source world and has good support for secure remote access. Make sure at the outset that you define a clear policy with respect to revision control. Who will have "commit access" (the ability to upload modified code to the repository)? How regularly should the repository be checked for updates to be downloaded ("local synchronisation")? How often should the repository be updated with new and stable code releases? Regular local synchronisations and repository updates are particularly important when working with volunteer teams whose enthusiasm can sometimes overcome their self-discipline. Ensuring that everyone is working from up-to-date source material wherever possible will help to prevent and detect specification creep or interface drift. Whatever your revision control policy, it should be clearly stated and known to all. Detailed notes about how to use the chosen revision control system with your project repository should be provided so that there is no excuse for not following the policy. On your mettle
Managing an open source project relying on volunteer programmers will keep you on your mettle and test your ingenuity. Every project will be different, of course, but if you remember these three tips -- aim for preference-based task allocation to maximise enthusiasm, direct project-related communication to a well-structured, universally accessible forum, and define and stick to a clear revision control policy -- you'll be giving yourself and your team of volunteers a strong start in the open source stakes.
For a weekly round-up of the enterprise IT news, sign up for the
Enterpise newsletter. Find out what's where in the new Tech Update with our
Guided Tour. Tell us what you think in the
Enterprise Mailroom.
Enterpise newsletter. Find out what's where in the new Tech Update with our
Guided Tour. Tell us what you think in the
Enterprise Mailroom.
