In 2019, I watched a fellow writer almost lose her life’s work.
We were working in an advertising agency. Like most writers who end up in advertising, we were both secretly working on our novels. One afternoon, after lunch, I noticed her pacing around the office, rifling through her bag, checking every desk. Her irritation quickly turned into panic.
Her pen drive was missing.
Hours later, on the verge of tears, she told us why this particular pen drive mattered: it held the only copy of her manuscript.
My first reaction was disbelief. Only copy?
No emailed draft to herself, no Google Drive or Dropbox, no backup anywhere? The answer was simple: she hadn’t thought about it. Relative tech illiteracy had put an entire novel at the mercy of a misplaced USB stick.
My reaction was part heartbreak, part annoyance, and part dread. That night I sat down to audit my own practice—how I recorded, recalled, and stored my work.
At the time, the source of truth for my fiction was a single folder on Dropbox, with dozens of subdirectories by project. All the manuscripts were .doc or .docx. I took regular backups of that folder, zipped them, and emailed them to myself with dates and times in the subject line. If something went wrong, I could theoretically roll back to a recent version.
On paper, that sounded reasonable. In my body, it felt wrong. I couldn’t articulate why, but I knew “not losing everything” was not the same as “leaving behind a studio that someone else could actually use.”
A few weeks later, on a whim, I decided to relearn programming after almost twenty years. Maybe, I thought, programming in 2019 would be kinder than it had been in 2001.
The first lesson on The Odin Project was on Git.
I went through it expecting boilerplate developer lore and came out with something else: a way to resolve the unease I had been carrying about my writing. Git didn’t just promise safety from catastrophic loss; it offered a way to keep a living, navigable history of my writing. It suggested that my studio didn’t have to be a pile of files.
It could be a time machine instead.
I remember feeling irritated that night: why was Git not being taught to writers?
The Timelessness of Plain Text
Sociologist Kieran Healy wrote a guide for “plain people” on using plain text to produce serious work. Neither he nor I are the first non‑programmers to come to this realization, and hopefully not the last: plain text is the least glamorous, most important infrastructure upon which I build my work. I use the word infrastructure intentionally: plain text forms the substrate that underlies, connects, and outlives higher-level applications. For people like you and me---whether we are writers or not---choosing to work with plain text is a political choice about memory and power, not a mere nerdy preference about file types.
It has been over six years since I moved all my writing to plain text and Git. Before that, my life’s work sat in one folder, spread over a handful of .doc and .docx files. Now, plain text is the lifeblood of everything I write—a choice to live closer to the infrastructure layer where I retain power over time, interoperability, and preservation. The alternative is renting them from whoever owns the fancy app.
Why does this matter?
In my last two columns, I spoke about how Emacs interfaces with my work: and using it for writing my next novel ; put simply, why I choose to work on Emacs in the age of AI tools. None of my Emacs-fu would be possible without plain text and Git sitting underneath.
Most of us are told that platforms will take care of our work. “Save to cloud” is the default. Drafts live in Google Docs, outlines in Notion, images in someone else’s “Photos,” notes in an app that syncs through servers we don’t control. It feels safe because it is convenient. It feels like progress: softer interfaces, smarter features, less friction.
The cost is deliberately obfuscated.
You pay it when the app changes its business model and the export button slips behind a subscription.
You pay it when comments you believed were part of the record are actually trapped inside an interface that will be sunsetted in ten years.
You pay it when a future collaborator has to sign up for a dead service—if that’s even possible—just to open a reference document.
You pay it when your own older drafts become psychologically “far away,” not because you are ashamed of them, but because the path to them runs through expired logins and abandoned software.
A repository of written work hosted entirely on proprietary, cloud‑bound software is a studio that dies when the companies behind it do—or when they decide that their future no longer includes you.
If you want your studio to outlive you, you cannot outsource its memory to platforms that see your work as a data source, a training set, or a metric. You need materials and tools that privilege longevity over lock‑in.
The Studio as a Text Forest
Plain text works because it is not sexy. It is not “disruptive.” Good. That is precisely why it is so important.
A text file is one of the most durable digital objects we have. It has remained readable, without elaborate translation, across decades of hardware, operating systems, and software ecosystems. It is trivial to convert into other formats: PDF, EPUB, HTML, printed book, subtitles. It compresses well. It plays well with search. It fails gracefully.
When I began moving my practice into plain text, I was not thinking about posterity. I was thinking about control. I wanted to pick up my work on any machine and carry on. I wanted to stop worrying that an update to a writing app would quietly rearrange my files. I wanted my drafts to be mine, not licensed to me through someone else’s interface.
The result is a studio structured less like a warehouse of finished products and more like a forest of living documents.
Each project—work‑in‑progress novels, screenplays, this very series of essays, research trails—lives in its own directory inside a single mono‑repo for all my writing. Inside each directory are text files that do one thing each: a chapter, a scene, a note, a log of cuts and revisions. The structure is legible at a glance. You don’t need me to draw a diagram or sell you a course. Anyone who knows how to open a folder can navigate it.
This is not nostalgia for a simpler computing era. It is about lowering the barrier for future humans—future me, future collaborators, future scholars, future strangers—to enter the work without first having to resurrect my software stack.
Plain text gives us a chance to build archives with the same openness as a box of annotated manuscripts, without the paper slowly turning to dust.
But text alone is not enough. A studio that outlives the writer needs a memory of how the work changed.
Version Control as Time Machine and Conversation
Linus Torvalds probably never intended Git for use by writers. And perhaps that is why I view it as almost possessing magical powers. You see, with Git I can talk to my future self, and my future self can talk to my past self.
In software, version control lets teams collaborate on code without stepping on each other’s toes. In a solo writing practice, it becomes something else: a time machine, a ledger of decisions, a slow, ongoing conversation between different iterations of the writer.
Every time I hit a significant point in a project—adding a chapter, making a painful cut, restructuring a section—I make a commit. I write a short message explaining what I did and why. Over months and years, these messages accumulate into a meta-narrative: not the story itself, but a veritable documentary of how my stories came to be.
When I open the log of a book or a long essay, I can scroll through those messages and see the ghost of my own thinking. I see the point where I abandoned a subplot, the week I rewrote an ending three times, the day I split a single swelling document into a modular structure that finally made sense. It is humbling and reassuring in equal measure: it shows me that good writing isn't a result of strokes of inspiration but sitting down consistently to wrangle my writing brain.
At some point, selected manuscripts from this mono‑repo will be made publicly available under a Creative Commons license.
When that happens, I will not just be publishing a final text. I will be publishing its making. A reader in another part of the world, years from now, will be able to trace how a scene evolved. A young writer will see that the book they admire was once a mess. A collaborator will be able to fork the repo, experiment with adaptations, translations, or critical editions, and perhaps send those changes back.
Version control turns my writing studio into something that can be forked, studied, and extended, not just consumed.
This stands in stark contrast to the way most digital platforms treat creative work today: as a stream of “content” to be scraped, remixed anonymously into generic output, and resurfaced as something merely “like” you. When your drafts live inside a proprietary system, you are not only dependent on that system to access them; you are also feeding an apparatus whose incentives diverge sharply from your own.
A Git repository of plain‑text work, mirrored in places you control, is not magically immune to scraping. Mine has been private from the moment I created it, and it will remain so until I am ready to open parts of it on an instance whose values align with my own. Even then, determined actors can copy anything that is accessible. The point is not perfect protection. The point is to design for humans first: to make the work legible and usable to future people on terms that you have thought about, instead of leaving everything at the mercy of opaque platforms.
Designing for the Long Afterlife
What does it mean, practically, to design a studio that outlives you?
It does not mean embalming your work in an imaginary final state. The texts we now call “classical” did not survive because someone froze them. They survived because people kept copying, translating, annotating, arguing with them. They survived because they were malleable, not because they were pristine.
If I want my work to have any chance at a similar afterlife—not in scale, but in spirit—I need to make it easy for future people to touch it.
For me, that means:
- The core materials of my work live in plain text, organized in a directory structure that makes sense without me.
- The history of that work is kept in Git, with commit messages written for humans, not machines.
- The repositories I want to be accessible are published under licenses that explicitly permit study, remixing, and adaptation.
- The studio is mirrored in more than one place, including at least one I self‑host, so its existence is not tied to a single company’s fortunes.
Notice what this does not require. It does not forbid me from using GUI tools, publishing platforms, or even proprietary software where necessary. I am not pretending to live in a bunker with only a terminal and a text editor. I am saying that the source of truth for my work is kept somewhere that does not depend on the goodwill of companies for whom my creative life is just another asset.
This is not an overnight migration. It took me years to get from a single Dropbox folder of .docx files to my current setup. The important part was the direction of travel. Every project I started in plain text, every journal I kept as a folder of files instead of a locked‑down app, every book I moved into a Git repo rather than an opaque project bundle, was a step toward a studio that a future human could actually enter.
A Quiet Resistance to Big Tech's Power
We are entering an era where large AI systems are trained on whatever they can scrape. The default fate of most creative work is to be swallowed, blurred, and regurgitated as undifferentiated “content.” It becomes harder to tell where a particular voice begins and the training data ends. As more of the public web fills with machine‑generated sludge, it becomes harder for human readers to find specific, intentional work without passing through the filters of a few large intermediaries.
A self‑hosted, plain‑text, version‑controlled studio will not stop any of this by itself. But it is a form of quiet resistance. And at this point in our collective history, where the same infrastructures that mediate our creative lives are entangled with surveillance, automated propaganda, and the machinery of war, even small acts of refusal matter.
Moving a novel into plain text will not topple a platform. Hosting your own Git server will not end a conflict. But these choices shape who ultimately has their hands on the levers of our personal and collective memories.
from It's FOSS https://ift.tt/8I1jalH
via IFTTT
