How to Fork a Book: The Radical Transformation of Publishing
by Sarah Ciston and Mark C. Marino
In software development, particularly free and open source software programming, creators place versions of their programs in repositories where others can download, clone, and fork them. When someone forks a piece of software, they change it in some way, perhaps customizing it for their own needs, perhaps improving upon the original design by adding features. What would it mean to fork a book the way we fork software?
A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project. (Github Docs)
Collaborators Winnie Soon and Geoff Cox have invited just such forks in their new book Aesthetic Programming: A Handbook of Software Studies (Open Humanities Press 2021). Publishing their book to a public Git repository, they have encouraged others to make copies of the files and develop them further. Answering their call, we have made our own fork of their book, and in the spirit of open-source development we have written a new chapter and added additional features to the text. In doing so, we are participating in the development of their book and the evolution of the codex book itself from a static product into an ongoing, iterative, process.
The original Aesthetic Programming teaches not only how to program but also how to view code through a critical and creative humanities lens. Chapters are just as likely to draw upon terminology from computer science as from philosophy. The book covers essential basic code concepts (functions, loops) up to accessible introductions to advanced current topics (machine learning, big data). The book approaches programming artistically/aesthetically but also with criticality, not only what learners might make with code (besides the rote examples found in CS textbooks) but why it matters and how their choices are informed by the tools they use. Sections such as “start()” and “While()” relate aspects of the code under discussion to broader topics in techno-culture. In the book’s terms, their text shows the “more complex and deeply entangled set of relations between writing, coding and thinking.”
Our chapter, 8.5 Talking Back, is sandwiched between two existing chapters, like the 7 ½ floor in a Charlie Kaufman film or platform 9 ¾ in Harry Potter. It does not remedy a lack in the book, but adds its own insights, following the “yes-and” ethos of its collaborating first authors. This added chapter extends some of the book’s writing on APIs and conversational agents, focusing on software for automated dialogue. It talks back to the previous version by adding new content and by adding two new perspectives. It also discusses how critical and creative code can be used as tools to talk back to powerful systems and to reflect on or even shift their working assumptions.
Our chapter discusses programs that talk, specifically Joseph Weizenbaum’s ELIZA (also mentioned in the original text) and Sarah’s project, ladymouth, a bot which talks back to misogynists on Reddit forums.
For the most part, we followed the pattern of the other chapters when adding our new content, but we also created two additional sections: Code Confessions and Code Commentaries. Code Confessions are opportunities to further humanize the process of writing code by talking about our embodied, emotional encounters with the process of programming: How it felt to work on this code or to encounter the same issues readers might during their practice. Meanwhile, Code Commentaries are opportunities to pursue the methods of Critical Code Studies by interpreting the meaning of the code on the page, line by line.
Code Confessions:
In code confession, we model how we as programmers feel about our own code. Extending the concept of comments in code, we take the opportunity to discuss the affective relationship to the journey that is programming, admitting to mistakes and acknowledging fears. These sections personalize the approach and dismantle the authoritarian hierarchy or boundary between knowledge “holder” and knowledge “seeker.” This aspect was essential to emphasize the ways we learn in community, revealing that the teacher programmer didn’t always know what they’re doing and may still find their way with a beginner’s mindset. The code confessions sections are expressions of humility in an effort to further welcome the newcomer. They stand opposed to encoded chauvinism, or the toxic brogrammer culture that can be so off-putting to new programmers, especially those who come from outside the dominant culture. We love how they put it at p5.js: #noCodeSnobs
Code Commentaries:
Code Commentaries model the activity of reading the code critically — that is, both for its function and for its rhetorical choices. They offer insights and inferences into what the code author is doing line by line, reminding readers that code is not natural, neutral, or inevitable, for there are many ways to accomplish any task. The selection of any one method or the process of moving between methods, architectural choices, and other structures create are always meaningful. These sections also model understanding at another level how someone might begin to read code (itself a useful method for learning to write code). All of this goes toward what we hope digital literacies can and should look like, and we admire about Aesthetic Programming: its case for code that is not intimidating but engaging, practical and inspiring alike.
How is this different than merely reviewing a book?
Forking someone else’s book felt a little strange, like we were tampering with their soup or redecorating their apartment. Most academic responses happen outside of the text you are responding to, but we had pulled back the curtain, we were inside the walled garden.
So, we felt a bit of nervousness and at the same time the thrill of an audacious incursion. We were being bolder than we’d been taught to be. We were trespassing (even if invited trespassers) — as though someone had asked us to admire their new mural and then handed us cans of spray paint.
Making your own version of a text means you learn it on another level, like when you start to teach it, you’re asked to think about how you would rewrite it or say it differently. You’re asking yourself what you can contribute to this conversation, which for many of us is itself a radical act.
Revising a book in Git also means changes in how the book will circulate. First, as with versions of any file in a Git repository, we annotated our updates with comments, documenting our changes. So, there is a trail of the evolution of our book, just as there is for Soon and Cox’s edition. Also, now there is the opportunity for others to fork our version, as well as the possibility for the “original authors,” if such a title means anything in this Barthesian (or Barthian) fun-house, to pull our version back into theirs.
We could have just written a review of our response to the book, and in fact, Mark has. With a typical print book, a reader might be able to annotate their copy, leaving some marginalia (and there is a lovely print version of the original version which still allows this if that’s your style). But to engage with a book like Aesthetic Programming is also to treat it more like software, something to be developed, extended, revised, and reimagined. To engage with the text in this way it’s possible to merely to react to it or to learn from it by doing all the online exercises of its web version. But it is also uniquely possible to change what the book can do, to join in its becoming, to transform the book itself.
What does this mean for the future of publishing?
The concept of “the book” is evolving and has been evolving (see Jessica Pressman’s Bookishness for recent thoughts on this). This last bastion of completeness, the codex, the monograph, was now a never-finished never-product, an ongoing conversation each person makes their own. Perhaps it always was and these new formats allow us to see the interconnections more clearly. Mark had pursued similar continued interventions with his co-authors Pressman and Jeremy Douglass when they were working on Workbench, a fork of Scalar in which new scholars were invited to clone and extend existing books (see more on that in Reading Project). And Sarah has been researching the potential of new and existing platforms to reveal the porous layers of paratexts…basically since she started reading books and discovered the codex never quite cut it. (It’s why she learned to code!)
The monograph, even when co-authored, appears as a memorial — or perhaps tombstone — to individual scholarly achievement, and this project shatters that paradigm. A monograph edition has fixed page numbers, fixed content, and fixed attribution. It marks with hard lines the accomplishment of one set of authors who can take credit on their CVs, with a sprinkle of acknowledgements on an interior page. In contrast to this individualism, the (first) authors of Aesthetic Programming, Soon and Cox, cite Tiziana Terranova’s concept of “transindivuation,” ”the shift between the individual ‘I’ and the collective “We” and how they are transformed through one another thing.” “We hope,” they continue, ”something of this happens to this book project, which is already collective by design, but also opens up further possibilities for the production of new versions and social relations in its reworking.” Our addition and revision of the book (for we also audaciously added ourselves to the introduction!) takes part in this reworking of social relations around a liberated volume.
The open source software model of book circulation makes publishing truly multimodal, iterative, and conversational (and interactive in different ways with different kinds of book-objects). Rather than fixed one-to-many, unidirectional discourse that is static and authoritarian, this allows for edit and error, reply and repair. This transformation is not a new view of discourse or even knowledge production in the digital age, but the moment when it opens up — to augmentation and perhaps denigration — the digital revolution reaches a new plateau that is no longer about mimicking its analog antecedents.
The book can no longer be thought of as a physical object but instead how people use the book, a well-read dogeared, many-forked and networking conversation of a book. Programming is teaching a book how to leave the realm of fixed characters and become a thing-becoming.
Sarah Ciston (she/they) is a Mellon Fellow and PhD Candidate in Media Arts and Practice at USC and a Virtual Fellow at the Humboldt Institute for Internet and Society in Berlin, researching how to bring intersectional theories, ethics, and tactics to artificial intelligence. They also lead Creative Code Collective, a community for co-learning programming with approachable, interdisciplinary strategies.
Mark C. Marino (he/him) (http://markcmarino.com) is a writer and scholar of electronic literature living in Los Angeles. His most recently published the book Critical Code Studies. He teaches writing at the University of Southern California where he Directs the Humanities and Critical Code Studies Lab (http://haccslab.com). He is also the Director of Communications for the Electronic Literature Organization.
