Week 10 - Libraries
Libraries: Collection, Commons, and Governance
Section titled “Libraries: Collection, Commons, and Governance”Welcome to Week 10. Over the past nine weeks, we have built substantial capability: variables for change, loops for repetition, functions for abstraction, events for interaction, local development for autonomy, command line for control, bash for automation, protocols for remote communication. Each week added new technical capacity while interrogating what that capacity means, who it serves, what it conceals.
This week we examine something you have already been using without fully understanding it. Libraries. Remember Week 5 when we used p5.sound to generate oscillators, shape envelopes, apply effects? We were using a library: a collection of functions written by others, maintained by others, made available to us. We called new p5.Oscillator() and sound happened. We did not write that code. Someone else did. Someone else maintains it. Someone else decided what functions should exist, how they should work, what they should enable.
This is directly building upon our discussions from week 4, where we examined how functions abstract complexity and conceal labour. A function is a black box: you call it, it returns a result, you do not see what happens inside. This abstraction is powerful. It lets us work at higher levels without reimplementing everything. But it also hides: the implementation details, the design choices, the labour that went into writing and testing and maintaining the function. Libraries extend this abstraction to entire collections. When we use a library, we inherit hundreds or thousands of functions we did not write. We gain enormous capability. We also enter into relationships we did not consciously choose, dependencies we may not understand, obligations we might not recognise.
A library is technically simple: a collection of functions organised into a module. P5.js itself is a library. But what is a collection? To collect is to curate, to decide what belongs and what does not, to establish criteria for inclusion and exclusion. Every collection embodies values. A museum collection argues for what art matters. An archive collection argues for what history deserves preservation. A library collection argues for what capabilities deserve technical support. These are political choices about whose needs matter, what practices should be enabled, what kinds of making deserve infrastructure.
When you use p5.js, you inherit curatorial choices made by Lauren McCarthy (and the Processing team before that)and hundreds of contributors about what creative coding should be. The library prioritises visual expression, interaction, animation. It makes these practices easy. It makes other practices harder: complex 3D graphics, game development at scale, network programming, data processing. This is not criticism. All tools enable certain practices while constraining others. But the constraints are not natural. They are designed. They reflect decisions about what matters.
p5.js exists because people chose to create it and continue to choose to maintain it. That choice is not automatic. It requires ongoing labour: fixing bugs, updating documentation, managing dependencies as ecosystems shift, responding to issues, reviewing contributions. This maintenance work is mostly invisible. We call createCanvas() without thinking about who wrote it, who maintains it, who answers questions when it breaks. We learned about infrastructure invisibility from Susan Leigh Star: infrastructure becomes visible upon breakdown, is relational (infrastructure for one person is work for another), is historically contingent. Libraries are infrastructure in this sense. For users, they are stable foundation. For maintainers, they are constant labour.
Libraries also create code commons. A commons is a shared resource accessible to all. Traditional commons were physical: pastures for grazing, forests for gathering, fisheries for harvesting. Digital commons are code, knowledge, data made freely available. Open source libraries are commons but non-rivalrous (one person using them does not prevent another), non-excludable (cannot prevent use once released), collectively beneficial (everyone gains capability). But commons do not govern themselves. They require institutions, rules, monitoring, sanctions. Elinor Ostrom spent her career documenting how successful commons function: through clear boundaries, collective choice, graduated sanctions, conflict resolution. Open source libraries lack most of these institutions. They function, but precariously. They depend on unpaid volunteers. They are subject to burnout and abandonment. They are exploited by corporations extracting value without reciprocating.
Libraries also function as gifts. Lewis Hyde argues that art operates in gift economies, not market economies. Gifts circulate and create ongoing obligations. When someone gives you a gift, you are expected to keep the gift moving, to give to others in turn. Open source libraries are given freely. You do not pay to use them. But gifts create obligations of reciprocity. Are we keeping the gift moving? When we use libraries, are we participating in gift circulation or are we simply consuming? What happens when gifts flow only one direction, when reciprocity breaks down, when the gift economy cannot function because users treat gifts as commodities they are entitled to consume?
These questions are not abstract. They have material consequences. In 2014, the Heartbleed bug was discovered in OpenSSL, the encryption library securing two thirds of the world’s HTTPS traffic. The bug existed for three years undetected. During that time, passwords, credit cards, private communications were vulnerable. How did this happen? OpenSSL was maintained by a small team of volunteers, essentially unpaid, responsible for infrastructure underpinning billions of transactions. This is the actual state of the commons we depend on: critical infrastructure maintained by overworked individuals, chronically underfunded, subject to catastrophic failure.
This week we examine libraries not just as technical objects but as collections that encode values, as commons that require governance, as gifts that create obligations. We will look closely at mapping libraries because cartography makes visible what all libraries do. Maps, like everything else we have been talking about on this module, are never neutral. They encode whose geography matters, whose spatial knowledge counts, whose territories get recognised. Maps decide what countries have the right to exist. Colonial maps erased indigenous place names. State maps privilege borders and capitals. Counter-maps assert alternative geographies: Queering the Map archives queer experiences in space that official maps ignore, indigenous counter-mapping asserts territorial knowledge against imposed borders. When we use mapping libraries, we work with infrastructure that privileges certain cartographies over others. Understanding this reveals what all libraries do: they make certain practices possible while foreclosing others, they serve certain communities while excluding others, they encode particular visions of what computing should enable.
We will examine the empirical reality of library maintenance through Nadia Eghbal’s research: 64% of actively used repositories rely on one or two developers, Fortune 500 companies build products worth billions on infrastructure maintained by unpaid volunteers, maintainer burnout is endemic. We will examine the theoretical frameworks that help us understand why this happens: Marx on commodity fetishism (how labour vanishes into objects), Hyde on gift economies (how gifts create obligations), Ostrom on commons governance (what institutions commons require), Hardin’s tragedy of the commons myth (and why it is wrong). We will ask what sustainable library maintenance would require: new institutions, new governance structures, new funding models, new social contracts.
Libraries are relationships. When you load a library in your code, you enter into relationship with maintainers whose labour enables your work. Understanding libraries means understanding these relationships: who creates them, who maintains them, who benefits from them, who is excluded by them, what obligations they create, what dependencies they establish, what happens when they fail. This is not abstract theory. This is the material reality of how software actually functions, who does the work, how it gets sustained or fails to be sustained, what it means to depend on others’ unpaid labour for infrastructure we treat as naturally available.
Part 1: What Gets Collected, and By Whom
Section titled “Part 1: What Gets Collected, and By Whom”Libraries as curated collections
Section titled “Libraries as curated collections”Every library is a collection. Someone, or some group, decided what functions to write, how to organise them, what to include and what to leave out. These are not neutral technical decisions. They are curatorial choices about what is worth preserving, what capabilities matter, whose needs get served.
When Sam Lavigne and Tega Brain created p5.riso in 2018, they collected functions for generating risograph print files. Risograph printing is Japanese duplicating technology from the 1980s: mechanical drums, limited colour palettes, characteristic registration errors. The aesthetic is beloved in zine culture because it is affordable, accessible, DIY. By creating p5.riso, Lavigne and Brain made risograph printing computationally accessible. They encoded DIY aesthetics and community print shop practices into software. The library enables people to design for risograph printing without needing expensive design software, without needing to understand colour separation manually, without barriers between coding and material making.
Their broader practice reinforces this commitment to making computational tools serve critical and accessible creative practices. New York Apartment (2023) used OpenAI to generate impossible property listings, exposing how AI reproduces housing speculation’s logic. The work scraped real estate language, fed it to language models, generated apartments with 47 bedrooms and negative square footage, revealing the absurdity of treating housing as data optimisation problem. Get Well Soon (2020) tracked pandemic labour extraction through Amazon job postings. As COVID spread, the piece scraped Amazon’s hiring page, visualising the scale of warehouse work required to deliver packages to people sheltering at home. The work made visible what Amazon’s interface conceals: the bodies doing the labour, the precarity of the work, the relationship between our convenience and their exploitation.
The Good Life (2016) scraped corporate Instagram accounts to reveal lifestyle capitalism’s visual language. The project collected images companies posted to demonstrate their progressive values: diverse workforces, sustainable practices, community engagement. Lavigne and Brain organised these into a searchable archive, exposing the repetitive visual rhetoric corporations use to perform ethics while extracting profit. The work asks: what does it mean when exploitation wears a friendly face? When companies collect and curate images of care to obscure their actual practices?
p5.riso is part of this practice. A library that collects functions for a specific material process, that argues certain cultural practices deserve technical support, that refuses the separation between digital creativity and physical making. The library is not just convenience. It is argument about what tools should enable, whose practices matter, what accessibility means.
Every library makes arguments through what it collects. When we examine libraries, we should ask: what has been collected here? Why these functions and not others? Whose needs does this serve? What cultural practices does this enable? These questions reveal that libraries are not neutral tools. They are collections that embody particular values, serve particular communities, encode particular visions of what computing should enable.
The gift and its obligations
Section titled “The gift and its obligations”Lewis Hyde’s The Gift: Creativity and the Artist in the Modern World (1983) examines gift economies versus commodity economies. In market economies, commodities are exchanged: you give money, you receive a product, the transaction ends. In gift economies, gifts circulate and create ongoing obligations. When someone gives you a gift, you are not obligated to pay them, but you are obligated to keep the gift moving, to give to others in turn. The gift creates social bonds, ongoing relationships, communities bound by reciprocity.
Hyde argues that art functions as a gift. When artists create and share their work, they participate in gift circulation. The work is not just a commodity to be bought and sold, though it often is that too. It is a gift that creates bonds between artist and audience, that creates communities of people connected through shared aesthetic experience. The gift does not deplete when it is given; it multiplies. More people experiencing the gift does not diminish it.
Open source libraries function exactly like Hyde’s gifts. When someone creates a library and releases it publicly, they give their labour away. You do not pay to use p5.sound or p5.riso or any other open source library. You receive the gift of their work. But gifts create obligations. Not legal obligations: open source licenses explicitly do not require payment or reciprocity. But moral and social obligations. When you receive a gift, you are expected to keep the gift moving, to give to others in turn.
The question is: are we keeping the gift moving? When we use libraries, are we participating in gift circulation or are we simply consuming? Most of us consume. We use libraries without contributing code, without funding maintainers, without even acknowledging the gift we have received. We treat libraries like commodities, things we are entitled to use, rather than gifts that create obligations of reciprocity.
Hyde distinguishes between gift communities where gifts circulate and create bonds, and market communities where commodities are exchanged and relationships end. Open source exists uncomfortably between these. It is structured like a gift economy: free circulation, no payment required. But it exists within capitalism, where most users are corporations extracting value without reciprocating. The result is what Hyde calls incomplete gift circulation. Gifts given but not returned. Relationships initiated but not sustained. Communities that cannot function as communities because reciprocity has broken down.
When Pipkin maintains tool lists, when McCarthy coordinates p5.js development, when Lavigne and Brain release p5.riso, they are giving gifts. The code is freely available. Anyone can use it. But how many users give back? How many contribute code, write documentation, fix bugs, fund development? The gift moves in one direction. It accumulates as dead property rather than circulating as living exchange. This is not sustainable. Eventually the gift givers stop giving. They burn out. The libraries decay.
Commodity fetishism and invisible labour
Section titled “Commodity fetishism and invisible labour”Karl Marx’s analysis of commodity fetishism in Capital explains how commodities conceal the labour that produced them. When you buy a coat, you see an object with a price. You do not see the workers who spun the thread, wove the fabric, cut the pattern, stitched the seams. The coat appears as a thing with inherent value, as if it naturally costs £50, as if its usefulness emerges from the market rather than from human labour. Marx calls this fetishism: relating to objects as if they have inherent properties while forgetting they are crystallised labour, the product of specific workers in specific conditions.
Libraries are fetishised in exactly this sense. When we call a function from a library, we see capability. We do not see the person who wrote that function, who tested it across different browsers, who updated it when JavaScript standards changed, who answered questions on Stack Overflow about edge cases, who continues to maintain it years after the initial release. The library appears as a naturally available tool, as if createCanvas() simply exists as part of p5.js, as if someone did not have to write and maintain it.
We examined how functions abstract complexity and conceal implementation details. Libraries extend this abstraction to an entire collection of functions. But what gets concealed is not just technical complexity. It is labour. The ongoing work of maintaining the library, fixing bugs, updating documentation, responding to issues, managing dependencies as ecosystems shift. This maintenance work is invisible until it fails. When a library breaks, suddenly we are confronted with the labour we had been depending on without acknowledgement.
Nadia Eghbal’s 2016 report Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure documents this empirically. Her central case is Heartbleed, a catastrophic security flaw discovered in 2014 in OpenSSL, the encryption library securing two thirds of the world’s HTTPS traffic. The bug existed for three years undetected. During that time, passwords, credit cards, private communications were vulnerable to exploitation. How did this happen? OpenSSL was maintained by a small team of volunteers. One developer, Stephen Henson, worked full time on it. The OpenSSL Software Foundation received approximately $2,000 annually in donations. One person, essentially unpaid, responsible for encryption infrastructure underpinning billions of transactions.
When Heartbleed was discovered, the response was not just technical: patch the vulnerability. It was also political: how did we build global communications infrastructure on software maintained by one overworked volunteer? Eghbal’s study found that 64% of actively used GitHub repositories in 2015 relied on one or two developers. Fortune 500 companies built products worth millions on infrastructure maintained by unpaid volunteers. The labour vanishes into the library as commodity, reappearing only when infrastructure fails catastrophically.
The myth of inevitable tragedy
Section titled “The myth of inevitable tragedy”Garrett Hardin’s 1968 essay “The Tragedy of the Commons” argued that commonly owned resources inevitably fail. His example: a pasture shared by herders. Each herder benefits individually from adding animals to graze, but the pasture’s capacity is limited. Rational actors will continue adding animals because they capture all the benefit while sharing the cost with others. The result is overgrazing, degradation, collapse. Hardin’s solution was privatisation or authoritarian control: end the commons before tragedy occurs.
But Hardin was wrong. His essay has been critiqued extensively for being both historically inaccurate and politically dangerous. Ian Angus’s 2008 essay “The Myth of the Tragedy of the Commons” documents how Hardin’s example was not based on actual commons. Medieval English commons did not collapse through overgrazing. They functioned sustainably for centuries through community management. Hardin invented a scenario to justify privatisation, then presented it as inevitable natural law. The essay has been used globally to justify enclosure of common resources, from land to water to knowledge. It provides theoretical cover for turning shared resources into private property.
Elinor Ostrom spent her career proving Hardin wrong empirically. Her 1990 book Governing the Commons examined successful commons that had persisted for centuries: Swiss alpine meadows, Spanish irrigation systems, Japanese mountain forests. These commons did not collapse. They functioned sustainably through community governance. Ostrom identified principles that successful commons share:
- Clearly defined boundaries: who has access to the resource
- Rules matching local conditions: governance adapted to specific contexts
- Collective choice arrangements: users participate in modifying rules
- Monitoring: someone watches for rule violations
- Graduated sanctions: penalties for violations start small, escalate if repeated
- Conflict resolution mechanisms: ways to handle disputes
- Recognition of rights to organise: external authorities do not interfere
- Nested enterprises: for larger commons, governance organised in multiple layers
Ostrom argued commons can work, but they require institutions, rules, monitoring, sanctions. Commons do not govern themselves. They are governed by communities through explicit arrangements.
Open source libraries are commons: shared resources, non-rivalrous (one person using them does not prevent another), non-excludable (cannot prevent use once released). But they lack Ostrom’s governance structures. There are no clear boundaries. Anyone can fork and fragment. Rules do not exist or are not enforced. Licensing is often ignored. Users do not participate in governance. They consume. Maintainers decide what gets merged. Users request, maintainers grant or deny. This is not participatory governance. It is voluntary dictatorship, usually benevolent but still unilateral.
Monitoring is absent. Sanctions do not exist. You can use libraries without contributing, without acknowledging maintainers, without reciprocating in any way. There is no violation because there is no expectation. Conflict resolution is informal. Disputes either get resolved through maintainer fiat or through community fracture: fork and split. Rights to organise are protected by licenses, but self-organisation requires organisation, which requires community, which requires boundaries. There are no nested governance structures scaling from individual library to ecosystem level.
We also discussed about infrastructure invisibility from Susan Leigh Star. How infrastructure becomes visible upon breakdown. How it is relational: infrastructure for one person is work for another. How it is historically contingent, not natural or inevitable. Libraries are infrastructure in exactly Star’s sense. For users, libraries are stable foundation. For maintainers, libraries are constant labour. The asymmetry is structural.
Ostrom’s principles reveal what is missing: boundaries, collective choice, monitoring, sanctions, conflict resolution, nested governance. These are not technical problems. They are institutional problems. Open source libraries cannot function as sustainable commons because they lack the institutions commons require.
What p5.js collects
Section titled “What p5.js collects”Before examining other libraries, consider what p5.js itself collects. The library provides functions for drawing, colour, interaction, text, images, video, sound. These are not neutral choices. They are curatorial decisions by McCarthy, the Processing Foundation, and hundreds of contributors about what creative coding should enable.
p5.js prioritises: visual expression, interactive systems, time-based media, web-native practices. The library makes certain practices easy: drawing, animation, interaction. It makes others more difficult: complex 3D graphics, game development at scale, advanced data visualisation, network programming. These are not limitations. They are decisions about what kind of creative practice matters enough to support.
The library’s documentation reflects these priorities. There are extensive tutorials for drawing and animation. There are fewer tutorials for working with data or building complex applications. The examples emphasise visual sketches, interactive pieces, generative systems. The community that has formed around p5.js reflects what the library collects: artists, designers, educators working in visual, interactive, time-based media.
When we use p5.js, we inherit these curatorial choices. The library makes certain practices accessible and others less so. We work within a collection that someone else curated, that embodies particular values about what creative coding should be. This is not constraining: all tools constrain. But it is political. Every collection argues for what is worth preserving and what is not.
But what p5.js itself cannot represent within its own conceptual and technical framework are the perspectives that fall outside its visual and interactive paradigms, such as analog practices, or working with physical sensors and hardware, or cartographic practices, or video-based works. Which is why p5.js, despite being a library itself, also supports add-on libraries to extend what p5.js can do. The p5.sound library we worked with is another example of how the ecosystem can be extended to support audio processing and synthesis. Within this week’s contents, we will look deeper into the ideas of libraries as tools to extend what’s possible. Because unless we are writing a library ourselves, what’s possible is defined by what’s prioritised, by people who build these libraries of collections.
Part 2: Mapping as Archive and Power
Section titled “Part 2: Mapping as Archive and Power”We begin our interrogation on libraries, first with mappa.js, created by Cristóbal Valenzuela, because it reveals most clearly what libraries collect and what that collection means politically. Mappa.js provides tools for working with interactive maps and geographic data in p5.js. It supports multiple mapping providers: Google Maps, Mapbox, OpenStreetMap via Leaflet. It enables overlaying custom visualisations on geographic projections. This sounds neutral, just technical capability for working with location data. But cartography has never been neutral. Maps encode power relations, colonial histories, surveillance infrastructures.
Brian Harley’s 1989 essay “Deconstructing the Map” established that maps are social constructions serving particular interests, not objective representations of territory. Medieval European maps placed Jerusalem at the centre because they were theological documents asserting Christian cosmology. T and O maps divided the world into three continents (Europe, Asia, Africa) corresponding to Noah’s three sons, encoding biblical geography as natural fact. These were not wrong maps that better maps corrected. They were maps serving different purposes, encoding different power structures.
Colonial maps made this even clearer. European empires mapped territories they were colonising, imposing European place names over indigenous ones, drawing borders that served colonial administration rather than existing territorial relationships, representing colonies as empty spaces ready for settlement even when inhabited by indigenous peoples for millennia. The map was not neutral record of what existed. It was tool of colonial power, making certain things visible (resources to extract, borders to enforce) while erasing others (indigenous sovereignty, existing place names, territorial histories).
Contemporary maps continue these patterns. State maps privilege national borders, capital cities, major infrastructure, resource locations. What gets mapped reveals what states care about: boundaries, populations, strategic locations, economic assets. All mapped for governance and control. What does not get mapped: indigenous territorial relationships, informal settlements, migration routes, places that exist outside state recognition. Mapping is always selective. What you choose to map, how you represent it, what projection you use, what you label and what you leave unlabelled: these encode whose geography matters, whose spatial knowledge counts.
Harley argues we must deconstruct maps. Examine what they show and what they hide. Who made them and whose interests they serve. What they naturalise as objective fact versus what they construct as political choice. This applies directly to using mapping libraries. When you load mappa.js and display a map, whose map are you using? Whose geography? Whose labels? Whose power structures?
Getting started with mappa.js
Section titled “Getting started with mappa.js”Let us see what mapping technically involves, then interrogate what it means. First, the library must be loaded. In your HTML file, add the mappa.js script before your sketch:
<!DOCTYPE html><html lang="en"><head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Mapping Data</title></head><body> <script src="sketch.js"></script></body></html>Now in your sketch, create a basic map centred on a politically significant protest site in New Delhi:
let myMap;let canvas;const mappa = new Mappa('Leaflet');
const options = { lat: 28.5466, lng: 77.3008, zoom: 12, style: "https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png"};
function setup() { // something we've not done before // storing the reference to our canvas in a variable canvas = createCanvas(800, 600); myMap = mappa.tileMap(options); // overalying the map on our canvas myMap.overlay(canvas);
// onChange redraws when map changes // it's an event - so needs a callback when triggerred myMap.onChange(drawMarkers);}
function draw() { // draw loop is fully functional // but the map itself comes from onChange
}
function drawMarkers() { clear();
// map marker let shaheenBagh = myMap.latLngToPixel(options.lat, options.lng); fill(255, 0, 0, 150); noStroke(); ellipse(shaheenBagh.x, shaheenBagh.y, 30, 30); fill(255, 0, 0, 50) ellipse(shaheenBagh.x, shaheenBagh.y, 100, 100)
// Display zoom and centre - access through myMap.map (the Leaflet instance) fill(0); textSize(14); text('Zoom: ' + myMap.map.getZoom(), 10, 20); let center = myMap.map.getCenter(); text('Centre: ' + nf(center.lat, 1, 4) + ', ' + nf(center.lng, 1, 4), 10, 40);}This creates an interactive map with OpenStreetMap tiles, overlays a p5.js canvas, and draws a circle at Shaheen Bagh. You can pan and zoom the map. The visualisation updates accordingly. The latLngToPixel() function converts geographic coordinates (latitude and longitude) to pixel positions on the canvas, abstracting the complexity of map projections.
But already we should ask: what are we depending on here? The map tiles come from OpenStreetMap, a volunteer-edited mapping project. OSM is remarkable, a commons-based alternative to corporate mapping. But it reproduces geographic biases. Well-mapped areas correlate with wealth, technical literacy, volunteer time. Areas with fewer contributors have sparse or outdated maps. Who maps whom? Whose geographic knowledge gets included?
Every map is a projection: a method for translating the three-dimensional sphere of Earth onto a two-dimensional plane. This is mathematically impossible without distortion. You cannot flatten a sphere without tearing, stretching, or compressing it. Different projections make different choices about what to preserve and what to distort. The Mercator projection, created in 1569 for navigation, preserves angles and shapes, making it useful for sailing. But it massively distorts size: Greenland appears larger than Africa, though Africa is actually fourteen times bigger. Europe and North America appear enormous. The global south appears tiny. This is not accident. Mercator centers Europe and makes colonial powers look proportionally dominant. It naturalizes European centrality as geographic fact. The Gall-Peters projection, developed as explicit counter to Mercator, preserves area: every region’s size is accurate relative to others. But it distorts shapes, making equatorial regions look stretched. Some cartographers argue it overcorrects, that accuracy is not the same as justice. The Robinson projection compromises: moderate distortion of both size and shape. National Geographic used it for decades. But every compromise is political choice. What you center, what you enlarge, what you compress: these encode whose world matters, whose geography is the reference point from which others are measured. When mapping libraries use these projections, they inherit these politics. The library does not invent the distortion, but it does make certain projections easily available while others require custom implementation.
Connecting to data you collected
Section titled “Connecting to data you collected”Last week we learned to fetch data from remote sources, including Google Sheets via opensheet.elk.sh. You collected data and made it available as an API. Now we can map that data if it includes location information.
Suppose your Google Sheet has columns for latitude, longitude, and description. Here is how to fetch and map it:
38 collapsed lines
let myMap;let canvas;let mappa = new Mappa('Leaflet');let data = [];let dataLoaded = false;let hoveredPoint = null;
let options = { lat: 54.0, // Center on UK lng: -2.5, zoom: 6, style: "https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png"};
function setup() { canvas = createCanvas(800, 600); myMap = mappa.tileMap(options); myMap.overlay(canvas);
loadSheetData();}
async function loadSheetData() { // data manually translated from https://en.wikipedia.org/wiki/List_of_pro-Palestinian_protests_in_the_United_Kingdom let url = 'https://opensheet.elk.sh/1jHwcznLEZyQtWvbfNjp4hvzwkos4p54TRTbhL6hpqdU/Sheet1';
try { // using vanilla JS instead of p5 loadJSON abstraction // first fetch the reponse let response = await fetch(url); // then parse it into json data = await response.json(); dataLoaded = true; console.log('Loaded', data.length, 'locations'); } catch (error) { console.error('Error loading data:', error); }}
function draw() { clear();
if (!dataLoaded) { fill(0); noStroke(); textSize(16); text('Loading data...', 20, 30); return; }
// Find closest point to mouse hoveredPoint = null; let closestDist = 40; // Larger threshold for bigger markers
// Draw all points for (let point of data) { let lat = parseFloat(point.latitude); let lng = parseFloat(point.longitude); let count = parseInt(point.protest_count) || 1;
if (isNaN(lat) || isNaN(lng)) continue;
let pos = myMap.latLngToPixel(lat, lng);
if (pos.x >= 0 && pos.x <= width && pos.y >= 0 && pos.y <= height) { // Scale marker size by protest count (logarithmic for better visibility) let markerSize = map(log(count), 0, log(85), 10, 50);
let d = dist(mouseX, mouseY, pos.x, pos.y);
// Check if this is the closest point if (d < markerSize / 2 + 10) { if (d < closestDist) { closestDist = d; hoveredPoint = { city: point.city, count: count, description: point.description, x: pos.x, y: pos.y }; } }
// Draw marker (highlight if hovered) if (hoveredPoint && point.city === hoveredPoint.city) { fill(255, 50, 50, 230); stroke(255, 255, 255, 200); strokeWeight(2); } else { fill(200, 50, 50, 180); noStroke(); }
ellipse(pos.x, pos.y, markerSize, markerSize);
// Draw city name for larger protests if (count > 5) { fill(0); noStroke(); textSize(10); textAlign(CENTER); text(point.city, pos.x, pos.y + markerSize / 2 + 12); } } }
// Draw tooltip for hovered point if (hoveredPoint) { drawTooltip(); }}
41 collapsed lines
function drawTooltip() { push();
// Calculate tooltip size textSize(14); let textW = max( textWidth(hoveredPoint.city + ': ' + hoveredPoint.count + ' documented demonstrations'), textWidth(hoveredPoint.description) ) + 20; let textH = 60;
// Position tooltip let tooltipX = mouseX + 15; let tooltipY = mouseY + 15;
if (tooltipX + textW > width) { tooltipX = mouseX - textW - 15; } if (tooltipY + textH > height) { tooltipY = mouseY - textH - 15; }
// Draw tooltip box fill(255, 250); stroke(0); strokeWeight(2); rect(tooltipX, tooltipY, textW, textH, 5);
// Draw text fill(0); noStroke(); textAlign(LEFT, TOP); textSize(14); text(hoveredPoint.city + ': ' + hoveredPoint.count + ' documented demonstrations', tooltipX + 10, tooltipY + 10);
textSize(12); fill(100); text(hoveredPoint.description, tooltipX + 10, tooltipY + 32);
pop();}This connects your data collection from last week to mapping this week. The data you gathered (protests attended, places visited, observations made, whatever you collected) becomes geographic visualisation. But immediately we should interrogate what this means. What are you making visible by mapping your data? What are you making invisible? Who benefits from this geographic representation?
Here’s one more example of all the foxes I’ve seen in the last few weeks
34 collapsed lines
let myMap;let canvas;let mappa = new Mappa('Leaflet');let data = [];let dataLoaded = false;let hoveredPoint = null;
let options = { lat: 51.4750, lng: -0.1200, zoom: 13, style: "https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png"};
function setup() { canvas = createCanvas(800, 600); myMap = mappa.tileMap(options); myMap.overlay(canvas);
loadSheetData();}
async function loadSheetData() { let url = 'https://opensheet.elk.sh/1jHwcznLEZyQtWvbfNjp4hvzwkos4p54TRTbhL6hpqdU/Sheet2';
try { let response = await fetch(url); data = await response.json(); dataLoaded = true; console.log('Loaded', data.length, 'fox sightings'); } catch (error) { console.error('Error loading data:', error); }}
function draw() { clear();
if (!dataLoaded) { fill(0); noStroke(); textSize(16); text('Loading fox sightings...', 20, 30); return; }
hoveredPoint = null; let closestDist = 20;
for (let point of data) { let lat = parseFloat(point.latitude); let lng = parseFloat(point.longitude);
if (isNaN(lat) || isNaN(lng)) continue;
let pos = myMap.latLngToPixel(lat, lng);
if (pos.x >= 0 && pos.x <= width && pos.y >= 0 && pos.y <= height) { let d = dist(mouseX, mouseY, pos.x, pos.y);
if (d < closestDist) { closestDist = d; hoveredPoint = { description: point.description, time: point.time, date: point.date, x: pos.x, y: pos.y }; }
// Draw fox emoji/marker if (d < 20) { textSize(24); fill(255, 150, 0); } else { textSize(20); fill(255, 120, 0, 180); } textAlign(CENTER, CENTER); fill(0) ellipse(pos.x, pos.y, 30, 30) text('🦊', pos.x, pos.y); } }
if (hoveredPoint) { drawTooltip(); }40 collapsed lines
}
function drawTooltip() { push();
textSize(14); let textW = max( textWidth(hoveredPoint.description), textWidth(hoveredPoint.date + ' ' + hoveredPoint.time) ) + 20; let textH = 70;
let tooltipX = mouseX + 15; let tooltipY = mouseY + 15;
if (tooltipX + textW > width) { tooltipX = mouseX - textW - 15; } if (tooltipY + textH > height) { tooltipY = mouseY - textH - 15; }
fill(255, 250); stroke(255, 120, 0); strokeWeight(2); rect(tooltipX, tooltipY, textW, textH, 5);
fill(0); noStroke(); textAlign(LEFT, TOP); textSize(14); text(hoveredPoint.description, tooltipX + 10, tooltipY + 10);
textSize(12); fill(100); text(hoveredPoint.date, tooltipX + 10, tooltipY + 32); text(hoveredPoint.time, tooltipX + 10, tooltipY + 50);
pop();}Queering cartography
Section titled “Queering cartography”Lucas LaRochelle’s Queering the Map (2017) is community-generated counter-mapping project for digitally archiving LGBTQ2IA+ experience in relation to physical space. The platform provides an interface where anyone can drop a pin on a map and attach a story: moments of coming out, encounters with violence, experiences of love, memories tied to places. Since launching in 2017, over 850,000 stories have been submitted in 28 languages from across the world.
The project challenges state cartography’s authority. State maps show borders, capitals, infrastructure. They do not show queer geographies: the park bench where you first held someone’s hand, the alley where you were harassed, the club where you found community, the bedroom where you came out. These geographies exist. They shape how queer people move through space, where we feel safe, what routes we take, what places we avoid. But they do not appear on official maps. They exist as lived knowledge, oral histories, embodied practices. Queering the Map makes this knowledge visible.
LaRochelle cites Sara Ahmed’s work on queerness as an orientation towards space. Queer spaces are not fixed places like businesses or neighbourhoods. They are relational experiences created by and between queer people. The same location might be queer space for one person and hostile territory for another. The same place might be queer space at night but not during day. Queering the Map archives these temporally and relationally contingent geographies that conventional cartography cannot capture.
The project received honorary mention at Prix Ars Electronica in 2018 and is included in the Library of Congress LGBTQ+ Studies Web Archive. But it also faced attacks. In 2018, shortly after launch, the site was flooded with homophobic posts attempting to drown out queer voices. LaRochelle worked with volunteers to rebuild the platform with moderation systems, secured it with Cloudflare’s Project Galileo cybersecurity service (which protects vulnerable communities from denial of service attacks). The attack revealed that counter-mapping is not just documentation. It is contested practice. Making queer geographies visible threatens those who benefit from their invisibility.
In 2023, during the Gaza war, pins appeared on Gaza Strip containing messages from LGBTQ Palestinians describing loss of partners in airstrikes, alongside messages of solidarity towards LGBTQ Palestinians. These messages went viral, revealing queering geography as practice that crosses borders, that refuses the separation between identity and geopolitics, that insists queer lives exist everywhere including places where they are officially denied.
Surveillance infrastructure of digital mapping
Section titled “Surveillance infrastructure of digital mapping”Trevor Paglen’s artistic practice makes visible the infrastructure of surveillance and military power that official maps conceal. Unmarked Planes and Hidden Geographies (2006) tracked CIA rendition flights. During the war on terror, the CIA kidnapped terror suspects and transported them to black sites in other countries for interrogation and torture. This was called extraordinary rendition. The flights were covert. The planes were unmarked or operated under shell companies. But they had to file flight plans. Paglen tracked these plans, mapped the routes, visualised the geographic extent of CIA’s torture program.
The work revealed what state maps hide: the infrastructure of state violence. Official maps show airports, flight paths, international borders. They do not show which planes are carrying kidnapped prisoners to secret prisons. Paglen’s mapping practice is investigative. It uses the traces systems leave (flight plans, radio frequencies, satellite orbits) to make visible what those systems intend to conceal. The maps are evidence. They document crimes. They make visible the geography of the war on terror as actually practiced rather than as officially described.
Autonomy Cube (2014, with Jacob Appelbaum) was a sculpture that functioned as a Tor relay node, routing encrypted internet traffic to help people circumvent surveillance and censorship. But the work was also about making surveillance geography visible. Where was traffic routed? Which countries blocked Tor? How did surveillance infrastructure operate spatially? The cube glowed brighter as more traffic passed through it, visualising flows of data seeking anonymity through geographic redirection.
Paglen’s practice consistently asks: what infrastructure exists that we are not supposed to see? How can we make it visible? His work connects to a longer history of investigative cartography: Bureau d’études’ mapping of corporate and state power networks, Josh Begley’s Metadata+ (collecting images of every drone strike site), Forensic Architecture’s spatial analysis of human rights violations. All use mapping not just to represent territory but to investigate and document power.
When you use mapping libraries, you work with the same infrastructure that enables this surveillance. Google Maps logs every query: where you searched, when, what route you chose, how long you stayed. Google builds detailed profiles of movement patterns, correlates them with other data, sells access to advertisers. When you use Google Maps API in your code, you use surveillance infrastructure even if your project is not collecting data. The infrastructure is shared between creative mapping and tracking. There is no clean separation.
Indigenous counter-mapping practices
Section titled “Indigenous counter-mapping practices”Against state cartography and corporate mapping, indigenous communities have practiced counter-mapping: producing maps that assert indigenous territorial knowledge, sovereignty, and spatial practices against imposed borders. These maps challenge the authority of state maps by offering alternative geographic representations grounded in indigenous cosmologies, seasonal patterns, resource management practices, territorial relationships.
The Miskito people in Nicaragua mapped their territories in the 1990s to assert land rights against state claims. The state’s maps showed national borders and property lines. The Miskito counter-maps showed territorial relationships going back generations, seasonal migration patterns, sacred sites, resource sharing arrangements. These were not just different maps. They were different understandings of what territory means, how it gets governed, who has authority over it.
Aboriginal communities in Australia have mapped songlines and dreaming tracks, spatial knowledge embedded in oral traditions and embodied practices that do not translate to conventional cartography. Songlines are paths across the land that record creation stories. Walking the songline while singing recreates the journey of ancestral beings. The map is not visual representation on paper. It is song, dance, story, lived practice. Converting this to digital mapping inevitably loses something: the embodiment, the orality, the sacred dimension.
Inuit communities have mapped Arctic territories including seasonal ice patterns, animal migration routes, traditional place names. This knowledge predates and challenges state borders. It reveals geographies invisible to satellite imaging: the texture of different snow types, safe routes across moving ice, places where animals gather at specific times. When state maps show the Arctic, they show territorial claims, resource deposits, shipping routes. Inuit maps show how to live there, how to move safely, how to sustain communities in relation to land and animals.
These counter-maps are not available through Google, Mapbox, or OpenStreetMap APIs. The infrastructure we use for mapping in code privileges state geographies and corporate cartographies. Indigenous spatial knowledge mostly does not exist in digital mapping systems. When it does exist, it has often been extracted from communities without consent, ownership, or benefit. This is not technical limitation. It is political choice about whose geography gets infrastructure status, whose spatial knowledge gets computational support.
Using mapping libraries means working within these constraints. We can interrogate them, we can acknowledge them, but we cannot escape them entirely. The infrastructure exists, and it encodes particular power relations. What we can do is make visible what mapping conceals, question whose geography gets represented and whose does not, refuse to naturalise digital maps as objective representations when they are always selective, partial, political constructions.
Other libraries, other collections
Section titled “Other libraries, other collections”Mappa.js reveals how libraries encode political choices through what they collect. The same pattern applies to every library. Here is a brief survey of other p5.js addon libraries, each collecting functions that extend p5.js in particular directions.
p5.riso by Lavigne and Brain enables generating risograph print files directly from p5.js code. Connects computational design to material printing. To use it, load the library:
Then create colour layers:
let blue;
function setup() { createCanvas(600, 600); pixelDensity(1);
blue = new Riso('mediumblue');}
function draw() { background(255);
blue.fill(255); for (let i = 0; i < 10; i++) { for (let j = 0; j < 10; j++) { let x = 60 + i * 55; let y = 60 + j * 55; let size = noise(i * 0.3, j * 0.3) * 40; blue.ellipse(x, y, size, size); } }
drawRiso();}p5.svg by Zenozeng replaces p5.js’s raster canvas with vector SVG renderer. Connects computational design to pen plotters, laser cutters, fabrication equipment. Download from https://github.com/zenozeng/p5.js-svg and include locally:
Then specify SVG renderer:
function setup() { createCanvas(600, 600, SVG);}
function draw() { background(255);
for (let i = 0; i < 20; i++) { let x = 50 + i * 25; strokeWeight(map(i, 0, 19, 1, 5)); line(x, 50, x, 550); }
noLoop();}
function keyPressed() { if (key === 's') { save("output.svg"); }}Both p5.riso and p5.svg connect computational practices to analog material processes. They argue that code should not stay on screens. It should extend into physical making, printing, plotting, fabrication. This is political: against the dematerialisation of digital culture, asserting that computational creativity should produce physical objects, that digital and analog practices should not be separated.
p5.serialport enables communication with hardware via serial connections: Arduino, sensors, actuators. Connects your p5.js code to physical computing. This requires running a local server and having Arduino or similar hardware. We mention it briefly because you work with Arduino in another module (CC1), but knowing it exists expands what libraries can collect. Not just visual functions or sound functions or mapping functions, but functions that bridge between code and physical electronics.
p5.scribble by Generaxion provides hand-drawn, sketchy aesthetics. Functions like scribbleLine(), scribbleRect() simulate human drawing gestures: wobbly, imperfect, organic.
let scribble;
function setup() { createCanvas(600, 600); background(255); scribble = new Scribble();
scribble.scribbleLine(100, 100, 500, 500); scribble.scribbleRect(200, 300, 200, 100); noLoop();}This library collects functions for anti-precision, for humanistic imperfection against computational exactness. It is aesthetic politics: refusing the ideology of perfect geometric forms, arguing for the trace of human gesture in computational output.
p5.grain by Meezaan-ud-Din Abdu Dhil-Jalali Wal-Ikram adds film grain, VHS glitches, paper textures. Simulates analog media aesthetics in digital tools.
function setup() { createCanvas(600, 600); applyMonochromeGrain(40);}
function draw() { background(100, 150, 200); ellipse(300, 300, 200, 200);}This nostalgic turn toward pre-digital aesthetics is political: it romanticises media obsolescence, argues that digital perfection lacks the character of analog imperfection. Whether this is resistance to digital culture or mere aestheticisation is an open question. But it reveals that aesthetic choices in libraries are never just aesthetic. They are arguments about what digital making should look like, what values it should encode.
p5.speech by R. Luke DuBois enables speech synthesis and recognition. Your sketches can speak using text-to-speech, or listen to speech input.
let speech;
function setup() { createCanvas(400, 400); speech = new p5.Speech();}
function mousePressed() { speech.speak('Hello from p5.js');}But whose voices get synthesised? Speech recognition works better for some accents, some languages, some speech patterns than others. Voice interfaces encode linguistic hierarchies, privilege standardised pronunciations and dominant languages. When you use speech libraries, you work with infrastructure that has accessibility implications and political dimensions around whose voices get recognised.
Each library makes curatorial choices about what is worth collecting. Together they reveal that extension is never neutral. Every library argues for particular practices, serves particular communities, encodes particular values. Each library is made of labour, of communities, of decisions, of time, of structures, of maintenance, of governance. Each library is released for public access - open source as digital commons.
Part 3: Governing Commons Without Institutions
Section titled “Part 3: Governing Commons Without Institutions”What are software commons?
Section titled “What are software commons?”Before examining governance, or why it matters to us, we must establish what commons means in the context of software libraries. A commons is a shared resource accessible to all members of a community. Traditional commons were physical: pastures for grazing, forests for gathering wood, fisheries for harvesting. These resources were rivalrous (one person’s use diminishes availability for others) and potentially excludable (communities could prevent outsiders from accessing them).
Software libraries are different. They are non-rivalrous: one person using p5.js does not prevent another from using it. A million people can call createCanvas() simultaneously without depleting the resource. They are also non-excludable once released: you cannot prevent someone from downloading and using open source code. These characteristics make software an ideal commons in theory. The resource does not deplete through use. It can serve infinite users without scarcity.
But this creates a specific problem. Traditional commons required governance because overuse could destroy the resource. Garrett Hardin’s 1968 essay “The Tragedy of the Commons” argued this was inevitable: rational actors would overuse shared resources until collapse. But as we established in Part 1, Hardin was wrong. His examples were invented. Real commons persisted for centuries through community governance. Elinor Ostrom documented this empirically: Swiss alpine meadows, Spanish irrigation systems, Japanese mountain forests all functioned sustainably because communities developed institutions to govern them.
Software commons face the opposite problem. The resource cannot be depleted through overuse. You cannot overgraze p5.js. But the resource requires maintenance. Code needs updating as ecosystems change, bugs need fixing, documentation needs writing, questions need answering. This maintenance is labour. It is rivalrous: the time maintainers spend on one issue is time they cannot spend on another. And it is exhaustible: maintainers burn out, quit, abandon projects.
So software commons are not commons of code. They are commons of maintenance labour. The code appears infinite and non-rivalrous. The labour sustaining it is finite and scarce. This is what requires governance: not preventing overuse of code, but distributing the labour of maintaining it, ensuring that maintenance is sustainable, establishing terms for how the commons functions.
The governance problem
Section titled “The governance problem”Governance means deciding how shared resources get managed. For software commons, governance questions include: Who decides what gets maintained? Who has authority to merge changes? How are conflicts resolved? Can maintainers exclude certain users? What obligations do users have? How is maintenance labour funded? Who enforces rules? What happens when rules are violated?
Open source libraries typically have no governance in this sense. They have maintainers who make decisions unilaterally. Users who make requests. Platforms (GitHub, npm) that host code and can override maintainer decisions. But there are no institutions, no participatory structures, no accountability mechanisms, no conflict resolution processes beyond maintainer fiat or platform intervention.
Consider what happens when a maintainer becomes frustrated with corporate exploitation. In January 2022, Marak Squires sabotaged his own libraries, colors.js and faker.js. Colors had 23 million weekly downloads and nearly 19,000 dependent projects. Faker had 2.5 million weekly downloads and over 2,500 dependents. Squires added infinite loops that broke any application using them. He had warned fifteen months earlier.
“I am no longer going to support Fortune 500s with my free work. Take this as an opportunity to send me a six figure yearly contract or fork the project.”
What governance question does this reveal? Maintainers own the code. Users depend on it. Corporations extract value from it. But there is no mechanism for maintainers to establish terms, to require reciprocity, to exclude exploitative users. The only power maintainers have is destruction. When Squires exercised that power, GitHub suspended his account and npm removed the sabotaged versions within 24 hours. Platforms became governors, punishing the maintainer for breaking his own work while doing nothing about corporations extracting billions from his unpaid labour.
Two months later, Brandon Nozaki Miller sabotaged node-ipc, a library with over one million weekly downloads. He released versions 10.1.1 and 10.1.2 containing code that checked users’ IP geolocation. If located in Russia or Belarus, the code overwrote every file on their system with a heart emoji, deleting all data. This was protest against Russia’s invasion of Ukraine. It was tracked as CVE-2022-23812, a critical vulnerability with 9.8 CVSS score. One report claimed an American NGO in Belarus lost thousands of human rights documentation messages. npm removed the versions. But Miller’s GitHub account was not suspended.
What governance question does this reveal? Platforms enforce rules selectively. Marak protested corporate exploitation and got suspended. Miller created actual malware that destroyed data and his account remained active. The difference in response reveals that platforms govern based on unstated political criteria. They decide which protests are legitimate and which are malicious. They have absolute power with no accountability. Users cannot participate in these decisions. Maintainers have no recourse beyond sabotage, which may or may not be punished depending on who they target.
These incidents are not aberrations. They are symptoms of governance failure. When users feel entitled to free labour, when platforms can override any decision, the result is either exploitation (maintainers quietly burning out) or conflict (maintainers sabotaging their own work). Neither is sustainable.
What governance institutions require
Section titled “What governance institutions require”Elinor Ostrom identified eight principles that successful commons share. These are not recommendations. They are empirical patterns observed across centuries of functioning commons. Let us examine each and ask what it reveals about software library governance.
1. Clearly defined boundaries. Successful commons have clear membership. Who belongs to the community? Who has rights to use the resource? Open source deliberately refuses boundaries. Anyone can use the code. Anyone can fork it. This enables widespread adoption but prevents community formation. Without boundaries, there is no community to govern collectively. Users are anonymous, temporary, unaccountable. They take code and leave. There is no shared identity, no mutual recognition, no basis for collective decision making.
2. Rules matching local conditions. Ostrom found that successful commons adapt governance to specific contexts. Swiss alpine meadows have different rules than Spanish irrigation systems. But software libraries serve global, anonymous users with no shared context. There are no local conditions to match rules to. The library serves everyone equally, which means it serves no particular community. Whose needs should determine what gets maintained? When different users want contradictory features, how are priorities decided? Without local conditions, there are no grounds for situated judgement.
3. Collective choice arrangements. In successful commons, users participate in modifying rules. They have voice in governance. Open source has pull requests and issue discussions, but these are not collective choice. Maintainers decide what gets merged. Users request, maintainers grant or deny. This is voluntary dictatorship, usually benevolent but still unilateral. When Marak wanted to change terms, he had no mechanism except destruction. When Miller wanted to exclude certain users, he had no mechanism except malware. Collective choice would require users having actual power to participate in governance decisions, not just making requests that maintainers can ignore.
4. Monitoring. Someone watches for rule violations. In alpine meadows, community members monitor grazing. In irrigation systems, water guards check usage. Open source has no monitoring because there are no rules to violate. You can use libraries without contributing, without acknowledging maintainers, without reciprocating in any way. Corporations can extract billions in value from unpaid volunteers. There is no violation because there is no expectation. Monitoring would require agreement on what obligations users have, which would require collective choice, which would require boundaries defining who participates in that choice.
5. Graduated sanctions. Rule violations start with small penalties, escalate if repeated. First offense gets a warning. Persistent violations face exclusion. Open source cannot sanction because it cannot exclude. Anyone can fork and circumvent. Even social sanctions (public criticism, community censure) are limited when communities are diffuse and anonymous. When Marak sabotaged his libraries to protest corporate exploitation, the community sanctioned him, not the corporations. The only enforceable sanction in open source is platform intervention, which is unaccountable and selective.
6. Conflict resolution mechanisms. Ways to handle disputes without destroying the commons. Open source has some mechanisms (codes of conduct, moderators, steering committees for larger projects) but mostly relies on maintainer fiat or community fracture: fork and split. Neither resolves conflict. They avoid or fragment it. The colors.js and node-ipc incidents were conflicts with no resolution mechanism. Maintainers could not negotiate with corporations or with users they wanted to exclude. Their only option was destruction, which platforms then punished selectively.
7. Recognition of rights to organise. External authorities do not interfere with community governance. Open source licenses protect this. No one can prevent you from forking, from self-organising. But platforms can suspend accounts, remove repositories, override maintainer decisions. When GitHub suspended Marak, they interfered with his right to govern his own code. When npm removed sabotaged versions, they overrode maintainer authority. Platforms are external authorities with power to interfere, and they exercise that power based on unstated criteria. The right to organise is protected in theory but violated in practice whenever platforms decide intervention is warranted.
8. Nested enterprises. For larger commons, governance organised in multiple layers. Individual users belong to groups, groups belong to regions, regions coordinate at higher levels. Software has some nesting (projects belong to foundations, foundations belong to ecosystems) but it is loose and informal. There is no nested governance structure from individual library up to ecosystem level. Decisions at each level are unilateral, not participatory. The broader ecosystem has no mechanism to support struggling maintainers, to redistribute labour, to coordinate maintenance across dependencies.
Ostrom’s principles reveal what is missing: boundaries, collective choice, monitoring, sanctions, conflict resolution, rights protection, nested coordination. These are not technical problems. They are institutional problems. Open source libraries cannot function as sustainable commons because they lack the institutions commons require.
The actual state of maintenance
Section titled “The actual state of maintenance”Nadia Eghbal’s 2016 study Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure documents how libraries actually function. A 2015 survey found that 64% of actively used GitHub repositories relied on one or two developers. Most libraries are maintained by individuals, not communities. They cannot have Ostrom’s governance because they do not have the scale governance requires.
Eghbal distinguishes between contributor projects (many people contributing code) and maintainer projects (one or two people maintaining, many people using). Most projects are maintainer projects. The ratio of users to contributors is wildly skewed. For popular libraries, millions of users depend on code maintained by a handful of volunteers.
Maintainer burnout is endemic. Developers start projects out of personal need or interest, release them publicly, and find themselves responsible for infrastructure used by thousands or millions. They receive constant demands from users, expectations of free support, minimal compensation, no recognition proportional to impact. Many quit. Their projects become digital ruins: code that worked but no longer gets maintained, users who depend on infrastructure that is slowly decaying.
Corporate exploitation is systematic. Fortune 500 companies build products worth billions on infrastructure maintained by unpaid volunteers. Some companies have open source programs, but these typically fund high-visibility projects like Linux or Kubernetes. Not the mundane libraries everything depends on. The boring infrastructure that enables everything gets nothing. When Marak asked for a six figure contract in exchange for maintaining libraries that Fortune 500s depended on, he was not being unreasonable. He was asking for compensation proportional to value extracted. No one paid. So the commons failed.
The Heartbleed bug revealed this starkly. In 2014, a catastrophic security flaw was discovered in OpenSSL, the encryption library securing two thirds of the world’s HTTPS traffic. The bug existed for three years undetected. Passwords, credit cards, private communications were vulnerable. How did this happen? OpenSSL was maintained by a small team of volunteers. One developer, Stephen Henson, worked full time on it. The OpenSSL Software Foundation received approximately $2,000 annually in donations. One person, essentially unpaid, responsible for encryption infrastructure underpinning billions of transactions.
This is the empirical reality. Critical infrastructure maintained by overworked individuals. Chronically underfunded. Subject to catastrophic failure. Not because maintainers are incompetent, but because the governance structures required to sustain commons do not exist. Users extract value. Maintainers provide labour. Platforms enforce rules selectively. Corporations profit without reciprocating. There is no mechanism to redistribute labour, to fund maintenance sustainably, to establish terms that users must accept, to exclude exploitative actors, to resolve conflicts without destruction.
Gift circulation interrupted
Section titled “Gift circulation interrupted”Lewis Hyde’s analysis in The Gift helps explain why reciprocity fails. Gifts must circulate to remain gifts. When gift circulation stops, when gifts are hoarded or consumed without return, the gift turns into dead property. It is no longer alive in exchange. It is static, possessed, dead.
Open source libraries are given freely. Maintainers gift their labour. Users receive that gift. But users do not return gifts. They consume. The gift stops moving. What was intended as living exchange becomes one-directional extraction. Hyde argues this kills the gift. It becomes commodity, not because anyone wanted commodification, but because circulation broke down.
From Part 1 we examined Marx’s commodity fetishism: how commodities conceal the labour that produced them. Libraries are fetishised in this sense. We see capability, not maintainers. We call functions without thinking about who wrote them, who maintains them, who answers questions when they break. The labour vanishes into the library as object. We treat libraries like commodities we are entitled to consume. This is not malicious. It is structural. The abstraction that makes libraries useful also makes labour invisible.
Hyde’s gift analysis reveals why gratitude is not enough. Users express appreciation for maintainers, write thank you messages, acknowledge their work. But gratitude does not circulate the gift. Gifts circulate through reciprocity: you receive, you give in turn. What would reciprocal gift circulation look like? Users contributing code, writing documentation, fixing bugs, funding development, participating in governance. Not as payment (which would turn it into market exchange) but as participation in ongoing gift movement.
This mostly does not happen. Some users contribute. Most consume. The result is incomplete gift circulation. Gifts given but not returned. Maintainers exhausted by one-directional giving. When Marak sabotaged his libraries, he was terminating circulation that had already stopped functioning as circulation. When Miller created malware, he was refusing to gift labour to users he wanted to exclude. Both were attempting to reassert control over gift circulation in contexts where reciprocity had failed. Neither succeeded because neither could restore the institutions gift circulation requires.
But what would be required to build actual governance? New institutions. New social contracts. New funding models. New power relations where maintainers have authority beyond code ownership, where users have obligations beyond gratitude, where platforms are accountable beyond selective enforcement. These do not exist yet. They might never exist. The question is whether commons can function long-term without them, or whether the current precarious state will eventually collapse under its own contradictions.
Reflections
Section titled “Reflections”On software as commons of labour, not code
Software libraries appear as infinite, non-rivalrous commons. Anyone can use them without depleting the resource. But what requires governance is not code availability. It is maintenance labour. Labour is finite, exhaustible, rivalrous. When we frame libraries as commons, what exactly is the shared resource? Is it the code or the labour sustaining it? How does this reframing change what governance would need to address?
On governance without institutions
Ostrom’s principles describe functioning commons. Open source lacks most of these institutions. Yet libraries continue to function, if precariously. What does it mean to have commons without governance? Is the current state sustainable or does it depend on exploiting volunteer labour until burnout? Can commons function indefinitely on gift giving without reciprocity, or does incomplete circulation eventually kill the gift?
On maintainer power and platform governance
Maintainers own code but have limited power to set terms, exclude users, or require reciprocity. Their only leverage is destruction, which platforms punish selectively. Marak got suspended for protesting corporate exploitation. Miller’s account remained active despite creating actual malware. What does this selective enforcement reveal about who really governs? If platforms are de facto governors, what accountability do they have? How could maintainers gain actual power beyond code ownership?
On boundaries and community
Ostrom’s first principle is clear boundaries. Open source refuses boundaries: anyone can use the code. This enables widespread adoption but prevents community formation. Without boundaries, there is no membership, no collective identity, no basis for participatory governance. Could libraries have bounded communities while remaining open source? What would that look like? Or is the refusal of boundaries fundamental to open source, making Ostrom-style governance impossible?
On collective choice and participation
Most libraries are maintained by one or two people making unilateral decisions. Users can request features, report bugs, submit code, but maintainers decide what gets merged. This is not collective choice. What would participatory governance require? Voting mechanisms? Community consensus processes? Democratic structures? Would this improve sustainability or just add bureaucratic overhead to already overworked maintainers?
On sanctions and exclusion
Open source cannot sanction rule violations because it cannot exclude users. Anyone can fork and circumvent. But this means no accountability for exploitation. Corporations can extract billions from unpaid labour with no consequences. What would meaningful sanctions look like? Can commons function without ability to exclude bad actors? Or does the inability to sanction make exploitation structurally inevitable?
On funding and sustainability
Eghbal documents chronic underfunding. Most maintenance is unpaid. Some projects get corporate sponsorship, but not proportional to value extracted. What would sustainable funding require? Mandatory payments based on usage scale? Foundation support coordinated across ecosystems? Consulting revenue that takes time from maintenance? Every model has limitations. Is there a funding approach that actually works at scale, or is unpaid volunteer labour structural to how open source functions?
On platform power and infrastructure control
GitHub, npm, and similar platforms host code, manage distribution, enforce rules. They have power to suspend accounts, remove packages, override maintainer decisions. But they are not accountable to communities they govern. What would platform accountability look like? Community governance of infrastructure? Cooperative ownership? Migration to federated systems? The platforms are themselves infrastructure. Who governs the infrastructure that enables governance?
Weekly Task
Section titled “Weekly Task”No task this week and next.
Use this time to catch up on the readings and materials. Review the week’s concepts and start thinking about your summative projects. We’ll have time to discuss 1-1 next week.