Matt Asay is kicking it up a notch: “Most would-be open-source contributors don’t have time to become anything more than casual contributors.” Maybe two notches: “[H]ow do we encourage ‘drive-by developers’ to become full-fledged members of open-source communities?” Not to mention his first two responses, which are roughly “you’re totally right” followed by “you’re totally wrong” (this is why I love the blogosphere – instant clarity through communal group-think!). So, if you’re keeping score, I believe we stand at:
– Matt’s right
– Matt’s wrong
– royrusso, who says Matt’s right, is wrong
– The_Decider, who says Matt’s wrong, is right
Follow me here.
Every open-source community needs an immunity system, to protect it from destructive, incomplete, or off-topic contributions. Nobody just opens the repository and invites “guest” to commit. As I argued in Redeeming the Commons, the integrity of the community first (and the code only second) is the real “common” that must be protected, and the mechanisms evolved by the open-source community at large do a remarkably good job at that. Some communities need more protection than others (Marten Mikos has often pointed out that the MySQL team has never rejected a patch … but they don’t get many, either, because the number of people actually prepared to work on a relational database is small). So, to this extent, I say Matt’s wrong: open-source communities do need to protect their borders, and the basic system of requiring community membership seems to work pretty darned well.
On the other hand: Matt’s totally right, that we need to find better ways to encourage participation: some good programmers with seriously useful value to add just don’t have that kind of time. And, granted, some communities may be more protective than they really need to be, or more … quirky … than makes for good social relations. And, as citizens of the open-source community of communities at large, we need to find ways to improve matters. It’s more like optimization, if not Goldilocks (not too hot, not too cold: just right!).
This is actually a huge part of what CollabNet is all about, from the perspective of helping our customers understand how to use and optimize these dynamics within their organization – “inner-sourcing.” For the opposite perspective, there are organizations like Open Logic, where Stormy Peters has been talking up “community management.”
Consider a history lesson: remember “Red Hat 1.0”? Red Hat’s first success was in serving as the QA arm of the Linux open-source community. Lots of Linux hackers failed to see the value in that … “who wants someone *else* to pick my patches for me?” But lots of enterprises, who were more interested in getting their own job done than hacking on a kernel, were eager to take a fixed set of features and patches, with a solid QA history and a solid promise that someone would answer the phone if need be. Red Hat 1.0 met a need: “just give me something that works!” And Red Hat also mediated bug reports and support needs back into the community, where appropriate, so their enterprise customers didn’t have to.
Organizations like CollabNet and Open Logic are kicking that up Matt’s extra notch: a big part of Open Logic’s value is teaching the enterprises how to contribute, how to join–and how to stay in budget and on time and all those enterprise imperatives. CollabNet offers professional enterprise-friendly support out the front, and takes care of the community membership (and, in the case of Subversion, a fair bit of the community management).
“Throw-it-over-the-wall” contribution is cheap for the contributer, but it’s very expensive for the recipient. Every contribution needs to be reviewed, even the ones that turn out to be perfect, ’cause you can’t tell which are which without the review. It’s a cost, and the open-source process is a solution, but it requires bi-directional participation. The solution to Matt’s cry for increasing the bandwidth seems to be specialization … “membership for hire.”