Hacker News Reader

Comment by throwaway81523 | Hacker News Reader

"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.

View on HN

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.

Hey great product! Wondering if you can provide some development insights. I'm looking at the activity for the grist-core repo

https://oss.gitsense.com/insights/github?q=pull-age%3A%3C%3D...

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!

Thanks for the insights! I'm trying to support different workflows and hearing about yours helps.

Oh so it's not even open source core then.

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.

and people can counter comment complaining about complaining...

It's allowed but you need more than that to justify it.

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.

I like those comments; I enjoy seeing and trying alternatives.

The title previously said open source, not open core.

When its marketed as a pro of the project, is debating it not debating the contents of the project?

This reminds me of Tailscale, which has open source clients, but the server is not open source

and, sure enough, someone wrote an open source server: https://github.com/juanfont/headscale

What do you think better way for opensource startups if it is not open core model?

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.

When they offer you to pay for support and hosting it for you.

Is these approaches sustainable?

Reply on news.ycombinator.com