The Spreadsheet Was the Constitution — Atelier

22 min read Original article ↗

Software picks up constitutional weight long before the by-laws catch up. It is where the rules live, and the first place anyone looks when a decision has to be defended.

Abstract

A co-op I helped run kept its weekly orders in a shared spreadsheet. We discovered, in the middle of a bad argument, that the spreadsheet had also been our constitution.

Software picks up constitutional weight long before the by-laws catch up. It is where the rules live, and the first place anyone looks when a decision has to be defended. But a spreadsheet was not built to carry that weight. Older governing documents had to earn properties we now take for granted: legibility, versioning, the ability to tell a draft from the real thing and to reconstruct ten years on what had been decided and why.

Wikipedia stumbled into one version of the problem; the DAO crashed into another. Smaller institutions live a quieter version of it every week, and mostly do not notice until something goes wrong. What is missing is answerability: the sense that some edits are acts the institution may one day have to account for.

Where the Rules Lived

Fizmat HouseI use a composite name here. The real dormitory was attached to a Physics, Math, and Informatics Lyceum in Baku, but naming it exactly would make this paragraph more biographical than the argument needs. was a small dormitory co-op I once helped run. It kept its weekly stock orders in a shared spreadsheet. I thought of it as plumbing. There was a column per member, rows for the things we bought in bulk — black tea, sugar cubes, buckwheat, sunflower oil, dish soap, the occasional jar of sour cherry preserves someone insisted everyone used — a formula at the bottom that summed each member’s contributions, and an unwritten rule that you did not change another member’s entries unless you had a very good reason.

Our by-laws ran the co-op no more than the spreadsheet did. When two members fell out one winter, the argument went on for the better part of a week: whose edit had overwritten whose, whether the version history could be trusted, why a grocery list was suddenly being held to the standards of a land registry. By the end of the week the spreadsheet was something closer to a constitution.

A Category Mistake

Looking back, we had confused a productivity tool with a constitutional one. There was nothing unusual about us in making the mistake. Tools get adopted because they save someone an afternoon, and then they pick up offices no one ever assigned them. Our treasurer ended up doing the job of a registrar, mostly on the grounds that she was the one who still remembered which cell the master formula lived in.

Lessig’s Code [1, 2] is about regulation by software; the CSCW tradition [3, 4] is about the work required to keep cooperation from falling apart. Both treat the software as the setting in which the interesting human business happens. Doctorow’s account of enshittification [5] is the version of the story that has had the most recent traction, and it is a story about incentives going bad. The pattern is narrower and earlier — the moment a tool quietly acquires a second job, before anything has gone wrong. A group then begins, without noticing, to govern itself through it.

What Paper Knew

A few years ago I went looking for what the co-op had decided about pets. I spent an afternoon scrolling our shared Google Sheet and an evening accepting that I was not going to find out. The relevant row said something about prior board approval. Revision history showed the row had been added, edited twice, and at some point picked up and moved to another tab. Whether any of those edits corresponded to a meeting, or whether the rule had been voted on by anyone, was simply not in the file. I asked the people who had been around longer than I had, but the rule’s origin had passed out of memory.

Paper has been doing institutional work for a long time, in ways paper as a substance can’t really take credit for. The properties we rely on accumulated slowly, by the same generational tinkering that produced the columns and conventions of a ledger [6]. Tamper-evidence came from inks that bled when scraped and from the eventual legal apparatus around forgery. The legibility of decisions was the work of generations of clerks. Canonicity was a matter of which copy lived in the cabinet and who held the key. Bowker and Star describe a version of this for classification systems [7]: how unremarkable materials gradually take on social and epistemic weight their users come to depend on.

One person’s diligence is a poor replacement for an office with a century of habits. Town clerks, registrars, secretaries, and archivists shared a professional habit of treating the record as part of the institution. Software-mediated organizations have no equivalent profession: the nearest substitute is whichever member happens to hold admin access.

What this added up to, by the nineteenth or twentieth century, was an arrangement in which an institution could lose its founders, its premises, and most of its membership, and still know what it had decided. Alterations showed. There was a moment, marked by signatures and seals, at which a draft turned into a binding act. The records survived custody changes. A stranger could walk into the archives and reconstruct what had happened. The whole arrangement was accumulation, deposited by centuries of institutional practice that any new group running on paper inherited automatically, and largely without noticing.

A shared spreadsheet inherits almost none of that. What it inherits instead is silent revision, the hosting vendor’s authority over its own product, and a canonical version which is, in practice, whichever copy you happen to be looking at. Spreadsheets are very good at the work they were designed for, and ours was useful every week. At some point I couldn’t pin down, it stopped being only a spreadsheet and became where the rules of the co-op lived. Nothing in the interface announced this. We went on editing the way we always had, and most of the time it still worked, which is part of why we kept doing it.

How Weight Accumulates

The shift was never deliberate. It accumulated through small mismatches between what the institution was doing and what its tools assumed, most of them too minor to argue about at the time.

Take judgment. The rule against editing another member’s column was always softer than it sounded; you could fix an obvious typo while the owner was on holiday, or rearrange columns and explain afterwards. You could break the rule the way people break rules, and apologize. Once the convention got translated into the spreadsheet’s permission system, most of that softness was gone. The system had two settings, edit and no-edit, and it could not tell a malicious edit apart from a friend covering for someone away that week.

Some decisions, in the spreadsheet, were cheap; others were disproportionately expensive. Adding a column was a click; removing one broke the formula at the bottom and was therefore not done. Discontinued products accumulated as ghost rows of zeros. The co-op had voted several times to stop carrying particular items, but the spreadsheet had nowhere to record those decisions except in the zeros themselves. Adding a new member was a new column. Removing a departed member would have required rewriting formulas, so departed members stayed. The order of the columns turned into a kind of seniority record that nobody had ever voted on. The treasurer’s column, by accident of founding, was always first.

There were also archives no one chose to keep. Every comment ever made on a cell sat there, visible to anyone who hovered. A heated exchange from a difficult month — about a member who had under-contributed, and about something said in reply that should not have been said — was still legible the next year, after the two had reconciled. Nobody had decided to keep it, and nobody could see how to remove it without losing the cell’s revision history, which the treasurer had come to rely on. The Drive folder was the archive by default, and whatever Google did with deleted revisions on the backend was, in effect, our retention policy.

Beneath all this, something slower was happening. Power was drifting from the institution to its vendor, which set the defaults and owned the file formats. When Google changed a default and the link became, for an afternoon, more permissive than the co-op had intended, the co-op’s privacy practices changed with it, until somebody noticed. When the version-history UI was redesigned, the evidentiary practices built around the old UI stopped working. Doctorow has a name for the broader pattern [5]: platform decay, the slow drift of bargaining position in the vendor’s direction.

General-purpose tools take on institutional responsibilities faster than groups can name them. By the time anyone notices, the product has already answered questions the institution never thought to ask: who may alter the record, how long a deleted message stays deleted. The answers are in defaults somewhere, or in a settings page that nobody on the board has the credentials to access in the first place.

All of this stays invisible until the spreadsheet is asked to testify. Until then it looks like office equipment. Then a trust breaks, or a vendor changes a default, or somebody is asked in a meeting what exactly was said in February of last year, and suddenly people are squinting at the edit history with the solemnity of a court record. The chat log gets searched as though somebody had been keeping it. The shared folder, until yesterday a place to misplace PDFs, is now an archive. Records did exist, in the way accidental records do; a comment thread survives, and its survival starts to look like a record, but it was never made to be one. The version history offers a story, rarely the one anyone would have written on purpose, because nobody had been thinking of writing one at all.

Star [8] observed that infrastructure becomes visible on breakdown. This kind only surfaces once you have begun asking it for authority, and by then someone else has usually inherited the workspace and the credentials to whichever shared account is currently in charge, along with whatever conventions the previous custodian forgot to write down.

Wikipedia and The DAO

There are cases where this drift doesn’t happen, because the institution and its constitutional material grew up together. The clearest example I know is Wikipedia [9, 10].

Wikipedia’s governance lives in software the institution itself controls. Article histories, talk pages, protection levels, the requests-for-comment process, the arbitration archives. These are how the encyclopedia remembers what it has done, and they are mostly shabbier than that list makes them sound: half the talk pages are unreadable, the templates have templates, and a fair number of policies are enforced more by who shows up than by what they say. Still: the Seigenthaler incident is inside that machinery today. In May 2005, a hoax biography accused the journalist John Seigenthaler of involvement in the Kennedy assassinations and stood uncorrected for more than four months. A reader coming back two decades later can walk through the original false article, the moment of discovery, the talk-page argument, Seigenthaler’s response in USA Today, and the policy that came out of it: the biographies-of-living-persons rule, adopted that December and still binding. The rule and the argument that produced it sit in the same place. That readability didn’t happen by itself. It came from a design tradition that took the constitutional role of the software seriously, sometimes before there was decent language for what it was doing.

The encyclopedia is not, however, especially legible from inside. Its governance pages sprawl across hundreds of cross-linked acronyms (BLP, NPOV, V, RS, COI), opaque to newcomers and gameable by veterans; arbitration eats weeks of unpaid labor for outcomes that are sometimes capricious; the loudest editors set norms more reliably than the written policies do; revision deletion and oversight suppression are available to a small number of accounts most readers will never identify; and enforcement is uneven enough that the apparent universality of the rules is partly a fiction.

What it has, and what the co-op didn’t, is something I want to call answerability. The records aren’t necessarily readable, or fair, or complete. What they are is the kind of thing a later question can be put to. Somebody who wants to know why a decision went the way it did has a place to put the question and a body that can be made to answer it, even badly. The co-op had records too, in the loose sense that a comment thread is a record, but nothing in them was shaped to be asked anything. Wikipedia’s were. That is most of the difference.

The other instructive tradition starts from almost the opposite pole. Tools such as Loomio and Polis were designed with deliberation in mind and do useful work for certain communities at modest scale. Blockchain governance pushed the ambition much further. DAOs tried to make rules durable enough that later embarrassment couldn’t easily revise them: an institution designed to refuse the kind of revision its builders had been relying on, tacitly, from every prior institution in their lives.

In April 2016, an investment vehicle called The DAO was deployed as a smart contract on the Ethereum blockchain. By late May it had attracted something on the order of $150 million worth of ether [11], which at the time was a number that confused people who tried to say it out loud. The contract specified, in code, how proposals would be made, votes counted, and funds disbursed. As constitutional material it looked unimpeachable on paper: tampering would show up cryptographically; the network could agree on which version counted.

On 17 June 2016 an attacker exploited a recursive-call bug and drained the funds. By the contract’s own terms, the transfers were legitimate. The institution had no way to disagree with that verdict from inside its own constitutional material. The only correction available was a fork, which amounted to founding a new charter, and the fork itself split the network: some participants refused to follow it and kept running what they considered the real chain. The DAO had assumed that the rules and the institution were the same thing. Once the rules produced an outcome the institution wouldn’t accept, there was nothing for the design to do except be overridden from outside.

The co-op’s ordinary edits became constitutional only in retrospect, when conflict forced them to serve as evidence. The DAO went the other way: its rules executed with such finality that correction meant breaking the material in which they were written. Ordinary institutions need to operate between these poles, with rules that bind without becoming traps, that a group can obey and still revise. Ostrom’s commons institutions occupy that middle ground: their rules bind because the people subject to them also have standing to maintain and revise them [12]. Wikipedia took neither route. It built protection levels for contested pages, a revert-and-discuss convention enforced both socially and by software, and an arbitration committee that can override the policies it was constituted to defend. Most small institutions have none of this. They have a folder called “Admin.”

I am not suggesting every co-op or union or neighborhood association should run its own MediaWiki. The overhead would be absurd, and most groups have no business maintaining infrastructure for ten people. The comparison is meant only to show that the problem is a design gap, and not something inherent in software.

Designing for Constitutional Weight

If software is going to carry constitutional weight, it has to give up some of the things we have come to expect software to do. Certain edits have to slow down. There needs to be an actual line between a draft and an act. The system has to keep records that someone, later, will wish had discreetly vanished. And a few changes have to be hard to make alone.

Suppose the co-op decides to change its order policy from a maximum of three orders per member per week to a maximum of one. In a spreadsheet built for this kind of weight, the change wouldn’t happen at the speed of typing. The proposing member would mark the cell as a draft, write the question down in a form that could be answered yes or no, and then stop. A banner would appear in everyone’s view of the artifact:

+----------------------------------+
| ADOPTION PENDING                 |
+----------------------------------+
| Q: Limit weekly orders to 1 per  |
|    member?                       |
|                                  |
| Change: F2: MAX_PER_MEMBER 3->1  |
|                                  |
| Proposed by Barish, 2018-01-12   |
|                                  |
| Signatures (2 of 2 needed):      |
|   [ Sign as Murad   ]            |
|   [ Sign as Ibrahim ]            |
|                                  |
| Reverting requires the same      |
| procedure.                       |
+----------------------------------+

Until two members sign, the cell still shows the old value. After they sign, it shows the new one, and below it, visible on hover and included on export, a record of the question, the proposer, the signatories, the timestamps, and the value that used to be there. Later edits are recorded as post-adoption changes. Reverting goes through the same procedure. The interaction is more awkward than autosave, but that’s the point. The cost of binding the group has to land somewhere visible: in the proposal, in the wait, in the moment when someone signs. Treating a confirmation dialog as a signature is a small part of how institutions lose track of what they have done.

Which version counts

The same distinction applies to which version counts. In most collaborative tools the canonical version is “whatever the server last broadcast,” which is fine for a project plan and a poor answer for a file that carries rules. For constitutional material the question has to be settled at the data layer, before the UI gets to render anything. The local-first research tradition [13] has worked out answers — CRDTs, version histories with explicit merge points, content-addressed storage — that productivity software has mostly not absorbed. When a dispute arrives, the canonical version will be whatever the data layer decided it was, and the institution will have to argue from there.

Witness in the record

Witness has to move from the edge of the system into the record itself. Audit logs typically sit alongside the record rather than inside it. They are useful in compliance settings, available to administrators, and ordinary members never see them until something has already gone wrong. Constitutional material needs witness folded into the act. The two signatures in the sketch above are what binds the change; they aren’t a report that the change happened. Strip the witness out and you’ve stripped part of the act out with it.

What the institution carries away

The last piece is what the institution can take with it. Export is usually a grudging courtesy: a CSV missing half the structure, a PDF that preserves the look of the screen and almost none of its institutional meaning. For constitutional material, export is the form in which the institution survives the tool. It has to carry the adoption records, the version history connecting them, and enough of the local conventions to make any of it intelligible to a stranger. This is the territory local-first work has gone after most directly, and the territory productivity software has the strongest incentives to ignore.

A useful discipline is to picture the tool after failure. The company has been acquired; the servers are gone; someone still needs to know whether a particular decision was properly made. What the tool wrote down, in formats a stranger can still open, is what the institution now consists of.

What all of this asks for is software built on the assumption that someone is eventually going to come back and ask what happened, and that some of its records are going to have to answer. The adoption banner above is one way of admitting it. There are others. Most tools refuse the question.

On Friction

Constitutional material gets its weight from friction. Witnessed adoption is the obvious case: responsibility has to be distributed across people in a room before the act can bind. A frictionless click cannot do that work; nobody is on the hook for it.

Software design has spent its working life going the other way. Each generation of tools is smoother than the last, and the smoothing is what counts as improvement. A tool that adds friction at the right moments will lose, in any side-by-side demo, to a tool that adds friction nowhere. Effortlessness sells, and the institutions whose work used to depend on a bit of drag are among the buyers.

A friend on a small zoning board described a meeting last year that spent its first hour trying to figure out when they had approved a particular variance. The email chain ran to forty-some messages. Someone had said yes in a thread started for something else. On paper, the question of whether that yes counted as a board action would not have come up; on email, the board had no way to answer it except by voting again. The original decision wasn’t visible anywhere that anyone could point to.

The response can’t be to add friction everywhere. A governance tool that demanded ceremony at every keystroke would be intolerable. Some moments inside a tool carry an act, others are just typing, and the tool has to know the difference. Robert’s Rules of Order draws this distinction with a vocabulary of motions, amendments, points of order, and previous questions, each with its own procedure [14]. Software has, for the most part, refused to make the distinction at all. Every change is the same kind of change.

What institutions wanted from software wasn’t speed at the cost of everything else. They wanted their decisions to be defensible months later, against the partisan reading the bylaws looking for an opening, and they wanted their bad decisions to be revisable, because some fraction of what any body ratifies should never have been ratified. These wants run in opposite directions. A spreadsheet resolves the tension by ignoring it. Robert’s Rules resolves it through procedure: rescission requires its own motion, its own vote, an explicit acknowledgment that something is being walked back. No productivity tool I know of has anything like that built in.

After the Spreadsheet

After the dispute, we tried to fix what had broken. Over two long Saturdays, in a Google Doc, we wrote down the rules: who could edit whose column, when one member could update another’s, what to do with a column when a member left. The conventions the spreadsheet had been silently enforcing for years, finally spelled out.

The document was thoughtful. The spreadsheet had no idea it existed.

Over the next year the two drifted, the way written constitutions and lived practice tend to when nothing material holds them together. The cells kept getting edited. The rules sat in a different folder, waiting to be read by someone who never quite needed to. Nobody noticed the gap until the next argument made it visible. The institution had understood that it needed constitutional material, and had produced some in the only form its tools made available: another document, in another folder, that the spreadsheet had no reason to consult, and didn’t.

Software that knew when it had been asked to carry institutional memory would have helped. Ours didn’t, and couldn’t have. It was, the entire time, exactly as easy to amend as it had been on the day it was created.

References

  1. Lawrence Lessig. 1999. Code and Other Laws of Cyberspace. Basic Books. cite

  2. Lawrence Lessig. 2006. Code: And Other Laws of Cyberspace, Version 2.0. Basic Books. cite

  3. Jonathan Grudin. 1994. "Groupware and Social Dynamics: Eight Challenges for Developers." Communications of the ACM 37, 1, 92-105. doi:10.1145/175222.175230. cite

  4. Kjeld Schmidt and Liam Bannon. 1992. "Taking CSCW Seriously: Supporting Articulation Work." Computer Supported Cooperative Work (CSCW) 1, 1-2, 7-40. doi:10.1007/BF00752449. cite

  5. Cory Doctorow. 2023. "The 'Enshittification' of TikTok". Wired, January 23. cite 1, cite 2

  6. Henry Petroski. 1992. The Evolution of Useful Things. Alfred A. Knopf. cite

  7. Geoffrey C. Bowker and Susan Leigh Star. 1999. Sorting Things Out: Classification and Its Consequences. MIT Press. cite

  8. Susan Leigh Star. 1999. "The Ethnography of Infrastructure." American Behavioral Scientist 43, 3, 377-391. doi:10.1177/00027649921955326. cite

  9. Joseph M. Reagle, Jr. 2010. Good Faith Collaboration: The Culture of Wikipedia. MIT Press. cite

  10. Andrea Forte, Vanessa Larco, and Amy Bruckman. 2009. "Decentralization in Wikipedia Governance." Journal of Management Information Systems 26, 1, 49-72. doi:10.2753/MIS0742-1222260103. cite

  11. Quinn DuPont. 2017. "Experiments in Algorithmic Governance: A History and Ethnography of 'The DAO,' a Failed Decentralized Autonomous Organization." In Bitcoin and Beyond: Cryptocurrencies, Blockchains, and Global Governance, edited by Malcolm Campbell-Verduyn, 157-177. Routledge. doi:10.4324/9781315211909-8. cite

  12. Elinor Ostrom. 1990. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge University Press. cite

  13. Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, and Mark McGranaghan. 2019. "Local-First Software: You Own Your Data, in Spite of the Cloud." In Proceedings of the 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software, 154-178. Association for Computing Machinery. doi:10.1145/3359591.3359737. cite

  14. Henry M. Robert, III, Daniel H. Honemann, Thomas J. Balch, Daniel E. Seabold, and Shmuel Gerber. 2020. Robert's Rules of Order Newly Revised, 12th ed. PublicAffairs. cite