GitHub’s CEO just announced his resignation and the internet is roiling with lamentations of how GitHub is going to turn to AI-infested shit now that Microsoft has fully taken over (they won’t be backfilling the CEO position^[1] but will rather have leadership report directly to MSFT execs). Don’t labor under that misapprehension. Lore has it that Dohmke came to MSFT via an acquisition, as did the previous CEO, Nat Friedman. When Nat took over, he managed to evince some of the hipster vibes from the early days when GitHub was cool^[2], but Dohmke charted another course, very much channeling MSFT leadership from the moment he took over, enthusiastically taking it upon himself to — and I quote from his personal mission statement — "boost the actual fuck out of all things AI". If his farewell post and recent other writings are anything to go by, nothing is going to change about that.

Might Microsoft end up doing a Skype here and shutting down its multi-billion dollar acquisition scant years after the purchase? I don’t think so. Microsoft’s lifeblood is developer goodwill: they want to be seen as a developer platform, and it’s going to take a lot more than an AI singularity to change that. So, I’m not worried about GitHub getting shut down. At least, not for the foreseeable future (where "foreseeable" is defined as "during the next 2 to 3 years").

I am, nevertheless, worried that GitHub is going to continue going all-in on AI, and I think that’s a mistake. By all means, they should integrate with AI from other vendors, and even from within MSFT itself, but not to the exclusion of building something that is actually a useful Git forge. AI is not GitHub’s core competency. They are uniquely positioned, however, to build the best code hosting and code review platform for all the worlds’ developers: at least, they would be if they were interested in doing so. Historical evidence suggests that they aren’t.

I’m not the only person who thinks this way, and that’s why you’re now hearing rumblings of discontent. If you’ve been listening, the rumblings have been going on for a while now, most noticeably beginning when MS acquired GitHub in the first place. Here’s a representative example from 2024: well after the MS acquisition, but before Dohmke’s resignation.

I myself only have a presence on GitHub for two reasons. Firstly, because it’s where all the eyeballs are. This fact corresponds to a network effect that has driven a huge amount of developer tooling and practices to be created around the assumption that all code that matters is available on GitHub. The second reason is that, as a distributed VCS, Git makes it easier to push to any given Git forge without having to fully align with an evil corporation: you can very easily push your source code to multiple Git hosts. For me, the only real "vendor lock-in" I have to worry about is the set-up I’ve added to some of my repos for running CI using GitHub actions. By definition, this is nice-to-have functionality that I could live without if forced to do so, and there are alternatives out there if push comes to shove and I have to move.

So, for me, for quite a few years now, I’ve thought of GitHub as but one mirror among several, albeit it happens to be the defacto standard location that people are going to go to first if they’re looking for something; so, in my project READMEs, I end up listing GitHub first.

But I keep my eye on the competition. GitLab, sadly, seems to be nothing more than a GitHub clone. Codeberg is based on Forgejo, itself a fork of Gitea, which pretty unashamedly sets out to copy everything about GitHub right down to the look and feel. Sourchut is a refreshing minimalist and anti-AI take on what a code forge should look like, eschewing forks and pull requests in favor of email-based workflows (which unfortunately raises the barrier to participation a little bit compared to the lowest common denominator approach of GitHub).

I used Phabricator^[3] when I worked at Facebook, and I sorely miss its stack-based review flow, even though I hated using Mercurial. I also rolled out and used Gerrit^[4] at a previous job, and it was powerful but not as full-featured as Phabricator (or GitHub, for that matter); that is, it was designed to make code review great, but if you needed anything like an integrated issue tracker or repo browser you were out of luck. Graphite probably deserves a mention here: hopefully not too uncharitably, I’d describe it as an attempt to graft Phabricator features onto a GitHub-centered workflow made by ex-FB/ex-Meta engineers who missed being able to use Phab and were tired of waiting for GitHub to implement stacked-based review flows; it’s a VC-funded startup, though, which means they are of course trying to cram in AI features, and the fact that it’s built to work on top of GitHub means that it will always be hampered by the limitations of the underlying platform. Fun fact: Dohmke invested in Graphite^[5] when he was GitHub CEO, ironically doing what he never saw fit to do with the company he was actually running (that is, invest in building good code review tooling).

Here’s a little story I don’t think I’ve told publicly before, although I think I’ve probably alluded to it on Twitter, but when I joined GitHub one of my principal motivations was to bring great, Phabricator-quality code review to Pull Requests. I spent a couple of years trying to do that, and failed.

I spilled veritable rivers of ink trying to explain to people what made Phabricator great. I made presentations. I collected testimonials. I demonstrated workflows. I was careful to not make it all about Phabricator though. Having seen amazing code review on the Git mailing list, and having used Gerrit extensively before that, I drew on examples from different sources trying to pull together the common elements that showed how different code review could be when done well. I recruited the assistance of ex-Googler’s who had used Google’s internal code review platform (called Critique), to argue the virtues of stacked workflows.

I was fortunate to have the support of my immediate manager, who carved out the space we needed to do a week-long "Hack House" where a small strike team assembled to sort out the details of what this could look like and build a demo. When we shared the demo, I was told by a Senior Director that it was the best demo he had ever seen at GitHub. This bought me the space I needed to produce a series of design documents, tallying to several tens of thousands of words, explaining how this could all work and how we would get there. When I said "rivers of ink", I wasn’t exaggerating.

And the end result? Well, you can^[6] see it when you go to GitHub today. Most of the engineering team is trying to cram AI features into the platform, and the rest of it is working to keep the site up, and only mostly succeeding^[7]. On the fringes, you have teams rebuilding things in React in the name of replacing legacy technology, giving them a fresh chance to build something with better accessibility and performance; sometimes they actually achieve these accessibility goals, but the performance ones are a bit harder to come by, and there’s the constant dance with the subtleties of reinventing wheels^[8] that the browser supported just fine on its own when pages were mostly server-rendered HTML.

In the end, I had to desist. I got pulled into the swathe of the engineering org that was engaged in permanent availability work, stumbling from crisis to crisis trying to get ahead of the next outage before it happened. Meanwhile I continued to update my code review design documents with supporting evidence whenever it appeared, but I could tell that there wasn’t the will within the leadership chain to take on any big bets in the product roadmap unless they had "Copilot" in the name.

So, it’s on my bucket list to build the code review tool that I would want GitHub to be. I wouldn’t actually want to displace GitHub in the market, of course, because if I did, I would immediately have to change my job title to "Chief Scaling Officer"^[9] and forget about building the thing that I actually care about, which is a code review tool: a code review tool for humans. (Yeah, I’m old-fashioned in that way, and I’m willingly giving in to nostalgia: I still care about giving tools for humans to do this particular job, and I find the idea of delegating both the writing and reading of code to LLMs to be one of the least inspiring things in the world^[10].) But yeah, I’d love to build a Git forge, even though it might have to wait until my retirement because I’m rather busy right now^[11]. I don’t know if anybody but me would use it, but it sure would feel good just using it myself.

---

1. A harsher soul than I might note that this qualifies the outgoing CEO as literally the opposite of "indispensable". ↩︎

2. Which in turn was because it was built with Rails, and Rails was cool. ↩︎

3. See also this Wikipedia article about Phabricator as well, in case the Phabricator site ever goes away, which is a distinct possibility now that the project is no longer actively developed (although a fork in the form of Phorge does exist). ↩︎

4. To see it in action, look at Gerrit’s own Gerrit instance. ↩︎

5. You can see him listed among Graphite’s "angel investors" here. Noticeable on the list are a fair few ex-FB/ex-Meta folks. ↩︎

6. That is, you can’t see it, because we never built any of it. ↩︎

7. GitHub has long been a victim of its own success in this regard: when you’re the most popular Git host, you have no choice but to build a massive team whose sole purpose is to scale Git storage. ↩︎

8. Things like scrolling, and find-in-page. ↩︎

9. The hard part about being the most popular Git forge isn’t the horizontal scaling you have to do to support lots of users; it’s the extreme engineering you have to do to support the outlier customers in the 99.9th percentile. These customers aren’t just going to have large monorepos with millions of files and even more commits, but they’re going to do things like have 100,000 open PRs (all of which need to be rechecked — even if only lazily — for mergeability when the target branch updates), or a million branches, and they might be merging and rebasing hundreds or even thousands of PRs per hour. People working on or adjacent to infrastructure at GitHub knew the database IDs of these p99.9 repos by heart because they’d seen them come up so many times when doing incident response or performance degradation analysis. ↩︎

10. Although, as a pragmatist, I try and extract as much value from LLMs as I can in my daily work. It’s just that I don’t enjoy doing it. ↩︎

11. Another fun fact: I actually already did build a repository browser once, back when my website used to be a Rails app. The repo browser is the easy bit, of course, but still. If you’re curious, the simplest way to see what it contained would be to look at the commit where I deleted it. The grand irony here is that GitHub’s React-based repo browser struggles a bit to render that commit, because it changes 75 files and a few thousand lines… The old version which was just server-rendered (Rails-rendered) HTML did it better. ↩︎

For a long time now I’ve been worried about the lack of security in my dev environment.

Tools like brew make it absurdly easy to install third-party tools on your machine. On my laptop right now, I’ve got 304 formula and 30 casks installed, and my /opt/homebrew directory clocks in at 13G. Other package managers are no better: Nix brings you apparent immutability, but all the hashes in the world won’t tell you if something is safe to install, only that its content matches a digest^[1]. No matter which package manager you use, you’re not auditing all of the packages you install, so you are in a sense delegating the task of monitoring the package registry to someone else; it could be a somewhat well-defined set of individuals, such as "the Debian maintainers", or something more nebulous, like "the watchers and contributors of the Homebrew repository".

And then there are the language ecosystems, each with its own package manager. Sampling a couple of small web apps on my machine, I find one^[2] with 33,265 files in its node_modules directory and another^[3] with 21,361. Note I said "small". These are not complex apps. They use React and number of related runtime and dev packages. Taking a non-web example that uses npm (well Yarn), even my dotfiles repo has 253 files in its node_modules, and that’s a project where I’ve tried to keep my JS dependencies to a bare minimum^[4].

At the GUI level, I’m far less worried, although I recognize that it’s no longer true — if it ever was — that "you don’t have to worry about viruses and malware unless you’re on Windows". I spend most of my time in the terminal or in the browser, and the other apps I use — few in number — are either provided by Apple or some other megacorp (with the attendant security measures, which are imperfect but better than nothing), installed via the App Store (again, with some layer of filtering via the approval process, which presumably includes some kind of static analysis), or are from third-parties who have built up my trust over a period of time. None of this is bullet-proof, but the surface area is relatively limited, and it doesn’t feel like the Swiss-cheese command-line environment, with its barn-door-sized holes.

In the dev tooling space, I have felt cold comfort in knowing that pretty much the only thing between me and having my machine devastatingly compromised comes in the form of a "herd effect", where there is a kind of "safety" in numbers. Specifically, I’m relying on the fact that if there is a mass vulnerability propagated via a supply chain attack targeting some widely used dependency, it will probably be detected quickly (via the "many eyeballs" effect^[5]), and I’ll be likely to hear about it soon, hopefully in such a way that I (or somebody positioned at a central choke point, such as working at a package registry) can mitigate it before it does me any harm.

I’m not sure who I heard say this, but it is an aphorism that security and convenience are always, always in tension with each other. You cannot have full security and utmost convenience at the same time. That is to say, you could air-gap your computer and audit literally every piece of source code you rely on before building and running it; this includes the kernel, the compiler, the libraries you use, the applications — the whole kit and kaboodle. But obviously, nobody does this, except perhaps for portions of the security apparatus of powerful nation states. And even for those, can they ever really be sure that somebody hasn’t inserted a self-concealing backdoor somewhere in the build chain? They would like to be, but I don’t think they can ever be (100% sure). So, we’re not going to go "all the way", sacrificing all convenience in the name of security. Common trade-offs include:

• Storing your passwords and your 2FA tokens in the same password storage (eg. 1Password), in the name of convenience.
• For that matter, storing all of your passwords in the single basket that is the cloud storage and closed-source application code of a for-profit proprietary software vendor (even if they publish a white paper on their security design).
• Running closed-source software at all, or open-source software that you haven’t audited and that hasn’t been adequately engineered for security (ie. most of it, with notable exceptions).

One thing I want to explore is running more things in containers, which is easier now that Apple has rolled out a built-in container CLI. Now, containers are a pretty thin layer as far as security is concerned^[6], but a thin-layer can still be useful in a defense-in-depth approach. The main benefit of containerization is reproducibility: you can specify what your dependencies are, prepare an image with those dependencies, and then run the same code in development and production. If you shift to another machine, you can take the container environment with you and everything will be the same. But while that is the main benefit, it’s not the only one. Installing a dependency in a container is a very different matter than "letting a third-party package shart bits of itself all over your base system". But this is again a security-vs-convenience trade-off: working with containers does involve another layer of abstraction, another set of tooling to learn, and another set of things to go wrong.

Now, it’s pretty clear that I could take those two web apps I mentioned above and containerize them fairly straightforwardly. Containers’ wheel-house, so to speak, is network services. If the ultimate goal of your service is to expose an app over HTTP listening on a port, then containers are a great fit: the container is a black box and you don’t need to care about what is going on inside it. But what about something like my dotfiles repo? I could certainly create a "base" dev image with all the stuff inside it that I need for a typical project — basically all or most of the stuff that I’m currently spraying all over the system with Homebrew — and then have pretty much all my terminal sessions start with me spinning up a container inside which I’ll do the real work.

But I’m not sure of what the details will be and whether it’s worth it for such a marginal additional layer of isolation. Will there be an unacceptable performance hit? Will updating the image be too much of a pain in the butt, even for a guy like me who is all too comfortable exploring the space between security and convenience? Will I still need to keep a bunch of third-party code running outside the container in order to get my daily work done? And if I end up giving the containers access to things like SSH and GPG keys, or Anthropic and other API tokens, won’t I just be back where I started, with a bunch of unaudited and untrusted third-party code running in an environment where it will have access to sensitive things that I would rather keep away from prying eyes and fingers?

All of these are open questions for now, but I’ll keep you posted if and when I actually start carrying out experiments in this direction^[7]

---

1. Reproducible builds are a related, useful idea, but while they close one potential gap, they are not a panacea. ↩︎

2. Masochist. ↩︎

3. I can’t link to this one as it’s private. ↩︎

4. And while my npm footprint is small there, I have around 70 submodules in the repo, and the file count across those is over 7.5K. ↩︎

5. "(1) with many eyes, shallow bugs get caught very quickly, and (2) that the more eyes there are, the more likely it is that some member of the group has sufficiently penetrating vision to catch the deeper-swimming bugs." ↩︎

6. Attacks may exploit vulnerabilities that allow code inside a container, or within a VM, to break out and access, or otherwise affect, the host machine. And even in the absence of vulnerabilities, in order to be actually useful, containers often need access to network facilities and filesystem contents elsewhere. ↩︎

7. If "keeping you posted" means pushing stuff to my dotfiles repo, that is. ↩︎

Woah. Look how many fancy things git rebase -i knows how to do now:

# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
#                    commit's log message, unless -C is used, in which case
#                    keep only this commit's message; -c is same as -C but
#                    opens the editor
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
#         create a merge commit using the original merge commit's
#         message (or the oneline, if no original merge commit was
#         specified); use -c <commit> to reword the commit message
# u, update-ref <ref> = track a placeholder for the <ref> to be updated
#                       to this position in the new commits. The <ref> is
#                       updated at the end of the rebase