There are actual benefits to a product like Supabase being opensource, some are: 1- Peace of mind. You might not choose to host it now, but you have one more way out, if you don't like their service (of course they also should provide access to your raw data) 2- Quality of code. If you have ever dealt with really bad code that works apparently well, you know how important it is to have code that you can proudly release to public. 3- Possibility of contribution. This is something I dismissed until it happened to me, in multiple occasions: you have a problem (missing feature, bug, performance problem, etc), you request it, or even contribute it. For most closed source projects, you're lucky if there is a transparent channel to request features.

One advantage of using open source products, even if you only use the commercial version, is that they place a limit on how “evil” the company can become: at some threshold, people might decide to put in the effort to fork it (like MariaDB).

My company has had people straight up tell us that they are comfortable using our managed service for that reason.

> some subtle missing documentation or some subtle bugs or some subtle missing important features

Unless you're implying that Supabase are for some reason deliberately releasing separate defective software to the open source community... to... convince users that using their commercial services is a good reliable option??? I can't really figure out how or why any business would go to the effort of doing this. It seems patently easier to be a legit open source company.

Assuming you're not implying the above & I've just misinterpreted... everything else in your comment paints Supabase in an eminently positive light.

They might not release a separate version for OSS, but I've seen this pattern in some "OSS" companies. They allow the OSS version to lag behind in terms on bug fixes and security updates. Some things are hard to achieve without paid support. These days it's not unbelievable that they are doing it on purpose. After all, we've seen some vocal OSS companies go proprietary after gaining some traction. The lesson is that you absolutely cannot trust corporations to uphold OSS ethos once they get a reasonable amount of traction.

> The lesson is that you absolutely cannot trust corporations to uphold OSS ethos

I'm absolutely with you here but I think this is a matter of least worst situations: I still think an OSS corporation trumps a non-OSS corporation regardless.

> These days it's not unbelievable that they are doing it on purpose.

I think there's a bit of a leap between a company - at a management level - deciding to "go open-source" for mainly marketing/branding/image reasons & that same company actively endeavoring to make their open-source product deliberately worse.

It's still likely (& common) that profit incentive will lead to paid plans receiving more investment & QA than open-source offerings. But again, this is a least worst outcome imo. A semi-abandoned corporate OSS project isn't very different from a semi-abandoned personal individual OSS project - maybe even better as there will typically be less social reluctance to build a community fork.

Thought experiment: You sell a hosted solution and also release your software as open source.

Daily, you are bombarded with decisions for how to allocate resources. In each of those, do you lean towards the option that makes it easier to self host rather than spending those resources on other things?

This is exactly my point.

There are systemic reasons for these systems to be underresourced - there's absolutely no need for theories about deliberately crippling OSS offerings.

I'm with you on this one. «Proper» open source software are installable with distributions package manager with workable defaults, albeit opinionated but crafted with minimum care for a targeted usage.

Maybe it's not viable for commercial purpose, but status quo hurt open source software hard by a strong erosion of what to expect of it, without clear long term benefits for companies choosing such a scheme.

I disagree: just because something is open source doesn’t not imply the authors have any duty to also provide packaging and distribution as well.

Distribution is an orthogonal concern. The fact that many existing things are nicely distributed is a pleasant bonus, not a necessary condition.

> open source doesn’t not imply the authors have any duty to also provide packaging and distribution as well

If the authors are using open source as a selling point and marketing relay for broad audiences, I think there is a moral obligation to.

For projects with little awareness, niche, or "just a hobby, won't be big and professional", yes sure, I would never think to have any opinion, nor bothering them.

Officially, it's open source as long as "the code is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose".

Open source isn't just about self hosting.

It also allows developers to look at the code that's actually running, even if they don't run it themselves.

It allows you to look at some code, if that's the one that's running or not is a different story.

To me looking at the code doesn't do much if I can't patch it

Considering the state of the average docs, I usually prefer code.

Right, but even if I have the source code but can't patch the version that I'm running, that's not very useful to me.

I think you are missing the point.

The open source part, especially it being Postgres, makes it possible for me to move away if I choose to do so, while picking and choosing the parts I want to keep. This ability was crucial for me, I would not have used Supabase otherwise.

If you look at Firebase for example, there are countless stories of how difficult it is to move away.

Even if I won't self host Supabase, I can just take my schema, take my data, and put it elsewhere fairly easily as all the postgres extensions and everything is open source. I have the ability to move away from Supabase completely, and people have done this successfully before (see https://news.ycombinator.com/item?id=36004925).

Some people do actually self host btw, and supabase is adding more options like hosting on Fly.io.

Besides this there are other advantages:

- I run Supabase locally for testing (using their docker images and CLI)

- We run Supabase in GH actions for automated testing and migrations

- I connect directly to the db, and use postgres tools for various things, backups, snapshots, db admin tasks.

- There are community clients for many different languages

Sure, it's also marketing, as these are all great benefits that really had a big impact on my decision to build on Supabase. Open source is more than just self hosting.

I know people who are running Supbase in production for Enterprise customers so that claim is just false.

So let's entertain that this is in fact the case: it makes no sense in practice to self host for production. Even if that is the case, you're still better off building on top of an Open Source product because you're in a much stronger position in being able to fork than hoping that the company you rely on will stay around and not charge you to death.

A lot of products we all use underwent complex business changes, but the Open Source ones still are here for us to use. MySQL had a tumultuous past and yet there is a very active version of it hanging around under a new business.

The marketing angle is for the company to leverage, but the open source nature of it is for the user.

I used one of their open source work in a project: https://github.com/supabase/wrappers

It’s appreciated since SaaS on AWS wasn’t a possibility.

I think this is the case with most open-source projects that have both a cloud and self-hosted opening, they provide a much better experience for their hosted solution and don't spend a lot of effort into making their self-hosted version as usable as it could be.

I don't agree this is just a marketing scheme but in any case it's still a much better situation for consumers than companies with closed-source products.

good points.

Realistically, it feels like the actual utility of an open-source project is based on:

1. it being educational: so everyone can look into its source & learn from its design pattern, etc, or build upon or borrow parts (eg to be modified) and to be used in their own projects - but the practicality of it will really depend on how decoupled and well-designed the system is

2. in favour of competition (so more possible start-ups / big corps can clone their systems/services) and as consumers we will obviously benefit from that

3. llm can access & train on its source code

I think point 3 is most interesting. And I’m also super curious how true point 2 is and to what extend

Point 1 is really cool too - esp when it is done wonderfully (Linux, React for example) but it really depends on so many levels

What do LLM’s have to do with code licences, and since when has the utility of code depended upon an LLM instead of, you know, its own utility?

What he is saying is that LLM’s released into the wild to train can anonymously steal from his code to improve their own utility outside of licensing boundaries.

I heard good things about self-hosting it through elest.io.

You clearly don’t get the difference between business models and raising interest. It’s interesting that a service I would use has open code because, you know, transparency is important. That lazy or incompetent users can’t get complicated software running doesn’t mean a scheme is in place, either.