Chapter Three
Big Diff, Granularity, Incoherence, and Production in the
Github Software Repository
Matthew Fuller, Andrew Goffey, Adrian Mackenzie, Richard
Mills, and Stuart Sharples
This chapter will discuss the way in which Github, one of the largest dynamic repositories of software online, can be seen to operate as a mode of
archive which in turn re-engineers the question of what an archive is. In
very simple terms, Github is a place where software is stored online and
from which it can often be downloaded. More expansively, it provides a
sense of the archive as simultaneously a site of fine-grained analysis and
of incoherence, of storage and of production. To get to Github, we need to
start with Git, a ‘source code management’ (SCM) system designed by Linus
Torvalds in 2005.1 Git was initially based on the characteristics of a file
storage system familiar to its author as the initiator of the Linux aspect of
the GNU/Linux operating system.2 Whilst it claims to be ‘a stupid content
tracker’,3 in practice Git is a highly sophisticated, decentralized, and distributed way of writing code in groups on scales ranging from an individual to
that of large organizations. Git encourages branching or multiple versions
of the same project at the same time and provides many different ways of
merging, tracking, duplicating, and integrating code repositories distributed
across many developers. It facilitates and encourages copies and variations
as well as the tracking and auditing of changes in almost any kind of digital
data. Since 2007, Github.com – a separate organization – has served as a
largely public host platform for Git repositories or ‘repos’. It has encouraged
software developers and programmers to store, work on, and retrieve the
source code and texts associated with software projects on many scales,
again ranging from individuals to large organizations. It has augmented
the many operations afforded by Git with ‘social coding’ affordances such
as ‘starring’, ‘watching’, the distinctive ‘pull-request’ mechanism, various
more formal organizational arrangements (teams, organizations, etc.), and
visual descriptive devices (graphs in particular). Github has grown rapidly
since 2007 to become perhaps the most important online code repository of
the moment, hosting around 10 million projects in total with several million
people contributing to them, albeit with widely varying levels of activity.
We might understand Github as the formal enterprise that organizes – and
88 FULLER, GOFFEY, MACKENZIE, MILLS, AND SHARPLES
somewhat ironically, centralizes – the informal de-centralized organization
of Git. Github itself publishes much data about the growth of repos. The
public legibility of platform dynamics is typical of contemporary softwaremediated culture: things are made to be readable by many. Github.com also
produces and encourages the production of various forms of visualization
and tabulation of what goes on there. To illustrate this legibility, we could
choose important or famous repositories on Github – the Linux kernel, for
instance, still led by Linus Torvalds, is a much-vaunted FLOSS project that
has become economically and technically central to the development of
the Internet – and analyze the flows of meaning, texts, and readers/writers
connected to that repository. 4 Relatively quickly, individual contributions
could be analyzed, and we could begin to characterize the composition
of the group of people who keep this important software object working
and up to date. But this work is largely already done by Github.com itself.5
Indeed, the site is characterized by a high degree of granularity of the data
it holds. This is understood to mean the availability of multiple kinds of
highly detailed, and to some degree tractable, information of the processes,
material, and actors it gathers. Since Github is notable for the ‘socialization’
of software production, in which the above-mentioned social media forms
are built into the archive, there is, in turn, a deep integration of quantification into the working processes of the archive.
Coding processes and architectures
The development of software has entailed a history of self-reflection of
certain kinds. The discourse and practices of software engineering, for
instance, were born of a need to intensify the quality and standardization
of code, in turn stabilizing factors such as the culture of engineering and
desirable qualities of personnel.6 Here, we should also note the strong differentiation between the engineering and software development approaches
and the concomitant differences between hackers and engineers that run
through them. Software engineering historically relies on the standardization and systematization of work in relation to large-scale projects. Hacking,
by contrast, emphasizes informality and virtuosity.
Faced with the explosion of programming and the applications in which
it is being deployed, computing has also developed numerous techniques
of management or methodology, modularity and re-usability, to stabilize
the nature of work and to make it more amenable to enjoyment or at least
to management. Programming methodologies develop out of various
Chapter Three
89
formulations such as the need to co-ordinate across often increasingly largescale projects or, conversely, the need to develop project requirements as
the system develops. Echoing such imperatives, examples such as Waterfall
(a software development model predicated upon strict division of stages)
involve an ordering and hierarchy of projects and products; conversely,
Agile methodology is a mode of close collaboration between coders and
clients, emphasizing the quality of working life, fast iteration of code, and
tight participation of the user. Alongside these organizational systematizations, programmers rework, add to, and link pieces of code. This may seem
an obvious statement, but the process also implies the development of
languages, programming environments such as IDEs (Integrated Development Environments) or the text editors (such as VIM or Atom) in which
programmers work as well as the use of systems of pre-written software
at different scales such as frameworks, classes, libraries, and objects. In
parallel, and in the wider contexts of digital work, new conditions for the
storage and management of files are generated. Music and architecture are
related areas that generate thousands of memory-intensive files and variations on those files, implying archival necessities such as version control.
In turn, the question of what constitutes a file is reconfigured: objects are
now increasingly understood as a particular state space within a matrix of
variable data, structured and inflected in turn by the specific qualities of
the kind of media that is being worked – as in the difference between a text
file and an architectural drawing, or a layer in an animation file. To a certain
extent, these version control systems can be seen as part of the general
modularity of work in the gloriously undulating fields of the contemporary
Bürolandschaft, echoing or reciprocating the modularity of paradigmatic
computing systems such as Unix.7 Part of the condition of such systems is
a general move towards a relatively high degree of granularity of objects
and, concomitantly, of the modes of analysis and use to which they may be
put, something in turn effecting the nature of their condition as archive
and as engines of production. We will explain this further below. Within
the specific domain of FLOSS (Free, Libre, and Open Source Software) code
repositories, what is particularly interesting is that they fuse thedistribution,
production, and consumption8 or use of software into the same architecture.
They constitute part of the establishment of a code commons that involves
some of the means of negotiating over and managing disagreements, and
they also provide the means of generating what we propose, following recent
work in biology, to call metacommunities: sparsely or thickly connected
populations of objects, users, producers. However, in distinction to the
biological or ecological use of the term, calling these systems ‘meta’ means
90 FULLER, GOFFEY, MACKENZIE, MILLS, AND SHARPLES
that they also partially draw up the matrix of possible operations that may
constitute communities. Here, the software that encodes such operations
is of crucial interest. FLOSS code repositories include GoogleCode, SourceForge, Savannah, Code Snippets, and Tigris.9 Some of these repositories
support multiple version control systems. Savannah, for instance, supports
CVS (Concurrent Versions System), Subversion, Git, Mercurial, and Bazaar,
though many if not most projects use CVS.10 Some of these systems will
be used in parallel, with code being developed on Git, and stable versions
of a programme being made available by multiple sources. Equally, an
organization may often make use of a public facing repository and have
one or more private ones in which the daily work is done. Github, as a
company, makes much of its money from providing the latter service on a
commercial basis. There are also many smaller, project-specific repositories
such as Rastasoft, CPAN (Comprehensive Perl Archive Network), or Python.
org that provide the output of a specific group of programmers or, more
expansively, the basic materials to work with a particular language. There
are also sites that are not repositories but that act as directories of projects.
What is crucial here is the question of version control. An example of simple
version control for non-software use would be the wiki software that was
originally developed for project documentation and collaboration around
Agile software development and that now forms the basis for systems such
as Wikipedia.11 Version control allows users of a system to develop more
than one version of a project, to have many people working on elements
of a project simultaneously without overwriting each others’ work, and to
archive and make available completed or ongoing versions of a project as
they develop. Code repositories act as part of the mix of systems used in
software development such as the bug trackers, mailing lists, IRC channels,
and messaging applications that particular metacomunities or teams might
work with in the development of a programme. These operate by means
of creating lists of work to do or by allowing fast means of communication
that can be both synchronous and asynchronous. On another scale, code
repos can be seen in relation to discussion forums such as Stack Overflow,
privately owned operations that in turn sometimes shape and cull conversations according to commercial imperatives. With many FLOSS projects,
too, there is a merger between development and marketing, garnering new
users and developers that also constitutes the prospective shaping of a scene
around the platform and the various constituencies that use it.12 Equally,
these projects often rely upon a legal and discursive framing via the use
of free and open source software licenses. These are generally defined and
differentiated by the way in which they either attempt to perpetuate the
Chapter Three
91
software as a common good or as a resource free of the encumbrance of
obligation to others. As we will see below, this is also something subject
to change.
Anatomies of forks
One of the crucial aspects of Github’s architecture is that it also upends
what is called the ‘taboo of the fork’ in free or open source software. This
is the taboo against splitting or duplicating a project, an act that often
potentially breaks apart the community around the code. Git, the system
that Github relies on, inverts this established software community ethic by
making the fork its fundamental operation, something that in turn reframes
the debate around the archive as the focus of storage, conservation, and of
communities of research.13
FLOSS has developed numerous terms for working with software and
practices of copying and changing. Cloning a piece of software is to copy it
either at code level or at a higher level, for instance in terms of functionality
and interface.14 Branching is to make a variant version of an existing body of
code within a project, perhaps to create a prototype or for other purposes.
Derivations are improvements or variations on an existing programme that
differ whilst maintaining existing compatibilities. In this chapter, we are
specifically interested in the way that Git, and by extension Github, has
worked with the question of forking.
Forking is the practice of taking a body of code by making a copy of it
and revising that code. Someone who forks some code may do so in order to
improve it by making variations; to release a variant version of something
modified for a more specific purpose. The term fork has a variable genealogy
within computing. In the POSIX operating system, a fork is a process making
a copy of itself. A fork bomb is a work of hacker craftsmanship in which a
process is launched to make a copy of itself.15 As each subsequent process is
launched, a further copy is made. One of the characteristics of a fork bomb
is that it exponentially uses up the resources of memory of the computer.
Forking software, as a techno-social operation, is often regarded as having a
similar consequence: using up the attention and capacity of all the developers in a community. Unlike a fork bomb, however, such an operation cannot
be ameliorated by a simple reboot. In this sense, it has historically been a
powerful taboo, since it drains resources and creates a division in what is
called the community. For Benjamin Mako Hill, author of a thoughtful text
on forking in FLOSS development, prohibitions on forking operate as social
92 FULLER, GOFFEY, MACKENZIE, MILLS, AND SHARPLES
taboo with large costs.16 An alternate view, offered by artist and programmer Aymeric Mansoux, is that the inability to fully differentiate a project
on Github, a situation that arises with the inversion of the forking taboo,
leads to other kinds of problems: ‘Forking has become so cheap, merging
and collaborating became tedious and consensus is no longer such a loved
value.’17 The inversion of the taboo ‒ indeed automating it to the extent that
there is a button on the Github interface reading ‘Fork This Project’ – may
perhaps deserve a psychological reading which describes the trajectories
of communities founded upon a crime (as if they arise any other way).
Forking is often studied as part of the field of software engineering, where
it is generally analyzed as part of the problem of efficiency, communication,
and duplication. Research into the quality assurance of software also typically relates an analysis of forks to the motivation and career-mapping of
developers by marking their productivity and through various metrics. The
economic analysis of software development projects may also be carried out
in these terms. Quantitively based empirical research on these systems is
relatively intensive in terms of memory, computation, and network‒though
involving analytical abstractions as a methodological imperative‒has
historically tended to involve a close engagement with the problems of
network outages and variability in processing power.18
Generations of versions
Different version control systems articulate the problems of forking, branching, and cloning in different ways. Along with these variations, they generate
variant ideas of the habitus of the programmer or developer, what forms
the constitution or the pacing of a project, and what goes into the activity
of software development. In order to trace this, before returning to the
analysis of Github, we want to briefly describe the different generations of
version control systems and repositories.
The first generation of repositories is in many ways epitomized by CPAN,
which is simply an index-based directory of software written in the Perl
language, alongside software for working in Perl, that has been run since
1995. That it is a directory-based repository implies a high level of familiarity
or willingness to attain expertise and mastery as the basic condition of
programming. Software repositories of the first generation employ minimal
interpretative filters, leading to a certain charm if not always a ready intelligibility to the uninitiated. There is a clear distinction between what they
store and make available, the structure that indexes them, and the systems
Chapter Three
93
that are used to produce and work with the software. The second generation
of repos was set in motion by Sourceforge, a MySQL-based directory of
software projects that became a central resource for FLOSS activity at the
end of the twentieth century and after. This repo grew in the first wave of
massification and visibility of FLOSS as a social and economic movement
alongside the growth of discussion forums such as Slashdot, and is owned
by the same company. Sourceforge ties project documentation and release
notes into a download site but also brings in project rankings, user reviews
of software projects, and user profiles, where users could be viewed according to the languages they used, projects they are involved in, and the stream
of their activity. Alongside these, it brings in advertising for tech jobs and
other related information. Users also have straightforward permissions as
admin or developer as well as team co-ordination tools for concurrency
management (in wiki or source code management environments). More
recently, Sourceforge has incorporated Git, Mercurial, CVS, and Bazaar
as a range of systems that projects may use from its central site. Amongst
these, it also includes cross-platform compatibility – allowing projects
to migrate from one platform to another or to exist across platforms. As
such, Sourceforge now epitomizes both the second generation and the third
generation of repositories. This third generation are decentralized versioncontrol systems such as Git, Mercurial, or Bazaar. They are characterized
by their speed of operation; the fine granularity of analysis of code, of
use, and of users that they allow; and their distributed infrastructure. As
software author and developer Joel Spolsky notes, Github tends to follow the
requirements of freelancing FLOSS developers.19 A more corporate, in-house
version-control system would imply hierarchical levels of access governed
by permissions structures, code reviews rather than promiscuous copying,
and most likely a clear prohibition against the sharing of code. The data that
is captured, stored, and made addressable in certain ways implies a social,
cognitive, or processual order that can make use of it. Amongst others,
Philip Mirowski interprets neoliberal economics, particularly in the work
of Friedrich Hayek, as the dream or ruse of a perfect information machine.
There are certainly accounts of DVCS that have such an inflection, or they
make the explicit correlation to idealized markets.20 The wider question
of open data in government may be a parallel here. What is counted as
informative and what is not constitute some of the key functions of a social
order. Bureaucracy arises, in James Beniger’s terms, from the need to control
the vast amount of variables, information, and contingencies in running an
enterprise.21 What we see in some sense in the present wave of social media
is the adoption of bureaucratic forms in the management of friendship,
94 FULLER, GOFFEY, MACKENZIE, MILLS, AND SHARPLES
dating, music acquisition, and so on. These are all more ostensibly trivial
aspects of life when compared with the intercontinental import and export
of goods, the movement of armies, and the mass markets of consumers
implied by continuous production machines such as the conveyor belt. At
the same time, their incorporation into control systems changes the nature
of both in different, non-symmetrical ways.
Events in the API
As a typical social media platform, Github also publishes much data about
what happens on Github.com through its APIs (Application Programming
Interfaces), an interface to provide information about the database and
some of its contents to other software. The data provided by the API is
indeed mainly intended for software applications and web services built
around Github. But the combination of the Events API endpoint, the API
that supplies a more or less ‘live’ feed of events on the Github.com platform
(https://api.github.com/events), and the archived copies of events stored
since 2011 at the GithubArchive22 means that Github can in principle be
analyzed using what some currents in social science refer to as ‘live methods’
(research approaches based on the dynamics of experimental and collaborative events across a variety of media platforms).
The tools and devices for research craft are being extended by digital
culture in a hyper-connected world, affording new possibilities to reimagine observation and the generation of alternative forms of research
data. Part of the promise of live methods is the potential for simultaneity
in research and the possibility of re-ordering the relationship between
data gathering, analysis, and circulation.23 The scale of the platform (only
millions of participants, not hundreds of millions) and the existence of
archives mean that social researchers can envisage analyzing the whole
of Github, not just one month of data or a selected group. There are both
great potentials and difficulties in doing so. The fact that we have ready
access to the Github event timeline is testimony to this. But what is most
available from that data is a set of pre-formed 18 event types.24 These event
types subsume much of the traffic around Github but give us little way of
deciding what is an important event and how to elicit – from the hundreds of
millions of events in the event timeline – which ones matter and which ones
do not. At the same time, we know from ethnographic and other studies
of software that the very detailed and fine-grained tracking of work and
activity that is inherent to Git means that, in principle, repos and software
Chapter Three
95
projects themselves can be analyzed in great depth. Patterns of work, flows
of meaning, borrowing and imitation of constructs and practices, and shifts
in interest and importance should be publicly legible in the repos and,
importantly, in the flow of code between repos. But the possibilities of
perceiving these flows and patterns presuppose capacities to filter and
select events in the stream that neither confirm the unsurprising importance of certain high-profile software projects (Linux, Mozilla, node.js,
etc.) or overwhelm us with the buzz of transient or ephemeral repositories,
a discussion of which we will move to below after also noting some of the
other overall features of the system.
‘Post-FLOSS’ archiving and the archive as engine
So, broadly speaking, what patterns of archiving are there? Users use Github
in different ways: in a canonical open mode of use, making all code and
forks visible; performing merges and the evaluation of code offline, invisible
to others, but keeping what is published clean; and, in a related way, to
publish changes in private Gits. There are also multiple hacks of the system,
where a repo or a file might be named or entered on the fly by users that
then rename a file locally to work on and subsequently reload it without
reference to any broader project. Equally, the question of which pull, merge,
and commit has priority has to be resolved locally within the work group
or organization around the repo. This means that large aspects of even the
most well-organized repositories remain inscrutable.
Alongside the constraints on access to data via the API such as those mentioned above, Github works via the encouragement of contribution. Some of
this encouragement is achieved through an efficient and useful system – via
the extensive adoption of user experience design, contemporary ‘flat design’
style graphic design, and, of course, a cartoon mascot. Equally, the site
operates by numerous types of granularity of access to analytics. There are
numerous ‘social’ features such as letting you view the repos ‘people you
may know’ have starred, (with starring being a mechanism to ‘liking’ or
drawing attention to). Project sites include images, videos, comments, and
tags. Such features also extend to a greater metricization of programming
culture, allowing users to view the rate at which something is updated,
see the number of users following a project, peruse network diagrams of
branches of code, and so on. Here we have the archive also operating as a
matrix of capture and semiotization devices, driven by the imperatives to
rate, share, participate! As an economic factor, such hyperauditing devices
96 FULLER, GOFFEY, MACKENZIE, MILLS, AND SHARPLES
allow the site to become a means of finding and hiring programmers; Git
and Github profiles become key to coders’ CVs as a means of displaying the
productivity, uptake, and significance of the work produced. In this way, as
in others, the archive is a site of production, an engine for the development
of new software that involutes the sense of the archive as a repository of
the unchanging past. Storage becomes the site of production when the
form of production is variation. This is not necessarily an entirely easy
condition to navigate and one that in turn ties back to the question of the
fork. Github tends to encourage the possibility of multiple versions of the
same code being developed, often in parallel, which sometimes fails to
fully reap the benefits of coordinated action. For instance, in a blog post,
Ruby developer Seth B contends that in one version of some code he was
wanting to work with, there were seventy versions of the same piece of
code with incoherent information about which branch was in which state
of development, including information as to where, if at all, a particular
bug had been resolved. Github, one can thus say, is an environment for
making a workflow rather than something that imposes a workflow of a
certain kind. This implies that a project needs a certain kind of organization
or at least a means of flagging or archiving defunct branches, those with
‘dirty’ code, experimental branches used for fixing and testing certain
approaches, and so on. Discussions of Github online do tend to show the
vexed question of how exactly to organize a repo well. Addressing this, quite
a number of large-scale organizations with repositories maintain one that
is public, where users are able to retrieve the latest versions of code and in
general act as public-facing. They will also maintain another that is where
the actual development work is done. Concomitantly, our findings from
statistically analyzing the Github archive show that the largest repos come
accompanied by organizations, i.e. organizations organize Git. Git and other
such systems propose a set of abstractions of software development from
and in which projects may compose themselves. The speed and granularity
of changes is one of the ‘innovations’ of FLOSS. But within this is a variation
in styles: the imperative to ‘release early, release often’ promulgated years
ago by software polemicist Eric Raymond can be compared to the Debian
Linux distribution which characteristically takes two years for the gestation of each stable release. Alongside the kinds of software development
characteristic of the classical forms of FLOSS, we also see what can here be
termed as ‘post-FLOSS’ forms of development. Post-FLOSS is characterized
by a general indifference to the discussions of and loyalty to certain kinds
of licences and the sense of ethics (GPL) or business models (Open Source)
that these drew upon. Large amounts of the material placed online through
Chapter Three
97
Github tend to be without a licence assigned to it. This is not to say that some
people don’t use these licences or that the imaginary of software as culture
that they map has no traction. Rather, they seem to exist alongside an
expanded and incoherent universe of code objects, projects, and practices
that is somewhat different from the legendary world of the Unix greybeards,
whose insistence on crafted, knowable code with powerful and rigorously
applied abstractions and a matching ethos and legal apparatus has been so
fundamental to the development of the Internet and of free software. In the
majority of cases on Github, code is uploaded to the repository, perhaps to
be treated as public domain, or simply abandoned. What relationship this
has to the wider ethos of the system and whether it signifies a change in
the nature of programming work – showing it to be more or less precarious,
perhaps, or marking the ‘coming into public’ view of another kind of coding
practice ‒ is unverifiable. Post-FLOSS inhabits conditions in which code
objects, scripts, css, config files, etc. form so much a part of everyday generic
stuff and thus not worth protecting in the way that the adoption of a license
implies, even when that license is available as a drop-down menu.
Diff as infrastructure
Aside from the cluster of large-scale projects with their pattern of high levels
of activity around complex software objects and systems, much of what is
on Github tends to be of a much more diffuse kind, with high degrees of
variation concerning project size, type, and code, including the rapidity and
scale of variations. We can say that in just about every parameter where
variation is possible, it can be found. And here we note the source of Big Diff
as this chapter’s title. Diff is a Unix command that shows the differences
between files. Git is similarly based on a file structure that works on the
basis of marking the differences between objects stored in the repository.
A diff is based simply on a character-by-character analysis of a file. Every
change is logged and is retrievable by choosing the right commit.
Needless to say, this has interesting effects on the notion of the repository
as archive. Archives tend to work with exemplars, not variations. With Git,
as with all forms of computer memory that always involve making copies of
files, objects no longer need to exist uniquely; indeed, they cannot do so if
they are to be used within the system. The archive in this case comes into being as a process of structural differentiation rather than as a thing. Overall,
Git is a massive graph structure and each code object, each archived file is
a set of trajectories across this graph. Based on a file structure that amasses
98 FULLER, GOFFEY, MACKENZIE, MILLS, AND SHARPLES
hashes of symbols and diffs, the archive transitions into a systematization
of the archive as an engine of minutely and massively assembled processes
of addition and variation. Rather than the archive storing history as a set
of exemplary if not necessarily unique entities, history is involuted in the
archive rather than stored in it. With a system of versions at the core, versions
generate histories and versions become generative. Different kinds of repos,
such as public-facing repositories, working repos, and empty repos exist in
memory and perhaps in use alongside those that are set up as websites, code
deployment platforms, agile infrastructures, and mechanisms for publishing
and working on apps and frameworks for making them. This generativity is
not simply one of a ceaseless, vitalist overproduction. If we were to phrase
it in terms of evolutionary modelling and to draw the archive as a form of
fitness landscape, what we find is that there are millions of objects stuck in
basins of activity. The phase space of the graph is a constellation of numerous
entities, many of which are lonely asteroids drifting amongst thousands of
archives of abandoned space junk, themselves giants against the millions
of motes of dust that form their background.
Organising incoherence
One of the aspects of Github that echoes the problematic nature of much
social media is that within the system it is impossible to have a ‘delete’ event,
so once a file is on the system, there it stays. This is one factor that may lead
to an understanding of Github as in many ways positively incoherent. To
put this another way, any initial scan of the system as a whole will find a
power law distribution for the size of the projects. (Crudely put, most activity clusters around a small group of very large projects, with much of the
remainder of the work being in tens of thousands of smaller projects of sizes
decreasing in inverse proportion to their number.) Much of this is simply
because there are low barriers to entry – a repo is easy to start but harder
to maintain. Just as there are junk repos, uploaded only once, modified a
few times or less, and left to drift, there are others that continue to gain
occasional downloads years after posting. There is an enormously diverse
range of patterns of use. Alongside lots of very small but somehow long-lived
projects, there are people updating repos to check the differences between
pieces of code, bots making various attempts to push changes, and multiple
tools for managing and analyzing Git data potentially implying a form of
recursive public or a certain kind of narcissistic fiddling that is not without
its pleasures. Notably, many people use Github to circulate configuration
Chapter Three
99
files for text editors such as vim and for operating systems such as OSX.
Github is used as a platform for sharing machine configurations on a very
large scale, and such files are rarely worked on as a project. The transverse
movements of such files aren’t really captured by the mechanisms of distributed version control, since they are so ephemeral. Equally, some users
may also use Github as their mode of cloud back-up, with no contributions
sought from others – they simply use additional features such as bug tracker
and wiki as a means of interaction with users of their code. Here it’s worth
comparing this system to other code-sharing systems such as Pastebin,
where files are just left alone on the off chance that they might be used
or picked up by bots or onsite scripts scanning them for certain kinds of
data – credit card information, serials, website layouts, URLs, usernames
and passwords, scripts, my little pony porn, and so on. With Pastebin, the
‘drive-by commit’ is all there is; the system is simply used as a generalized
open notepad. Github is a far more variable and multi-dimensional field
of entities with high degrees of differential use and relation to the idea of a
project and, in turn, to the question of production and sharing.
As an archive, then, Github.com is exemplary in its crystallization of
certain aspects of contemporary software cultures. It is a zone of massive, concerted activity and simultaneously a ground for the dumping and
drifting of files characteristic of post-FLOSS; a space of atypical formations
disparately linked across directory structures and smeared unevenly across
timestamps and between users; a social factory of difference founded upon
the violation of a communitarian norm that it in turn also constitutes; and
a site of perpetual audit and production and an architecture for the free
form, the shapeless, and the corporate that is in turn perpetually being built
up for a hoped-for but deferred valuation on the stock market. As a site for
unearthing the finely grained ambivalence of the contemporary archive,
it is indeed something to keep tabs on.
Notes
1.
2.
3.
4.
5.
Git, online at http://Git-scm.com.
Git uses the MIT Licence, http://opensource.org/licenses/MIT.
Torvalds.
The Linux Kernel is archived at https://GithubGithubGithubGithub.com/
torvalds/linux.
One of the aspects of the discussion of archives in the era of open data
and of big data is the way in which the archive as a site for the exercise and
100 FULLER, GOFFEY, MACKENZIE, MILLS, AND SHARPLES
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
communication of expertise can sometimes be quite literally dumped—uploaded and then abandoned‒following the idea that unspecified emergent
forces will sort out the questions of legacy, interpretation, and preservation
that are characteristic of the archive as an institutional form. In relation to
this aspect of the debate, this chapter, like others in this book, suggests that
archival architectures find quite variegated forms and that the archive as
structured information, with attached practices of expertise, maintains the
condition of being a mutable field in contemporary software development.
Ensmenger.
Macpherson, ‘US Operating Systems at Mid-Century, the intertwining of
race and unix’.
For instance, in Github.io, which provides the conditions for software to run
directly from Github servers.
Alongside the FLOSS-oriented systems, there are tens of proprietary source
control management systems, and many IDEs include version-control facilities.
See Yuill.
Labouef and Cunningham.
For instance, the Mozilla Foundation’s regular Mozillafest.
In turn, there are a number of implementations of Git in several languages
and that also run on various platforms (Gitorious, Gitlab, Gitprep [a direct
clone of Github], etc).
The analysis of cloning here is often coded in relation to the question of
intellectual property, predicated on the idea that one body of code may
contain a direct copy of another.
See Cox.
Hill.
Mansoux.
Mockus.
Spolsky.
Mirowski. See also Mirowski’s acerbicly perceptive, if partial, comments on
Wikipedia in his postscript to Philip Mirowski and Deiter Plehwe’s The Road
from Mont Pelerin, the making of the neoliberal thought collective.
Beniger.
Githubarchive.org
Back and Puwar.
Constraints on access to data via the API also take other forms. Events support pagination; however, the per-page option is unsupported. The fixed
page size is 30 items. Fetching up to ten pages is supported, for a total of
300.
Chapter Three
101
Works cited
B., Seth. 2001. ‘Github, Your Network Graph Sucks!’ The Sublog, 30 August. http://subimage.com/
blog/2011/08/30/github-your-network-graph-sucks/#.VT5XiyHtmko.
Back, Les, and Nirmal Puwar. 2012. ‘A Manifesto for Live Methods: Provocations and Capacities.’
Sociological Review 60: 6-17.
Beniger, James R. 1986. The Control Revolution, Technical and Economic Origins of the Information
Society. Cambridge: Harvard University Press.
Cox, Geoff. 2012. Speaking Code, Coding as Aesthetic and Political Expression. Cambridge: MIT
Press.
Ensmenger, Nathan. 2010. The Computer Boys Take Over, Computers, Programmers and the Politics
of Technical Expertise. Cambridge: MIT Press.
Labouef, Bo, and Ward Cunningham. 2001. The Wiki Way, Quick Collaboration on the Web. Reading: Addison Wesley.
Macpherson, Tara. 2011. ‘US Operating Systems at Mid-Century: the Intertwining Of Race and
Unix.’ In Race After the Internet, eds. Lisa Nakamura and Peter Chow-White, 21-37. London:
Routledge.
Mako Hill, Benjamin. 2005. ‘To Fork Or Not To Fork.’ Lecture at Linuxtag 2005, Karlsruhe. Online
at: http://mako.cc/writing/to_fork_or_not_to_fork.html/
Mansoux, Aymeric. 2014. Fork Workers, presentation at Jonctions/Verbindingen festival, Brussels,
http://vj14.stdin.fr/Fork_Workers.xhtml.
Mirowski, Philip. 2002. Cyborg Dreams: How Economics Became a Cyborg Science. Cambridge:
Cambridge University Press.
—. and Deiter Plehwe. 2009. The Road from Mont Pelerin, the Making of the Neoliberal Thought
Collective. Cambridge: Harvard University Press.
Mockus, Audris. 2009. Amassing and Indexing a Large Sample of Version Control Systems: Towards
the Census of Public Source Code History. Mining Software Repositories. MSR ‘09. 6th IEEE
International Working Conference.
Spolsky, Joel. 2013. ‘Town Car Version Control.’ Joel on Software, 11 March. http://www.joelonsoftware.com/items/2013/03/11.html.
Torvalds, Linus. 2005. Git Manual Page. online at https://www.kernel.org/pub/software/scm/
Git/docs.
Yuill, Simon. 2008. ‘CVS.’ In Software Studies: A Lexicon, ed. Matthew Fuller, 64-69. Cambridge:
MIT Press.