Git Virtue?: Github and Commons-based Peer Production

On: November 1, 2009
Print Friendly, PDF & Email
About John Haltiwanger
An underliner. An intensifier. A meanderer. A walker in betweens. The gross product of the souls of forebears sliced into ribbons and blown into a clay him. A poetic impulse. An open source advocate. A master of ceremonies. A writer of codes. An interface fiend philandering among operating sytems. Creative nonfiction research artist. Textual mystic. Frequently explicit Function 'popular education' enumerated 03.03-12.6 TESC (Evergreen) WA NW US. Political economics, systems administration, cultural studies, writing, ethnomusicology, computer programming, web design, etc. All part of a balanced liberal arts degree. Socialist high school founded by feminists with a farm (Putney) 01-02 VT NE US. Deserter of West Chester PA. 16 year old proto Perl monger. 26 year old Ruby excavator. New new media student, old new media sponge. Mondo minded year 2000 Millenial Generation American. Of a rare form. Eagerly chewing electronic book reviews, ctheories, and autonomedias independent of any formal Media scholastics. Before the field had a name in my mind. Chasing a thing called 'software studies' through the tubes, across the Atlantic, and into a Nederlands classroom. Playfully aware that this bio, like the medium it exists in, like the life it describes, remains malleable. Yet static in its own right.


Github, online beginning in 2008, has quickly changed the face of source code hosting. Called “social coding” by participants and commentators alike, the site has propelled the adoption of distributed version control systems (DVCS) in general, and git in particular. One of the key features of DVCS is the way in which all individual nodes in a network of source code are equivalent (leading some to wish a more descriptive name had been chosen for this new system, such as “federated” or “peer-to-peer.”) The switch from centralized to distributed version control represents a sea change in the organization of source code online.


Since a picture is worth a thousand words, perhaps a few visuals are in order (I hope Kalid Azad doesn’t mind me borrowing his vizporn here):

Centralized Version Control

Centralized Version Control

Centralized Version Control

Distributed Version Control

Distributed Version Control

Distributed Version Control

While code in the centralized example requires an iterative (one step at a time) methodology, code in the distributed example can be undergoing many changes at once in a diverse range of locations. Certain limitations of truly centralized version control, such as allowing only one person to edit a given file in the source code tree at a given time, had already been overcome years ago. The prime differentiation between distributed and non-distributed version control in modern times is the primacy of a given repository (a folder of code that keeps track of changes)–in DVCS every repository is equivalent in importance, whereas previously “true authority” resided with a single repository through which all changes to the code were coordinated. In DVCS, repositorial authority is a social function rather than a technical distinction.

To introduce an analogy, traditional version control systems implemented the equivalent of a central government, with a capitol repository through which all operations are coordinated. Distributed version control, on the other hand, implements anarchy. And does it well.

Github the Virtuous?

In 2006 The Journal of Political Philosophy published a paper by Yochai Benkler and Helen Nissenbaum titled “Commons-based Peer Production & Virtue.” Stepping back from the kind of economic analysis he usually engages in, Benkler collaborated with Nissenbaum to construct a moral argument for “commons-based peer production” (which is a form of the broader concept of “social production” which he describes at length in his book The Wealth of Networks, available for free online). Noting examples such as SETI@home, Slashdot, Wikipedia, and the Open Directory Project, the authors acknowledge that free/open source software (FOSS) is the most pervasive and successful example of commons-based peer production in today.

Acknowledging that virtue is a sticky philosophical subject, Benkler and Nissenbaum take a very broad, zoomed out look by assembling what they consider “clusters” of virtuous impulses. The first cluster includes autonomy, independence, and liberation. The second cluster contains creativity, productivity, and industry, while the third and fourth are composed of benevolence, charity, generosity, and altruism, and sociability, camaraderie, friendship, cooperation, and civic virtue. All of these characteristics are in some way stimulated by, as well as driving forces behind, commons-based peer production. Furthermore, Benkler and Nissenbaum argue that, by its virtuous nature, commons-based peer production may very well encourage the development of virtue. They cite thinkers such as Winner, McLuhan, and others who have noted the shaping of the social by technology.

For the philosophers and social scientists who study technology, this metaphor draws attention to a world in which we are constrained not only through the narratives and expectations of the self and other social agents and institutions, but by the material world which is constituted in increasing measure by technology. (416)

It is clear to me that this is directly borne out by the continuing expansion of FOSS principles and practices throughout the software industry. Hardware is also increasingly open source as well. Considering the explosive growth of Github, which is now home to many high profile OSS projects whether those projects have consciously moved there or not, can it be said that Github is virtuous software?

Since the distributed/federated/anarchic nature of git clearly enables new opportunities for virtuous action through its emphasis on autonomous repositories, perhaps an instance of the phenomena the authors intend to evoke with their statement “[Commons-based peer production] does not bypass virtuous action, but generates new opportunities for it.” (418) It’s virtue emerges through the distributed activities of its developers. Since no one is in true control, the overall form of the code is shaped by individual decisions regarding quality and appropriateness of contributions. Something you perhaps find appropriate for your repository may invoke `git blame` in others’.

The software further induces virtue in its participants through the `git blame` function, which immediately calls up the person responsible for a commit. In practice it used as much to know who to praise as it is to know who to berate, but it fulfills one of the the paper’s common criteria for extant commons-based peer production: that of a mechanism to mitigate the potential impacts of malicious users. Slashdot has its moderation system, Wikipedia its editors, and git has `blame`. In fact this functionality is a crucial part of what enables the ‘virtue spreading virtue’ element of such peer production.

Since Github automatically inherits all the virtue of git, in a sense my question has already been answered. But because Github is also a free service for those who wish to engage in commons-based peer production (and one that doesn’t involve ads, I would add) that makes git hosting “no longer a pain in the ass” (their marketing slogan at launch), they too encourage virtue to spread. It costs money to host your code privately, and thus withhold the source.

As institutions in the past could be considered to spread virtue, is it possible that today software could do the same? To further Benkler and Nissenbaum’s argument, I’d argue that not just the process of commons-based peer production (as they say), but the very outputs of that process in the form of free software are engines of virtue. In the case of git and Github we are faced with ‘recursive enablers’, free software (completely in git’s case, and totally dependent on in the case of Github) that quite directly enables and encourages the spread of further free software.

The question of morality in software is not generally addressed, so Benkler and Nissenbaum’s contribution is a welcome one. All too infrequently do we see moral cases presented before us these days. As such, I would like to leave you with the motivating thrust behind their paper:

Unlike many political analyses of technologies, ours does not warn of a direct threat or harm. Rather, it warns of a threat of omission. We might miss the chance to benefit from a distinctive socio-technical system that promotes not only cultural and intellectual production but constitutes a venue for human character development. (417)


Additional Resources:

Comments are closed.