Social and Institutional Computing
Software as a medium of governance — how the systems we build distribute power inside groups, organisations, and publics, and what designers owe to the institutions their software half-creates.
A small co-op I once helped used a shared spreadsheet to decide how their weekly stock orders were placed. There was a column for each member, a formula at the bottom that summed the contributions, and a quiet convention — never written down — that you did not change another member’s row. The spreadsheet ran the co-op as much as the by-laws did. Probably more. When two members fell out, the dispute that ended their working relationship was not about money or principle; it was about whose edit had overwritten whose, and whether the version history could be trusted. The artefact had become a constitution, and nobody had noticed when it happened.
This is the territory I want a name for: software functioning as infrastructure for collective life — for groups, teams, communities, organisations, publics — and the way that role tends to be invisible to both the people who build the software and the people who live inside it. Lawrence Lessig’s Code is Law is the obvious anchor; Code v2 generalises the argument, and the long CSCW tradition (going back at least to Grudin’s Groupware and Social Dynamics, 1994) gives the empirical ballast. Yochai Benkler’s Wealth of Networks, Cory Doctorow’s writing on platform decay, and Elinor Ostrom’s older but indispensable Governing the Commons round out the apparatus. I will not return to citations after this paragraph.
Why “social and institutional” rather than just “social”
Most of the recent literature on this subject is framed as social computing — a phrase that, by usage, has come to mean social networks, content moderation, online communities. That work is important, and it overlaps with mine, but the framing leaves out a category I think matters more.
The category is institutions: schools, courts, hospitals, unions, co-ops, neighbourhood associations, small companies, large bureaucracies, standards bodies, scientific fields. These are not platforms and not publics. They are persistent structures with rules, roles, memory, and a life span longer than any of their members. And they have, over the past two decades, quietly migrated most of their operations onto general-purpose software that was not designed with their constitutional weight in mind.
The result is that an institution’s actual rules — who may speak, who may sign, what counts as a record, what is reversible — increasingly live in the configuration of software products. The by-laws still exist on paper, but the by-laws are no longer where the institution is run.
What software is doing inside institutions
A few patterns worth naming.
The most visible thing software does, when it lands inside an institution, is codify the previously informal. Practices that used to live as conventions, with all the slack conventions allow, become hard constraints once they are encoded. The room for negotiated exceptions narrows. This is sometimes good — predictability and accountability go up — and sometimes ruinous, when the encoded version misses the very exceptions that kept the institution humane.
It also changes the cost of certain actions, often asymmetrically. Sending a message becomes free; reading messages becomes expensive. Adding a member becomes one click; removing one is buried three menus deep. Because institutions adapt to the gradient of effort their tools present, these asymmetries reshape behaviour over time, even when no written rule has changed.
Less remarked but equally consequential, software creates archives that institutions did not ask for. Chat logs, edit histories, access logs, drafts. The past becomes legible in ways the institution may not have meant to commit to, and the question of who can read it later becomes a political question whether or not anyone phrases it that way.
And underneath all of these, software redistributes power between the institution and its vendor. The vendor controls features, pricing, and continuity. When the vendor changes a default, the institution’s operations change with it. This is the structural backdrop to Doctorow’s argument about platform decay: the bargaining position drifts, slowly at first, then all at once, in the vendor’s direction.
None of this requires bad intent on anyone’s part. It is what happens when general-purpose tools become load-bearing parts of structures that needed bespoke ones.
Where my interest lies
I am drawn to the design of systems that take their institutional role seriously — that try to be honest about the fact that they are governance infrastructure as much as they are productivity software. There is some genuinely promising work happening here.
Federation, in the ActivityPub sense, is the most visible example. By making the protocol the institution and the server a tenant, federation returns some of the bargaining power to the local community, at the cost of the seamlessness a centralised platform offers. Whether that trade is sustainable at scale is one of the open questions in the field.
Less visible, and to my mind more interesting, is the slow growth of governance-aware productivity software — version control with explicit review, document systems with provenance, discussion tools with explicit decision records, voting and deliberation tools that are honest about their assumptions. These are not new ideas, but they are increasingly available as components rather than as bespoke builds.Loomio, Polis, the various decision-record conventions, and the open-source governance docs at projects like Rust and Kubernetes are good places to look for working examples.
Open questions
The basic question is what a piece of software should do differently when its users are members of an institution rather than individuals. Defaults are the next thing — how to design them so they respect the institution’s existing constitution rather than silently rewriting it. There is also the question of whether software design has anything to learn from separation of powers, or whether that is a habit imported from constitutional law that does not generalise. And when a platform changes a default, the question of what an institution that depends on it deserves — in the way of notice, migration support, or veto — has barely begun to be asked.
There is one question I have not seen posed often enough, which is about succession. Institutions outlive their founders; software, often enough, does not outlive its vendor. What does it look like to build collaborative software whose canonical state can survive the company that made it, the way an institution’s records used to survive its founders? This is Local-First Software software taken seriously as civic infrastructure.
Some examples I keep returning to
The Wikipedia governance system is the standard example, and it deserves the standing — it is the only large institution I know of whose core decision-making process lives in software that the institution itself controls. Open-source projects like Debian and Rust have built governance-on-software apparatuses worth studying, especially their written processes for conflict and succession. On the other end, the gradual hollowing-out of municipal records into vendor-controlled SaaS is a quieter, larger, and probably more consequential case study, because its failure mode is not dramatic — it is a slow loss of institutional memory measured in licence terms.
A working stance
The hardest thing about this area is that the design choices that matter most are usually invisible to the user at the moment they are made. A default about who can edit, an unstated retention policy, a quiet change in a third-party API — these settle into the institution’s bones long before anyone formulates them as policy.
The ambition I am working toward is software that is honest about being infrastructure: that names the powers it is exercising on behalf of its users, that makes those powers reviewable, and that leaves the institution something it can hand to the next generation of its members. That is more than a UX problem, and not one the law alone can solve. It is the design problem this area is about.