Arron write about his discomfort with the culture around one of the open source communities he’s dependent on.

“…  a tradition of edginess, individual expression, one-upmanship, and disregard for such fluffy, fake egalitarian notions as consensus, inclusion and good manners. It is expressed in the take-it-or-leave-it, I-don’t-owe-you-anything  …  a community which collaborates largely by aggressive competition and fierce meritocracy. …”

He goes on to contrast that with what we have tried to achieve in the Apache community.

“Apache, like …, is a strict meritocracy, but I believe that may be where the similarities end. There’s nothing wrong with giving credit where credit is due, but the Apache philosophy asserts that collaborative peer development trumps rockstars. Rockstars are an anathema to the ASF culture. In the long run, a large, diverse community of contributors provides a stability and quality”

I often wish that we, Apache that is, would find a word other than meritocracy to hang out on our shingle.  I have no truck with it’s clear association with social darwinism, but that’s for another post.

There is a lot of cultural diversity across the landscape of open source.  Rich writes a bit about the Perl culture in another posting.  It would make a  fascinating  sociology study to reveal those more transparently.  There are some projects that I’d like to be a part of, if only for their culture.  There are others I am part of, in spite of their norms.

Cultures (communities) are funny things.  There is a lot of cargo cult presumptions around them.  Teasing out what is  superstitious  ritual v.s.  fundamental  is very hard.  Humans are very good at making us stories which provide a plausible story for why this or that activity is  fundamental  v.s. superstitious.  For example, let me make one up:  Living in with such high population density the Japanese don’t shake hands for reasons of  hygiene.  That’s not true, the true story is more about how standards emerge, but that’s for another day as well.

Arron says something in passing that I don’t think is true, or at least is missing an important point.  He writes:

“If it’s unsurprising that a community of rockstars would gravitate to a hip tool like git, which favors individual forks, compared to a staid tool like subversion, which forces developers to work together in a centralized repository, then it should be equally unsurprising that the rockstars don’t care that they offend or drive others away.”

Which is similar, in a way, to something I read back in January: that git by encouraging forking makes it hard for users to find the high quality fork that they should probably adopt that it  dissipates  a valuable binding force for the community.

These are opinions I have harbored.  Recently, I have set these  opinions  off to one side.

There are lots of hard problems in open source.  One of them is certainly how to form a cohesive collaborative group around a code base.  Source control is a tremendous help in that.  In part because it provides a locus around which the work can  rendezvous.  It a campfire, and the community gathers around it.  I accept that.  But let’s be clear, it isn’t the only campfire.  Other examples:  the irc channel, the email, the bug tracking, the release process, the distribution system, the license, the social networks, etc. etc.

There is something else going on with git that members of my community, Apache, often are blind to.

Open source works best when your users crack open the seal and add features and fixes based on the unique scarce knowledge they have.  That scarce knowledge comes into two flavors.  First is that they are embedded in real world problems.  Second they often have unique talents.  Both of these are impossible to simulate back in the center of the project.  Open systems with liberal licenses enable the periphery to solve thier problems and exercise their unique talents.  To scratch thier itch.

But then what?  Well I tell you what happens next: nothing!

For a laundry list of reasons users do not contribute back their innovations, fixes, hacks, etc.  Which results in starving the project for the knowledge it most desperately needs.  Knowledge it cannot get any other way.

Well maybe that’s a bit strong.  You could write into your license a requirement that they give back.  Or, you could attempt moral suasion.  Or, you could create one or more firms that provide consulting and services and hope they collect and feedback what they learn.  But when all is said and done generally this step, the step between user scratches his itch and project gets access to the knowledge created, is simply broken.

The thing that blew me away about git was that it helps to address this problem.  It increases the  probability  that users will reveal their knowledge.  It helps to create a cultural norm toward that behavior.  To me this is far more important than the risk that their forking would  quench  the community campfire.  In turn I’ve come to believe that encouraging the early and public revealing of that work in progress has other key benefits.  It acts as a shout out.  It increases the chance that other folks with similar or complementary skills and problems are given a chance to come out of the woodwork.  That a positive for the community, it creates a stronger social network; not a weaker one.

So I’ve come full circle.  I used to see the central repository as a key tool in encouraging the group to form and maintain common cause.  I’m now more concerned about how groups avoid cutting themselves off from their supply of fresh knowledge.  There are a lot of tools we use to avoid starving – e.g. open licenses, convivial interaction norms, enthusiasm (not just respect) for diverse skills, etc. etc.

We can do a lot to make the source control frameworks encourage rather than frustrate these knowledge flows.  The key is to think about the knowledge in motion and to encourage that. The  knowledge  at rest is less important.