Open-core concerns

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.

1 Like

One thing to take into account when you decide if you call yourself Open Source or Open Core is that we have to consider who the audience is and what their understanding of these terms are.

Most people that use Baserow, do not know what Open Core even means, we have clarified this in our documentation so that we can be more specific if you want to know exactly how our project is licensed.

So to the average Baserow user Open Source is a term they understand, and they wouldn’t even know that technically all of the software has to be freely available (which seems to be your definition of Open Source roughly?) , for the average person when they hear Open Source they think “you can have a look at the code yourself”.

Now I understand that you are frustrated about the fact that the term is being watered down, but people do this all the time to make things more understandable for the average person.

If you were talking to your non-technical friend about Modals you probably wouldn’t call them Modal you would call them Pop-Up, which is technically wrong but it is the term non-technical people understand.

Let me know what you think about that aspect of the naming :slightly_smiling_face:

1 Like

I don’t have my own definition. The definition is near-universally respected: https://opensource.org/osd

The proprietary part of any open-core project does not meet the definition. Baserow doesn’t have any problematic claims to the contrary either (meaning Baserow doesn’t ever say wrongly that the proprietary part is Open Source).

That’s not a useful emphasis because it’s like describing that a lot of people know that “Organic” is a label on some food, but they don’t know what it means. We never defer to the existence of totally ignorant people as a way to defend what a label means.

The average person among those who do understand generally what Open Source means is indeed a non-wonky sort. They don’t know which licenses are officially recognized as Open Source. They may have misunderstandings about exactly what it does and doesn’t cover. Yet overall, they do mostly know that Open Source means more than source-available-to-read. They know that Open Source means there are no legal obstacles to using, modifying, and sharing the software.

I’m not objecting to making things accessible to a wider audience. But just insert the “organic” food analogy to see the problem with your framing:

“I understand frustration about the organic label being watered down [and used for food that has only partly-organic ingredients], but we want to make things more understandable for the average person.”

This sort of thing isn’t making things more understandable, it’s making it less understandable. “Open Source project” as a label without qualifications generally and strictly means anyone can get the source, share it, modify it, and use it freely. If it only sorta sometimes means that some of the software is like that but also there’s proprietary parts you cannot share, use, and modify, then this is reducing understanding.

The “Modals” vs “Pop-Up” comparison doesn’t have the same problems.

1 Like

For clearer and more honest labeling, (e.g. at the GitHub README) instead of " Baserow is an open source no-code database tool", make it “Baserow is a no-code database tool that is open-core (mostly Open Source with some proprietary premium features).”

But I have a suggestion for Baserow to consider that would remove all the issues because it would no longer violate any aspect of the Open Source definition:

Use an open-core business model but with 100% Open Source software. Here’s how it would work: Keep the limitations around certain features even though the entire source code gets licensed under MIT (or switch to AGPL to block others from making proprietary derivatives). So, all the users at Baserow.io would still have all the same limitations, still be prompted to pay to get the premium features. All the self-hosting where people host unmodified software would also have such limitations except you’d have a variation of the message so that prompts them to pay for a support contract or become sponsors/patrons. Perhaps some code or something associated with their contract would be used to enable the features. Alternatively, allow the features to work but put modals in certain places that tell people they should sponsor Baserow. Done the right way with the right messaging, there are businesses that would feel adequately obligated to indeed fund Baserow, have a contract etc.

With that approach, people could modify the software to remove the modals or limitations, but there’s friction both socially and technically in doing that. Some people will be more comfortable funding Baserow because they appreciate it being 100% Open Source. Others who don’t understand Open Source anyway will just treat it exactly as they treat it now.

Because this approach is 100% Open Source, if you also drop the CLA, that would remove from Baserow the capacity to impose lock-in or to move to mostly-proprietary (or even all-proprietary) terms later. The ultimate in this direction is AGPL without CLA becuase it avoids the risk of ever being tempted to sell out values. It engenders trust when a company shows willingness to close the door on the option to go in a community-hostile direction.

Side-note: who makes proprietary derivatives

Despite my wanting to not draw attention to a direction I dislike, I will be complete here. There’s another benefit to CLAs from a business perspective besides the project itself building proprietary software. Some 100% Open Source projects with zero compromises still use CLAs along with copyleft licenses like AGPL in order to sell proprietary licenses of the same software to businesses who separately want to make proprietary forks for themselves. In that case, the project is enabling proprietary software as a means to get funding, but the project remains 100% Open Source itself. Despite my complaints about that direction, it does leave the main project with more integrity than if the project itself mixes FLO and proprietary software. I don’t know of any licensing-based method for a project to block itself from being more proprietary while still having the option of selling proprietary licenses to others. If the project has the capacity to shift to proprietary (either because of CLAs or because of permissive licensing like MIT), then it has the capacity to do it directly or to allow others. The one method to keep itself FLO while offering proprietary licenses to others would be to have CLAs or permissive licensing but some governance structure that prohibits the project itself from becoming proprietary.

Anyway, the main point is that there are ways to be completely Open Source and still use open-core elements in the business model. And doing that has some merit, especially if you do sincerely value Open Source principles.

And yes, there are some still-open-core things you can also do to entrench Open Source values. The concern here isn’t just a picky one about prescriptive labeling. The concern is whether I and others can trust the long-term trajectory of Baserow given numerous examples of Open Source (and especially open-core) projects that sold out their communities or got proportionally more-and-more proprietary over time. And there’s also just some inherent conflicts with open-core in general, e.g. the Kanban feature being proprietary means people can’t contribute to that part of the software in the same way, it feels different and is less motivating to the community.

I really like where this discussion is going. I must agree with @wolftune and his reasoning.

1 Like

Perhaps the most prominent of open-core projects is GitLab, and I noticed that they take care to present themselves accurately.

At GitLab.com landing page, they never claim to be Open Source. At Why GitLab? | GitLab they write “It’s open and always improving. Because GitLab is built on open source software,”

That is accurate because they do build the whole product on their open core. It is also accurate to say “GitLab CE is Open Source”.

I think it matters to be transparent and not oversell something. Visitors who feel tricked and oversold may get frustrated in ways that won’t happen when they feel the presentation is honest and accurate (even if they would have preferred a 100% Open Source project).

All that said about the simple labeling, I do want to still emphasize my suggestions about ways to consider being more completely Open Source.

Incidentally, Discourse (this forum software) is an example of a functional working business with paid employees that is 100% uncompromised Open Source.

1 Like

Thanks for the feedback @wolftune! We will look into all references and suggestions you shared.

Definitely! As the first step, we plan to publish the page explaining the Baserow business model, so there are no confusion and misunderstanding.

1 Like