It makes sense for a successful product that’s being hurt by competitors packaging it up and selling as a paid service. My advice: for a younger product, keep it actually open-source (FOSS).
With either Sentry’s FSL license or FOSS, you as a user can run your own. If you want a paid managed service, you can pay Sentry. With FOSS, there can be competitors who offer such service using the same exact up-to-date version, and undercut Sentry on price (since they aren't paying developers). With FSL, they’d have to run a 2-year old version. That’s a disincentive to competitors.
BUT: even with FOSS, a similar disincentive exists, because the maker of the FOSS software could decide to change license, forcing competitors to run a stale version or invest into their own development, or pay up for licensing.
Seems if you are small enough, pure FOSS is better for this reason (the option to release future changes under a different license is always there). But if you are big enough to have competitors, and you can’t convince enough competitors to pay or revenue share (e.g. through support agreements), then FSL can be a way to twist their arms without hurting most other users too much. (It does hurt to some extent, as the many arguments in this discussion point out.)
[Grist founder here] On separating formulas from data, that's always been an important part of Grist.
In Grist, check out the "Code View" page in the left-side panel -- it shows all the logic (i.e. formulas) of the document along with the Python data model (i.e. all the column names and types).
Also, you can save or download a copy of the document without the data, but keeping all the formulas. So you can get all the logic (and formatting, layouts, etc), and use it for different data.
(No support for solving circular references though.)
Any particular reason why knowing how useful it would be you’ve not implemented some kind of Newtonian iterator to solve circular references numerically?
formulas are a big part of coda and so much easier and safer than excel. I don’t know what layouts and access rules are in grist, but there are similar sounding features in Coda as well.
Shhh, don't tell them about SQLite! It's the secret sauce behind Grist (I am a founder), and we are sort of competitors. Wouldn't want Monday.com knowing about our competitive advantage!
(Grist cofounder here.) "Co-code" first became popular with developers in the form of Github Copilot (and now others), adding productivity. But for spreadsheet users it makes an even bigger difference, enabling them to do what they didn't know to be possible.
This is especially true in case of Grist, which puts the power of Python in the hands of spreadsheet users. So much more is possible, but most users will need some assistance to unlock that.
Grist is a spreadsheet with Python support (I am a founder). Python does make some formulas far easier. Nice to see Excel has data science libraries included from the start, that's something we've had our eyes on for a while. On the other hand, Grist is open source and can be run locally.
For example:
As part of a monitoring system.
HR / crm Database.
Self serving vacation planner and approving system.
Tamperproof GMO(genetically modified organisms) database.
As my go to source as a quick and dirty data dump while hacking...
It's a spreadsheet, Excel was always our primary competition! :) The more Excel follows us, the better for everyone. Python is a start, but they have a way to go. Imagine proper relational data, self-hosting for cloud Excel, open-source, access rules....
