East River Source Control has been around for over a year now, but we haven’t been talking much publicly about what we’ve been working on. We aren’t announcing anything just yet, and we will soon, but we wanted to share some of our thinking around version control and where things are going.

Making software is different now

Building software is fundamentally a collaborative task. Projects start with humble beginnings, and end up growing into incredibly large and complex systems. But what cargo new generates is the same thing as what a multi-billion line monorepo contains: source code. Storing this code safely and securely, managing how it changes over time, and ensuring its availability to developers are some of the most critical functions of any technology organization.

In the old days, you might have had a shared server where your code lived. Academia and then industry developed what are now called Source Control Management (SCM) and Version Control Systems (VCS). And even within the VCS space, we have seen many, many tools over the years: CVS, SVN, and Git are the tools that have dominated the open source space, but there have been others as well: Perforce, ClearCase, Fossil, Mercurial, SCSS, Monotone, BitKeeper, and many more. These tools became the standard way to store your code and have your team collaborate on changes to it.

The rise of agentic development has changed many things about how we develop software, but it places particular strain on your version control system. Teams are producing more code more quickly than ever before, ballooning repository sizes, increasing the number of active branches, and producing significant contention on merging in new work. Agents work well with monorepos, because they can get more access to more context more easily, exacerbating these issues as well. They’re moving development environments to the cloud, with isolated environments, which means that they need fast clone times. All of these problems used to be the domain of larger organizations, but agents are bringing big company problems to the rest of us.

We believe that as organizations continue to scale up their ambitions, they will need a next generation VCS tool. But they are rightfully a bit conservative with adopting new tooling in this space. As I said above, source code is one of the most precious commodities an organization has, and change has risks as well as rewards. We deeply appreciate these concerns, and so are building a bridge from the present to the future.

Storage is the foundation

Lots of Git servers exist though. What makes us special?

At a high level, the way most places that host Git repositories for you looks something like this:

Your git client connects to their service via the Git protocol. Inside the service, they store your repositories on disk, and have a service layer that connects the two.

Now, this is a bit reductive: it is going to be many servers, with a complex layer of services in front of the repositories. The storage will be replicated, and there’s all sorts of stuff going on. We’re focusing on the overall architecture here, but don’t mistake the simplicity of the diagram for the simplicity of the system. There is a lot going on here, but those details aren’t germane at this exact moment.

In that spirit, here is the diagram for what we’re doing:

It looks pretty similar! It is also simplified, for example, there is a GraphQL API interface not shown in this diagram at all. But the difference is important: while you still connect to our storage with your regular git client and it uses the git protocol, we don’t store git repositories on our servers. Instead, we have a custom storage engine.

Put plainly, we do not believe that Git is the future of source control. Git has served developers well for many years, but it was designed around the constraints of 2005, not 2025, let alone 2035. For example, it was built for the Linux kernel: an open source project. Open Source is incredibly important to our industry, but this means it’s missing key features that are useful for organizations that aren’t sharing their code with everyone. Also, while the Linux kernel is not a small repository, with 7.2 clocking in at about 43 million lines of code, major companies in the industry already had monorepos that were measured in billions of lines of code years ago. The choices you make really matter at this scale.

At the same time, it’s difficult to consider using a different version control system. Git is baked into so much of our tooling: it’s not SvnOps, it’s GitOps! So many things speak Git, and this makes it difficult to consider alternatives. When Git was created, several other projects started around the same time, notably Mercurial and Bazaar. But network effects led to Git being used by virtually everyone.

So what to do? Speak the Git protocol, while changing how the storage layer works. While this doesn’t solve all of the problems that we foresee in the future, it does help out. Our system is horizontally scalable in a way that systems that use a Git repository as the source of truth are not. And because this isn’t a global, unified platform, other companies’ usage does not affect yours, as they’re separate deployments. This gives you reliability and control, two things that are critical when talking about infrastructure.

Engineering for adoption

So what about those future possibilities? What if you need to scale beyond what the Git protocol offers, or you need features that aren’t provided by Git? This strategy of speaking the protocol has an advantage: you can speak multiple protocols.

This is where Jujutsu comes in. We’re big fans of jj here at ERSC, and part of that is that we really love how it’s an example of a technology that’s easy to incrementally adopt. While jj is its own version control system, it has the ability to speak to multiple different backends. Most developers use jj with the Git backend to work directly with a local Git repository, but Google also has a backend to their Piper version control system. This is what lets individual developers choose to use jj at work, even if their co-workers still use the regular Git client: to the server, it’s just another user of the Git protocol. We’ll be mirroring this strategy, but on the server:

This leads to a smooth path to the future of version control: you can start off by using regular old git, and enjoy reliable and scalable source control management. Individual developers can choose to adopt jj at their own pace, and when you’re ready to step forward, jj can speak a different protocol to the same underlying engine.

An important note about this: this is future work, not available yet. Upstream has no ”jj native” protocol today, and we don’t claim this is what we’re building. If this is useful as an upstream thing that upstream desires to support, we’ll work with the community on this. And the protocol will be well documented, and any client modifications to support it will be open source. We do not assume that just because we build such a thing that upstream will want to use it, as the Git protocol works to serve the needs of most of their users already today. We are committed to being good players in the jj ecosystem, whatever that ends up looking like.

The first of many pieces

A storage solution is only part of what your team needs to collaborate around code. Code Review, CI, issue tracking, the list goes on and on. While traditional software forges have offered everything in one unified package, we believe that we’re entering an age of more customizability with software. As such, our product offerings are more like building blocks than one single forge. Storage is the foundation, and therefore, is coming first. But you can expect that we want to make our storage solution work with the rest of your software stack, not against it. While we’ll be offering multiple products in the VCS space, if you want to bring your own software for the rest of the stack, you can do that. Or if you want to adopt some pieces of our first-party things, and bring some of your own, that’s great too.

While none of this is available just yet, we’ll be opening things up soon. In the meantime, we’ll see you at JJ Con next week!