"Open core", seems to mean the low level libs (useful for sure) are FOSS while the full featured apps are proprietary. This is kind of unpleasant since it creates a tension between a natural desire to build featureful apps with the low level stuff, and not wanting to "bite the hand" that supplied grist-core. Similar things happen with other partly-proprietary programs like ansible.
Aren't there already some FOSS alternatives to google sheets? No idea about airtable, don't even know what it is.
As for simple ways to write a form app, ActiveAdmin is one of the few things I like about Rails.
Open core is definitely a tension (disclosure: I work at Grist). Specifically for Grist, we differentiate by offering data portability and autonomy, and a full-featured open-source app is part of how we do that. I invite you to check the repo out, you'll see we're not holding back. We did want to flag the project as open core from the start, since we will build proprietary services and features around the core app (which again is very featureful!), and don't want that to come as a surprise down the line.
I appreciate you taking the time to answer this question. Often projects seem to skip over such difficult/awkward questions, but seeing an honest reasonable answer to it makes me want to check out the project and its ecosystem more.
and it looks like not much has changed in the last 4 months. Is development mainly happening on your SAAS product or is there another repo I can analyze?
Development currently happens on a private mono-repo with all sorts of stuff in it - including for the SaaS environment yes, and bits left over from when Grist started out initially as a stand-alone desktop app, and so on. Commits are pushed to grist-core about once a week, using git subtree. If you look at commit history, you'll see plenty of features going in month after month. Since we currently develop elsewhere, you'll see few pull requests on github. Internally we use phabricator, which is deprecated now, so we'll need to rejigger our setup soon. It would definitely be good to get more of the development process out there, especially now more people have found us!
Why does every "Show HN"-style thread on here always starts with a comment from somebody complaining about about the project's license, or how the project isn't "open-source enough" for them?
The authors are at liberty to choose whichever license they see fit, they have their reasons, what else is there to complain about? Can't we just debate the actual contents of the project?
and the commentor has a liberty to comment if they dislike a given license. If the core of marketing benefit is a given program being open source, yet the license is limiting in that sense, I don't see anything wrong with mentioning that issue.
I don't disagree, but I will also take debates about licensing over 30 separate "Looks cool! I've built something similar here: PLUGS PROJECT" comments.
Calling it open core / open source isn’t a requirement, and often it looks like it’s only done to attract engineers that want to work on OSS and as a marketing funnel for PMs that don’t expect the software to have a paid tier.
In my opinion, the differentiator is how viable the ‘open core’ product itself is by itself; I can’t speak for the thread’s product, but Redis is an example of the good side of this coin: core functionality, even that related to security and user permissions isn’t gated to their paid plugin system, while Elastic before 6.0 (IIRC) was pretty bad as application authentication wasn’t included in the open source edition. Also, Elastic and Mongo’s current SSPL license is just a workaround for not wanting to associate their respective codebases with the string ‘AGPL’ while still preventing cloud customers from running hosted versions, all in an effort to hopefully not turn away good talent/good customers that want to use “open source” software.
This distinctly reminds me of MS Access. Was a teen at the time, but saw (through my father) a whole bunch of small businesses that basically ran off of an Access database with a bunch of forms for invoicing and such.
My education was in business and accounting. But working with data these days I am surprised to find that the popularity of MS Access was greatly exaggerated.
No no, it's not an alternative to Airtable and Google Sheets, it's much more than that! Seeing the demo, coupled with the Python support, I felt like anyone could built a complex SAAS like Salesforce on it.
Thanks for the reminder of SQLite's limits. I knew that they were enough to just not think about it for everything I could imagine practically doing. But that I could even extend them beyond even that was nice to see:
> The default setting for SQLITE_MAX_COLUMN is 2000. You can change it at compile time to values as large as 32767.
If you don’t need concurrent transactions, SQLite is usually more than enough. A lot of people’s “big data” problems, not really big data but still significant data, can be solved using SQLite.
The use-case of this app is that a couple of people editing things at a time, which is perfect for SQLite. It can read a lot, only struggles when you have hundreds of parallel write transactions. It's a big misconception about SQLite that it doesn't scale. It absolutely can if you don't write it a lot!
As a developer who has been in React/Angular/Vue era, why didn't this project leverage these modern technologies for UI and instead went with Backbone and Knockout?
I am just trying think outside of the modern widely used frameworks and see how they solve some unique problems?
Please anybody can tell me why still anybody use good old technologies for frontend in their products?
Well, think about it like this. React had several major versions in recent years, and did remove several APIs. Also the whole thing with the new hotness of the hooks API (which, honestly, I just truly don't get).
Angular had the whole thing with Angular 2, where they just shipped a whole new framework with the same name. So everyone with angular 1 codebase was, well, stuck with angular 1.
Don't know much about vue, but I think there was some drama about rather large API changes from Vue 2 to Vue 3. Correct me, if I'm wrong.
Backbone and Knockout, on the other hand, look fairly complete. Almost no chance of backwards incompatible changes there. So you can just write your code and be done with it.
But, honestly, one should use things that one knows. My current project is written in React. I'm fine with it. And if I had to start a greenfield one, I wouldn't use anything else, because I am proficient with React. I can deliver features. After all, our customers want the features, not the hot new framework.
> Why shouldn’t they use stable technology they are proficient with?
This perspective is one of the major indicators of an engineer with more experience managing real projects. Making a technology choice or transition is a milestone/roadmap affecting decision. To do so for preference over deliverability has killed many a project.
Eh, I'm pretty sure Backbone and Knockout are more stable than React :) They didn't have a release since 2019.
I mean, React itself is quite fine with backwards incompatibility. But how many completely backwards incompatible versions did react-router have? I think there four, but I can be wrong.
Despite all the talk, there isn’t a world of difference between how apps used to be written 10 years ago and more modern frameworks. The tooling and the language have evolved, but you still manage state in similar ways, fetch data, build components, render.
Mainly you’ll be managing the rendering lifecycle manually in Backbone, which you’d end up doing in React anyway to get the best performance for an app like this - you’ll get molasses if you naively build a spreadsheet in react.
One thing I consider a huge advantage: you can read and understand the source in one afternoon. Makes debugging and optimization a lot easier.
>you’ll get molasses if you naively build a spreadsheet in react.
I digged a bit more on other real world applications. Found two interesting posts from atom text editor implementors. [1] Why they moved to React. [2] Decision to implement text editor DOM updates manually instead of via React
I looked at it for 5 seconds and was able to understand what it does without fine studying the functions. That is therefore an excellent example of coding practice. Good structure, clean, excellent comments that were explicit not tacit and provide any newcomer to the code with information about what is going in. A great way to future proof the code.
Coincidentally, I was once passed up for a job after writing code like this. Verbose code is apparently cartoony to some people, but I believe code should be written to be read.
This looks like just what I needed when I built my "admin ui" last year.
Instead of building an admin ui with Django or similar, I encourage you to just stick with a web-based spreadsheet for your internal users (if you have a small team, technical teammates, startup, etc).
In that case you may not even need to build a web based one. There's lots of nice DB GUIs which will connect over an SSH tunnel. If you're after a record editor, they're often enough.
For anyone wondering what Open Core means, Grist explains their approach:
`Grist Labs is an open-core company. We offer Grist hosting as a service, with free and paid plans. We intend to also develop and sell features related to Grist using a proprietary license, targeted at the needs of enterprises with large self-managed installations. `
That is amazing. I've complained about the lack of "spreadsheet but more structured" ms-access-like solutions here a few times. I've been a happy airtable user for a while. But this is really the next step. I love it and can't wait to give it a go (self hosted)
I'm not the author of this post or the software, but as a general rule, if docker can run it, so can a host machine without docker (unless docker itself is a dependency which is rare and generally only done for Docker specific tooling).
Here you can see the the image is based on buster which is a Linux type host. So you can almost certainly get it working on FreeBSD
Airtable makes most money from pro/business use cases and that's what alternatives mentioned here compete for.
But consider personal/family use: Recipe collections, inventories, todo, personal project planning and tracking, ... There competitors won't need more powerful scripting/customizability, just basic feature parity plus cutting the dismal ~6 seconds startup time of Airtable's Android and Windows apps. "Same but faster" wins me over.
I tried to load the CSV that I most recently imported into Google Sheets into this hosted Grist and it choked. The behavior of the progress bar implies some kind of super-linear algorithm.
The most important component of "alternative to Google Sheets" is function. "Open core" is an aesthetic matter of little interest to most users.
It's a Node app, so CPU-bound work will run linearly on a single thread unless work was done to break up work into multiple processes or worker threads.
I've been looking for something like this for ages! Self-hosting is so important for databases; I plan on piping way too much data for me not to own the stack.
Baserow seemed to be my best bet initially, but it seems like the Grist feature set is way more what I'm looking for.
if i remember correctly, the self hosted version of baserow doesn't have all the features that the paid version has, which is something that made me a bit apprehensive about using trying it out
Yeah, I used to think the same thing (that Airtable is a Gsheets and Excel competitor). I find it more like Access + Excel. It's a database software with a nice and powerful front end.
Like airtable and ms access, this is a bit more structured. You can do `=$A` to reference A from another column in the same row. But if you want A1+A2, then you probably want a summary table like "group by", or chart it, or do something else. Think about it like a database - summing a column from rows 1 and 2 is not something you normally do.
You can still do this if you want: (there may be an easier way though)
=sum(row.A for _,row in zip(range(2), Table1.all))
I was tempted to try this but I'm fed up with getting spam from US-based companies so I'll only jump on board if they either comply with GDPR or otherwise tell a really good privacy story. Sadly that doesn't seem to be the case here, with a paltry privacy policy hidden even further out of sight than usual and no promises about handling data at the point of capture.
Sure, I could sign up with a temporary email address to try it out, but why invest that effort if I know that I'm not going to trust them if I become a regular user?
Believe it or not, I have actually considered that possibility.
However, I think Grist looks like a great project and I can see they are reading the comments here. They might appreciate the feedback and it might not be hard to act on it.
Plus, they might be small enough to fly under the CCPA radar for now, but I suspect privacy matters to many people inside the USA too.
Is the implication here that if a company collects your email and send you a message, that’s spam and not considering your privacy?
I’m genuinely curious - I run a SaaS and have spent way too much time ensuring privacy and refusing the use 3rd parties whenever possible. I get occasional emails from folks asking me to delete their email address in our system - we do not send almost any email ever and every email has an unsubscribe link - but I can’t sort out the goal - if you sent me an email so I get rid of your email - aren’t you… giving me your email? I can’t make it into a reasonable position in my head. What is the dream system from your perspective?
Thanks for asking. I'm using a broad definition of spam here although not quite as broad as the one in your question. :)
In ascending order of impact from slightly annoying to serious issue:
1. Sending marketing without consent. In the EU and UK this is unlawful (PECR regulation 22); elsewhere it's still highly unwelcome. This applies to users/customers who have chosen to sign up (just ask when you collect the data).
2. Sending reminders for unnecessary actions such as giving feedback. Reminders should be for genuine problems like unpaid invoices.
3. Missing/broken unsubscribe link or not acting on it. The latter is so common I began to doubt my memory and started saving screenshots. Even years later, marketing often resumes, perhaps after a botched provider migration.
4. Data breaches. Whether sold, given away or lost the effect is the same: too much spam to wade through (when looking for false positives), eventually making my email domain unusable and forcing a migration. I've used a different email address for every company to track this (> 20 years) and around 1 in 25 providers are affected.
Points 3 and 4 might help to explain why people are asking you to delete their data. Even if you have done none of the above, the well of trust has already been poisoned by others.
Companies that win my trust tend to follow a couple of broad principles: be transparent about how you use data (and keep promises), and give the user control.
To your last point, yes it's difficult to fully erase data immediately, especially by email.
By way of example, in cases where GDPR applies, a data controller might need to keep a record of the request for a while to demonstrate compliance. This is provided for in the regulation but the company would need to keep it for no longer than necessary, be transparent about how long that is, minimise what's kept and keep it secure.
In practice, the best thing would be to provide a self-service delete capability. Log in, go to My Account, delete account. Personally I don't mind an email confirmation. Good companies don't try to trap customers, and if I can delete my account easily then I will leave with a positive experience and probably return later.
Failing that, if I have to email you asking you to remove my personal data, I would make the calculation that having my deletion request in your inbox is not as risky as having it in your main customer database, which will likely to be replicated to several other data processors as well. You could always send an email saying you've carried out the request and will then delete the email thread immediately after.
Not saying you should do any/all of the above but I hope it helps.
This looks good but you need to import the data into it. It would be great if it can be connected to an existing DB.
From the discussion, came across https://nocodb.com/ but the authorization levels doesn't seem fine grained enough. For ex. limiting access for group of users to a particular schema in postgresql
Where do you see a Pro plan? Their pricing[0] lists a 10 documents limit for the free Individual plan and unlimited for the paid plans Team and Enterprise.
Their pricing-site is just broken. You get the 10 Documents for teams on mobile or when you shrink the window on desktop small enough to force the side into a vertical(?) view of the blocks.
Did you settle on "last change wins" for simultaneous changes, or was that even an error state that occurs? I'm pretty sure GoogleDocs just have the second text/cell/whatever replace the new edit as soon as it hits the server.
Aren't there already some FOSS alternatives to google sheets? No idea about airtable, don't even know what it is.
As for simple ways to write a form app, ActiveAdmin is one of the few things I like about Rails.