I thought I had written this post, but I can’t find it in the archives. I know I gave a talk about it, but that was a meetup in the fall of 2019. Maybe it was a bit of the Progressive Delivery book I wrote and then cut.
Where we’re at
Git is a distributed version control system that is 20 years old now. When it emerged, we were in the full flower of Agile and before most software-as-a-service. It’s only a tiny bit younger than Gmail. It is a response to the specific needs of the moment, including asynchronous distributed work, semantic releases, and the need for alignment that is not organizationally-imposed. Also, it is notoriously difficult to use, because it requires an extremely specific conception of the architecture of the code storage and deployment. You can make whatever (binary) code you want, but in order to store it and share it properly, you need to do the mystic incantations in exactly the right order. If you screw that up, you may wreck your code, or you may wreck everyone else’s. Probably not. We have safeguards. Mostly. Usually.
GitHub is a significantly friendlier wrapper that is a de facto industry standard for dealing with git. There are a lot of wrappers, but GitHub kind of won. It has a better user experience, and surfaces a lot of the things that are most opaque with git, like “who else is working on this” and “where do we disagree” — questions most of us have. And they have done so much work on tooling and enhancements and sideways features. It’s a mature product, and could go in some interesting ways.
Why that’s a problem
GitHub is a mature product built on a distributed version control system designed for
- binary code
- semantic releases
- dedicated users
- included code libraries
Look around you. Do you feel like maybe it would be nice to be able to have relational databases in your nice safe DVCS? What about streaming releases? What about coders who might be scared about screwing up? Do you actually roll all your code libraries up into the version control, or do you reference them? Does that feel like a safe way to operate?
There are workarounds, sure. And the more mature an organization is, the more idiosyncratic and custom their use of GitHub is, until “do you know how to use GitHub” is like, a vibe-check, since they’ll have to relearn everything from scratch to work with your GitHub.
This is not a long-term solution. git is a bad fit for how modern coding works, and your choices right now are either to be constrained by old-fashioned structures, or build new, bespoke weirdness that is not working in the same way at all, and you’ll have to sustain yourself.
Why now
It’s not just now. I mean, I’m writing this because I got nerd-sniped by an article about Microsoft’s (frankly baffling) announcement today that they’re going to stop treating GitHub as a standalone company under their umbrella and roll its assets into their AI shoggoth. That’s why I’m writing this today. But I have thought for 7 years that git is a constraint on our understanding and distribution of software, and that in order to really modernize, we need something better. Over the last 20 years, we’ve changed:
- Software specification/development – we’ve moved from waterfall to whatever post-agile thing we’re doing now
- Software assurance – automation and delegation have moved a lot of the testing we used experts for onto the developer’s plate
- Software delivery – We’re not shipping disks, or even downloading that many distros. Our software experiences look much more like a stream
All of that has moved a lot. But our version control systems are still thinking in ways that make it harder and harder to support the new software models.
We have a whole generation of people who are now senior software engineers who have had entire careers where they haven’t had to negotiate a locked file (good) or used a system that wasn’t git (worrisome). I believe that there are other ways.
What next
For the last 5 years, I’ve been waiting and watching for someone to found “the git-killer”. It’s a DVCS that can do the things that git can’t do (or can’t do natively). It’s designed from the ground up to be safe first, powerful second. It knows about databases, feature flags, and referenced libraries. In fact, you can gate how you include other people’s code based on a kind of credit rating. It knows that storage and compute are relatively cheaper than delivery and implementation. It has clear visuals, including predicting where your code will go and what it will affect and be affected by. Security is a first-class consideration.
I haven’t seen it yet. Given how much movement there has been in other areas of software, I think that’s because we, as an industry, have a sunk-cost fallacy, and have invested in so many workarounds that we don’t feel an urgent pain that would cause us to move off something that works. And it does work. It could just be so much better.
So, if you’re making the git-killer, please hire me to tell people why they need it. If you’re looking for an idea, please take this one. And if you’re going to defend git to me, well, you won’t be the first.
Slides from a talk I gave on the topic in 2022
There is another whole post on the marketing and brand identity aspects of this, but I didn’t want it to get too cluttered.