PickWorth

Method

When open source actually matters

Open weights sound like a pure win, and a lot of the argument for them is aesthetic. Here are the four conditions under which open source genuinely changes the decision — and how to tell them apart from the ones that do not.

22 October 2026 PickWorth Editorial

The short answer. Open source changes the decision under four conditions: the data cannot leave your network, the token arithmetic changes what you can build, you need to modify the tool in a way the vendor will not, or the cost of the hosted version stops adding up. In every other case it is a preference dressed up as a requirement.

When does open source actually matter?
Under four conditions: the data cannot leave your network, the token arithmetic changes what you can build, you need to modify the tool in a way the vendor will not, or the cost of the hosted version stops adding up.
When is 'open source' just a preference?
When the data can leave, the token arithmetic does not change the work, you do not need to modify the tool, and the hosted version is cheap enough. In those cases it is a preference dressed up as a requirement.
What is the four-condition test?
Data stays on your network? Token arithmetic changes the work? Do you need to modify the tool? Does the hosted cost stop adding up? If none, the open-weights version is not the right pick.
Does open source automatically mean better?
No. It means more control and a different cost structure, not necessarily better output for your job. The four conditions decide.
Where do I see the open-source tools we covered?
The open-source Cursor alternatives list: Cline, Zed, Aider, Continue, Tabby, Void. Each picked by scenario and by whether the project is still being maintained.
Does PickWorth take money from any vendor or project?
No. Reviews are written by a single editorial team; GitHub data (stars, licence, last push) is verified from each repository.

The four conditions

Almost every serious argument for open weights reduces to one of four conditions. They are worth naming separately, because the first two are usually decisive and the second two are often not — and mixing them up is how people end up running infrastructure for a preference.

Condition Test Usually decisive?
Data cannot leaveIs there a contract or compliance clause saying so?Yes — settles it outright
Cost arithmeticDoes the token price change what you can build?Yes, at volume
You need to modify itIs there a change the vendor will not make for you?Sometimes
LongevityMust this still work in five years?Sometimes

When the data cannot leave

This is the condition that settles arguments, and it is the one people reach for last. If a contract, a compliance requirement or a client's security review says the codebase does not leave the network, then the question of whether the closed tool is better is simply not on the table — you are choosing among the open options. The thing that makes this condition powerful is that it converts a preference into a constraint, and constraints are what end debates. If you genuinely have this constraint, you already know, because someone has told you in writing.

When the arithmetic changes

The second real condition is volume. An open-weights model at roughly an order of magnitude below frontier token pricing is not a small discount — it changes what you can afford to spend a model call on, which changes what you can build. At low volume this is a rounding error and the closed tool's quality edge wins. At real volume it is the whole decision, and the answer is usually a router rather than a choice: the cheap model for the easy majority, the frontier model for the hard minority, and the quality gap absorbed by the split rather than argued about.

When you need to change it

The third condition is real but narrower than it looks. If there is a specific modification you need — a behaviour the vendor will not add, an integration into a system they do not support, a fine-tune on your own data — then access to the weights is the only path, and the operational weight is the price of the requirement. But "we could modify it if we wanted to" is not a requirement. Almost nobody modifies their tools; the option is what people value, and the option has a running cost that is paid every month whether or not it is ever exercised.

When it is just a label

Which brings us to the fourth condition, and the one most often overstated. Longevity is a genuine argument for open weights — a tool with open weights cannot be taken away the way a service can — but it only bites when you have decided to bet your workflow on a tool surviving years. For most work, the honest horizon is months, and a paid service that you can leave is a smaller risk than infrastructure you have to maintain. The tell that you are in preference territory rather than requirement territory is simple: if the same argument would still feel right with the words "it just feels better" substituted in, it is a preference. That is allowed. It is just not the same thing as a decision.

Related