Mistakes New Contributors Make
DDJ: What are the mistakes that you've seen people joining projects frequently make?
BB: Well, a little more than 10 years ago, on the Apache main HTTP developers mailing list, there was a developer who showed up from a well-regarded UNIX vendor for graphics machines, let's say, and they had recently moved to 64 bit. This was before Apache really had a portable runtime that abstracted away a lot of system calls so that it was easier to port to other platforms.
This guy showed up and hadn't really met anybody, and he emailed me and said, "I have a bunch of stuff to contribute, can I do that?" I said, "Yeah, just show up on the list and start posting patches." And I may have given him too lightweight instructions because he, ah, came on the list and said. "Great news, I ported Apache HTTPD to our 64-bit ship and have gotten permission from my company to redistribute these patches; and here is the first one out of 10." The first patch was a couple hundred individual changes. Many of them changed #ifdefs without allowing for the old code to continue to compile. It wasn't really an abstraction so much as a modification.
He said, "Number two will come tomorrow, and number three the next day, and you've got to apply them all in sequence because they're deltas, the first to the last, and that's how I modified and check-pointed my code." So the first patch gets posted and immediately people start saying, "This doesn't look like the right kind of change because it breaks it on this other platform or this messy #ifdef just complicated the code and it would be nice to have a more elegant call that starts out so we don't have to repeat it a billion times in the code."
The next day, when he saw that response, he was flabbergasted. He said, "Wait, I can't deal with this. Guys, I ported this to 64 bit. You can't make me go back and redo all these changes. Besides, my second patch depends on everything in the first one going through, so I can't change anything. I have nine more of these." What he didn't understand is there is intense review of code that goes into an open source project and it's better to show up on the scene and say, "here's what I'd like to do, it's a substantial change and I'm wondering about the right way to go about it," rather than to say, "Good news, I've ported this to the Commodore Vic 20. And here's the changes made. Please commit these in." There's a bunch of different problems with that one; the size of the patches and the dependencies. The other is the attitude: I've written this software, I am God.
[There's] a righteous attitude that some developers get that ends up being fairly self-defeating, because it ends up accomplishing the opposite of what you intend. Instead of building confidence in your solution, it causes people to question it.
DDJ: What other errors do new contributors make?
BB: The other is just being too lazy to search through the discussion archives or to RTFM. Or, as a member of the community, to give a snarky response to somebody and it just escalates, or to give no response, and they interpret that as meaning these developers are stuck up or ignorant or hate newbies or whatever. Communication differences: it's the kinds of things that happen when two people are miscommunicating at long distances, and if they were face to face, wouldn't happen, even if they started off on the wrong foot.
DDJ: In many cases, contributors aren't just communicating across long distances, they're communicating across cultural barriers, too.
BB: Yeah. And you could add that for some projects that have a healthy user participation, a lack of understanding of the need to save face. Many developers are very rigorous and scientific and absolutist: "Your code sucks and you need to go back to school." It can be humiliating and especially in Asian cultures, that's a death sentence that's somebody who's never coming back to participate. Even more subtle passive-aggressive kinds of things can cause somebody to lose face.
Getting Committers To Respond
DDJ: I was looking yesterday at the Apache Poi project, which is looking for some point men for some of the subprojects. It gives some elaborate directions on how to participate. In a nutshell, build it, find the place you want to make your patch, submit your patch, and then bug the developer mailing list until somebody does something with your patch. It seems to me that that last bit is one where trouble lurks. If you're a newcomer and you're bugging people to respond to your patches, you're likely to rankle people if you don't do it right.
BB: If you're making genuine contributions and no one is responding? If the project is dead, there's not going to be anyone around to resuscitate it. Someone has to stand up and say, "No, this project has to come back alive, get the heart-jumpers."
DDJ: Does that ever happen? Have you seen projects that were completely dead come back to life?
BB: There are projects where it really is one core developer who people turn to when there's a question. Maybe there's an area of the code that no one understands or no one wants to touch so that the question remains unresponded to, while other conversations continue apace. There are far more underappreciated projects than living projects.
Patience, asking questions, always making sure that you're carrying a tone of appreciative inquiry, are the key. Such as saying, "I think this is the right solution, I'm really curious about what others think of it. If I'm the only one who cares, maybe the code should just be excised."
You also should rabble rouse a little bit and maybe go to the issue tracker and see who else has reported similar defects and maybe try to pull them back into the community. If you want to fire up a moribund project or portion of a project, then go out and speak on it. There are innumerable tech conferences out there these days and plenty of opportunities to speak, especially if you don't care to get paid. Telling people why a particular thing excites you is a great exercise, and a great way to make sure you really know it, too.
DDJ: Thank you. I think you've laid out a helpful roadmap, packed with useful observations and commentary that will help guide potential contributors and give them a sense of what to expect.
Long ago, Brian Behlendorf was the CTO at Wired Magazine. During his work there, he started patching the NCSA Web server. As he added more patches, a community of contributors emerged, which later forked and rewrote the server. This product became the Apache Web Server. He later founded the Apache Software Foundation. He also cofounded Collabnet, where he was a principal contributor to Subversion. He is currently the CTO for the World Economic Forum.