Discuss on Hacker News.

In response to yesterday’s post about Anthropic’s Scion ripping off Mononoke, I received a number of questions and concerns. Here’s a followup to answer the big ones.

This was a ripoff. My post yesterday was trying to be as charitable as possible given what I knew, and in particular that the similarity to Mononoke was mostly unintentional and the lack of credit was the result of not doing due diligence. However, after publishing the post I privately received confirmation that Scion intentionally and blatantly ripped off Mononoke, and in particular that there was overlap in personnel. There is no chance that this was an unintentional homage. This is something I had a hunch about but was not comfortable saying yesterday, given what I knew back then.

The resemblance is much deeper than just the notion of derived data. Some people pointed out that derived data is just an index, which is a well-known concept. I want to clarify that derived data was merely the most striking resemblance. It goes much deeper than that, and extends to the entire data model, as well as a number of the structures built around it.

Here is how Anthropic describes Scion changesets:

In Scion, the unit of work is a “changeset,” an entry in a write-ahead log. A changeset stores most of what you’d expect from a commit in git. But where a git commit stores a pointer to the tree, a changeset stores a list of the files that changed relative to its first parent,1 along with content-addressed pointers to the compressed file contents in blob storage. Changesets are created server-side and are available everywhere, instantly. (followed by a pictorial of a changeset)
How Anthropic describes Scion’s changesets.

Mononoke has the same concept; we call it a Bonsai changeset. In the same Oxide materials from 2022, here’s how I described them:

The Bonsai data model. To solve this problem, we flipped around how we look at commits. Rather than containing a pointer to the root tree object, a Bonsai changeset contains the metadata (author, commit message etc), hashes of parents, plus the list of files changed in it and hashes of blobs. (A Bonsai changeset is still a Merkle DAG, just with a different model.)
How I described Mononoke’s Bonsai changesets.

They are exactly the same. Even the name “Scion” reverses the syllables of “Bonsai” and drops the “B”! This might be a coincidence, or might not.

For derived data, I also wanted to draw attention to the kinds of indexes being built, such as for blame. Needing to do this is a natural consequence of the Bonsai data model, so it’s not surprising that indexes need to be built; I was drawing attention to the striking similarity in terminology and framing, because that was indeed how we used to think about it during my time on Meta’s source control team.

Another set of resemblances is in the server-side API to do version control queries and mutations with. This was implemented in Mononoke, but I believe other systems before Mononoke had it as well, so I’m not going to claim novelty. But if what you did is point Claude at Mononoke and asked it to rebuild that, you would probably design something very similar.

The Bonsai data model is wildly contrarian. I want to emphasize that the prevailing wisdom in source control is Git-like data models. Building a write-ahead log-style Merkle DAG was very far away from what anyone else was doing in 2018, and required solving several hard problems along the way such as how to perform server-side rebases (to my knowledge, one of several novel algorithms in Mononoke). While I was leading the team effort to design and implement the model in 2018, I personally had to justify it to several layers of management at Meta. It is quite rare for skip levels to get pulled in to discuss a system’s data model in depth.

The Bonsai data model is also wildly successful. At this point, almost a decade later, the model has been stretched far outside its initial design parameters, and it’s still chugging along. The team effort to build it remains one of my proudest career achivements. Given the overlap in personnel, there is no reasonable way the Scion team could not have known about this. (Which is why they quite reasonably copied it!) This brings us to my next point:

The problem is attribution, not copying. I mentioned this in my original post, but I am completely fine with good ideas being copied. I am not fine with the serial numbers being accidentally stripped off, and I am certainly not fine with them being intentionally stripped off.

Crediting Sapling for “hard-won lessons” is not enough. Several people pointed out that Mononoke is part of the Sapling ecosystem. The problem here is that Sapling can mean either the VCS client (sl, originally forked from hg) or the system as a whole. If you were previously on Meta’s source control team, you absolutely know the difference between the two. Besides, the resemblance is much, much deeper than merely “hard-won lessons”. The Lore VCS can claim inspiration from Mononoke, but it differs in several ways as well. Scion’s resemblance to Mononoke goes well beyond that, and merely crediting Sapling (not even Mononoke) with “hard-won lessons” is dishonest. (And specifically, I would expect the Scion changeset section to mention Bonsai changesets as the thing they are copied from.)

This makes Anthropic’s achievement significantly less impressive. Anyone who’s put a distributed system into production knows how many issues tend to crop up during the productionizing process. “Our LLM built this thing, productionized it, and dealt with all the attendant challenges over 5 months” is a significantly more compelling narrative than “the source control team at Meta had spent 10 years building and productionizing this system, and we were able to point our LLM at it and rebuild it in 5 months”.

…and yet, it is still quite an achievement. Being able to point to an existing system and rebuild it in this short a period is still quite stunning. It is shocking to me that Anthropic didn’t just say they copied Mononoke and rebuilt it in 5 months. That is still noteworthy, even if it isn’t as grand. Surely they knew they would be called out?

It is always good to situate your work in the larger context. We all stand on the shoulders of giants! There is nothing wrong with borrowing and adapting existing work to new contexts — that is the vast majority of what I do as an engineer. When you position your work as derivative, you are acknowledging those that came before you, as you hope to be acknowledged by those who come after you.

There is nothing without the team. On a personal note, it’s been many years since I worked on Mononoke. There is a team that still carries the torch forward all these years later. Anthropic ripping the Bonsai data model off hit me hard, but spare a thought for the team working on it now: those who were most directly plagiarized. Imagine how they must feel about their work being deliberately copied wholesale and intentionally presented as someone else’s.

It’s been two days since I first posted about this on Bluesky and Linkedin, and I haven’t seen an update to the original post yet. This remains yet another shameful example of large AI companies appropriating the commons and presenting others’ work as their own. I don’t know what it will take to rebuild bridges from here, but my default assumption now is that Anthropic’s public engineering presentations are largely bad-faith ripoffs. That’s a shame.