Redeeming the Commons

At CollabNet, we believe that the techniques that have made Open Source software development so successful can be reapplied (with some tweaks) to development within the enterprise – what we call inner-sourcing. But it takes some care: much has been written about how and why the movement has produced its surprising success stories, but nearly all has been written from the pure Open Source perspective.  The different circumstances facing the enterprise require different thinking.

To Have a Community, Start With Community

A particular kind of community spirit is essential to the Open Source way of work.  It is even more critical to the inner-source way.  Some Open Source techniques need only to be adopted by the inner-sourcing community; some must actually be avoided; but this one needs to be fed, nurtured, watered, encouraged, and promoted.  Open Source communities live or die by their consensus, and they work at it.  Inner source needs to create a consenting community not only for the reasons Open Source does, but also to compensate for some of the unavoidable weaknesses of the enterprise system itself: less personally committed participants, higher schedule pressure, and creativity-killing directive authority.  I’ll be exploring these techniques further in upcoming posts.

Community Does Matter

In a classic series of papers collected as The Cathedral and The Bazaar, Eric Raymond analyzes what makes an open-source contributor contribute.  A focal idea, touched in several of the essays, is the remarkable way in which Open Source development has avoided a trap known as The Tragedy of the Commons (usually identified with a 1968 essay by Garrett Hardin): when a group of people hold a resource in common, individual best interests tend toward over-consumption; eventual exhaustion or destruction of the common resource seems inevitable.  This dynamic is quite familiar in corporate circumstances: individual departments or teams often maximize their own interests at the expense of the good of the company as a whole.  But it is startlingly absent from Open Source communities.

Raymond’s explanation concentrates on personal motivations, such as prestige, pride of workmanship, and the famous "scratching your own itch," and has been called a Manifesto of the Open Source movement.  But Raymond dismisses out of hand any ideas of altruism, community participation, or the common good, and in this he misses a key factor in successful OS projects, a key lack in unsuccessful ones, and a consideration peculiarly essential to any enterprise attempting to copy the successes and avoid the failures.

Conscious Community

In fact, the OS movement in general, and the flagship successes in particular, have always been very careful to engender and encourage the sense of community: communal directions, communal work, communal support, and communal success.  Contrary to Raymond’s contention, the "common" of open source exists: it is the good will of the community. And it is very fragile, very susceptible to the kind of over-exploitation Hardin predicts, through such dangers as divergent implementations, disruptive participants, and careless work.  Open Source dialog is rich with slogans that maintain the common: "There’s no ‘you and us,’ there’s only ‘us’."  "Give something back."  Even the most negative remarks tend to be framed in (pointedly ironic) communitarian language: "patches welcome! (you crazy dreamer)".

What is special about successful Open Source communities is that they have found a way to protect the common.  How do they do this? By encouraging community: altruism, agreement, "the good of the many," and contribution as the greatest good.  An Open Source or Inner Source community is much more than a collection of individuals, or individuals working on the same project, or a project team: it is individuals who work constantly and primarily to become like-minded, to want the same thing. In this way, the common resource is not merely protected, but strengthened.

Tagged with: , , ,
Posted in Subversion
6 comments on “Redeeming the Commons
  1. Bil says:

    Excellent. The difficulty – perhaps as it has always been – seems to be in getting everyone in the community (inner- or open-) to drink the cool aid. That is, feel attached to those things that you are pointing out are important to the community and stop thinking “them and us.”
    How *is* that accomplished? Is it the constant encouragement you alluded to when you talked about the fact that the OS movement was always careful to engender and encourage? Is it a need for cheer leaders … and beer … free beer (sorry couldn’t resist)?
    Or do you just pick people who are only inclined to be on board already. But if that is the case then how does that work in enterprise where you inherently hire people who might not be as “on board” as others.
    Awesome post about an awesome way to do enterprise!

  2. I’ve got quite a stream of posts planned on how to do this, so I won’t go into too much detail here, but yeah, all of that stuff! Most importantly, there seem to be some particularly potent techniques, which is what I’ll try to focus on. For the moment, I can refer you to Karl Fogel’s splendid book, Producing Open Source Software (available under an “open copyright” at

  3. Lois Shawver says:

    Jack, I like your topic: How does the bond of open source communities develop and what aids or diminish it? People sometimes get along in daily life by censoring their disagreeing words, but I believe Open Source communities need something more than this old trick. I argue that open source communities who agree need to listen well to and those who disagree, and then, when common opinion overrules the disagreeing force, the community needs to appreciate the disagreeing voice for it’s willingness to yield to the common good.
    All of this might be easier if there was more recognition that “agreement” and “disagreement” are not so much of a binary as our culture pretends. “agreement / disagreement” is probably better seen as a kind of continuum and often woven with some degree of uncertainty. If one recognizes the continuum, then it is easier not to become polarized in a militant, frustrated “disagreement”.
    I should add that my programming skills are limited. I’m a psychologist and author (see Nostalgic Postmodernism on Amazon, for example – my name is all over the web). I believe open source is leading the way to a social revolution, and I intend to be in the background applauding as you continue to succeed. So, best wishes to all of you revolutionaries. May your force live on forever.
    ..Lois Shawver

  4. Hey, great thoughts, Lois, thanks!
    The topic of “agreement, disagreement, and something else” is also in my plan. I think your “continuum” slant is an improvement, but still a bit limiting. In the Open Source community, it’s not only that we may “agree mostly” or “disagree on a few points,” but we also experiment in disagreement in order to try out the ideas, we synthesize polar points to lead the discussion into a completely different direction, and (what turns out to be remarkably important in Open Source discourse) we use technical debate to establish personal credibility. All of these widen the field far beyond any particular point under debate, and these extensions weave the discourse, design, and community together, and form the “meritocracy” by which an Open Source community assigns leadership.

  5. Lois Shawver says:

    Well put, Jack, and thanks for your response.
    Jean-Francois Lyotard, the postmodern philosopher, would have called it “paralogy” – a kind of conversation that is more experimental and inventive than strictly logical deduction. Logical deduction does not work well when the aim is creativity, or when we think in terms of continuums, or of splitting off into different directions, widening (or narrowing) the field of collaborative reflection, and weaving new inventive discourse, or building off of each others ideas, letting things evolve without being too certain about our initial notions.
    ..Lois Shawver

  6. “Paralogy,” eh? My cool new word for the day!
    In the Open Source, we call it “a bikeshed” (

Leave a Reply

Your email address will not be published. Required fields are marked *