Open core, or packaging?
The author's position on this moved between two dated documents, five weeks apart, and both are published here rather than tidied into one — because a site that shows its view moving as commercial pressure arrived is worth more than one that only publishes the settled version, and because the July document names the tension itself, which is the interesting part. Then the test that settles it.
18 June — nothing proprietary
"my line is that everything the company does, the code, the logic, the functionality, and the schemas, is open source. There should be nothing proprietary. You never have the temptation of the bait model, where some of the best features are locked behind proprietary stuff, because the community always sees through it."
With a single, clearly-drawn boundary:
"The moment you have closed repos is the moment you do customisations for the customer, the moment you hit customer data… that becomes the natural place for proprietary, non-public information, because at that point it is the customer's data and their strategy."
That is a coherent position with a defensible line: the boundary is the customer, not the feature set. Nothing that would be useful to a second customer is withheld from the first.
17 July — a subset of the main repo
"more and more we want situations where the customers only have a subset of the code that exists in the main repo, because of security, because of maintainability, because of complexity."
And then, in the same document's own tensions table:
"Open source versus the customer subset | A fuller main repo than the customer receives sits uneasily with a pure open-source claim; this is open-core, and worth saying so plainly."
The test that settles it
There is a real reconciliation available, and it turns on a distinction the June brief did not need to make. From 4 June, the subset is framed as subtraction, not withholding:
"a company might only need 10% of them. So we create a version with only 10% of the features. It has much less attack surface, it is much cheaper to run" — "customisation is not only addition; it is subtraction… less attack surface… cheaper to run… maintainable."
That is a genuinely different thing from open core, and the difference is testable in one question:
Does the customer build contain anything the public repo does not?
No → it is packaging. A smaller build of public code, shipped for security and operability reasons. Every line the customer runs is public. Nothing is being held back; something is being left out.
Yes → it is open core. And per the July brief's own instruction: say so plainly.
The test is deliberately blunt because the failure mode is gradual. Open core rarely arrives as a decision; it arrives as a series of individually reasonable exceptions, each one made under revenue pressure, each one moving the boundary toward the vendor. A binary test applied at each release is the only thing that catches that, and it is the same discipline the stress test applies to a vendor from outside.
Both sides of open core, fairly
| The case for | The case against |
|---|---|
| It is the only model that has repeatedly funded large-scale development without rent extraction on the core. The core stays genuinely open, genuinely forkable, genuinely usable by people who will never pay — and somebody pays the engineers. | The boundary always moves toward the vendor under revenue pressure. That is not cynicism; it is what 2018–2024 recorded. The mechanism is the same every time, and no company has ever announced in advance that it intended to move the line. |
| VS Code is the strongest live example done well — MIT core, and an ecosystem that is real. It is difficult to argue that the world would be better off if it had not been built this way. | And it is the strongest example of the cost: a proprietary shipped binary, a licence-restricted marketplace, and most of its very large user base does not know it is running proprietary software. Executed smoothly enough that the boundary is invisible, which is precisely the problem. |
Where this leaves the position
Unresolved, and marked as such. The June statement and the July statement are both on the record; the test above is the site's proposal for settling it, and applying it is a decision for the project rather than for this page. The self-audit is where that decision will have to be made in public, because the same question — what does the customer actually get, and how does it differ from what is published — is leg one of a stress test we are running on ourselves.