Abstract
The process of making digital objects available and discoverable demands a great deal
of labor, from digitization, to creating metadata, to preservation, to importing it
into a digital asset management system, and finally to presenting it. We begin this
essay with a case study of one such system, called “Vault,” in the University of
Victoria Libraries, and the work required to migrate from a Software as a Service
(SAAS) model (called ContentDM) to a free and open-source software (FOSS) model (a
customized instance of Samvera).
Vault illustrates what we call “minimal computing from the labor
perspective,” which seeks to reduce the opacity of software through
“low-tech” practices such as pseudocode, thereby reducing the alienation of
practitioners from their projects. Drawing from feminist ecological work on
capitalism, affective labor, and care, we advocate for the “degrowth” of digital
projects by resisting tendencies to reinvest surplus labor and value into increased
productivity. Instead, degrowth as minimal computing prompts practitioners to
articulate a project’s needs and desires; what work is required and from whom; and
how or whether to sustain this labor for the future.
For some practitioners, research begins in library collections or archives at the
moment of contact with an object of interest. In the case of digital objects, this
encounter is usually mediated by a digital asset management system. Although screens
afford the allure of immediacy, the process of making digital objects available and
discoverable demands a great deal of labor, from digitizing a physical object to
creating metadata, to maintaining the object, to importing it into the system, and
finally to presenting it.
We begin this essay with a case study of one such digital asset management system,
called “Vault,” in the University of Victoria Libraries, and we focus on the
work required to not only keep it running but also advance the migration process from
Software as a Service (SAAS)
[1] to free and open-source software
(FOSS).
[2] Vault does not seem like a
typical minimal computing project. It it does not involve a static site generator,
small single-board computer, or lightweight markup language; nor does it espouse a
minimalist aesthetic. Yet it does inform and enact what we call “minimal computing from the labor perspective,” which seeks to
“degrow” digital projects.
Here, our use of “degrow” corresponds with ongoing feminist ecological work on
capitalism, labor, and care [
Barca 2019]
[
Akbulut 2017]. For these scholars, particularly Stefania Barca and
Bengi Akbulut, degrowth “ultimately means eliminating the
productive reinvestment of surplus value”
[
Barca 2019, 208]. For us, degrowth in the context of computing —
or degrowth
as minimal computing — prompts people to articulate what
they need or want from a project, what work is required when, and who will do that
work, all without appealing to increased efficiency or productivity. Minimal
computing from a labor perspective is thus first and foremost about social relations
between people, projects, and labor before minimalism is reified into a form,
technique, tool, or feature. Practically, it defines an explicit endpoint to resist
scope creep and potentially endless maintenance. Politically, it acknowledges and
seeks to address power structures in claims to minimalism, including the hierarchies
of labor they entail. In the following study of Vault, for example, we discuss how
software maintenance resists binaries of masculinized programming culture (“real”
technical labor) and feminized carework (devalued organizational or affective labor).
Finally, there is a design angle to the labor perspective, whereby minimal computing
reduces the opacity of digital projects to make labor apparent. Through methods such
as annotation and pseudocode,
[3] it demonstrates out how
computation transforms objects and information, and it demystifies projects to avoid
proverbial black boxes. As is the case with Vault, minimal computing from the labor
perspective eschews SAAS in favor of FOSS while recognizing and supporting the
everyday labor demanded by the latter.
Taken together, these practical, political, and design approaches to digital projects
speak to the primary aim of minimal computing from the labor perspective: to degrow
computation’s alienation of practitioners from their own projects and from social
organization and collective expertise. Rather than asserting this perspective and
then applying it to examples, we begin with Chan’s argument, based on experience,
which describes the conditions and practices that gave rise to Vault and her
contributions to it. From there, we extrapolate lessons from Vault to further define
and historicize minimal computing from the labor perspective and outline its real and
potential effects on the habits, cultures, and values of computing.
Case Study: Vault at the University of Victoria
I am one of two developers at University of Victoria Libraries (“Libraries”) who
knows and uses Ruby on Rails.
[4] Ruby is a
general-purpose programming language akin to Python, while Rails is a server-side
framework for building web applications with Ruby. I am responsible for developing
and maintaining Vault,
[5] which is the Libraries’
asset management system. Written in Ruby on Rails, Vault is a custom instance of
Samvera’s open-source repository software Hyku. It is further part of a multi-year,
collaborative effort unfolding across occupations and groups within the Libraries,
including digitization (Page DeWolfe, Leanne Gibbs, and Kathy Mercer), metadata and
cataloging (Karen Dykes, Dean Seeman, Maggie Tan, and Shelley Coulombe), software
development (Braydon Justice, Ethan Getty, and me), library systems (John Durno), and
digital scholarship and strategy (Lisa Goddard and J. Matthew Huculak). Importantly,
Vault is not the first platform the Libraries have used for asset management. Like
most platforms, it arrived in the middle of our work at the University of Victoria
(UVic), after we used the CONTENTdm software.
Changing platforms from CONTENTdm to Vault will gradually increase public access to
the Libraries’ collections by reducing UVic’s use of proprietary software.
[6] This aspect of Vault aligns with some goals of
the FOSS movement, where people “have the freedom to run, copy,
distribute, study, change, and improve the software”
[
GNU 2021]. There is also a keen appetite among libraries and other
memory institutions for open-source platforms. The list of Samvera adopters, for
example, contains 485 organizations, including many university and college libraries
as well as high-profile organizations such as the British Library and the Electronic
Literature Organization [
Colvard 2021]. That number will likely
increase; several institutions recently reported migrating from CONTENTdm to
open-source repositories, and many institutions worldwide are facing a major
open-source repository upgrade from Fedora 3 to Fedora 4-6 [
Dohe 2019]
[
Hardesty and Homenda 2019].
At the Libraries, switching from CONTENTdm to Vault will also help to reduce SAAS
costs; however, implementing open-source software, and implementing it well, is
obviously not free.
[7] When
choosing between SAAS and FOSS, each institution should take into account their own
needs, resources, and local contexts. One cost that institutions might have to bear
for complex, server-side FOSS platforms is the infrastructure that supports software.
They may also have to pay internal or external developers to develop, maintain,
and/or migrate data to their instance of that software, and software localization may
pose challenges in the process. When developers have to update FOSS, no automatic
patch, built-in support, or documentation may exist for custom features designed for
a particular institution. Developers such as myself thus consider each feature on a
case-by-case basis to determine the best way to port the functionality from one
version to the next. Sometimes this process is relatively simple (e.g., copy and
pasting code that other developers have already tested), but it can also be very
laborious.
Although maintenance is rarely discussed in research and academic publications, it is
part of the routine work and decision-making processes in memory institutions such as
the Libraries.
[8] It also points to palpable contradictions
at play within project design and development, where increasing access may not reduce
the labor of maintenance.
[9] Such tensions assert themselves when projects
and institutions have limited staff and faculty, are underfunded and under-resourced,
and/or face significant material constraints. Kate Dohe observes that open-source
software initiatives are mostly dominated by wealthy, historically white institutions
and are still relatively opaque to non-specialists [
Dohe 2019]. She
adds that this disparity is compounded by tensions between the masculinized
micro-culture of software development and the feminized library workforce. “The end result,” Dohe declares, is “elite
institutions making products for other elite institutions, and every year the
technical and economic barriers to entry grow higher”
[
Dohe 2019]. If libraries strive to support and customize software, and
they recognize, as Samvera’s development team does, that contradictions between
support and customization are the rule of, rather than the exception to, product and
service design, then we must ask who can afford to develop and maintain FOSS [
Frost 2015].
[10]
While Hyku may be more transparent than CONTENTdm, the technical expertise required
to read or write its code nevertheless creates barriers to participation that
existing governance structures often exacerbate [
Dohe 2019]. For
instance, one piece of software is composed of many different components working in
concert. In the case of Vault, those components include Fedora 4 (repository
software), Blacklight (discovery service), Solr (indexing software), and the
International Image Interoperability Framework (IIIF), among others.
My typical day can involve working with three to six types of code, depending on the
task and how “code” is defined. Coding a single web page for Vault requires
knowledge of HTML (the marked-up content of the page), CSS (the style or display),
JavaScript (animation and interface elements), and Ruby on Rails (the page
interacting with the server or database). Each of these languages has its own syntax
and quirks while also relying or building on other languages. Programming a simple
hide/show animation in JavaScript, for example, requires knowing which HTML element
to animate — an element I will likely mark with a CSS selector or class before
passing it into JavaScript. A task that may at the outset appear simple requires
familiarity with three different languages that, in turn, require a non-trivial
amount of time and labor to learn. The difficulties of this work are compounded when
people are not compensated or supported for developing technical expertise, or where
a lack of resources or staff means one person must juggle many separate tasks in
addition to debugging software.
Errors and error messages are, like maintenance, largely ignored in broader
discussions of technological innovation and software, except in minute conversations
between developers or as lingering comment threads in forums such as Stack
Overflow.
[11] They are unplanned interruptions and undesirable hiccups in
the “seamless” experience of technology, and they are mostly forgotten as soon
as a problem is fixed and an error disappears. But they are also ubiquitous, not to
mention fundamental, to the composition of code and the maintenance of software such
as Vault. Errors highlight the messiness of migration, localization, and upkeep. They
emphasize how code resists exact or straightforward replication over time or across
platforms. Although some code can be reused, people still need to modify it to fit a
different context (e.g., renaming variables), match changes elsewhere in the software
(e.g., updating to a code module needed for an existing application), or accommodate
an unexpected edge case (e.g., data that does not easily fit within an existing
database schema and thus requires an update to that database’s structure). Other
common maintenance and debugging issues I might anticipate during a project like
Vault include typos or syntax errors, libraries deprecated for performance issues or
security vulnerabilities, adding or deleting columns in a database, cascading errors
introduced by a bug fix, reference errors, or — worst of all — code that fails
silently, without any indication of where the problem may be. Such errors are in fact
so common they become banal, at least for developers.
[12]
Software development is associated mostly with writing new code; however, in practice
I work with non-functioning code — that is, code that does not operate how my
colleagues or I want or expect it to — as often as I do with functioning code. And I
am not alone. Nathan Ensmenger notes that software maintenance is “the single most time consuming and expensive phase of [software]
development,” representing 50-70% of total expenditures from the early
1960s to 2014 [
Ensmenger 2014, 2]. Code is in constant need of
repair. As Ensmenger declares, “All software has bugs; the
question is simply whether [or] not they are known, and the degree to which they
affect the general consensus on whether or not the software is ‘working’”
[
Ensmenger 2014, 4]. Ensmenger’s statement echoes research in
maintenance studies that stresses the necessary but invisible and devalued acts of
care and repair performed by people who keep the machine running [
Rosner and Ames 2014]
[
Jackson 2014]
[
Chachra 2015]
[
Mattern 2018].
The development and maintenance of Vault, like research across maintenance studies,
demonstrates quite clearly why code is not
logos, or the one true “source [or] . . . representation of action”: something that
simply works, untouched by the messy world of people and things [
Chun 2013, 19]. As Wendy Hui Kyong Chun argues in
Programmed Visions, fetishizing source code frames it as a
seamless set of instructions that propel execution without regard for the many
systems, agents, and social relationships in between [
Chun 2013]. Chun
writes, “[Fetishization] assumes no difference between source
code and execution, between instruction and result”
[
Chun 2013, 21]. If code requires constant maintenance, then it
cannot stand as a monolithic “enclosed object” — not only since it is always
breaking down, but also because it is deeply enmeshed in social and material
relations that enable it to run and continue running [
Chun 2013, 54]. As Ensmenger puts it, “software . . . is like a contract, a
constitution, or a covenant” under constant revision and negotiation [
Ensmenger 2014, 11]. It is “history,
organization, and social relationships made tangible”
[
Ensmenger 2014, 11], especially under the SAAS paradigm, where
everything from networking and storage to applications and data may be hosted and
managed remotely by a company or organization. This arrangement means SAAS customers
usually play little to no role in programming and maintenance decisions related to
access, discovery, search, metadata, customization, and the storage limits of their
project. They are
here, and software is
there. The irony,
then, is that the consequences of code as
contract may not differ
significantly from the consequences of code as
logos. While they operate
under distinct assumptions — “code does what it says” versus “code is a
service” — both isolate code from social dimensions of its workflow. Projects
such as Vault and Hyku may be understood as a response, if not a corrective, to this
isolation. With them comes increased, localized attention to the contingencies of
code: software moves from
there to
here.
As Vault demonstrates, code and software are contingent on the needs of the
Libraries’ catalogers. Responding to those needs, Justice and I implemented a
CONTENTdm migrator tool, which lets catalogers map metadata terms from one system to
another before exporting CONTENTdm data to a comma-separated values (CSV) file with a
row for each item and its metadata. Importantly, each row contains a file path to the
digital object that the metadata describes so Vault can link them together. After
refining the CSV, catalogers upload it to Vault. Vault parses the CSV, ingests both
the metadata and objects, and performs various other tasks, such as indexing metadata
or creating thumbnails. Previously, an empty file path in the CSV would cause the
entire batch upload job to fail without any notification to the uploader. So, based
on feedback, Justice and I also implemented a file path checker tool that determines
whether a file actually exists at the path indicated before Vault tries to import the
object or metadata. The path checker then prints a list of empty paths for catalogers
to correct. Accurately typing long file paths is often difficult and frustrating for
people, especially if they are accustomed to graphical interfaces or different
operating systems (for instance, Linux paths use forward slashes while Windows paths
use backslashes). During the migration and localization processes, the Libraries are
able to address some of these difficulties and frustrations through customization by
way of automation, which may not be available to SAAS customers.
Vault’s features are also contingent on what the Libraries do not need or choose to
avoid. Justice removed Hyku’s built-in notifications feature to decrease the number
of internal system requests, which impede server performance. To restrict access, he
also removed the option to register for an account without an explicit invitation
from an administrator. I included an option for the Libraries to allow people who are
not affiliated with UVic to view an item without being able to download it. Hyku’s
default settings coupled “viewable” with “downloadable,” but the Libraries
needed to restrict downloads for items that are in copyright or have protocols
governing their use. These sorts of customizations fall under the broader umbrella of
maintenance as they not only speak to the ongoing, local needs of the Libraries but
also affect, or cascade across, Vault as a whole over time. Although they are quite
technical in the particular cases of programming and debugging, they need to be
communicated more generally to everyone in the Libraries who relies on Vault.
Otherwise, code and software are once again isolated from who and what keep them
running.
Pseudocode, or an informal description of how a computer program operates, is useful
for such translation practices, and for instilling a sense of trust when labor is
divided and individuals contribute only to specific parts of a platform based on
their roles within the Libraries. Consider an example based on writing a Ruby on
Rails web application (“app”). When digitizing objects such as periodicals or
books for archiving purposes, the Libraries’ digitization team scans each page as a
.tiff image (Tagged Image File Format, or “TIFF”) at about 600 dots per inch
(DPI) and a file size of hundreds of megabytes each. However, people who access the
Libraries’ collections may prefer to view these images as .pdf documents (Portable
Document Format, or “PDF”) in which every image is a page. Justice, Greg
Lanning, and I begin by talking with the Libraries’ digitization unit about which
Ruby functions and features may help to address this issue of format needs and
preferences. Then the three of us compile a list of specifications, written in rather
plain language. The list may look something like this:
- People will select a folder of TIFFs (through a dialog box) on a shared library
storage drive for conversion.
- The app will ignore all non-TIFF files in this folder.
- The app will check the DPI of each TIFF, print a warning if the TIFF is under
600 DPI, and resample the TIFF to 600 if it is above 600 DPI.
- The resulting PDF will be linearized or “web-ready.”
- Up to four people should be able to use the app at the same time.
This imagined app considers the fact that converting the TIFFs to a linearized PDF is
a time-consuming task that cannot be done easily through a graphical user interface
(GUI). Even proprietary software such as Adobe Acrobat, which allows for some
automatic conversion, will crash when given a significant number of high-quality,
information-dense image files. And so, rather than jumping immediately into the Adobe
Creative suite, I begin writing pseudocode for the Libraries.
Pseudocode enables me to draft code as a series of actions the code will perform. To
increase accessibility and bypass assumptions of shared technical language, I write
in prose instead of code. “Linearize the PDF” would, for example, be expressed
in Ruby as `qpdf #{input_pdf_name} — linearize #{output_pdf_name}`.
Here is sample pseudocode for the specifications list above:
- Take a folder containing TIFFs as the input.
- Create a list of TIFF files to convert.
- Check the DPI of each TIFF and resample, do nothing, or print a warning if
necessary.
- Convert each TIFF to a PDF.
- Combine all the PDFs (in the correct order) into one PDF file.
- Linearize the PDF and save it somewhere.
- Notify the user when the process is done and allow them to download the PDF.
Pseudocode is important for describing what a project should or must do without
becoming tangled in the particular syntax of a programming language. As intellectual
work, it helps practitioners to clarify what they need and how to judge whether, how,
or to what degree a resulting program succeeds. It is also advantageous from a
maintenance perspective because the potential for error in digitization projects is
high, and it is far easier to debug a small program (in terms of number of lines)
than a large one. By avoiding resource-heavy interfaces and scope creep, and by
adding complexity incrementally and only when necessary, the Libraries can thoroughly
test one part of a program and confirm it is working before moving to another feature
or function of Vault.
Along the way, I may use a “low-tech,” non-GUI interface such as a text editor,
command line, or interactive shell or console called a Read-Eval-Print-Loop (REPL)
when composing code. I may also draw or sketch a workflow on paper before touching a
keyboard. Such interfaces narrow attention and tend to reduce complexity when testing
and debugging. They focus the work on describing details concretely. What functions
are needed? What do those functions need — which data types, variables, or
parameters? What are some errors that could occur? What alternative functions or
workarounds exist if initial attempts fail? What information is needed from people,
and what can be provided, calculated, or expressed by the computer? If the Libraries
are creating profiles in Vault, for example, do we need a person’s first or last name
or email address? Where and how will this data be stored, used, displayed, and
retrieved?
After writing preliminary pseudocode, I build these steps using logical statements —
such as if/then clauses or loops — to guide the computer in its decision-making
process. If/then statements are like forks in the road: they describe two (or more)
conditions that a computer calculates and pair each condition with a specific action
the computer will take if the corresponding condition is met. Loops are repeated or
repeatable if/then statements. They say, “As long as condition X
is met, repeat action Y.” For instance, I can loop through a list of files
in a folder (“for every file . . .”). Here is the revised
pseudocode for the TIFF-to-PDF conversion process, including if/then statements and
loops:
- Take a folder containing TIFFs as the input. The function needs a parameter or
argument: the folder’s name. This name must be unique and unambiguous.
- Create a list of TIFF files to convert based on the folder’s contents. For
every file:
- If the file is a TIFF, then add it to a list of TIFFs.
- If the file is not a TIFF, then ignore it.
- For every TIFF in the list, check the DPI of that file.
- If the DPI is over 600, then resample it to 600 DPI.
- If the DPI is equal to 600, then continue to the next file.
- If the DPI is under 600, then warn the user but keep the file in the list
for conversion.
- Convert each TIFF file to a PDF file.
- Combine all the PDFs (in alphabetical order based on the TIFF’s original
filename) into one big PDF. Each PDF becomes a page of the resulting PDF.
- Linearize the PDF and save it in a folder for download.
- Email the user with a link to the PDF when the process is done.
After I create a pseudocode roadmap for my app, I begin to translate it into Ruby on
Rails. Ruby contains a number of built-in methods: algorithms that transform some
input into an output. Where possible, I look for these built-in methods as well as
external code libraries (called “gems” in Ruby) to achieve common programming
tasks such as creating, moving, or removing files. This step avoids reinventing the
wheel. Why write code entirely from scratch if someone else has already created an
effective approach to the problem? In some cases, writing code entirely from scratch
is not reasonable. When converting a TIFF into a PDF, for example, I would have to
know the byte-by-byte values of image headers (data placed at the beginning of a file
that tells a viewer to parse or interpret the file as a TIFF) and replace them with
PDF headers, all without corrupting the content of the file itself. In this scenario,
programmers usually rely on image manipulation libraries, such as ImageMagick, for
conversion. Offloading the task in this way would allow me to concentrate on the
scope of the app I am writing. It also saves me significant time and labor in the
short term. Yet shortcuts like ImageMagick depend on external code not written or
hosted by the Libraries. The use of such dependencies as part of Vault may therefore
be vulnerable to obsolescence or deprecation, thus yet another tension at play in
project maintenance. A desire to reduce the complexity of code conflicts with another
desire to reduce dependencies and maximize a project’s persistence. Such tensions
are, for good reason, more likely to be accepted than resolved in projects like
Vault.
Defining the Labor Perspective
What does my work with Vault tell readers of this journal about minimal computing?
This may at first sound like a rather odd or misguided question. After all, Vault is
substantial in both its size and reach, and it draws upon a significant array of
resources in the Libraries.
[13] Again, Vault is
neither the product of a static site generator nor stored on a small, single-board
computer.
[14] It is also not a project about the art of
programming, elegant code, or teaching the fundamentals of computing.
[15] It is, however, an
informative case study for minimal computing from what Sayers and I call the labor
perspective, where — drawing from work across media and technology studies,
especially McKenzie Wark’s
Molecular Red — labor is an
activity operating both within and against computation,
[16] where the combination of “within”
and “against” is key to our approach [
Wark 2015]. Contra Marx, we
need not find humans, and specifically the universal human subject, always at the
center of labor.
[17] To quote Wark, “Labor is
the mingling of many things, most of them not human”
[
Wark 2015, 217], hence our attention to both activity and
infrastructure throughout the following inquiry.
The logic of the labor perspective unfolds like so:
- Computation is historical, not abstract. Minimal computing starts in the middle
of institutional work — in medias res.[18] It engages computation as mediation,
beyond the packaging of minimalism as a canned style, transhistorical feature, or
list of fundamentals intended for download and exchange. From the labor
perspective, a minimal computing project is its files and the relationships
between them; it is also the ongoing activity of maintenance, customization, and
care moving into the future with the past in mind.[19]
- Computation subsumes labor. Or, labor is found within computation [Wark 2015, 19].[20] Minimal computing happens within
infrastructures greater, or larger, than itself. From the labor perspective, a
minimal computing project attends to the power and persistence of these
infrastructures and determines which ones are worth maintaining.
- Yet labor also experiments with computation [Wark 2015, 19].
Or, it is an activity of resistance and friction, especially with respect to
software’s default settings. Minimal computing projects find new uses for
computing outside SAAS paradigms. From the labor perspective, a minimal computing
project positions technical work as creative and critical work beyond familiarity
with management systems.
- Minimal computing from the labor perspective may thus be defined as the
reduction of computation’s alienating effects: the alienation of
projects but also of practitioners from social organization and collective
expertise. From the labor perspective, a minimal computing project degrows
computation’s tendency to reinvest in productivity by investing instead in shared
structures and common activities, also called “convivial computing”
[Barca 2019]
[Sterne 2007].[21]
All of these aspects are more than metaphors, and they can be unpacked with attention
to the particulars of Vault as a computing project and labor issue.
We would be remiss, however, if we did not first recognize how minimalism is often an
expression of power, if not an exaltation of it. Google’s reduction of search to a
single input field on a mostly blank page is a canonical example of such power.
[22] The cost of Apple products, known for their minimalist design, is yet
another. Beyond computing, we may — at the risk of digressing for a moment — look to
minimalist sculpture in the U.S. starting in the 1960s. Donald Judd once described
such sculpture as “plain power”
[
Judd 2002], and Frank Stella said, “What you see
is what you see”
[
Stella 1995, 158]. Here, the exposure of means is the medium,
what Anna Chave deems not only a will to power but also the face of patriarchy and
capital [
Chave 1990, 51–8].
[23] In the New York's minimalist sculpture scene
during the 1960s, that will to power was also predominantly white and male, and a lot
of the work was factory-made, or it evinced the factory-made.
[24] Chave notes that Tony Smith once boasted,
“I didn’t make a drawing; I just picked up the phone and
ordered it”
[
Chave 1990, 52]. Minimalist sculpture of that scene rarely left a
trace or signature of its production, and it did not appear to address a particular
subject or community of subjects [
Foster 1996].
[25] It functioned more like an
impersonal, austere, monolithic object: as “anti-artifice” rather than art in
the making [
Strickland 1993, 13]. It did not readily disclose its
process of composition, either, reminding audiences that “laying bare” the means
does not necessitate attribution, let alone transparency, of labor.
This labor issue persists in the exhibition and care of minimalist sculpture found in
public parks and plazas. Consider, for instance, Chave’s analysis of Richard Serra’s
Tilted Arc, constructed in 1981 and commissioned by
the U.S. General Services Administration’s Art in Architecture Program:
In its site on Federal Plaza in lower Manhattan, Serra’s mammoth,
perilously titled steel arc formed a divisive barrier too tall (12 feet) to see
over, and a protracted trip (120 feet) to walk around. In the severity of its
material, the austerity of its form, and in its gargantuan size, it served almost
as a grotesque amplification of Minimalism’s power rhetoric. Something about the
public reaction to that rhetoric can be deduced from the graffiti and the urine
that liberally covered the work almost from the first, as well as from the
petitions demanding its removal (a demand met last year). [Chave 1990, 59]
Here, minimalism was so assertive, so aggressive in its will to power, that people
responded by tagging it and relieving themselves on it.
[26] Employees of the Department of Health and
Human Services then had to attend to it — all to help maintain Serra’s public work.
After almost a decade of this back-and-forth,
Tilted Arc
was dissected into three pieces, removed, and delivered to a nearby
scrap-metal yard [
PBS 1999].
While minimalist sculpture in New York may not appear immediately relevant to Vault,
it does provide an example of how minimalism is value-laden, and it may serve as a
model for how not to approach minimal computing from the labor
perspective. Rather than assuming that a minimalist project is the impersonal
expression of means or the exaltation of a lone artist’s patriarchal power and
capital, the labor perspective attends to the social and material mingling of
activities with infrastructure over time. We approach this mingling through
technical, organizational, and affective labor in particular.
Technical Labor: On the Recalcitrance of Computing
The technical labor of Vault engages the “recalcitrance” of computing [
Wark 2015, 18], and it starts in the middle. In the narrowest
senses of mediation and history, it migrates and localizes materials from the
“there” of CONTENTdm to the “here” of Vault in the Libraries. This by no
means makes Vault unique. Thousands of these stories exist across the world, and — as
noted previously in this article — more and more institutions are moving from SAAS to
FOSS for the purposes of management. But
in medias res persists as a
theme even when we speak more generally about Vault; web and software projects rarely
start from scratch and, of course, memory institutions by necessity engage with
historical materials in their collections. In the case of UVic, these include
collections such as Victorian Serial Novels; Herbert Geddes; Medieval and Early
Modern Manuscripts; Food Not Bombs; and the Rikki Swin Institute: Gender Education,
Research, Library, and Archives.
[27] Digitizing, stewarding, and caring
for these materials is labor-intensive, and localizing them with customizations of
Hyku written in Ruby underscores how migration is not a mere copy-and-paste job from
CONTENTdm.
When viewed in the aggregate, these issues of mediation demonstrate why maintenance,
rather than innovation or disruption, is a fundamental term for Vault and the labor
around it. The lived reality of Vault and other FOSS projects is one of constant
negotiation with software, of moving from one moment of stabilization to the next,
between past and future. As Vault reduces UVic’s alienation from its own collections,
and the Libraries from their own labor and computing, all as an alternative to
proprietary software in the academy, it also makes everyone involved more aware of
the means available for asset management. This awareness of means underscores the
fact that technical labor — like all creative and critical work — carries both
negative and affirmative connotations, from managing endless bugs and implementing
updates to experimenting with code, building knowledge around historical materials,
and imagining new uses for computing.
[28]
An awareness of means has been an appeal of minimalism for some time now. In his
examination of minimalist tendencies in music and plastic arts, Edward Strickland
asserts: “In much Minimal music . . . overt and immediately
audible repetition of simple, even simplistic material, is the predominant
structural principle. In dance, film, sculpture, and literature, similarly,
Minimalism exposes the components of its medium in skeletal form”
[
Strickland 1993, 13]. The same may be argued for the technical
labor of minimal computing; for instance, the components, skeleton, and even the
principles of infrastructure are foregrounded in the design of open-source
microcontrollers and static site generators.
[29] People accessing or contributing to such
projects are presumably not estranged from computation’s component parts and, in some
cases, the connections between those parts and their dependencies. The materials are
presented in plain sight, as if they
are the interface. Vault does
something similar through the simplicity of its online presentation. Descriptions,
metadata, and items are all shared together on the same page, and a collection’s size
(in bytes), number of items, provenance, and permalink are readily available.
Additionally, since Vault is a custom instance of Hyku — and Hyku is FOSS designed
for modification and reuse — the Libraries may create new features or adapt existing
ones to suit workflows specific to UVic.
[30] In CONTENTdm, there is no easy way for people to download
either specific image items or images of an item’s constituent parts, such as
particular pages in a codex. The components and skeletal form of CONTENTdm are not
readily apparent to local developers, and modifying its code is very difficult and
likely illegal. CONTENTdm is thus an example of the proverbial black box.
[31] Developers and libraries must rely
on the vendor (the Online Computer Library Center) to determine costs of features,
which of those features to offer, and when.
With Vault, the Libraries see the component parts and their relations, and the UVic
team may adjust the platform’s settings to allow or disallow file downloads and
increase granularity in access protocols, making only a subset of collections
downloadable or permitting downloads of specific works in a given collection. This
sort of technical labor, including customization, applies to the general maintenance
and care for Vault: the living activity of ensuring the social and technical
reproduction of the Libraries’ holdings through code and software. It is also central
to reproducing scholarship and, by extension, the academy [
Shirazi 2017]. As we discuss later in this article, smaller projects, such as a journal built
with Jekyll or an exhibit made with Wax gems, may integrate Vault, with items from
UVic’s holdings becoming featured materials for curation and interpretation and the
platform itself serving as infrastructure for the description and persistence of
assets.
[32] This aspect of
Vault and projects like it is critical to approaching minimal computing from the
technical labor point of view, as it prompts practitioners to account for the entire
stack of scholarly communication, and to render visible its structures and
components, even if no one is an expert in all the areas and technologies
involved.
[33] While some layers of this stack, such as
storage, servers, digitized assets, and metadata, may be centralized according to
standards at institutions like the Libraries, other layers, such as applications and
even data, may be decentralized.
[34] But focusing solely on particular layers of a
stack — on only a journal or exhibit application and not the storage and server, for
instance — risks abstracting an otherwise social process and treating its features as
immediate or ahistorical.
Low-tech practices such as pseudocode help to render an otherwise recalcitrant stack
intelligible to a group — to keep code mingling, and to degrow its alienating
effects. The labor question is not whether everyone in the Libraries knows how to
code (where programming is a means to power) or whether code does what it says (where
code as
logos is the means becoming the medium).
[35] It is, more generally, whether people
follow how
this becomes
that: how, for example, a TIFF
becomes a PDF with a simple program that begins as a specifications list and is then
translated into Ruby, which is then written into infrastructure. Such shared working
knowledge brushes against “what you see is what you see,”
“plain power” assumptions of common sense, also popular in minimalist design
principles like “Keep It Simple, Stupid” (KISS), where simplicity is presented
overtly in ableist terms, as if it is obvious or readily apparent to whomever.
[36] In
reality, the unfolding of technical labor is not obvious, uniform, immediate, or even
coherent. As pseudocode for Vault reveals, simplicity is value, and it must be
iterated, learned, and communicated through composites of knowledge and experience
that gradually decrease collective estrangement. Otherwise, the recalcitrance of
computing and the layers of a stack are naturalized: assumed to be an abstract
quality of a project or an inherent property of computers. “I’m not good with
computers,” we might, for good reason, hear someone say, and minimalist expressions
of plain power and assertions of technical labor’s simple sense may be reasons why.
Organizational Labor: On Bringing People Together around Tasks
The organizational labor of Vault addresses people’s everyday negotiations with
computing but also “thread[s] people together around their
tasks”
[
Wark 2015, 18–19]. Vault is a collaboration across digitization,
metadata and cataloguing, software development, systems, and digital scholarship and
strategy in the Libraries. Each of these groups has their own areas of concentration,
across which they work and communicate. Organization is vital for these reasons.
Vault is developed, maintained, and used by unionized employees at UVic; those unions
agree upon and follow collective agreements, which are pivotal to stability,
advocacy, and governance given the increasing number of precarious positions in and
beyond the academy, the expanding breadth of job qualifications in the gig economy,
the rise of for-profit colleges, and the maintenance, carework, and digital labor
involved in FOSS [
Aneesh 2006]
[
Scholz 2013]
[
Fuchs 2014]
[
McMillan Cottom 2017]
[
CUPE 2018].
[37] Such agreements also foster a collective
awareness of a mediating apparatus, if you will, without assuming consensus among all
involved.
Expounding Donna Haraway’s cyborg point of view, Wark says an “apparatus renders
to the human a world that isn’t for the
human”
[
Wark 2015, 151].
[38] Wark is not examining computing
here, but it fits. While practices such as pseudocode matter for the comprehension of
computation — for understanding in general terms how this becomes that — a mediating
apparatus affects apprehension, or the aspects of a computing stack that are not
intended for us. Components of code may “speak” more often to each other, or to
machines, than to (most) people. Recall, for instance, this line of Ruby:
`qpdf
#{input_pdf_name} — linearize #{output_pdf_name}`. It is not exactly
human-readable, even if aspects of it are intelligible. Or, approaching the business
of mediation more broadly, people are unable to witness what a project like Vault is
doing “behind the scenes” or “on the back end.” So much process is
indecipherable or invisible, and this can all be quite alienating in the absence of
organizational labor. After all, people rely upon software and instill their trust in
it, usually without being proximate to those who keep it running.
[39] Ensuring that an apparatus is understood as social and
technical labor supported by collective agreements decreases the potential for
estrangement without aspiring for immediacy. It also increases the visibility of
technical labor, affirms it, and underscores why it is essential, in part by framing
maintenance as research publishable in a journal such as this one. Furthermore,
collective awareness of an apparatus — a shared apprehension of how it renders to us
what is not for us — can shape the language and practice of organizing around Vault —
“project” rather than “product,” for example, or minimal computing as
labor first, then style, specification, file, or theme, if need be. With such
changes, a project’s design process may begin with maintenance considerations rather
than ignoring them (acting as if they do not exist), deferring them (acting as if
they matter less than other considerations), or attending to them as they emerge
(acting as if they are isolated incidents rather than patterns or cascades).
Affective Labor: On Being Directed by Computing and Computing Projects
The affective labor of Vault engages the feeling of “being directed” by
computing and computing projects [
Ahmed 2017, 43]. As we mentioned
earlier, the challenges of technical labor are compounded when people are not
compensated or supported for developing their expertise, or where a lack of resources
or staff means one person must wear many hats and fix bugs in code as they arise.
While the organizational labor of a collective agreement may help to alleviate issues
related to compensation and professional development, the occupational aspect of
“many hats” involves various cultural factors that are entwined with the
everyday experiences of programming and carework. A labor approach to Vault
underscores the need for structures and guidelines that protect employees from
outside demands for increased efficiency or motivate institutions to reinvest a
project’s surplus in productivity. UVic’s
Library Services for
Grant-Funded Research Projects unfolds along these lines, communicating to
researchers what the Libraries do and do not provide, when, and the monetary value of
in-kind contributions.
[40]
Where affect matters here is in the articulation of maintenance with service and
happiness: fixing bugs that impede people’s access to historical materials, for
instance, or designing simple interfaces to decrease friction during research, not to
mention enduring recurring acts of mansplaining and routinely being asked to
communicate one’s position in a feminized library workforce.
[41] These are topics, no doubt associated with
expectations, that likely go unmentioned in a collective agreement. But, as Sara
Ahmed makes clear in her work on building feminist worlds [
Ahmed 2017],
such expectations are norms, and in computing they are norms entangled with how
software and its values govern people, especially white women, nonbinary folks, and
people of color, in how to act and feel. Ahmed calls this “power
as directionality”
[
Ahmed 2017, 43], and included within it is the heteropatriarchal
command (if tacit) to appear happy and busy during maintenance and care, despite the
fact that frustration, delays, negotiation, bugs, skepticism, confusion, and
complaints are not just inevitable but necessary aspects of any inventive computing
project, especially if and when people are wearing many hats.
[42]
Minimal computing from the labor perspective is thus premised on supporting (and not
just “accommodating”) people who are marginalized or silenced by systemic
directionality. It aims to name problems, call attention to norms, slow down
investments in productivity, discuss difficult topics, experiment, and refuse to
feign happiness when maintenance and carework are devalued. This means the degrowth
of computing’s alienating effects must at the same time recognize alienation as a
critical position, even if the result is a contradiction.
[43] Ahmed states: “If
alienation is sensation, it is not . . . just or only the sensation of
negation”
[
Ahmed 2017, 41]. It is “studious”; it is “wonder”
[
Ahmed 2017, 41]. Ahmed offers a guide to such alienation in her
“killjoy survival kit”
[
Ahmed 2017, 235–249], and other cultural precedents for engaging
affect in computing include
Bodies of Information,
edited by Jacqueline Wernimont and Elizabeth Losh; zines by Julia Evans, Mimi Onuoha,
and Mother Cyborg (Diana Nucera); and recommendations made by Katrina Anderson et al.
[
Wernimont and Losh 2018b]
[
Anderson et al. 2016].
[44] Each of these publications succeeds at
moving beyond heroification (“Hail the maintainers!”) and romantic celebrations
of maintenance without devaluing or abstracting it from social and material
relations.
[45] Parallel steps may include recognizing how
minimal computing manifests from both a necessity and desire to degrow. This is the
path to which we now turn.
Degrowing Digital Projects: Necessity and Desire
Degrowth in minimal computing instigates a shift from using technologies to reinvest
in productivity (“crunch,” increased output, longer hours, more data, jobs rather
than careers, and technology as a service, for instance) to designing shared
structures that support technical, organizational, and affective labor as critical
and creative activities. This is frequently achieved by reducing scope creep, and
thus we might echo Alex Gil’s question, “What do we need?”
[
Gil 2015]. We might also look to
archipelagos — a
journal of Caribbean digital praxis for examples. With co-editor, Kaiama
L. Glover, Gil describes that journal in the following way:
[W]e have thought through our platform with the same critical
eye we cast on the archive, and our resulting infrastructure embodies our
principles. We are fully open access and charge no author fees. Our authors retain
their copyright. We pursue best indexing, accessibility, and archival practices.
We emphasize the primacy of “sustainable authorship in plain text.”[46] Our website and PDFs are generated from the
same markdown files using Jekyll and ConTeXt, respectively. The resulting website
is light-weight and mobile-friendly, acknowledging the importance of mobile
phones, bandwidth differentials, and data costs in the Caribbean.
[Glover and Gil 2020]
The skeleton of the project, not to mention its editorial and commit history, are
accessible to readers along with the journal’s technological stack. Readers are also
“allowed to read, download, copy, distribute, print, search,
or link to the full texts of the articles in [the] journal without asking prior
permission from the publishers”
[
Glover and Gil 2020]. The publication process relies on Markdown and format
redundancy (PDF and HTML) rather than extensive markup or word processing, and it is
enhanced by Dublin Core for general metadata needs.
[47] The interface, like the project itself, privileges content and responsive
design. There are no ads or contrast errors, there is only one menu, the HTML is
mostly valid, and articles are available in a single column (without distracting
sidebars). The journal also bypasses a content management system and database and, in
doing so, reduces the frequency of potential errors and hacks. All of this work is
done by necessity to facilitate access in the Caribbean and reduce the likelihood of
alienating readers and researchers there. At one point, Glover and Gil ask, “How might we encourage collaboration with, increase accessibility
for, and otherwise work to narrow the gap between Caribbeanist researchers,
especially those in the North Atlantic academy, and the communities we are
committed to serving?”
[
Glover and Gil 2020].
From the labor perspective, Glover and Gil also articulate minimalism with
sustainability. They publish the journal’s workflow, render clear its standards and
structure, bypass subscription fees (including SAAS fees), credit all team members
(including the designer, architect, and editorial board), and ensure the journal is
available in English, French, and Spanish. Even though
archipelagos relies on GitHub for storage and distribution, the entire
journal (213.3 MB as of this writing) could easily be downloaded to a USB stick and
deposited with a library, press, or nonprofit organization, without any need for a
running version of Ruby or Jekyll.
[48] What’s more, Glover, Gil, and the
archipelagos team provide a low-maintenance, light-footprint
model for other projects that could integrate and interpret collections housed by
open-source platforms such as Vault, thereby bridging small, nimble, and focused
projects with large, persistent, and extensive ones often found in libraries. Their
model may especially appeal to groups and institutions that are underfunded,
under-resourced, and/or understaffed. Certainly, the project’s files and open-source
repository and the files contained within it are crucial here; however, the
technical, organizational, and affective labor involved in
archipelagos’ production is equally important, framed around a dedicated
team with a clear sense of the sort of scholarship and knowledge work they want to
see in the world. The project may be what Jonathan Sterne had in mind when, in 2007,
he called for “a whole convivial system of digital components, a
convivial digital infrastructure”
[
Sterne 2007, 28].
The labor of minimal computing may also emerge from a desire to degrow “forever”
projects. Here, we might ask what relationships we want with technologies and each
other as we are propelled into the future.
[49] Keeping in mind that academic FOSS
initiatives are largely dominated by wealthy, historically white universities, what
kind of work can other institutions maintain? Or do they wish to maintain? Which
infrastructures are worth keeping? Which projects are, or should be, prioritized,
updated, and routinely debugged?
[50] For how long, and by whom? Which tasks do we
want to automate or offload to scripts, and which do we want to conduct
manually?
[51] If, as
Susan Brown et al. indicate, “Users now firmly expect that
scholarly digital publications will be kept up-to-the-minute and respond to user
suggestions”
[
Brown et al. 2009], then minimal computing from the labor perspective
addresses user (or consumer) expectations directly by accepting and encouraging
others to accept the fact that the internet and digital materials, like all other
materials, age, rot, and degrade [
Kirschenbaum 2008]; that code does
not always do what it says [
Chun 2013]; that capturing content and
archiving the web is a “messy affair”
[
Davis 2014]; and that even public projects must stop growing at some
point. Initiatives such as Vault are in positions to organize around this issue and
educate people on the lived realities of preservation, planned obsolescence, and
digital labor, where projects are published yet presumably never done [
Brown et al. 2009]
[
Kirschenbaum 2009].
[52]
Part of this degrowth may imply attention to, if not an embrace of, ephemerality in
scholarly communication [
Donaldson 2020]
[
Sample 2010]. Or, in some cases, the labor response may very well be
“done” or “enough,” a refutation of the assumption that practitioners
are service-providers who accumulate piles of technical debt that must be paid
indefinitely back to users expecting fresh content on demand.
[53] And yet others may focus on computing and
labor’s potential role in environmental justice. As Stefania Barca argues, “Alienation of the producers from the products of their work is what
leads to the reinvestment of surplus into increased production,” and “weak unions and virtually non-existent enforcement of labor
regulations play a major role in determining the environmental impact of
production”
[
Barca 2019, 209–10]. Each of these possibilities demonstrates
why, in the last instance, necessity may be inextricable from desire.
At UVic, the Endings Project (2020) at the Humanities Computing and Media Centre
(HCMC) has begun addressing degrowth via technical labor practices.
[54]
Although they do not use the term “degrow,” they argue that “projects — even digital ones — need to end”
[
HCMC 2020]. We agree from the vantage of both desire and necessity.
The HCMC outlines “endings principles for digital longevity,” consisting of five
primary components: data, products, processing, documentation, and release
management. Various aspects of these principles correspond with dimensions of minimal
computing, such as “build a static website with no
databases,”
“[d]ata is stored only in formats which conform to open standards
and which are amenable to processing,” and “every
entity in the site has a unique page with a simple URL”
[
HCMC 2020].
[55] One potential benefit of the Endings Project is it
could nudge researchers, especially faculty members, to start their projects with an
ending in mind and — recalling Tony Smith’s boast in 1966 — curb the likelihood of
people “phoning in” projects for others to build and maintain.
[56] Starting a project with an ending, and a
roadmap for how to get there, should increase researcher awareness of projects like
Vault as well as the labor required to publish content and keep the machine running.
It could also encourage more researcher involvement in maintenance and carework and,
by extension, degrow researcher alienation from their own projects. Importantly, all
of these possibilities extend beyond the habituated use of management systems — a
tendency encouraged by many SAAS paradigms.
And ultimately, that is what we hope minimal computing from the labor perspective may
achieve through degrowth: a change in habits, culture, and values, not just
technologies. We admit it is no small task.
Works Cited
Åhäll 2018 Åhäll, Linda. “Affect as Methodology: Feminism and the Politics of Emotion.”
International Political Sociology vol. 12.1 (2018):
36–52.
https://doi.org/10.1093/ips/olx024.
Ahmed 2017 Ahmed, Sara. Living a
Feminist Life. Durham, NC: Duke University Press, 2017.
Aneesh 2006 Aneesh, A. Virtual
Migration: The Programming of Globalization. Durham, NC: Duke University
Press, 2006.
Balbus 1986 Balbus, Isaac D. “Disciplining Women: Michel Foucault and the Power of Feminist Discourse,”
Praxis International vol. 5.4 (1986): 466–483.
Barad 2007 Barad, Karen. Meeting
the Universe Halfway: Quantum Physics and the Entanglement of Matter and
Meaning. Durham, NC: Duke University Press, 2007.
Barr 2018 Barr, Adam. The Problem
with Software: Why Smart Engineers Write Bad Code. Cambridge, MA: MIT
Press, 2018.
Benjamin 1940 Benjamin, Walter. “On the Concept of History”, trans. H. Zohn. In Selected Writings, vol. 4, 1938–1940, edited by Eiland,
Howard and Michael W. Jennings, 389–400. Cambridge, MA: Belknap Press of Harvard
University Press 2003.
Botha 2017 Botha, Marc. A Theory
of Minimalism. NY: Bloomsbury, 2017.
Chave 1990 Chave, Anna. “Minimalism and the Rhetoric of Power.”
Arts Magazine vol. 64.5 (1990): 44-63.
Chayka 2020 Chayka, Kyle. The
Longing for Less: Living with Minimalism. NY: Bloomsbury, 2020.
Chuh 2019 Chuh, Kandice. The
Difference Aesthetics Makes: On the Humanities “After
Man.” Durham, NC: Duke University Press, 2019.
Colpitt 1990 Coplitt, Frances. Minimal Art: The Critical Perspective. Ann Arbor, MI: University of
Michigan Press, 1990.
Dictionary of Computer Science 2016a
“Open-source.” In A Dictionary of
Computer Science (7th ed), edited by Andrew Butterfield, Gerard E. Ngondi,
and Anne Kerr. Oxford, UK: Oxford University Press, Oxford, 2016.
Dictionary of Computer Science 2016b
“Saas (Software as a Service).” In A
Dictionary of Computer Science (7th ed.), edited by Andrew Butterfield,
Gerard E. Ngondi, and Anne Kerr. Oxford UK: Oxford University Press, 2016.
Dictionary of Information Science and Technology 2013
“Software as a Service (SaaS).” In
Dictionary of Information Science and Technology (2nd Edition), edited
by Mehdi Khosrow-Pour, 827. Hershey, PA: IGI Global, 2013.
https://doi.org/10.4018/978-1-4666-2624-9.
Dijkstra 1972 Dijkstra, Edsger W. “The Humble Programmer.” 1972 ACM Turing Award Lecture,
Communications of the Association for Computing Machinery, October 1972.
https://doi.org/10.1145/355604.361591.
Edwards and Harris 2017 Edwards, Sue B. and Duchess
Harris. Hidden Human Computers: The Black Women of NASA.
North Mankato, MN: Abdo Publishing, 2017.
Ferguson and Folbre 2000 Ferguson, Anne and Nancy
Folbre. “Women, Care and the Public Good: A Dialogue.” In
Not for Sale: In Defense of Public Goods, edited by
Anton Anatole, Milton Fisk, and Nancy Holmstrom, 95–108. Boulder: Westview Press,
2000.
Fitzpatrick 2011 Fitzpatrick, Kathleen. Planned Obsolescence: Publishing, Technology, and the Future of the
Academy. NY: New York University Press, 2011.
Foster 1996 Foster. Hal. Return
of the Real: The Avant-Garde at the End of the Century. Cambridge, MA: MIT
Press, 1996.
Foucault 1980 Foucault, Michel. Power/Knowledge: Selected Interviews and Other Writings,
1972-1977, Colin Gordon (ed). NY: Pantheon Books, 1980.
Fuchs 2014 Fuchs, Christian. Digital Labour and Karl Marx. NY: Routledge, New York, 2014.
Fuller 2005 Fuller, Matthew. Media Ecologies: Materialist Energies in Art and Technoculture.
Cambridge, MA: MIT Press.
Gilbert and Mobley 2013 Gilbert, Heather and Tyler
Mobley. “Breaking Up with CONTENTdm: Why and How One Institution
Took the Leap to Open Source.”
Code4Lib Journal 20 (2013).
https://journal.code4lib.org/articles/8327.
Graham 1971 Graham, John. System
and Dialectics of Art. Baltimore: Johns Hopkins University Press, 1971.
Originally published in 1937.
Gramsci 1971 Gramsci, Antonio. Selections from the Prison Notebooks of Antonio Gramsci, translated by
Quentin Hoare and Geoffrey Nowell-Smith. NY: International Publishers, 1971.
HCMC 2020 Humanities Computing and Media Centre (HCMC).
The Endings Project, August 8, 2020.
https://endings.uvic.ca.
Hall and O’Shea 2013 Hall, Stuart and Alan O’Shea.
“Common-sense Neoliberalism: The Battle over Common Sense Is a
Central Part of Our Political Life.”
Soundings 55 (2013): 8-24.
Hallett 1996 Hallett, Cynthia J. “Minimalism and the Short Story.”
Studies in Short Fiction vol. 33.4 (1996):
487-495.
Hayles 2005 Hayles, N. Katherine. My Mother Was a Computer: Digital Subjects and Literary
Texts. Chicago: University of Chicago Press, 2005.
Hicks 2017 Hicks, Mar. Programmed
Inequality: How Britain Discarded Women Technologists and Lost Its Edge in
Computing. Cambridge, MA: MIT Press, 2017.
Illich 1973 Illich, Ivan. Tools
for Conviviality. NY: Harper & Row, 1973.
Jackson 2014 Jackson, Steven J. “Rethinking Repair.” In Media Technologies: Essays on
Communication, Materiality and Society, edited by Tarleton Gillespie,
Pablo J. Boczkowski, and Kristen A. Foot, 221–240. Cambridge, MA: MIT Press, 2014.
Judd 2002 Judd, Donald. “Specific
Objects.” In Donald Judd, Early Work
1955-1968, Kellein, Thomas (ed). NY: Distributed
Art Pub Inc, 2002.
Jullien 2009 Jullien, Nicolas. “A Historical Analysis of the Emergence of Free Cooperative Software
Production.” In
Encyclopedia of Multimedia Technology
and Networking, edited by Margherita Pagani, 605–612. Hershey, PA: IGI
Global, 2009.
http://doi.org/10.4018/978-1-60566-060-8.ch001.
Kirschenbaum 2008 Kirschenbaum, Matthew Mechanisms: New Media and the Forensic Imagination.
Cambridge, MA: MIT Press, 2008.
Knuth 1968 Knuth, Donald. The Art
of Computer Programming, Volume 1: Fundamental Algorithms. Boston:
Addison-Wesley, 1968.
Latour 1988 Latour, Bruno. Science in Action: How to Follow Scientists and Engineers through
Society. Cambridge, MA: Harvard University Press, 1987.
Lientz and Swanson 1980 Lientz, Bennet P. and E.
Burton Swanson (eds). Software Maintenance Management.
Boston: Addison-Wesley Publishing, 1980.
Macpherson 2014 Macpherson, Shaun. “‘A Computer for the Rest of You’: Human-Computer Interaction in the
Eversion.” M.A. thesis, 2014. University of Victoria.
Martin and Runyon 2016 Martin, John D. and Carolyn
Runyon. “Digital Humanities, Digital Hegemony: Exploring Funding
Practices and Unequal Access in the Digital Humanities.”
ACM SIGCAS Computers and Society vol. 46.1 (2016).
https://doi.org/10.1145/2908216.2908219.
Marx 1976 Marx, Karl. Capital: A
Critique of Political Economy, translated by Ben Fowkes. NY: Vintage,
1976.
McMillan Cottom 2017 McMillan Cottom, Tressie.
Lower Ed: The Troubling Rise of For-Profit Colleges in the
New Economy. NY: The New Press, 2018.
Meyer 2001 Meyer, James. Minimalism: Art and Polemics in the Sixties. New Haven: Yale University
Press, 2004.
Mita et al. 2018 Mita, Amanda, Zachary Pelli, Kimberly
Reamer, and Sharon Ince. “CONTENTdm to Digital Commons:
Considerations and Workflows.”
Journal of Archival Organization 15 (2018): 58-70.
https://doi.org/10.1080/15332748.2019.1609308.
Moraga and Anzaldúa 1983 Moraga, Cherríe and Gloria
Anzaldúa. This Bridge Called My Back: Writings by Radical Women
of Color. Latham, NY: Kitchen Table, Women of Color Press, 1983.
Murphy 2012 Murphy, Michelle. Seizing the Means of Reproduction: Entanglements of Feminism, Health, and
Technoscience. Durham, NC: Duke University Press, 2012.
Nakamura 2009 Nakamura, Lisa. “Don’t Hate the Player, Hate the Game: The Racialization of Labor in World of
Warcraft.”
Critical Studies in Media Communication vol. 26.2
(2009): 128-44.
Obendorf 2009 Obendorf, Hartmut. Minimalism: Designing Simplicity. London: Springer-Verlag,
2009.
Onuoha and Mother Cyborg 2018 Onuoha, Mimi and Mother
Cyborg. A People’s Guide to AI. Detroit, Allied Media
Projects, 2018.
Plant 1997 Plant, Sadie. Zeroes
and Ones: Digital Women and the New Technoculture. NY: Doubleday,
1997.
Roberts 2019 Roberts, Sarah T. Behind the Screen: Content Moderation in the Shadows of Social Media. New
Haven: Yale University Press, 2019.
Rosner and Ames 2014 Rosner, Daniela K. and Morgan G.
Ames. “Designing for Repair? Infrastructures and Materialities of
Breakdown.”
Proceedings of the 17th ACM Conference on Computer Supported
Cooperative Work & Social Computing, Baltimore, Maryland, February
2014.
https://doi.org/10.1145/2531602.2531692.
Sayers and Dietrich 2013 Sayers, Jentery and Craig
Dietrich. “After the Document Model for Scholarly Communication:
Some Considerations for Authoring with Rich Media.”
Digital Studies/Le Champ Numérique vol. 3.2 (2013).
http://doi.org/10.16995/dscn.237.
Scholz 2013 Scholz, Trebor (ed). Digital Labor: The Internet as Playground and Factory. NY: Routledge,
2013.
Shirazi 2017 Shirazi, Roxanne. “Reproducing the Academy: Librarians and the Question of Service in the Digital
Humanities.” In Making Things and Drawing Boundaries:
Experiments in the Digital Humanities, edited by Jentery Sayers, 86–94.
Minneapolis: University of Minnesota Press, 2017.
Slade 2006 Slade, Giles. Made to
Break: Technology and Obsolescence in America. Cambridge, MA: Harvard
University Press, 2006.
Smith 2007 Smith, Martha Nell. “The Human Touch Software of the Highest Order: Revisiting Editing as
Interpretation.”
Textual Cultures vol. 2.1 (2007): 1–15.
Stella 1995
“Bruce Glaser: Questions to Stella and Judd.” In Minimal Art: A Critical Anthology, edited by Gregory
Battcock, 148-164. Berkeley: University of California Press, 1995.
Sterne 2007 Sterne, Jonathan. “Out with the Trash: On the Future of New Media.” In Residual Media, edited by Charles R. Acland, 16-31. Minneapolis:
University of Minnesota Press, 2007.
Strickland 1993 Strickland, Edward. Minimalism: Origins. Bloomington, IN: Indiana University
Press, 1993.
Tenen and Wythoff 2014 Tenen, Dennis. and Grant
Wythoff. “Sustainable Authorship in Plain Text using Pandoc and
Markdown.”
The Programming Historian 3 (2014).
https://doi.org/10.46430/phen0041.
Wark 2015 Wark, Mackenzie. Molecular Red: Theory for the Anthropocene. London: Verso, 2015.
Wernimont and Losh 2018a Wernimont, Jacqueline
and Elizabeth M. Losh. “Wear and Care Feminisms at a Long Maker
Table.” In
The Routledge Companion to Media Studies
and Digital Humanities, edited by Jentery Sayers, 97-107. NY: Routledge,
2018.
https://scholarworks.wm.edu/asbookchapters/5/.
Wernimont and Losh 2018b Wernimont, Jacqueline
and Elizabeth M. Losh (eds). Bodies of Information:
Intersectional Feminism and Digital Humanities. Minneapolis: University of
Minnesota Press, 2018.