When he joined the Ruby on Rails core team last January, Yehuda Katz expected to be working on a project he loved. Instead, he had to concentrate on appeasing a community of open-source developers all vying for his attention, a situation becoming more common for developers in his shoes.

But Katz and others have risen to the challenge of bringing distributed teams into sync. Along the way, they’ve discovered tips and tricks that can change community management from herding cats to driving a stampede.

Katz said that a large part of his job now is doing code reviews with contributors. That’s a huge part of community management, he said, because most contributors are not up to the level of competence of the core team, and code reviews are a way to bring them up to speed.

Fortunately for Katz, the Ruby community is quite cohesive, and even more so since the merging of his Merb project into the Rails 3.0 mainline. Katz does not have to deal with too many social conflicts.

James Bottomley, distinguished engineer at Novell and maintainer of the Linux SCSI subsystems, has learned how to deal with such problems. As the Linux community is larger than the Rails community, there are more egos to butt up against, he said. He has three pieces of advice for smoothing over the inevitable social friction that can occur within an open-source project.

“First, keep it technical. Once things become personal, it’s much harder to have rational conversations,” he said. “Give everyone the impression you’ve listened to them (however silly the opinion might have been).

“Second, and this is really an extension of ‘keep it technical’: don’t just say ‘no,’ say ‘no’ with a reason.

“Third, organize face-to-face meetings at least once a year (possibly in a conference people are already going to). Some of the heat in e-mail discussion seems to happen because people don’t connect the e-mail address at the other end with a real person. Just meeting and talking can help this enormously and remove potential flashpoints before they erupt.”

Fulltime job
Joe Brockmeier worked with Bottomley at Novell until the end of January, when he left the company to pursue other interests. At Novell, he served as openSUSE community manager, and also oversaw the documentation development processes on the platform. Brockmeier said that “community manager” is a misleading title.

“Community management really isn’t about ‘running’ a community, it’s about working with and facilitating a community,” he said.

He also said that, despite what you’d expect, running an open-source community is not a thankless job.

“Is it thankless? No. People often let it be known that they appreciate the work that’s done to help a community, in word or in deed,” he said.

“Plus, if you’re successful in getting things done, the community gets more done, and that’s thanks enough in and of itself. Nobody should take a community management job unless the goals of the community are their own. If the community achieves the goals, then they’re getting plenty of thanks.”

Off the Rails
Perhaps one of the most dangerous things a developer can do to a community, however, is nothing at all. Sometimes the community and the developers of a project just run out of steam, as in the Apache Beehive project, which was discontinued on Feb. 10 due to lack of interest.

Or it could be something far more depressing: ennui. In July 2009, the CentOS community sent an open letter to the project’s founder, Lance Davis, asking him to come back to the community. For some weeks leading up to that letter, Davis had ignored phone calls, e-mails and messages related to the project he had helped to found. The CentOS community was livid, as Davis also controlled the project’s domain name and funding statements.

Since that time, Davis reappeared and transferred control of CentOS’ domain and other projects back to the community. But the whole affair proved that even when a project is worked on by hundreds of people and used by major companies like Oracle, a single person with too much control and not enough motivation can severely hamper project progression.

Greg Kroah-Hartman perhaps put it best when he explains what he has learned from working with the Linux community. Kroah-Hartman is the head of the Linux Driver Project, and he is frequently charged with working alongside corporations and individuals who wish to have their drivers included in the kernel.

He said there is one very important thing to learn about managing a community: “The best thing I’ve learned over the years is humility. There is always someone out there that is better than you and can point out problems in your code. And that’s good, because in the end what matters most is the code getting better, and by virtue of that, Linux getting better.”