Free Binaries, Again

The phrase "open source" has a birthday. February 3, 1998, at a strategy session in Palo Alto, called in a hurry after Netscape announced it was releasing its browser code. Christine Peterson coined it in that room, and her reasoning was specific: "free software" made everyone think about price, and price was the wrong axis. She wanted a word that pointed at the source code itself. Within a few weeks Netscape and O'Reilly were both using it, and the Open Source Initiative existed to defend the meaning.

The thing the word was invented to be different FROM matters more than the word. There was already freeware, free binaries, software you could download and run and pass to a friend at zero cost, and could not read, could not rebuild, and could not carry forward without the company that made it. The whole point of 1998 was to say that those are different categories and that we should stop confusing them, because one makes you a participant and the other makes you a guest.

Twenty-eight years later, we are calling model weights "open," and I would like someone to explain to me which category they're actually in.

Tobi Knaup made the case this week that open-weight AI is having its Kubernetes moment, and I want to be careful, because I agree with nearly everything he wants to happen. He also has standing on this; he co-founded Mesosphere, built DC/OS, and then watched Kubernetes take the category out from under him. I was on the other end of that trade. I was the first (non-founding) product manager on Kubernetes, which means I spent 2015 and 2016 doing the thing that ran him over.

So when he says "Kubernetes moment," I know exactly which moment he means. And I want to push on the analogy harder than he does, because if you take it seriously — actually, seriously, not as a compliment — it is asking for a great deal more than a download link.

Start with the definition, since we already have one. The OSI published its Open Source AI Definition in late 2024, and it asks for four freedoms (based on the Stallman-coined freedoms): use the system for any purpose, study how it works and inspect its components, modify it, and share it. Open weights, nail use, and share. However, unlike source code, models have a bit more complexity. You cannot study a model the way you study source code; you can probe its behavior, which is a different activity that we call evals precisely because it is not reading. And you cannot modify how it was made. You can fine-tune the output of a process you were never shown, which is closer to sanding a table than to changing the design. Meta's LLaMa ships under a custom license with a monthly-active-user threshold attached, and publishes nothing meaningful about its training data, which is why OSI has had to keep posting things with titles like "Meta's LLaMa license is still not Open Source" and why Meta simply rejected the definition rather than argue with it.

I've had some experience in this rodeo before. I believe open weights are the most important thing happening in AI economics, and I still do. The commodity tier is going to eat this market from below. Good enough at a fraction of the cost, running on hardware you control, is the winning bid for most enterprise work, and the labs sealing off the top of the index do not change that. None of what follows is a case against open weights. It's a case against the sentence people say right after "we went with the open model," which is usually some version of: so now we're not dependent on anyone.

A bit from my history: I was there when, on July 21, 2015, Kubernetes hit 1.0, and Google handed it to a foundation that did not exist the week before. While we released it under Apache 2, I believe the real novelty was the governance. There was real friction from people who did not want to be tied to Google or its schedule. Giving the project away was how you removed our veto. And that's what we wanted! We knew that if we exercised too tight a control over the top, we never would be able to get the industry moving in that direction. I was only one of the people weighing in on this decision, but I am so glad we did.

With the foundation and the license, people also had the freedom to completely fork. Not grab binaries and then hope upstream stayed compatible; people could take every element of Kubernetes (other than the name) and fork away. Not that anyone planned to use this threat, but it kept the community honest. If the steward went bad, or slow, or greedy, you could take the whole project and keep going, and everyone knew it, which is exactly why nobody had to. That is what "open" purchased: Continuity without asking.

This is where I start to reject the concept of "open" models. You cannot fork a model; there is nothing to fork. A fork of Kubernetes is a living project with a build and a roadmap you now control. A "fork" of an open-weight model is a fine-tune of a snapshot, because the two inputs that would let you continue its development, the training data and the compute, were never in the box. The lab kept the factory and shipped you the output. That is not a criticism of the lab! It's a description of what you received.

At the end of 2017, Jeremy Lewi, Vishnu Kannan, and I announced Kubeflow, which was our attempt to open-source the way Google ran machine learning internally. It was ALSO Apache 2.0, with contributions from Google, Cisco, IBM, and Red Hat. It had all four freedoms, for real, the full 1998 package, no asterisks. Sadly, one thing that really hurt us in the beginning (and even now) was that it was miserable to install, miserable to upgrade, and miserable to keep running. We shipped a pile of genuinely open components and told people they had a platform.

We weren't alone; Kubernetes was ALSO miserable. In 2015 you stood a cluster up by hand, in the right order, and if you got certificate rotation wrong you found out about it eleven days later. Kelsey Hightower wrote a tutorial called Kubernetes The Hard Way, and it wasn't satire; it was the documentation that a lot of us actually used. Difficulty didn't kill Kubernetes; it barely slowed it down.

So, difficulty was never the variable. Two projects, same license, same four freedoms, both a nightmare on day one. What Kubernetes had was a few hundred people at Red Hat and Rancher and three cloud providers whose paychecks depended on making it installable, plus a foundation that made it safe for all of them to show up in the same room, with a license that made it legal for them to try.

I think this is the thing missing from all the discussions of model "openness." Publishing something and getting it adopted are two different projects with two different budgets, and getting it adopted and having a community are two more. We shipped the first one and wrote "platform" on the box. We are doing a version of the same thing with open weights, and it is going to cost somebody a couple of years.

Because when a lab hands you weights, you're getting the cheapest artifact in the building. Not cheap to make — training is the most expensive thing anyone does with a GPU. Cheap relative to what it costs to keep a model running in production, for other people, which is where the actual bill lives.

Go count what a frontier lab actually operates. Serving infrastructure that holds a tail-latency target while traffic swings 10x over an afternoon. A batching and caching strategy that decides whether the unit economics work at all. Quantized builds for whatever silicon the customer actually bought, not the silicon you wish they'd bought. An eval suite that catches the regression before the customer does. A safety layer, an abuse pipeline, a deprecation policy, capacity planning eighteen months out, and a human being holding a pager at 3 AM with the authority to roll the whole thing back.

None of that shipped with the weights. And, most importantly, almost none of it is represented in open source either. Not because open source is bad at it, but because open source has never been in the business of operating things on behalf of strangers. Nobody's pager is attached to your cluster. That was equally true of Kubernetes, which is precisely why Red Hat and the clouds got to build real businesses on top of a free thing, and why nobody found that outrageous.

The labs and the hyperscalers are doing an enormous amount of this work, and the open-weight conversation has picked up a bad habit of calling all of it rent. Most of what they're charging for is the product. You can hate the price and still be accurate about what's being priced.

Knaup is right that a serving stack has shown up, and it's a good one. vLLM, SGLang, llama.cpp, Ollama, MLX — I use these; they're excellent, and honestly, they were never in doubt. Engineers build inference runtimes because inference runtimes are FUN. Nobody open-sources a deprecation policy. Nobody sends a pull request with a capacity plan. The missing pieces are missing because they're boring and because somebody has to be accountable for them, and accountability is the one thing a download cannot transfer.

People are choosing open-weight models right now as an insurance policy, a hedge against a lab repricing them, deprecating them, or quietly re-aligning the thing they built on. I understand the instinct completely; I've written about what it costs when the wire in front of the model goes away. That's not to say weights on your own disk, which let you keep running what you already have, isn't genuinely worth something. But they do not let you extend it in the spirit of open source. When the version you're on stops being good enough, your options are to wait for whatever the lab decides to release next or to stop.

Run it, or stop. That's the whole menu.

So let's total up what "open" has actually bought us so far. You can run a very good model on hardware you already own, and the top slice of the inference bill, the expensive slice with somebody's margin stapled to it, goes away. I've spent a lot of words arguing that it's going to reshape this market from the bottom, and I still believe that. It is also, start to finish, an argument about price.

But I want to capture, in the current discussion, the wisdom from those people in February 1998 in Palo Alto, in a new phrase, precisely because the old one made everybody argue about price, and price was the wrong axis. It took about twenty-eight years for us to need their word again, and we've spent it on a discount.

Want to learn how intelligent data pipelines can reduce your AI costs? Check out Expanso. Or don't. Who am I to tell you what to do.

NOTE: I'm currently writing a book based on what I have seen about the real-world challenges of data preparation for machine learning, focusing on operational, compliance, and cost. I'd love to hear your thoughts!