Many people agree that teams are good : doing team maintenance of packages is often seen as A Good Thing inside Debian, and Ubuntu enforces it by switching to the everything is team-maintained philosophy. However, teams are subject to complex group dynamics, and raise interesting issues that you don’t encounter when working alone. It is important to ask yourself those few questions

Dilution of knowledge: Team members tend to individually know less about specific packages. Does the sum of all team members really know more than an individual developer would know about a specific package ?

Responsibility: Are there some clear responsibilities in your team ? Are people feeling responsible for packages ? Not having clear responsibilities is dangerous, because a package could become sort-of-orphaned inside the team, because nobody would consider “his duty” to work on it.

Hierarchy inside teams: Is there a clear hierarchy inside your team ? If there isn’t (which could be OK), are you sure there isn’t an unofficial hierarchy that built up with time, causing people to wait for an unofficial leader’s decision, while this leader might not even be aware that he is that leader ?

Scalability: How much can a team scale ? How does *your* team scale ? How many team members are really active ?

External interface: When dealing with the outside world (read: upstream), it’s easier to have a single point of communication. How does your team’s external interface look like ? Remember that teams’ external interfaces can easily become much more complex for upstream developers to deal with.

There are no magic way to build a team that work, but it’s important to look at your team with a critical eye and try to improve its inner workings.