Working in teams is great. And a massive pain. It depends on a lot of things: the other team members, the team lead, the project itself, your motivation for being in the team, the structuring of the team, plus the general environment of the team. Obviously, in a normal job, the individual doesn't have too much influence on most of these factors: your team lead is a given, project is set by your boss, you've got a given position determined by what others think is best, the environment is set ... most of the factors you'll have no influence on.
Things are supposed to be different in an open source project. You have much more of a say in things: you determine what, if anything, you contribute. You determine what parts of the project you're working on, if any. The structure of the team is - with a bit of luck - also something you can have effect on. Open source projects could thus be a dream come true in terms of development experience: people that want to work together on a project they want to participate in. What could go wrong?
Needless to say, tons of things could make things problematic in OS projects. My personal experiences come from working with BeWelcome, a hospitality/cultural exchange organisation and website. Founded on the bad experiences a number of people had with other sites (notably HospitalityClub and Couchsurfing) these people set out to avoid the problems they saw with the other sites. This, unfortunately, led to defining BeWelcome first negatively in terms of the other sites and only secondly to try defining it positively. In terms of the organisation it has led to a lot of bureaucracy - something that has also been felt in the various teams, including the dev team. The main problem has been a lack of clearly defined leadership. There have been team leads, for sure, great ones as well, but an overall problem with leadership in the project has influenced all teams as well (a team environment factor: the outside world influencing the team because the team feels it should mimic the outside world).
By far the biggest problem that I have experienced till now, though, has been lacking a team lead. After the last guy stopped no one stepped up to the plate so we've been working without one for a while now and boy! does that suck if there are ever differences between members in the team. Lacking a clear way to resolve differing opinions, point out the way or decide upon the priority of tasks is a major problem. Even just a thing like processes in the team needs a team lead to enforce them: if one person doesn't like the way things are done and starts working in a different way, who's to stop her?
While it's true that in an OS project anyone can step up and take on ownership, human nature would have it that not everyone does. In a project that runs on volunteer motivation, taking part already costs energy ... and taking on more responsibility can easily be too much. There's no extra pay to sweeten the deal, no perks, just more responsibility, more people calling on you to help them with bug fixes and feature requests. Obviously, seeing the project take the right turns and head in the right direction is a reward, but is it enough to outweigh the extra weight on your shoulders? I think the amount of people fighting to take on the role of team lead reflects just how much status is attached to the project - in most situations, it's not going to be many people.
Then what?
The possibilities for dealing with leadership in development teams fall in three groups:
- having a team lead
- sharing the team lead role between several members
- not having a team lead
1. This is the obvious possibility and the best in my opinion. In order for it to work properly, a good team lead is required but it's a role in which people can learn and rise to the task.
2.This means cutting the role down to size, sharing out responsibilities and making sure the resulting roles are not too big or too small. If the team gets the roles right and make sure there are no overlapping responsibilities, this can probably work almost as good as option #1. It's a requirement that the roles are clearly defined and that the people sharing the team lead role can work together without problems.
3. An alternative to having a lead is having clearly defined processes and sticking to them. If the group can agree to some clearly defined procedures for working and follow them, most differences in the every run of things can be resolved by pointing to the rules. Bigger differences in opinion or view of goals and mission can be resolved through a democratic show of hands in the group. This solution might work if all the people in the team shares a mindset and like to work together, but if not it's doomed from the outset.
In BeWelcome we're currently going with option #3 and my personal experience is that it's not working and it's not worth using - we're spending way too much time discussing and arguing things, and there's no option for resolving differences over working processes. Too many confrontations which takes time away from development.
So, time to change things.