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.”