Gates vs. Kildall: The Lesson We Don’t Like but Can’t Ignore
- Rich Washburn
- Sep 16
- 3 min read
Not every founder story survives the passage of time. But some stick around because the pattern keeps repeating. Over and over.
The story of Gary Kildall and Bill Gates is one of those. Two brilliant technologists standing at the same crossroads in the early days of personal computing. Two very different outcomes.
Kildall created CP/M, the first dominant operating system for hobbyist machines. He was a deep systems guy, the kind of engineer who could make the silicon sing. His work was elegant, credible, ahead of its time. He built real value.
Gates didn’t out-code him. He out-maneuvered him. He saw the platform opportunity, moved fast, cut deals with hardware manufacturers, and built the ecosystem that defined personal computing for decades.
One had the technical edge. The other had the execution edge.And history, as it so often does, chose execution.
Now here’s the part that bothers me: Kildall’s work mattered. CP/M powered real machines and shaped early computing. It wasn’t vaporware, it wasn’t a bad product. It was important. But that wasn’t enough.
And that’s the tragedy in this story. It forces you to ask: how many brilliant technologies never made it simply because their creator wasn’t shrewd enough, aggressive enough, or connected enough? How many things of real value got buried—not because they failed—but because they didn’t get packaged, distributed, and sold at the right moment?
I’ve lived this. I’ve built hundreds of things over the years, and I’ve got patents gathering dust to prove it. Some of those ideas had genuine merit. They could have solved real problems. But they never became anything more than clever inventions because I didn’t build the pipeline alongside the product. I didn’t close the loop between creation and adoption.
And that’s the hard truth nobody tells you when you’re in the middle of building something you love: if you build it, they will not come—unless you build the bridge to them at the same time.
That lesson feels even sharper now as we stare into this new era of AI. Because AI changes the tempo of innovation.
In the past, it took years to design, ship, and refine something worth using. Today, you can spin up a prototype in a weekend. Launch it. See if it sticks. Users tell you what works and what doesn’t, and you adapt on the fly. Iteration becomes the innovation. The process itself is the product.
That raises a fascinating question: does AI change the equation Kildall lost? Or does it just accelerate the same old race?
I think it tilts the field a bit. For the first time, builders can not only create the core innovation but also ship the wrapper, the documentation, the landing page, the demo video, and even the first wave of integrations—without an army of developers or a marketing department. You can actually do the invention and the distribution in parallel.
But here’s the catch: the underlying lesson hasn’t gone away. The world still rewards the combination of vision, logistics, and timing more than it rewards invention in isolation. What AI does is give creators a fighting chance to carry both halves of that equation themselves.
So if you’re building something today, here’s the part I wish I’d learned sooner: don’t just build the thing. Build the path to the thing. Build the pipeline, the adoption loop, the bridge to the people who will actually use it.
Because Kildall wasn’t forgotten for lack of brilliance. He was forgotten because brilliance wasn’t enough.
Comments