Managing Your Open Source Project
-----------------------------------------------
Many want to know about getting people to join and how to manage their project.
This is asking quite a hard question :o) Attracting and vetting people in open source is something that can be done in a lot of ways. You also will find an issue with people that want to join as a developer or even as an owner, but they are asking for something that they may never act upon.
So, it is really three things:
1) How do you get people to join?
2 ) How do you manage those on the team?
3) What to do with those that are asking for more than they need or want?
Getting Volunteers to Join
For 1, getting people to join, the keys are organization, information and promotion. Be clear about your goals. Be specific about the tasks and what needs to be done and in what order. Lay out the phases. Make sure people understand why this project is important. Also talk about why participating in the project is good for them too from the types of technology to what they may be able to put on their resume.
The primary place to do this is with your project pages, but you can also use the wiki, forums, documents and files, the issue tracker, the help wanted wiki, and finally blogs. The more that you talk about your project in both volume, location, and frequency, the greater the probalility that you will get someone that will help.
Beyond that, you have one key volunteer to do the important work and that is you.
How Do You Manage Your Project?
For 2, this depends on how you want to manage. Open source should not be about code changes happening at the will of every member. Usually there is an owner (you) that acts as architect. This person often creates the first prototype. It does not need to be big. Either it lays out the features, and does not implement them, or is a pilot, or just the first couple features. Work from there still rests with the architect and getting people to help design or to shepherd others on tasks.
Once a project has actively participating members it is a matter of passing out assignments. Very often it is volunteers that pick assignments. Rarely can you assign someone with something unless the task is related to a request,bug, or area that the participant is very familiar with. Remember that this is about voluntary involvement and not a boss/worker relationship.
If tasks are laid out in a way that people can see something interesting to do or something that they want so bad that it must be done by them, then they will do it. People must be drawn to their tasks. Your tools are coolness, interesting problems, learning opportunities, resume filler, irritating bugs, needs from other tasks, and even self promotion.
What About People That Join To Just Join?
For 3, the problem is in part about 1 and 2 and also not reading up on 1 and 2. The more you make it clear what the responsibilities are, the greater the chance that they will select the right option. Many request that the joiner email prior to joining other than observer. Some require observer before any other request. Some require joining the email lists and the forums. The key is to require something for being other than observer. You need to be careful about anything beyond observer because there are people that can really mess up your site. Only grant higher rights to people that are properly vetted to your satisfaction.
In the jxta.org platform project (one I think has one of the better models), you need to be an observer and submit a fix or enhancement via the issue system. If the proposed patch is good or that there are a series of good patches, the user is upgraded to developer. All code changes are submitted as patches which are attached to feature/bug issues. Each patch must be approved by at least one other member of the development team before the code is allowed to be physically changed in the cvs. The cvs commit must contain a reference to the issue and the person that approved the patch. Of course this is with an established project that has had many versions, but it is a good model that can be expanded to larger features.
Remember, open source is not anarchy. Linux is run by Linus and his closely held team - not by the millions of Linux users and contributers. It is a commons with agreement from a gentile monarch or a tight team. Information is power both to keep things on track and to cause people to take action. Active forums, email lists, issues, project pages, documents, demos, releases, and blogging can help cause people to take action.
.
.