As a Grist user, my ‘2 cents’ on the direction that Grist seems to be heading towards and issues due to it:
My Position
Everything Grist Labs ships as code — community edition and full edition alike — should live in grist-core under Apache-2.0, as a single edition. Not a better-drawn boundary. No boundary.
I am not asking for source-available, and I am not asking for a generous free tier. I am asking that the open-source project be the whole product, and that whatever Grist Labs sells be something other than access to code.
Standing
I run Grist Community edition in production: self-hosted on Postgres, Redis-backed doc workers, S3-compatible external attachments, gVisor sandboxing, Keycloak OIDC.
I chose Grist over the proprietary alternatives for one reason: the core was Apache-2.0 and the format was portable. Every hour I have put into it since rests on that.
What is currently outside grist-core
This is the list from the project’s own README at v1.7.18, under the heading Features not in grist-core, with the years given there. My summaries, not theirs.
| Feature | Year | What it is |
|---|---|---|
| GristConnect | 2022 | Lets a site with Discourse login plugins provide logins to Grist. |
| Azure document storage | 2022 | Azure back-end for document versions; core covers S3-compatible only. |
| Audit log streaming | 2024 | Audit-oriented event organisation and a configuration UI. |
| Advanced Admin Controls | 2025 | Installation-admin page for monitoring and editing user access, using administrative endpoints absent from core. |
| Grist Assistant | 2025 | Broader AI assistance — building tables and dashboards, styling, explaining access rules, modifying data. Core has the formula-only assistant. |
| Invite Notifications | 2025 | Email a link when a user is added to a document, workspace or site. |
| Document Change and Comment Notifications | 2025 | Change notifications by email; core can approximate this with webhooks. |
| Automations | 2026 | Trigger-driven workflows: conditions on any table, email or webhook actions, delivery log. |
| OAuth apps | 2026 | Register and scope OAuth applications to orgs, workspaces or documents; review and revoke. |
| MCP server | 2026 | Built-in Model Context Protocol endpoint for AI clients over JSON-RPC. |
| Single sign-on via OIDC or SAML | 2026 | (no description given) |
Every item on this list should be in grist-core. All of it is code. All of it costs nothing per additional user. None of it is a service.
What changed, and when
v1.7.16 — yarn install in the Apache-2.0 repository now builds the full edition by default, via a post-install hook that fetches the proprietary material. The community build became the opt-out.
v1.7.17 — the Admin Panel gained a control that downloads proprietary extensions and restarts the server in place, and a Document Settings checklist that lists unavailable features and what each is waiting on, including the full edition, with a request-to-admin flow.
v1.7.18 — Grist Labs stated it will no longer officially support SSO via OIDC/SAML outside the full edition; the Admin Panel marks both as requiring an activation key; and the README moved SSO into the list above.
What I verified, and what I am not claiming
I did not take the v1.7.18 note at face value. I cloned grist-core and read the login path at both tags.
getCoreLoginSystem() in app/server/lib/coreLogins.ts iterates a LOGIN_SYSTEMS array and returns the first provider that builds. OIDC and SAML are both present, unconditionally. OIDCConfig.ts and SamlConfig.ts contain no edition or activation checks. There is no new-install-versus-existing-install distinction anywhere in that path.
The code was not removed, and I am not claiming it was.
What I am claiming is narrower and, I think, harder to dismiss: OIDC and SAML have been in grist-core for years, substantially contributed by French public-sector developers, and the project’s own README now lists them among features not in grist-core. Whatever the source says, the project’s description of itself has changed, and it changed in one direction.
One related observation, stated with its limits. v1.7.18 added maxUsersPerOrg and maxApiCallsPerOrgMonth to app/common/Features.ts, set to 10 and 3000 on the free team product, with enforcement in HomeDBManager.ts, ApiServer.ts and usageKeys.ts. Neither field existed in v1.7.17. I traced the org creation path in HomeDBManager.ts and self-hosted team sites land on the stub product with an empty feature set, so self-hosters are not affected today and I am not suggesting they are. I note it only because seat and API caps are now enforceable code in the open tree where a month ago they were not.
Why the stated justification does not hold
The README says proprietary features are targeted at the needs of enterprises with large self-managed installations.
Test it against the table. Automations is webhooks and a scheduler. Notifications is SMTP. Admin Controls is SCIM plus admin endpoints. MCP is the REST API with a server in front. Audit streaming is structured events plus a shipper. These are not enterprise-scale concerns; they are what a general-purpose data platform is expected to do. The README itself concedes as much for several of them, noting that core can achieve similar results with more work.
The same section commits Grist Labs to being thoughtful about how proprietary offerings impact data portability and autonomy. Which authentication provider I can connect to, and whether that connection is supported, is an autonomy question. It is difficult to reconcile that commitment with the last row of the table.
Why this matters to people who build on Grist
I cannot build on a boundary that moves.
That is the objection. Not the price — the free activation key genuinely is free below US $1M in total annual funding. Not the features — most I can reproduce against the REST API. The problem is that in July I could have said with confidence which capabilities were permanently mine, and today I cannot, because the answer turned out to be revisable by release note.
Every self-hoster who has recommended Grist internally did so on an implied promise about what the open project is. When that promise is adjusted, the cost falls entirely on us, and it is not a cost we can price in advance.
The ask
One edition. Everything in grist-core. Apache-2.0.
Every row of the table above, moved into the open tree. Alongside that:
- A written, versioned commitment that no capability shipped in
grist-corewill be moved out, restricted, or de-supported — with particular weight for externally contributed work. - Restore the community edition as the default source build. An Apache-2.0 repository should not produce a proprietary artifact from
yarn install. - Resolve the documentation contradiction. The help centre describes the Community edition as including SSO provider connection; the README and product pages now say otherwise.
- A statement that plan-limit enforcement will not be applied to self-managed installations.
This model works, in harder markets
I am not going to propose a business model, and I do not think users owe vendors one. But the claim that gating is necessary is presented as a fact about markets, so it is worth showing that it is not.
Frappe Technologies has published ERPNext under GPLv3 since 2008 with no paid enterprise edition and no feature paywalls — every core module included. Their pricing page states directly that unlike companies which mislead customers with open-source claims and eventually charge for enterprise features, they are 100% open-source, with hosting and enterprise support as their primary revenue. They price on compute rather than per seat, so large headcounts do not scale licensing costs. Implementation is handled by a certified partner network rather than by Frappe, so they can focus on the product. ERP is a considerably harder market than this one.
Proxmox Server Solutions publishes Proxmox VE under AGPLv3 with every feature present in the free download — clustering, live migration, high availability, backups, firewall — and nothing locked behind a key at runtime. The subscription buys access to the more extensively tested Enterprise repository, support tickets, and a response SLA, priced per CPU socket per year. They compete directly with VMware.
Two companies, two decades, two hard markets, zero gated features. So “our market requires us to gate” is a choice, not a constraint.
The lesson I would take from Frappe specifically: they treat not gating as a competitive asset and say so on their pricing page. It is a material reason I trust them enough to run my business on their software, and I am a paying Frappe customer.
Who the gate actually binds
It is worth being precise about who is affected, because I expect this post to be read as wanting more for free.
By Grist Labs’ own policy, the full edition is already free for individuals and organisations below US $1M in total annual funding. For that entire cohort — the great majority of self-hosters — the gate generates no revenue whatsoever. What it generates is uncertainty: a set of capabilities held on a one-year renewable grant rather than an irrevocable licence.
So the revenue question concerns only organisations above the threshold. Those organisations have platform teams. Forward authentication is available in every edition; putting oauth2-proxy or Traefik ForwardAuth in front of Grist and pointing it at an existing identity provider is an afternoon’s work, and nothing in the Apache-2.0 licence prevents it. The same holds for most of the table above — webhooks, SMTP, SCIM, the REST API.
The gate is therefore a speed bump for the organisations Grist Labs most wants as customers, and a source of doubt for the ones it has already decided not to charge. I do not think that trade is working, and I do not think removing it costs Grist Labs revenue it is currently collecting.
Where I stand
I self-host Grist and I intend to keep self-hosting it. That is not a transitional state on the way to buying hosting; it is the deployment model I chose deliberately, on infrastructure I control, for reasons that are not going to change.
So what I want from Grist Labs is not a product. It is a commitment: that the open core is the whole product, and that what is in it stays in it.
I will not build further on a codebase whose open boundary is adjusted release by release. The way to end that concern permanently is to have nothing left to adjust.
One edition. In the open.