Mallebare software: Gebruikersregie herstellen in een wereld van afgesloten apps

De oorspronkelijke belofte van persoonlijke computers was een nieuw soort klei: een mallebaar materiaal dat gebruikers naar eigen wil konden vormgeven. In plaats daarvan kregen we apparaten: op afstand gebouwd, verzegeld en onveranderlijk. Wanneer je tools niet werken zoals je ze nodig hebt, stuur je feedback en hoop je op het beste. Je wordt gedwongen je workflow aan te passen aan je software, terwijl het andersom zou moeten zijn.

In dit essay schetsen we een visie op mallebare software: tools die gebruikers met minimale wrijving kunnen aanpassen aan hun unieke behoeften. Aanpassing wordt routine, geen uitzondering. Adaptatie vindt plaats op het punt van gebruik, niet via engineeringteams bij verre corporaties.

Het realiseren van deze visie vereist dat we veel barrières aanpakken. Van programmeertalen tot besturingssystemen en app-stores; elke laag van het moderne computerveld is gebouwd op de aanname dat gebruikers passieve ontvangers zijn in plaats van actieve co-creators. Wat we nodig hebben zijn computersystemen die elke gebruiker uitnodigen om geleidelijk een maker te worden. Tools die samengevoegd kunnen worden tot aangepaste workflows, in plaats van gesilo'de monolithische apps. Systemen die lokale groepen ondersteunen in gemeenschappelijke creatie.

Gelukkig is er veel inspiratie putten uit zowel onderzoek als commerciële producten van de afgelopen decennia. In dit essay synthetiseren we ideeën uit dat werk, evenals lessen die we hebben geleerd van jarenlang testen van onze eigen prototypes. Of je nu een softwareontwikkelaar, een onderzoeker of een computergebruiker bent, we nodigen je uit om ons te vergezellen in het streven naar een wereld van mallebare software.

Motivatie

We willen onze omgevingen aanpassen

Omgevingen doen ertoe. Om ons beste werk te doen en ons beste leven te leiden, hebben we ruimtes nodig waarin we elk ons unieke potentieel kunnen uiten.

Een gitaarbouwer richt zijn werkplaats zo in dat zagen, hamers, beitels en vijlen precies op de juiste plek liggen. Hij kan ook nieuwe tools bouwen wanneer dat nodig is voor het beste resultaat—een houten blok als steun, of een tang die is weggeschuurd tot de juiste vorm.

In de loop der jaren stelt een thuiskok geleidelijk een combinatie van messen, snijplanken, potten en pannen samen, en vindt degene die het beste werken. Ze kunnen haken aan het plafond installeren en planken verplaatsen om hun workflow te ondersteunen—of het nu gaat om het koken van doordeweekse diners of het organiseren van uitgebreide weekendmaaltijden.

Dit zijn alledaagse situaties. In de fysieke wereld komt het vormgeven van onze omgevingen natuurlijk, omdat de fysieke realiteit mallebaar is. Kleine aanpassingen—een post-it op de muur plakken, lades herschikken, een meubelstuk verplaatsen—kunnen direct worden gedaan zonder toestemming te vragen. We kunnen ook grotere veranderingen aanpakken die meer inspanning en vaardigheid vereisen, zoals het bouwen van een werkplaats of het renoveren van een keuken. En als we die vaardigheden zelf missen, kunnen we hulp inschakelen van vakmensen in onze lokale gemeenschap.

Wanneer we werken en leven in een fysieke ruimte die we controleren, hebben we de neiging deze te laten evolueren om aan onze eigen behoeften te voldoen. Zoals Stewart Brand schrijft in zijn boek How Buildings Learn: "Leeftijd plus adaptiviteit is wat een gebouw geliefd maakt. Het gebouw leert van zijn bewoners, en zij leren van het gebouw."

Massa-geproduceerde software is te rigide

Tegenwoordig brengen we steeds meer tijd door in omgevingen die zijn gebouwd uit code, niet uit atomen. We hebben in deze verschuiving veel mogelijkheden gewonnen—we kunnen onmiddellijk samenwerken over continenten heen en duizenden bestanden in een oogwenk doorzoeken. Maar we verliezen ook iets belangrijks: het vermogen om onze omgevingen aan te passen en ze van onszelf te maken.

Een voorbeeld: een van de auteurs werkte in een softwareteam dat zijn werk bijhield met indexkaarten op een muur. Het team liet de tracker constant evolueren—lijnen werden verplaatst, checklists verschenen, speciale zones van kaarten ontstonden rond het hoofdgrid. De vloeibaarheid van het middel stimuleerde de vloeibaarheid van het proces.

Later stapte het team over op een webgebaseerde issue tracker om remote samenwerking mogelijk te maken. Er was echter geen manier om een speciale zone van kaarten te modelleren of weer te geven, dus liet het team dat deel van hun proces vallen. Verdere proceswijzigingen kwamen tot stilstand. Voorheen kostte het uitproberen van nieuwe ideeën minuten; nu kostte het uren aan configuratie-gevechten, als het überhaupt mogelijk was. De computerisering van het werk leidde tot een verlies van agency (regie).

De rigiditeit van software is niet slechts een klein ongemak. Het kan mensen die belangrijk werk doen ernstig belemmeren. De arts en schrijver Atul Gawande heeft beschreven hoe computerisering in de medische professie leidt tot recordniveaus van burn-out. Artsen sloegen vroeger irrelevante velden over bij het invullen van papieren formulen; nu dwingt de software hen om die velden in te vullen, en ze hebben geen macht om die software-regels aan te passen. Zoals Gawande over een arts zegt: "De extra tijd besteden maakte haar niet boos. De zinloosheid ervan wel."

Wanneer software niet aan je behoeften voldoet, kun je proberen feedback te geven aan de ontwikkelaars—maar dat resulteert meestal niet in directe actie. Wanneer verschillende gebruikers verschillende behoeften hebben, kan een gecentraliseerd developmentteam onmogelijk ieders problemen oplossen. Bovendien, wanneer een ontwikkelaar probeert te veel oplossingen in één product te proppen, is het resultaat een opgeblazen chaos. Om deze valkuil te vermijden, leren goede productteams om de meeste gebruikersverzoeken af te wijzen, waardoor een lange staart van nichebehoeften onvervuld blijft.

Het lijkt onvermijdelijk dat onze specifieke eisen niet worden bediend door onze software—maar dat is alleen omdat we er als vanzelfsprekend vanuit zijn gegaan dat software wordt gecontroleerd door gecentraliseerde developmentteams. Wat als we meer controle zouden verschuiven naar de gebruikers die hun eigen behoeften kennen?

Gawande vertelt het verhaal van een neurochirurg die met een IT-analist samenwerkte om het medische registratiesysteem van zijn afdeling aan te passen. "Al snel hadden ze een snellere, intuïtievere interface gebouwd, specifiek ontworpen voor neurochirurgische spreekuren." De eisen werden gedreven door de behoeften van hun specifieke afdeling, niet door de behoeften van elke arts in het land. Naast het directe productiviteitsvoordeel voelden de artsen zich meer in controle over hun tools—een tegengif voor burn-out.

Hoewel dit verhaal inspirerend is, is het eerder de uitzondering dan de regel, omdat de tools en infrastructuur die we gebruiken om software te implementeren, gebruikers behandelen als passieve ontvangers in plaats van actieve co-creators. Software is georganiseerd in monolithische applicaties in plaats van flexibele, remixbare toolkits. Customisatie vereist programmeervaardigheden die de meeste mensen niet hebben—en bovendien is de meeste software closed source. Software wordt niet geleverd met de tools om de software zelf te bewerken. App-stores zijn ontworpen voor bedrijven die software distribueren aan consumenten, niet voor amateurs die tools delen met hun vrienden. Dit is een systeem van industriële massaproductie, niet van kleinschalig vakmanschap.

Om eerlijk te zijn, heeft massa-geproduceerde software veel voordelen gebracht. We hebben toegang tot een breed scala aan hoogwaardige applicaties tegen redelijke prijzen. Software heeft vooruitgang geboekt in betrouwbaarheid, toegankelijkheid en beveiliging. Ontwikkelaars hebben bedrijfsmodellen gecreëerd die teams duurzaam kunnen betalen om continu verbeterende software te leveren.

Maar zoals deze verhalen laten zien, staat inflexibele, massa-geproduceerde software ook in de weg. Hoe meer je afwijkt van de gemiddelde gebruiker, hoe meer de voordelen van customisatie opwegen tegen de voordelen van professionele afwerking. Iedereen is op een bepaalde manier uniek—misschien heb je sterke meningen over tools voor schrijven, muziek maken, discussiëren of projecten plannen. Wanneer je specifieke behoeften hebt, is agency van cruciaal belang.

Ons doel: mallebare software

We voorzien een nieuw soort computing-ecosysteem dat gebruikers agency geeft als co-creators. We noemen dit idee mallebare software—een software-ecosysteem waarin iedereen zijn tools met minimale wrijving kan aanpassen aan zijn behoeften.

De term "malleable software" heeft een lange historie en is niet onze uitvinding. Recentelijk is het gebruikt in onderzoek, waaronder de doctoraatsthesis van Tchernavskij en Webstrates van Klokmose et al. Hoewel de oorsprong van de term onduidelijk is, is het mogelijk begonnen bij Alan Kay, die het idee van software als "klei" introduceerde in zijn artikel Computer Software uit 1984.

Met "software-ecosysteem" bedoelen we de brede technische en culturele omgeving rondom software en haar gebruikers. Malleabiliteit is geen smal technisch probleem.

Met "iedereen" bedoelen we dat brede toegankelijkheid het doel is. En hoewel individuele zelfredzaamheid nuttig is om te cultiveren, is samenwerking met de lokale gemeenschap ook waardevol.

Wanneer we spreken over het "aanpassen van tools", bedoelen we een hele reeks aanpassingen, van kleine tweaks aan bestaande software tot diepgaande renovaties en het creëren van nieuwe tools die goed samenwerken met bestaande. Adaptatie betekent niet dat men opnieuw vanaf nul moet beginnen.

Ten slotte is "minimale wrijving" essentieel. Het bewerken van onze tools moet snel gaan. Het moet licht aanvoelen. Idealiter is het iets dat we kunnen doen op het moment dat een behoefte ontstaat, zodat we direct kunnen terugkeren naar de taak die voor ons ligt.

Bestaande benaderingen

Je vraagt je misschien af: hoe zit het met instellingen of plugins? Er zijn inderdaad veel technieken voor het aanpassen van software die bewonderenswaardig zijn. Ze hebben echter ook limieten die voorkomen dat ze de bovenstaande doelen volledig bereiken.

Instellingen

Instellingen zijn een gebruikelijke manier om het gedrag van een applicatie te wijzigen. Als de juiste instelling bestaat, kun je een selectievakje aanvinken en verdergaan met je dag.

Maar instellingen bieden alleen controles die de applicatie-ontwikkelaars hebben bedacht om bloot te stellen, waardoor je vastloopt als er geen instelling is die doet wat je wilt. Instellingen neigen bovendien te lange lijsten van onsamenhangende selectievakjes te worden zonder coherent mentaal model dat ze verbindt.

Plugins

Een manier om verder te gaan dan de bandbreedte van een centrale ontwikkelaar is het toestaan van plugins van derden die het gedrag van een applicatie uitbreiden. Een goed pluginsysteem maakt het voor gebruikers gemakkelijk om met minimale inspanning te beginnen met aanpassen, omdat ze plugins kunnen installeren die anderen hebben gemaakt. Een plugin-API heeft bovendien het voordeel dat het contract tussen de onderliggende applicatie en diverse extensies stabiliseert, wat helpt bij het voortdurend onderhoud.

Echter, pluginsystemen kunnen het gedrag van een app nog steeds alleen op specifieke, geautoriseerde manieren wijzigen. Als er voor een bepaalde aanpassing geen plugin-oppervlak beschikbaar is, heeft de gebruiker pech. (Sterker nog, de meeste applicaties hebben helemaal geen plugin-API, omdat het ontwerpen van een goede API veel werk is!)

Er zijn ook andere problemen. De stap van het installeren van plugins naar het zelf maken van een plugin is een kloof die moeilijk te overbruggen is. Bovendien heeft elke app zijn eigen plugin-systeem, waardoor het doorgaans onmogelijk is om plugins tussen verschillende apps te delen.

Modding

Wanneer instellingen en officiële extensie-API's niet ver genoeg gaan (of helemaal niet worden aangeboden), kunnen gebruikers soms de controle overnemen via "permissionless modding" (aanpassingen zonder toestemming). Browser-extensies kunnen bijvoorbeeld ingrijpen in de gebruikersinterface van een website en nieuw client-side gedrag injecteren zonder dat er hooks hoeven te worden blootgesteld door de oorspronkelijke ontwikkelaar.

De term "modding" lijkt afkomstig te zijn uit video game modding. Voorbeelden van modding in andere domeinen zijn de historie van Mac kernel hacking en de pixel-gebaseerde reverse-engineering van interfaces door Prefab. Modding overlapt aanzienlijk met het concept van "adversarial interoperability".

Permissionless mods zijn toepasbaar in een veel breder scala aan scenario's dan officieel ondersteunde plugin-API's. Ze kunnen zelfs worden gebruikt wanneer de oorspronkelijke ontwikkelaar actief tegenstaan tegen een bepaald type extensie—adblockers prioriteren bijvoorbeeld de belangen van gebruikers boven die van websites.

Mods hebben echter hun eigen beperkingen. Ze vereisen vaak tedious reverse-engineering. Ze zijn vaak moeilijk te onderhouden naarmate de onderliggende applicatie evolueert. Verschillende mods voor dezelfde app werken vaak niet schoon samen.

Ook de limieten van het onderliggende platform kunnen beperkend werken—browser-extensies kunnen bijvoorbeeld het server-side gedrag niet wijzigen. Bovendien is er, net als bij andere plugins, een grote kloof tussen installeren en creëren. Om een browser-extensie te maken, moet je de browser verlaten, code schrijven en een gepackt code-artefact distribueren.

Open source

De open source-beweging promoot het idee van het distribueren van broncode, zodat gebruikers eigenaar kunnen zijn van hun software, eraan kunnen bijdragen en, indien nodig, hun eigen versie kunnen maken die beter aan hun behoeften voldoet. Dit is een positieve kracht geweest en is een belangrijk ingrediënt voor malleabiliteit.

Maar toegang hebben tot de code betekent niet dat er minimale wrijving is. Het wijzigen van een serieuze open source-codebase vereist meestal aanzienlijke expertise en inspanning. Dit geldt zelfs voor een kleine wijziging, zoals het veranderen van de kleur van een knop. Zelfs voor een ervaren programmeur is het opzetten van een development-omgeving en het kennismaken met een codebase een drempel die niet zomaar terloops wordt overbrugd.

AI-ondersteunde codering

Tot slot is het waardevol om een actueel onderwerp aan te stippen. Zullen AI-tools mallebare software automatisch realiteit maken?

Historisch gezien was een van de grootste puzzels bij het democratiseren van softwarecreatie het uitzoeken van hoe gewone mensen computerprogramma's konden schrijven. Veel benaderingen zijn geprobeerd: programmeertalen met vriendelijkere syntax, macro-opnamesystemen voor programmeren-door-demonstratie, visuele live-programmeeromgevingen, en meer.

Tegenwoordig bieden grote taalmodellen een nieuwe benadering: vage ideeën uitgedrukt in natuurlijke taal automatisch omzetten in code. Er is nu een beweging naar een wereld waarin iedereen een webapplicatie kan genereren vanuit een chat, zonder programmeerervaring.

We denken dat deze ontwikkelingen een opwindend potentieel hebben, maar AI-codegeneratie alleen lost niet alle barrières voor malleabiliteit op. Zelfs als we aannemen dat elke computergebruiker perfect code kan schrijven en bewerken, blijven er grote vragen open:

• Hoe kunnen gebruikers de bestaande tools die ze hebben geïnstalleerd aanpassen, in plaats van alleen nieuwe, gesilo'de applicaties te maken?
• Hoe kunnen AI-gegenereerde tools met elkaar samenwerken om grotere workflows te bouwen over gedeelde data?
• Hoe kunnen we gebruikers meer directe, precieze controle geven over het tweaken van hun software, zonder dat ze voor elke kleine wijziging naar AI-codering moeten grijpen?

Producten die een cloud-hosted applicatie genereren vanuit een prompt, beantwoorden deze vragen niet. Het integreren van AI-coding tools in het huidige software-ecosysteem is als het brengen van een getalenteerde sous-chef naar een foodcourt. Als je gewend bent maaltijden van een menu te kopen, kan een bekwame chef weinig voor je doen. Op dezelfde manier kan een AI-coding assistent als gebruiker weinig betekenen als je closed-source software uit een app-store gebruikt. Om optimaal gebruik te maken van de mogelijkheden van AI, moeten we verder gaan dan het foodcourt naar iets dat meer lijkt op een keuken—een plek van open-ended creatie.

Ontwerppatronen voor gebruikersregie

Het herstructureren van de fundamenten van computing rondom gebruikersregie is een ambitieus doel. We vatten hier drie ontwerppatronen samen die essentieel zijn voor het bereiken van mallebare software.

Een flauwe helling van gebruiker naar maker

Mallebare software betekent niet dat iedereen al zijn tools vanaf nul moet creëren. Dat zou tijdverspilling zijn, aangezien veel standaardtools al dicht bij onze behoeften komen en slechts kleine tweaks nodig hebben.

Een verstandigere aanpak is om te beginnen met bestaande softwaretools, maar de optie te hebben deze te wijzigen zodra je ontdekt dat ze niet aan je behoeften voldoen. Je begint als passieve gebruiker en wordt geleidelijk een editor en een maker.

In een paper uit 1990, User-Tailorable Systems: Pressing the Issues with Buttons, stellen Allan MacLean en zijn medewerkers een model voor. Stel je een grafiek voor waarbij de x-as de kracht of diepte van een aanpassing representeert, en de y-as het niveau van vaardigheid dat nodig is. In dit model verschijnt een verticale "klif" wanneer iemand plotseling veel meer moet leren om het volgende niveau van aanpassing te bereiken.

Om deze kliffen te vlakken en vloeiende progressie te stimuleren, stelden MacLean et al. een ontwerpdoel voor: elke incrementele toename in aanpassingskracht zou slechts een kleine incrementele investering in leren en vaardigheid mogen vereisen. Een systeem dat deze regel volgt, heeft een "flauwe helling" (gentle slope) zonder kliffen.

Spreadsheets zijn een goed voorbeeld hiervan. Je begint met het bekijken van een document of het bewerken van een cel. Daarna pas je misschien opmaak aan. Later begin je formules te tweaken of nieuwe cellen toe te voegen. Een spreadsheet kan aanvoelen als een "applicatie", maar in tegenstelling tot een app kun je vloeiend overgaan naar diepere aanpassingen.

Spreadsheets tonen twee nuttige eigenschappen:

1. In-place toolchain: Iedereen die een spreadsheet gebruikt, draait de volledige editor. Er is geen aparte development-omgeving nodig.
2. Rauwe esthetiek: Het voelt veiliger om een spreadsheet te wijzigen dan een pixel-perfect gepolijste professionele applicatie.

Een andere manier om een flauwe helling te bereiken is via expliciete modi. HyperCard (Mac, jaren '80) bood "niveaus" die bepaalden welke acties beschikbaar waren. Niveau 1 was alleen-lezen; niveau 2 en 3 ondersteunden tekst- en grafische bewerkingen; niveau 4 voegde het maken van knoppen en koppelingen toe; niveau 5 ontgrendelde volledige programmering via HyperTalk. Deze modi dienden als vangrails.

Voor browser-aanpassingen is de kloof tussen het installeren van een extensie en het zelf bouwen ervan momenteel een steile klif. We kunnen deze helling vlakker maken door lichtere technieken aan te bieden, zoals tools voor custom styling (bijv. Stylish of Arc Boosts), macro-systemen voor het opnemen van acties, of user scripts (bijv. Tampermonkey).

Er zijn twee manieren om een helling minder steil te maken:

1. Vanaf de rechterkant: De vereiste vaardigheid voor volledige expressiviteit verlagen (vriendelijkere syntax, live-programmering, etc.).
2. Vanaf de linkerkant: Geleidelijk meer kracht bieden via een media-editor met optionele programmeerbaarheid (zoals in Notion, Airtable of spreadsheets).

Gereedschappen, geen apps

Veel applicaties zijn als "avocado-snijders": gespecialiseerde gadgets die één taak heel specifiek uitvoeren (zoals een 3-in-1 apparaat dat een avocado halveert, de pit verwijdert en in 7 plakjes snijdt). Ze zijn makkelijk in gebruik, maar nutteloos voor alles wat buiten die ene taak valt.

Een mes is daarentegen een algemeen instrument. Je moet leren hoe je het veilig en vaardig hanteert, maar het is de moeite waard omdat het bijna alles kan snijden.

Veel software-applicaties zijn avocado-snijders. Ze bundelen functionaliteit voor één specifiek scenario (bijv. een vakantie plannen). Omdat een app veel taken binnen één scenario moet afhandelen, doet hij er soms geen enkele echt goed. Je mist belangrijke functies terwijl er andere zitten die je niet nodig hebt.

Om software meer als een "mes" te laten voelen, moeten we kijken naar twee subproblemen: het delen van data tussen tools en het combineren van tools in de gebruikersinterface.

Data delen tussen tools

Als verschillende tools samenwerken, moeten ze opereren op één gedeelde realiteit. In moderne cloud- en mobiele platforms beheert elke applicatie zijn eigen data in een private silo. Dit belemmert malleabiliteit.

Een voorbeeld van gedeelde data is het desktop-bestandsysteem. Als informatie in bestanden wordt opgeslagen, kun je hetzelfde bestand bewerken in verschillende tools die zich richten op verschillende subtaken.

We geloven dat een modern equivalent van het bestandsysteem, met betere ondersteuning voor samenwerking, ontbreekt in het huidige ecosysteem. Andere voorbeelden van gedeelde data zijn low-code database-builders zoals Airtable en Notion, waarbij verschillende weergaven (grid, kalender, board) op dezelfde database opereren.

De gebruikersinterface samenstellen

Tools moeten niet alleen data delen, maar ook een werkruimte waar ze samen gebruikt kunnen worden. Het app-paradigma is hier niet op ingericht; een applicatie neemt controle over een window of tab en bouwt daar een eigen wereld in.

Inspiratie hiervoor komt uit compound-document systemen (zoals OpenDoc en OLE), waarbij documenten worden samengesteld uit verschillende soorten media die in elkaar zijn ingebed. Een tekstdocument kan een ingebed diagram bevatten, dat op zijn beurt een datatabel bevat. Het selecteren van een deel opent de editor ter plekke.

Een radicalere aanpak is te zien in Dynamicland, waar programma's bestaan uit fysieke objecten (zoals stukjes papier) die code en data dragen. Interfaces worden samengesteld door objecten fysiek bij elkaar te leggen op een tafel.

Communale creatie

Hoewel het spannend is om te denken aan individuen die hun eigen ervaring creëren, schiet een puur individualistisch beeld tekort. Voor grotere wijzigingen is meer tijd en vaardigheid nodig. Niet iedereen wil een software-expert worden.

Bovendien gebruiken we computers samen. Een productteam heeft één systeem nodig voor projecttracking; een ziekenhuisafdeling één systeem voor patiëntformulieren. De oplossing is niet "iedereen-voor-zich", maar het ondersteunen van gemeenschappen bij het bouwen van gedeelde oplossingen.

Met de juiste infrastructuur kunnen we samenwerken aan onze software. Lokale gemeenschappen kunnen software bouwen die is afgestemd op hun specifieke context. Clay Shirky noemde dit "situated software".

De geschiedenis van vrije software biedt lessen over hoe zulke sociotechnische systemen kunnen worden opgebouwd. We zijn geïnspireerd door situaties waarin gemeenschappen niet uitgaan van één centraal gecontroleerde versie van een applicatie (bijv. Mastodon-instanties die hun code aanpassen aan lokale beleidsregels).

Ink & Switch prototypes

Bij Ink & Switch hebben we onderzoeksprototypes gebouwd om verschillende aspecten van mallebare software te verkennen.

Infrastructuur voor malleabiliteit

We hebben een infrastructuur-stack geprototypeerd die malleabiliteit prioriteert, gebaseerd op local-first software (gebruikersbeheer van data met collaboratieve mogelijkheden).

• PushPin: Een collaboratief media-canvas. We ontwikkelden "document functional reactive programming" (DFRP), waarbij een tool een UI-component is (in React) die wordt ondersteund door een JSON-document dat automatisch wordt gesynchroniseerd via Automerge.
• Cambria: Een systeem dat schema-compatibiliteit oplost door schrijfschema's los te koppelen van leesschema's. Live vertalingen zorgen ervoor dat tools kunnen samenwerken, zelfs als ze niet exact hetzelfde dataformaat gebruiken.
• Farm: Een experiment waarbij code als data wordt behandeld. De broncode voor tools (geschreven in Elm) wordt opgeslagen en gesynchroniseerd in Automerge-documenten, waardoor het systeem tijdens runtime bewerkbaar is.
• Patchwork: Een collaboratieve omgeving die voortbouwt op PushPin en Farm, maar met toegevoegde versiebeheer-functionaliteiten (zoals geschiedenisweergaven en branching) voor zowel data als code. We noemen dit "universeel versiebeheer".

We gebruiken Patchwork nu zelf voor ons interne werk. Tijdens het schrijven van dit essay merkten we bijvoorbeeld dat het lastig was om de lengte van secties te overzien. In Patchwork kon een auteur snel een "Section Word Counter" tool programmeren en deze direct integreren in de workflow zonder het hele systeem opnieuw te deployen.

Dynamische documenten

Naast infrastructuur onderzoeken we hoe gebruikers tools kunnen creëren zonder te programmeren, door gedrag toe te voegen aan bestaande media.

• Potluck: Een systeem voor receptplanning waarbij gebruikers tekstnotities kunnen verrijken met dynamisch gedrag (bijv. ingrediënten schalen of timers instellen) via detectors die structuur uit platte tekst halen.
• Embark: Een tool voor reisplanning gebaseerd op hiërarchische outlines. Embark gebruikt gestructureerde objecten (zoals Google Maps-locaties) en biedt rijke weergaven (kaarten, kalenders) die diep bewust zijn van de omringende context in het document.

Naar een betere toekomst

We hebben een visie geschetst van een computing-wereld die mensen in staat stelt hun eigen tools te smeden en de macht te verschuiven naar lokale gemeenschappen. De uitdagingen zijn echter groot:

• Privacy en beveiliging: Hoe gaan we om met kwaadwillenden wanneer we software extensibel maken en interoperabiliteit stimuleren?
• Bedrijfsmodellen: Hoe kunnen ontwikkelaars geld verdienen als ze composable tools leveren in plaats van monolithische applicaties?
• Cultuur: Hoe stimuleren we een beweging waarbij mensen hun digitale omgevingen daadwerkelijk willen aanpassen?

Technische mogelijkheden alleen zijn niet voldoende; er zijn economische en culturele verschuivingen nodig. Maar verandering is mogelijk.

Wanneer mensen hun tools geleidelijk laten evolueren om aan hun behoeften te voldoen, ontstaat er een bijzondere kwaliteit. Mallebare software mist misschien de designconsistentie van producten die achter gesloten deuren in Palo Alto zijn ontworpen, maar het ontwikkelt de charme van een oud huis: het getuigt van het verleden en draagt sporen van eerdere beslissingen, terwijl het mee evolueert met de behoeften van vandaag.

Iedereen verdient het recht om zijn digitale omgevingen te evolueren. Het is een essentiële manier om ons creatieve potentieel te vervullen en regie te behouden in een wereld die steeds meer in code wordt gedefinieerd.