I’ve had an idea rolling around in the back of my mind for a little while now and the Call for Papers for ZendCon brought it up and into focus in the last few weeks. I am a part of the Joind.in project, a community event feedback site that’s also an open source project. My co-conspirator Lorna Mitchell and I have worked hard over the past year or so really trying to make the project the best it can be. There’s been a lot of learning that’s gone on during that time, so I wanted to share some of that in a series of blog posts.
This first post, as the title mentions is about communication. I’m going to break it up into two parts because there’s really two different sides to this one word when it comes to a project with so many moving pieces.
Communication with the Group
The first and more obvious form of communication people of think of when working with an open source project is talking to the community at large. Once you take that step an decide to open the source for your application, you’re no longer alone in its development. Sure, you might be the only one committing code to the project, but that doesn’t mean there’s not interested parties out there keeping an eye on your work. This is the first thing to consider as communication from your project to the outside world – the code you write. Even the best, most elegant code without some kind of commenting or internal documentation will fall flat. If there’s nothing helping an outside developer to understand your code and the design of it, chances are they’ll abandon it before they even get started.
Following this same line of thought, there’s the next most important (maybe more important?) form of communication for you to share with potential developers – project documentation. I know it’s been hounded to death by this point, but please don’t wait until the very end of your coding to write documentation. Yes, it’s a pain, but with so many tools out there (like the excellent DocBlox) to help you generate documentation, you have no excuse. Auto-generated docs are great, but real human-made files that include examples and descriptions are even better. Don’t forget to put a human side on your project – it draws in more contributors than just code comments alone.
The “human touch” brings me to the next topic under communication – personal interaction. Comments and documentation on the project are one thing, but if you really want to get people involved and get them as excited about the project as you are, you need to reach out to them on a personal level. There’s lots of ways to make this happen including:
- mailing lists (we have ours split into “developers”, “features” and “site news”)
- an IRC channel (#joind.in on Freenode, stop on by and say “hi”)
- a blog
- a Facebook page
- a Twitter account
It’s an easy thing for a developer of a project to just want to stick with the code and get tunnel vision when it comes to the overall project. I’m going to go so far, though, as to say that if you don’t choose at least one of the things from the list above, your project will not succeed past the point of you and maybe a few other developers hacking on the code. At the recent php|tek conference in Chicago, there was a hackathon one night where several (I think it was around 8 or 9) folks all sat down and worked on Joind.in bugs. This was excellent except for the fact that I, one of the project leads, wasn’t able to be at the conference. This is where the IRC channel became invaluable – Lorna was there helping but there was only so much of her to go around. Me being able to have an official place for those people to come and ask questions was a huge boost in productivity over something like email.
Two things to remember, though – having these things is great, but don’t spread yourself too thin. You don’t have to have all of the things from the above list to make a successful project. Pick what fits your needs and the needs of your group. Remember, not everyone that’s interested may be a developer. Also, and this goes hand in hand with #1, don’t forget to nurture the communities you build. I’ve seen first-hand how things can drop off if the driving forces behind the project aren’t there to help drive these interactions. The past few months my time was increasingly eaten up by the conference I was planning and I just wasn’t able to spend the time with Joind.in that I wanted to. As a result, the mailing lists ran a bit dry and even the IRC channel was sparse. I’m on a mission to turn this around, though and am doing what I can to keep our current developers and bring in those shiny new faces eager to hack away.
Disclaimer: Okay, so I lied a little bit – turns out there’s more to say on this topic than I thought, so the second part of the “communication” idea will be in a “Part 2″ post coming soon. Until then, here’s a few suggestions for the project organizers out there about communication with your developers:
- Be transparent – don’t hide decisions from your community. No one likes surprises, so do them a favor and let them give their input
- Be consistent – you and the other project leaders need to present a united front on decisions. No “ask him, he’ll say yes” sort of thing
- Be polite – yes, there’s going to be “those people” that seem to live to cause trouble, but deal with them politely. You never know who’s listening
- Be a dev leader – this is an easy one for the project leads that are still developing, but for the others this could mean moderating pull requests or being familiar enough with the code structure to answer some high-level questions
In the next post I’ll talk more about the flip side of this – communication within the project between organizers and some of the difficulties that are hiding in there.