Most distributed teams aren’t fully distributed. They split their staff between the home office and everywhere else. The group in the home office have an easy time communicating. Walking over to someone’s office is simpler than chatting online so the home office group do it more often. After a while they rely on each other more and more. They work together and become productive. All of this feels good, but it excludes the rest of the team.
Second class citizens is the most common problem in distributed teams. And Subversion had it in a big way. The core group was so used to working with each other that they did it without thinking. They had been doing it for years. Everything they did was right —they focused on teamwork, communicated well, and wrote a lot of good code— but it wasn’t working.
Subversion started as an open project with a public mailing list, and shared repository, and a public review process. But the core group was too good at working together. They had private email and phone conversations. Notifying the public list became an after thought. Without realizing it they created two teams: core Subversion and everyone else.
Open source projects succeed or fail based on the quality of their community. Jim, Karl, Ben, and Brian together weren’t enough to make a product as large and complex as Subversion. They needed help from other people and they weren’t getting it.
Making someone feel like a second class citizen will make them leave your project. According to Karl, having two tiers on the team always “becomes visible to the other engineers who are not part of the core. And it doesn’t serve any purpose except to increase the core’s comfort level with itself.”
The core team’s interactions with community members was dwindling. The first wave of interested volunteers was leaving and they weren’t being replaced by new ones. CollabNet CTO Brian Behlendorf was the one that noticed it first. He saw the team going in the wrong direction before it became a problem.
Faced with the possibility of losing their openness and hurting the project the Subversion team did something amazing. They changed. Changing a team is extraordinarily difficult. First you have to admit to yourself that something is going wrong. Then you have to identify what it is and get everyone to agree on what you should do about it. Taking practices that have worked in the past and abandoning them is one of the most challenging tasks an organization could face.