So, what started out to be a post or two on some of the important things to consider about communication in open source projects, has now turned into it’s own little mini-series. In part one I talked about some of the important things to consider when it’s you, the organizer, talking to the people that come in and want to get involved with your project. In the second part I covered some of the organizer-to-organizer communication techniques to keep the project running smoothly.

In this part I’m going to focus on something that’s a bit harder to control, but can still make a huge amount of difference in your project’s life. Contributors talking back and forth with the organizers is fun and all, but sometimes they just want to skip a step and go directly to another developer. Dev-to-dev communication is absolutely necessary to make a project thrive. If a developer comes in and the only chatter they see on a mailing list is the project’s admin taking to various people, chances are they won’t stick around too long. People want to see life, they want to see lively discussions and ideas being explained and played off one another.

There only one real issue – you can’t control this.

You can, however, make use of some tools that make it a lot easier. As I mentioned, mailing lists are great tools to have for your contributors to ask questions and get their own ideas across. You have to encourage this, though – it’s not just going to magically happen. Sometimes you have to get the ball rolling by asking a few questions yourself first, but once that ice is broken conversations will more easily pop up. Even just a response or two to a question you posed to the list can spark ideas from other developers not even interested in the original thread. Challenge yourself to, at the start of every week, try to come up with a topic that you think needs to be discussed on the project and start a thread on the list. It’s okay if the majority of the activity at the project’s start is from the organizer(s). Lots of people have their opinions, some are just more forthcoming than others with them. Having a good “feel” for the list helps bring these out.

A second tool that can be invaluable for any project, just starting out or already mature with its contributor base in hand, is something that several of the code repository sites (like github or Bitbucket) offer as a part of their service – the ability to look at the changes someone’s committed to their branch (or to trunk), see the differences and comment on them right in the same page. Previously, version control systems have sent out commit emails that might have included the diffs from one version to another. This is good and all, but developers would need to respond to these emails with their suggestions and, well, as I’ve already mentioned, email is really more about the point-to-point rather than for lengthly discussions.

There’s a huge benefit to having a record of all comments related to change in the code right there in front of you. Github will even let you make a comment about a specific line in the change and all parties involved in the discussion are notified. No more batting around emails and trying to keep track of how many “Re:” there are in the latest response.

The final recommendation I’ll make is probably the most tricky depending on the size of the project. If at all possible having developers on your project physically in the same room makes amazing things happen. Take, for example, the Hackathon that happened at the last php|tek conference. Several developers were all there with the intent of working out some of the bugs in the Joind.in project as well as several others (including writing tests for PHP itself). Remote communications can be efficient, but there’s nothing quite like sitting across the table from another developer poking around the same code you are and hashing things through. Obviously, the Hackathon was a rare event, but if you’re even able to just get two or three contributors together, do it. Conferences are a great place to organize things like this – there’s people from all over that already know the project and look forward to the community that comes with other developers on the same project. There’s even the possibility of drafting new recruits!

Developer -to-developer communications is one of the hardest to get right mostly because it’s not really something you can control. It’s more of a “throw it and hope it sticks” kind of thing that can really pay off in the future of your project.