Sufaces, Standards, Layers, Stacks: Toward a Platform Textuality

Kyle Bickoff, Setsuko Yokoyama, and I reunited for a roundtable at the Society for Textual Scholarship’s 2017 conference on “Textual Embodiment” at the Maryland Institute for Technology in the Humanities. Our roundtable was a loosely structured public conversation on Benjamin Bratton’s The Stack (2015) and the idea of “platform textuality.” We each prepared some remarks to lead into conversation, and below are mine—on GitHub as a platform and Paul Ford’s “What is Code?”

Familiar Strangenesses

We can begin by affirming aloud, as we are increasingly called upon to do, the familiar strangenesses of the present. By “familiar strangenesses,” I suppose I am invoking Viktor Shklovsky’s classic idea of ostranenie, “enstrangement,” or “defamiliarization.” Shklovsky wrote on art in a time where art was a tool of revolutionary political potential. Perhaps these days we do not need art to enstrange reality as much, as reality rises to meet us each day with fresh strangenesses.

I also mean to point to the temporality of our familiar strangeness, the tension through which we are all navigating constantly between the ways that our world is changing rapidly in these first decades of our century, counterbalanced against how these changes seem to look increasingly inward and backward. Or that they overthrow any imaginary of historical teleology, as we see baffling new configurations of online communities, multi-state covert hackings, and the weaponization of information in startling and unsettling ways all marshalled towards fundamentally reactionary revanchism: a relitigation of familiar sexisms, racisms, and fascisms. To quote Benjamin Bratton’s The Stack, we might see the technologies of our present-future, which we might think as ones of globalization, as “both destabilizing and enforcing borders, tethering retronationalisms and technological integration into the same contradictory dramas, populated by state and nonstate actors, czarists and androids, switching sides without moving an inch.” 1 This is perhaps the most trenchant takeaway, for me, from Bratton’s geopolitical model: that as borders grow more porous and fungible, we see a whiplash return to invoking the physical referentiality of those very borders, particularly in technical realms.

So I’ll be real, I felt uneasy opening this talk with Bratton’s geopolitics because I’m actually going to spend the rest of my time talking about a magazine article and GitHub and people complaining on the Internet. The scales don’t feel quite commensurate. But I suppose I justified this opening to myself in that we can argue that much of the strangeness of our present moment gets played out in textual fields, particularly those of code.

The June 11th, 2015 edition of Bloomberg Businessweek was a single magazine-length article by author and programmer Paul Ford called “What is Code?” I have a feeling many of us read it, if only to find out, once and for all, what code is. The article made a huge splash on Twitter not only for its lucid writing but also its innovative digital format. The text of “What is Code?” is a length exegesis of 1) what software is, materially; 2) what cultures of software production have been and have become; and 3) how software gets produced in the contemporary corporation. Ford’s writing is remarkable because it’s accessible to the technologist, humanist, and entrepreneur all at the same time—or perhaps reveals how all these roles get collapsed together in our present moment. From the technical side, “What is Code?” shares more than a passing similarity to a piece like the New York Times’ 2012 “Snow Fall” article, which similarly makes an implicit argument for journalism as interactive, digital-first, and media-rich. Its web page isn’t just full of image and video, but features an MS Word Clippy-style avatar guiding you through the piece, interactive coding exercises, a word tracker to tell you how fast or slow you read, and even a webcam integration that produces an ID card for you at the piece’s end. Like “Snowfall,” “What is Code?” argues that journalism is no longer broadsheets and newsprint, but a specifically interactive enterprise. The piece won many awards, and a year after it was pubished, Michael Bloomberg fired Joshua Topolsky, Businessweek’s then editor-in-chief, because that’s just the kind of world we live in now. “Familiar strangenesses.”

“What is Code?” lives two clear textual lives: on the page and on the screen. However, it also foregrounds a third life, one usually hidden away from the reader but that exists, as we know, for every article we read online and indeed for even any book that we pick up: as objects of code itself. Specifically, as a repository, a collection of various files, on the popular software version control site GitHub. I’m going to use this third life of “What is Code?” as an occasion to explore GitHub as a collaborative textual platform. I use Bratton as a suggestive analytic not only for what this document might suggest about geopolitics (I know, light lift) but mostly for thinking through how GitHub positions texts and how it encourages its users to produce and consume texts. These textual practices, I suggest, are familiarly strange in some of the same ways as Bratton’s geopolitics: boundaries made porous and multiform but that end up intensifying and repeating familiar terrain.

GitHub is a dizzying platform, technically, socially, and aesthetically. I anticipate that we have a range of familiarities with it in the room, so rather than take up a chunk of time with a full account of its history, I want to focus on what it does as a platform. By “platform,” I follow Bratton’s definition, more or less commensurate with Ian Bogost’s and Nick Montfort’s definition in their “platform studies” book series for MIT Press, as a technical architecture or infrastructure that mediates and stages different kinds of technologized actions—though actions that may work hard to subsume their own technicity.

So GitHub promises to do quite a bit. In “What is Code?”, Ford writes a paean to the platform that goes like this:

What if I told you that you could have a record of every change made to the many, many documents that go into your codebase and a record of who made them, up to the minute, a permanent record and every change could be reviewed by anyone, in a totally transparent way . . . and everyone can have the history of every change ever made to the code . . . and it’s all completely totally free to download and is the default way of distributing source code throughout the world!

So let’s break this promise down. GitHub is a website built by a California start-up. Like many start-ups, it hasn’t invented anything, but rather streamlined and made accessible a concept that’s existed for a very long time, even beyond software: version control.

We all practice version control in some capacity. Whether we write longhand or into word processors, we have some private practice of naming and saving files or drafts.

As you might expect or know from personal experience, version control is a particularly salient anxiety for writing software, given the extraordinarily labyrinthine nature of many codebases and the sheer number of developers who might contribute to a project over time. So there have been a number of tertiary pieces of software built to manage to work of version control, from the Source Code Control System baked into UNIX back in 1972 through to git, built by Linus Torvalds in 2005 and now the closest thing we might have to an “industry standard.”

Git, as you’ve no doubt gathered, undergirds GitHub. What lets GitHub exist in the first place is the distributed model with which git keeps track of changes in a document. Git keeps a master copy stored up on a server, though it could be stored anywhere. Contributors download a copy to of that master repository to their local machines, make changes locally, and then when they’re ready “push” changes up to the server, where they can be reviewed and integrated by whoever controls the project.

So here’s the “What is Code?” repo. Since its publication, or at least since the repo was first put up on GitHub, there have been 629 commits, or changes, from 29 contributors, although the number of folks who have proposed various changes in the “Issues” tab is a bit higher. It bakes in a number of social and chat applications, which is one reason why it’s so useful for collaborative development and has also become a kind of tech support platform for open source software.

A quick demo: if I click here on the “index.html” file, I see the source HTML for “What is Code?” and can track all changes made to it since its initial publication.

The index.html file.

We can see that GitHub fulfills a certain Borgesian dream of textuality: endlessly addressable, endlessly remembered, easily navigable and infinitely dense.2 These promises are what Bratton characterizes as the “added value” of platforms, in that the networking operations of platforms “absorb and train information, making it more visible, more structured, and more extensible for the individual User or in relation to other Users who make further use of it.”3 This value-added work undergirds what Bratton calls “platform sovereignties,” or the ways that we as Users get trapped within these fundamentally useful operations such that platforms begin to produce and structure governance.

And indeed, for GitHub’s dream to be realizable for you, the platform needs to train you into a kind of material, rhetorical, and methodological compliance. For example, you’ll see that all of the files in this repo are in formats discrete and legible on a line-by-line basis—they’re “plain text.” A Microsoft Word file, for instance, isn’t legible to this platform because it’s a binary file—an enclosed package of custom XML that’s not immediately parsable in the way a .txt file is. This echoes out to the kind of platforms that one can then use to craft texts—a WYSIWG word processor is going to find hard purchase in the git ecosystem.

On the level of praxis, git’s not constantly writing changes into a database the way that, say, Track Changes in Word is. Git’s not watching all the time as a daemon program, but rather has to get invoked by you the user at regular intervals and at a sufficiently granular level as to then be useful to you, the user, or your collaborators later down the road. If you don’t train yourself into a useful personal rhythm, GitHub can’t add value. Finally, while we can see utility for this platform beyond software development—indeed, one of the use cases GitHub wants to sell itself on is for creative writing more generally—such users have to take on the cultural paratexts and languages of software development. So this is the strange tension we might see in the “issues” forum for “What is Code?”

If we look at current open issues, a number of these are technical in nature. We see debates over whether or not the article should call for webcam access, and how to properly ensure saving to Instapaper. But there are lots of issues tagged “text,” which are actually essentially issues of literary criticism. And they’re a little strange.

So in highlighting these threads, I’m not trying to poke fun at these users or make a claim that literary criticism, even in rudimentary forms, is inappropriate to the GitHub ecosystem. I mean, maybe it is a little bit, but I want to have an open mind about the possibility for GitHub as a kind of space for productive amateur critique. This is a kind of public critique made possible by the GitHub platform—in its line-by-line granularity it bears a passing resemblance to something like the CommentPress platform that’s been used in open peer review for publications like Kathleen Fitzpatrick’s Planned Obsolescence book the Debates in the Digital Humanities series. But these critiques, I suggest, are distinctly operationalized. It becomes difficult to thread together multiple moments in the article, or to talk about effects that aren’t articulable as emerging from a particular line of code. Indeed, such a relation is baked into the git software itself—there’s even a function called “git blame” that does precisely what it sounds like, indexing a change to a particular user for later review. GitHub demands total transparency and accountability: indeed, asks you to reproduce such transparencies and accountabilities in your own writing and committing practice, without which the platform cannot train your “data” or actions, into an interface that’s then legible and “useful” to you and others. This is precisely the power of GitHub as a platform: how it intensifies and operationalizes some of the otherwise fuzzy and blurry features of textuality, such as, in this moment, literary critique.

Briefly visualizing the work on the "What is Code?" repo with gource.

I want to close briefly by returning back to Bratton and the more heady geopolitics that opened this talk. I’m not going to stick this landing, and indeed I’m less interested in doing so and more in opening up space in which we can speculate collectively on these textualities and the work of platforms in guiding and training how we produce and respond to texts. I’ve actually been trying to do all of my formal writing this semester in GitHub, as a kind of practical training for this talk. It’s a hard practice. It takes a lot of effort to remember the contours of “plain text” markup and to stay in the rhythm of commits. I have become very aware of how the platform incorporates me and my practices into and as technical objects: I am a User, me, my body, my fingers and a User-function, a collection of traces in a system indexed to but not precisely bound to my body. Given that this talk is at the very end of the conference I want to try a grand circle of sorts, and also return the citation karma: I’m struck for how the social aspects of GitHub as a platform infect and reverberate into the version control in ways similar to how Marisa Parham limned for us in her opening keynote. GitHub becomes, like any online platform, a negotiation between the thing I am and the thing I imagine myself to be, even as that imagination is the sub- or unconscious aggregation of thousands of tiny, self-imposed, self-trained, self-made-useful-to-myself textual actions. In this sense, perhaps Bratton’s theory is most useful in characterizing particular techniques through which systems incorporate selves into them: ideology for the machine age.

  1. Bratton, Benjamin. The Stack: On Software and Sovereignty. MIT P, 2015, pp. 23 

  2. I get the Borges frame from Matthew Kirschenbaum, cite your mentors. 

  3. Bratton, 48. 

revision history for this page