Redeeming the Commons

June 6, 2008 Jack Repenning

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.

Previous Article
Putting Task Estimates in their Place

Let’s look at how a team makes use of task estimates. During Sprint Planning, teams create tasks and task e...

Next Article
Reasons to Disable Your Tool’s Estimates vs. Actuals, Ideal Line, and Individual Burndown Charts

Organizations that are looking for an automated tool to help manage Scrum fall along a continuum. At one en...