Historisierung

Perhaps it's because I'm a historian, once you strip back the particulars of job titles, but I think narrative has a place in open source. I always appreciate READMEs that have a "Why this exists" section, and even those are usually functional: improved performance, modernization, maintainability. For something like Source Hut or Codeberg, there's principles of no AI or non-profit governance. I come from a world of artistic statements and grant applications; I think we can afford to mythologize a bit about what we do. You might think history is self-evident in Git commits, but these are utilitarian, not human—literally, as automation and CI account for huge swathes of commit messages these days.

Writing about making software can be more personal, and arguably more informative, than marketing copy or documentation. It's why I like to read developers' blogs, which is also a point of frustration: why is the history of a piece of software ancillary, even extra-canonical? Of course there's responsibility and humility at play. A single contributor can only speak to their experience of a project, a limited but still valuable perspective. So it's up to nosy people like me to piece together information from such storytelling, and even then, developers who blog or enjoy writing prose are a minority.

This void of information especially bothers me when it comes to themes, which occupy a strange place anyhow. A theme is, in essence, a list of RGB and/or HSL values—more romantically, a style guide or a visual vocabulary—that begets a dozen or dozens or hundreds of ports that you can individually count as discreet software. Some are .ini <20 lines long, and others paint full-fledged IDEs. But as something central to developer experience, which personalizes our work, I'm a bit baffled that they're so widely-adopted and touch so many UI surfaces, yet users do not seem curious about their origins, or their creators don't feel the need to explain their work. There is a sentiment of "talk is cheap" and code should speak for itself, but again: a palette isn't actually code. They're not actually runtime necessities. No one needs themes, yet we keep making them. They're a purely aesthetic pursuit, and what else warrants navel-gazing?

By my counting, popular open-source themes include Gruvbox (2012)¹, Dracula (2013)², Nord (2016)³, Everforest (2019)⁴, Rosé Pine (2020)⁵, Catppuccin (2021)⁶, and Kanagawa (2021)⁷. For five of these, I had to clone their repos and run git log | less to get a first commit date. It's only Dracula that has a narrative origin story (sic), which I suspect is possible because Zeno Rocha is one guy. My measure for "popularity" isn't quite GitHub stars (as established, I am on Codeberg), but actually their inclusion in Minimal for Obsidian. Then there's ports of VS Code themes like tokyonight.nvim, whose origins are even more opaque to me.

The majority of these themes have some sort of snappy one-liner about themselves. Catppuccin is "a soothing pastel theme for the high-spirited," and Everforest is "comfortable & pleasant" and "designed to be warm and soft in order to protect developers' eyes." Kanagawa cites the Hokusai painting as inspiration while Rosé Pine is derived from the Pacific Northwest. But I want to know more. Many of these themes emphasize they're "community-driven," where ports are the responsibility of maintainers in an organization, but that doesn't explain who first made the palette, when the colors were canonized, why they're maintained the way they are. And one could read an entire 1k+ commit history and track down when a shade of green changed incrementally and by whom, but there is no why there.

Good software is intentional as any creative work, and intention is as worthy of record as source and function. It might be difficult to see an ongoing project as having historical value, especially if you're focused on making the thing rather than talking about it, but subjective memory breathes. It proves software is made by humans with tastes and habits, who actually live with it.