Here’s what is happening. Any existing OIDC/SAML core installation continues to work. You can upgrade without concern. Going forward, we’d like new installers who want to use OIDC/SAML to use full Grist.
Individuals and small orgs with total finances less than US $1 million may apply for a free activation key for the full version of Grist. The free activation program is there for the community. For what it’s worth, Grist Labs, the company, would totally qualify for it. More about the free key program: Free Grist Activation Key FAQ | Grist
This change is directed at our free-rider problem. You’d be surprised at how few companies pay for Grist, and how many of the non-payers are massive. This puts the whole project at risk.
If you’re curious, you can see that from 2022 we’ve been trying to find what it takes to be financially viable, since we’ve found that OSS alone does not work GitHub - gristlabs/grist-core: Grist is the evolution of spreadsheets. · GitHub . That’s our side of this. I hope you take the time to review the measured steps we’ve taken, then make your own decisions based on your needs and values.
I understand and fully respect you decision. Self-sustainability for open source projects is of paramount importance.
On the other side, I’m sorry to say I’m sad. Not upset, but sad.
I had chosen Grist, for it is a great project. And for your bold decisions on what features were available in grist-core. I had contributed a little (very little indeed) and invested on you. I supported the idea of new features behind paywall for enterprises.
Now, after removing such a fundamental feature as SSO from core, I have to think: what’s next? Which fundamental feature will you remove next, when you eventually discover that it’s not enough?
I know my little self-hosting projects will keep working, for now. But, something more important is crackling: trust.
I imagine you evaluated all pros and cons before the announcement, I sincerely wish you the best. I like this project a lot.
Thanks @Emanuele_Gissi for your support through the years, including being our very first github sponsor (we have 16 currently). I hear your concern at Grist Labs saying we no longer officially support OIDC/SAML outside the Full edition of Grist. This message is directed at enterprises, and not organizations of the scale and budget the free activation key program covers. I understand how it is hard to trust this, and of course you will judge us by our actions now and in the future. I appreciate your clear and measured feedback, thank you.
I first took interest in Grist a long while back for a project, but it wasn’t stable then so I ended up using Nocodb. But recently (in June) it became a point of discussion over in the Cloudron community [1], and it caused me to take another look as an alternative. We had some users managing to crash Excel on the web, which opened the door for us to look at some alternatives. So, I hesitantly [2] deployed it for one of the smaller teams within our $1M+ organization (we don’t qualify for a key).
The 5 or so users from that department were enjoying Grist enough they started to convince some people in HR to have a look at leveraging it for some things in their department. Interest has been growing, because a couple of the ladies in IT are particularly fond of the way Grist works, so they became sort of in-house champions. Eventually, with time, Grist may have touched enough departments and created enough value that we can have a justifiable discussion regarding licensing some users. But that’s always going to be difficult when you’re only getting started as the new alternative to Excel worksheets.
Keeping automations premium was the right play - because those features are a real selling points when there are enough people getting value from the fundamental Grist experience.. and no, not just because I don’t want to keep maintaining automations in n8n. I think the current proposition looks healthy, and you have enough gated features to make the eventual jump across to licensed users easily justified.
But by introducing unnecessary friction with the removal of established core features you’re saying the quiet part out loud. You are willing to enshittify the product to punish the few, and destroy the trust the community has in you. Whether it’s free or paid for, arbitrarily disabling a core community feature should be done as a last resort. As the person who puts forward recommendations to management on who we buy from each budget, this incredibly short sighted rug pull means we have to look elsewhere. Not because of cost, but because you think it is ok to treat your supporters this way.
I’m just chiming in here to state the obvious: Moves like these will very likely cost you customers rather than bring in new ones. You should definitely think this over very carefully.
Let me elaborate a bit from personal experience. I’m currently involved in campaigning for Grist, for lack of a better word, inside my organisation (which is part of the public administration of Germany). What I’ve been communicating thus far has gained a fair amount of positive feedback and is now building up real traction. We’re very close to adopting Grist Core as a first step to utilizing your product throughout our organisation. The problem is that, especially for risk-averse organisations like what you typically have in the public sector, all of this is pitched on the promise of feature stability and a trustworthy licensing/monetization model.
It seemed highly likely up until I saw this that my organisation would adopt Grist Core, and then, as it would have proven its great worth without any doubt (low code in public administration being a real thing, after all, and for good reasons), we’d successively move on to Grist Enterprise for its even greater value. But if you start going down this road now - of taking away features from Core to put them behind the paywall -, then I’ll have to agree with @UMNZ: You’re jeopardizing trust. You’re beginning to chip away at the core promise that makes a product like this attractive for organisations like mine in the first place. What seemed like a very safe proposition with an option for future (paid) expansion suddenly looks like more of an optimistic bet where you can’t be certain your free version won’t erode from under you before it has had any chance at gaining the internal traction necessary for the move to a paid model. I can’t speak with any authority as to how private companies will react but for the public sector, I’m sure this will cost you lots of potential customers.
I’ll go one further and project with some confidence that this won’t sit well with the French administration, either. Given France’s (most admirable) stance on tech sovereignty and robust digitization of their public administration, I’d think them very likely to fork off Grist at some point and do their own thing rather than stay on board with you. This would be a very sad outcome.
I would very much like for Grist not to go down this road. Please do reconsider.
I have to agree with TomNit on this. The whole situation gives a strong impression of enshitification in progress. It’s understandable that GristLabs needs to make money, we all do. But removing existing features that are actively used by the community has really bad optics.
My experience mirrors that of Tom in many ways. I work in the public sector, and a lot of the times IT solutions do not come top down, but bottom up. We spend a great deal of time producing Grist workflows that make our users lives easier. A lot of times it’s hard to nearly impossible to get the whole organization to switch to Grist. But bit by bit we manage to find new uses and applications for it and it spreads trough the organization. The organization itself might be huge way outside the 1M$ mark, but the actual use cases are often very local and developed organically. A server for 10 people here, another for 20 people there. People who are super cautious about sharing their data, who want entirely isolated systems, or just regular interdepartmental bickering that makes it easier to have 10 small server over 1 central one. There’s really an endless amount of cases where a decent SSO makes sense. Moves like this, where functionality suddenly starts to get limited, make it extremely hard to build trust and spread the use. Literally every couple of months I get questions from my superiors along the lines of “Is our data secure, will we be able to get to it in two years time.”. Until now I have always been able to say with a clear conscious “Totally secure”, the next time I’m not sure I’ll be able to confidently claim that.
Thanks for bringing up the topic.
As far as I know, OIDC/SAML is the only way to identify users.
Inclusion in OIDC/SAML on paid subscriptions is a common occurrence, for example:
But, all these services have an alternative, access to the table of users and roles and a login form.
Just wanted to add my perspective, since I am in a similar situation as TomNit and David_Fabijan (Public administration. Germany, in my case. Not IT.).
Grist has been well received so far by our team and I plan to establish it further. But public budgets move slowly, especially if only a fraction of the whole administration uses it. The whole org manages more than 1M but our department is funded well below that.
Next year, I could potentially get the funding for “Pro” for a few selected persons, but the automation feature in “Business” is where the interest lies (managing n8n additionally would be too big in scope). We are far off from being able to get the “Business” tier funded, since Grist is not established enough yet.
So we hang somewhere in a limbo.
Ironically, the technical features such as SSO are not even relevant for us at this point in time. But as the others already noted, things have to be stable and trustworthy. Public administration needs those kinds of values. Being “risk-averse” is a good term.
When I researched potential database solutions to replace our aged Excel files and workflows, I wanted to avoid “enshittified” products (judged by the community) and overly enthusiastic marketing. Being also used by the french government was a huge plus. That´s why I started with Grist and it worked out well.
Your need for paying customers is only natural. We don’t pay yet and I think that’s a problem.
In my personal opinion, for our current situation, the industry standard to use €/user/mo for pricing is the greatest hurdle. The jumps in pricing are too high. It is hard to get out of the free model and into a tier that fits our needs.
We have very few power users but a large pool of potential persons with light Grist usage. Paying 288 € for every user is just not feasible.
Governments think in fixed annual budgets. A license with a flat fee and less restrictions on user count could be easier to get money for.
Maybe it would be better to offer other pricing options, instead of moving features behind a paywall.
Thank you for this constructive feedback. On the pricing side, the biggest take-away for me is that we need to better communicate our flexibility in pricing terms. Per-user is what works for most SMEs. At the enterprise and public sector level, orgs come to us to ask for predictable, flat annual costs. Often they prefer large user tier bands.
By the way, we’ve also experimenting with a new pricing model where an installation can have Community team sites, and Full team sites – similar to how pricing works on our SaaS, except it’s all on-prem under your control. The goal for this pricing model is two-fold:
Keep pricing flat and predictable for the IT team that wants to buy support and installation-level governance features, but not be on the hook for per-user pricing
Let the end-users upgrade their team sites when they need to, or downgrade back to Community when they need to. IT keeps the installation-wide security-management and governance tools they need and pay for, like audit logs and admin controls.
In this way, costs are spread across the org’s various budgets. Your department isn’t on the hook for some other department’s usage, or trying to reconcile budgets internally.
So far we’ve offered this to large orgs when they reach out to us to see what is possible. Maybe we should publish this option as well, with a clear explainer. We haven’t published it so far because it’s still early-days and in an experimental phase. But we can publish the experiment.
I want to add my perspective as someone who self-hosts several services, mostly for my own use. On most of them, I am the only user. I do not mind using forwarded headers, signing in through getgrist.com, or sometimes having no login at all.
When I first started using Grist, I actually disliked that it had no built-in local authentication. Over time, OIDC grew on me. It introduced me to that whole world, and I came to appreciate it, including the ability to use the same identity across different services I run like Outline. Existing installs may keep working, but future installs mean changing the deployment process I have used before and making adjustments around authentication. That is frustrating on its own. More than that, though, it breaks my trust in the Community edition.
I have recommended Grist here and there; that is how much I loved the product. I am currently considering it for a company I consult for. They could become paying customers. The idea was to let them use Grist first, see whether it fits their work, and then make the case for paying once they have seen enough value in it. But they are conservative about their data and cautious with new tools. I can work around OIDC, or the lack of it, during the initial “free” stage. That is not the issue. I am now less comfortable telling them that Grist Community is a safe foundation to build on while they evaluate it.
If something people have already built around can later become unsupported outside the Full edition, what is next? API access? Access Rules? A company will not want to put its data and workflows into a tool if it cannot tell what parts of that tool will still be available a year from now. I want Grist to succeed, which is why this is frustrating. This makes it harder for me to keep recommending it with the same confidence.
@anais-grist Thank you for taking the time to answer, this is much appreciated. However, please don’t take it the wrong way when I say that it seems you’re mostly missing the point. This is entirely not about predictable pricing. It’s about a predictable feature set and a trustworthy open-core promise. @deuts’s reply above illustrates this perfectly.
Public sector freeriders - that’s what we are at this point, no one is denying that - will turn into paying customers only if these conditions are met. Seeing as the enterprise edition offers real value, I can absolutely see organisations adopting that subsequently: Once they’re convinced of Grist’s merits. As @Till rightly pointed out, it’s almost always a bottom-up, employee grassroots kind of thing. Take away that stability and trust I’m talking about and it just doesn’t stand a chance. I’m fairly certain these are not isolated cases. At least for Germany’s public administration, it’s a cultural issue in the worst kind of way. Which means you’re looking at an entire market worth of opportunities. Or not…
I personally would like to avoid the term free-riders, it has unnecessarily negative implications. There’s no reason to expect organizations to pay for something they don’t have to, and entirely rational for each group of users to hope that someone else will pay for it. For example, a group of users within a large organization may hope that others pay Grist Labs for support. But they themselves don’t need that, because Grist Labs has built the project well and carefully, so it builds and installs and upgrades without fuss, there is plenty of good documentation, the UI for administering it gets better and better. What would one need support for?
With SSO, we are now taking a different support posture. OIDC/SAML SSO is no longer officially supported by Grist Labs outside the Full edition. This is reflected in our documentation, UI work, and support contracts.
This is a severe and egregious misstep in the spirit of software that claims to be open source. The very concept of OIDC is there to provide single sign on that breaks away from the original vendor lock-in that Microsoft had established with LDAP. Open is in its name.
As a small organization, I already pay for Microsoft accounts to use EntraID, I already pay for our own servers so we can self host Grist, and I rely on the multi factor authentication between the two using OIDC to help keep our small form secure.
Whether or not we may get a free license is irrelevant. You are now moving down a path that is openly advertising a move away from a security-first posture by adding roadblocks and red tape to foundational user management and in-house MFA with ease of integration for small organizations. OIDC was the leading reason we chose Grist from the beginning.
I guess we’ll have to freeze our Grist versions in place and focus on hardening our servers instead of keeping up with the latest features and patches. Trust lost. This isn’t OSS. It’s on its way to being as bad as ClickUp.
Who knows, maybe tomorrow nginx will put a paywall on reverse proxying. Then we’ll see how you feel about this.
Since you’re considering a commercial activity based on Grist, I’d encourage you to join our Partners program. As a partner, we can help you craft your offering to raise your chances in getting the customer. Partners have access to discounts that you can pass to your customers, we can support you during the development of a proof-of-concept and more. You can still offer things for free, and in a way that secures the long-term viability of Grist itself.
You can DM me for more details, if you’re interested.
You might want to read the room? Why would anyone stake their livelihood and reputation on a partner who acts this way? That’s the trust part the community is trying to convey to the team. Focus on creating value worth investing in - not taking it away.
