A Vision for Open Content
January 1, 2024
We programmers love Open Source. Its magic is all about collaboration, and about compounding efforts which would otherwise be dissipated. The fact that thousands of programmers can meet in the Internet and work together towards improving a program seems like a miracle, and it just couldn’t exist without robust (and simple) versioning systems, such as Git.
Git made decentralized collaboration easy, and GitHub leveraged it to build a platform in which people could agree on a program’s source of truth. Versioning with Git is simple and robust. Every change needs to be “committed”, and each commit creates a snapshot of the code at that specific point in time. I often times enjoy going through a popular repository’s initial commits—how much code were the authors pushing, at which times, and with which commit messages. But more than a fun little hobby, the robustness, traceability, and transparency Git (and GitHub) enabled means programmers enjoy a powerful authoring workflow, which, in the long term, compounded into better programs.
“Why don’t we have this, but for content in general?“ is a question I always asked myself, and I’m sure many, many programmers have asked themselves throughout the years. While Git can be used to version any text-based thing, I found that it’s not as convenient for content editing, nor accessible (in terms of UX) for content creators. Moreover, content hosted in GitHub is hard to distribute, as distribution is not the use case GitHub was designed for. There are tools, such as GitBook, which attempted to build something like this, but unfortunately, their underlying data model didn’t feel as robust as Git. Other modern content creation tools (think Notion or Google Docs) and CMSes (think Contentful or Sanity) often times miss essentials like branching, diffing, commits, and revertions.
So, Git and GitHub are not as convenient for content editing and distribution, but existing, more convenient solutions are not nearly as robust as Git. I believe this problem deserves as many attempts to solve it as it takes.
Today, it’s hard for content in the Internet to have a “source of truth”. Stuff lives in blog posts, gets shared on X, gets screenshoted, etc. There’s no robust place in which content is written, stored, and distributed—everything seems ephemeral and fragile; as it could change at any time without we even noticing. Collaborating with anonymous people is hard, and so is compounding the efforts of them all.
“So, here’s the paradox: it’s now so easy to write that we’re awashed in bad content. Bad posts, bad tweets, bad books, bad laws, bad text code, bad everything. (…) On the other hand, these tools are now so effective, that there ought to be a giant explosion of high quality content. We also ought to be awashed in the most amazing written material that we’ve ever seen in our entire lives, in every genre. So, where’s all the good stuff? Where are the supergenius, brainiac authors, screenwriters, novelists who are producing a much larger amount of material at a much higher speed?”
— Marc Andressen, How I Write Podcast with David Perell.
What does a future with “Open Content” look like? Is there a world in which there are large, public content repositories that store robust knowledge in them? Does iterating on the exact words of a piece of content matter as much as iterating on the right keywords and functions in a piece of software? How can we empower people to create and distribute better content through the Internet?
Wikipedia already showed us the way. It showed the amount of value creation that’s possible within a system in which people can collaborate in an easy, anonymous, and transparent way. But that marvelous workflow shouldn’t be constrained only to Wikipedia. People should be able to leverage tools to create “their own Wikipedia” for their own use case, such as a blog, a news outlet, a documentation website, or why not the whole constitution of a country. People should be able to collaborate on content the same way they do on code, with Open Source.