Building in the Open is Dead
What does that even mean? Was it ever alive? 10/10 clickbait title.
Over the last few years I’ve worked on, and managed the development of, a lot of open source code. As you might expect, it’s primarily been hosted on cloud platforms (mostly GitHub, occasionally GitLab).
I had a realisation last month—that my relationship with open-source code was changing. My internal cost/benefit calculus was shifting. At a minimum, if you’re iterating towards an MVP, it should no longer be in a public repository.1
For most organisations, this would be a given anyway—just because a competitor might not understand what they’re looking at, why take the risk? Still, the chance of that code being made comprehensible by an AI assistant is pretty strong, so this scenario has gone from a poor strategy to suicidal strategy.
Okay, in all likelihood, you’d have built in a private repo anyway, but is that safe?
Although GitHub say that they don’t train their AI models on organisation private repositories, they’ve made no such claims on individual accounts. Indeed, any attempts to gain clarity on the matter using their issue tracker et cetera have been met with crickets. It’s been the subject of threads on Reddit and Hacker News, with some users openly not trusting the public statements given by the company. This comprehensive post by Simon Williamson digs into the matter in depth and still can’t reach a definitive answer.2
This does ultimately mean you’re putting your faith in a large organisation (Microsoft) with hugely asymmetric power over you to both a) not act maliciously and b) not act incompetently. Quite a big ask.
After all, from Microsoft’s point of view, they’re not in the business of stealing the IP of nascent ideas—they’re happy to buy them—so you’ve got to ask the question, how does it even get back to them if a) or b) above is violated, and your IP is leaked via Copilot?
This may be paranoia, but it’s worth considering. In my previous post on Hard Problems, I pointed out that in the age of AI coding agents you need hard problems with barriers to entry. A good way of ensuring the barrier to entry you thought you had (your unique idea, GTM and IP) remains unique is to apply some adversarial thinking to your development stack.
This is all rather bizarre for somebody that’s worked in crypto for the last 5 years—where your DMs blow up if you release anything that isn’t fully open-source, and your competitors brazenly just fork your code and deploy it—but I can see myself in the future taking not only steps back from open-sourcing system components that are part of products we are building, but even going so far as to host them on company Git servers instead of cloud platforms.
In my life as a consultant I talk a lot about TCO—it’s the reason most businesses should be using these cloud tools, rather than rolling their own—but by the same logic, I now find many of my own projects falling on the other side of that fence. There’s a cost to risk, and I think it would be naïve to not factor that in.
One changed line in a cloud platform’s Terms and Conditions that gets missed, a malicious or incompetent move, and you’re toast. It’s a Dark Forest now.
I can’t emphasise enough what an OSS maximalist I’ve been in the past. It’s my default mode for anything.
And on a related note, the T&Cs of copilot changed while this was a draft post, nicely illustrating the problem, “From April 24 onward, interaction data—specifically inputs, outputs, code snippets, and associated context—from Copilot Free, Pro, and Pro+ users will be used to train and improve our AI models unless they opt out.”