Continuing the discussion from Introduce Yourself: New Member Monday [September]:
Replying with new topic since this isn’t about introductions.
Baserow is an open-core project. Open-core is not merely a business model, it also refers to a project that has both an open-core under free/libre/open terms and also part of the software project that is under proprietary terms.
I was struggling with thinking through how to talk about situations like this. One of the leaders in the Open Source world who I was discussing with brought up a great analogy, the use of “Organic” label on food. Organic food is not partly organic. If it is, then it has to say “made with organic ingredients” or similar, it can’t have the full label unless it is all organic.
If Baserow were to use an actual different name and some clear separation between an entirely open-source project and some derivative with a different name that was proprietary, then it would be honest to say “Baserow is an Open Source project”. The same applies to GitLab and other open-core projects that obscure the distinction with one name that applies to the business, and multiple versions of software.
“Baserow is a mostly-Open-Source project” would be fair. Or “Baserow is an open-core project” is the simplest honest thing to say. Being open-core does itself say that the core is open, as is true.
As much as I don’t see any malice, any attempt to hide anything, it is a real problem pattern (which is not exclusive to Baserow) to dilute and obscure the meaning of Open Source such that people learn about many Open Source projects and then have to investigate further to see which are actually just Open Source and which are open-core. That distinction is pretty important. So, while you are absolutely right and good to use “Open Source” as a term for the open core, I’d urge you to say explicitly right up-front that it’s “an open-core project”. That will avoid anyone reacting negatively to thinking it’s fully-Open and then later learning it’s open-core. Being clearer with the language this way builds stronger trust. Keep in mind that we live in a world where a lot of once-community-first projects have sold-out their values, and you want to assure people that’s not you.
That is a great and honorable. Unfortunately, there is a tension because some amount of modest lock-in might be in your business interests. If you want to make an absolute commitment to fighting lock-in, you could take these steps: put that commitment in some hard-to-change governance document and figure out what coding and legal choices would remove from you even the possibility of lock-in temptation. It is easier to avoid temptation than to resist it — Dan Ariely.
Thanks for what you’re doing to care about and engage with the community.