Hacker News Reader

If you really care about open source software, as you seem to, you should know that attitudes and statements like this are just about the worst thing for it. Self-hosting isn’t the only benefit or purpose of OSS. It’s fair to point out that it isn’t easy to self-host, but consider doing it without being poisonous.

> Self-hosting isn’t the only benefit or purpose of OSS

I would say that making self-hosting difficult is completely against the spirit of OSS.

I certainly wouldn't expect an OSS technology to lock me in. At that point it just becomes a privative technology that builds upon open source and exposes its interfaces.

And I say this as someone who very regularly makes strong cases for the hosted solution in a make vs. buy scenarios, and would therefore probably argue to pay for Supabase hosting instead of complicating everyone's lives in my organization.

That's a fair criticism. We've looked closely at everyone's comments and it's obvious that we need to make self-hosting Supabase much easier. This has always been the intention and has always been possible: everything except our dashboard has OSI-compatible licenses, so anyone can run the same back end that we do.

But "technically possible" isn't good enough. It needs to be straightforward, and we're going to invest some effort into making it so. The only thing I'll say in our defence is that this didn't happen for business reasons, i.e. there's no secret plan to hobble the self-hosted version. Quite the opposite, we want the open-source tech to be super easy for everyone to run. We only want people to pay us because our paid product is valuable, not because the free tech is somehow hard to use. We only introduced billing yesterday, and we aren't charging anyone yet. But from the feedback, I understand why this wasn't obvious. It needs to be much clearer how to put the pieces together and we're going to prioritise this now.

I have started updating [0] our docs in this PR [1]. We will merge this tomorrow morning as part of our CLI release [2]. The Docker setup in this PR is 100% compatible with every project on Supabase, and we also link to several of the one-click tools which we have deployed into the AWS and Digital Ocean marketplaces. All this still needs improvement, this is just a first step. If anyone still has trouble setting up a self-hosted version of Supabase, please contact me (my email is in my profile) and I'll personally do whatever it takes to get you up and running. Then I'll update the docs some more so those difficulties won't happen again. Hopefully with a few more iterations this will be as smooth as it should be. The tech is there and 100% ready to go.

[0] Preview: https://docs-git-docs-self-hosting-supabase.vercel.app/docs/...

[1] PR: https://github.com/supabase/supabase/pull/999

[2] CLI release: https://supabase.io/blog/2021/03/25/launch-week#wednesday-cl...

I'm just an observer, but this response seems pretty top tier. I've seen your posts here for a while... I think the issue stems from a lack of clarity about what is free/open source, and what is proprietary. Ive read all your releases and am just now seeing that the dashboard is proprietary. Just to be clear, I'm not criticising the business model, but am just providing my 2 cents on a potential cause for "backlash" - namely, clarity in pricing.

Nakama is a similar open source + commercial hosting model. I think the model is strong and we will see it proliferate in the future. You simply can't beat the development power that a good open source ecosystem can bring.

this is what soured me on piwik (now matomo) as a self-hosted web analytics solution. they allow you to self-host, but make it difficult to automate updates, to steer you to their hosting service instead.

What is the difference between "make it difficult" and "don't include"? They gotta keep some features in their hosting service, don't they?

it’s been a couple years now, so i don’t remember the details, but i tried to workaround the limitations and came away with the conclusion that automating upgrades was intentionally crippled rather than simply neglected. there was no documentation on it, and it was explicitly touted as a feature of the hosted product.

the problem is one of messaging and positioning in line with the parent comment’s criticisms. instead of calling the non-hosted version a limited demo, the implied claim is that the non-hosted version is ‘production-ready’. but ‘upgrades’ were fresh reinstalls, complete with database integrity issues at stake. it was clearly a gotcha situation to steer you quickly to the hosted version (rather than being upfront about this significant limitation).

Is open source synonymous with self hosted?

I can think of some open source projects are prohibitively difficult to host yourself.

I can also think of closed source projects that are easy to self host.

In any case I feel that your fervor is unjustified.

Yes this is misplaced anger. I remember long time ago I tried compiling PhantomJs.exe (it's now defunct but it was a alternative to puppeteer). It was insanely hard to compile the latest release for Windows. I had to actually hire and pay someone to do it for me.

Yet I could not be more thankful to the creator of PhantomJs for the work he put into making it. The source code was all there but I wasn't able to do it. But the person I hired did eventually. I am only thankful to the people who make anything open-source and are kind enough to share the code with the world to see and learn.

Everything said above is true.

Supabase started Open Source , their GitHub repo had tutorials on how to host the platform yourself with a bit of documentation. Basically from what I understood they've been growing SO FAST ( they raise 10+$M IIRC ) they had to make a choice between "Growth" or "Integrity".

Obviously it's a YC company , the market they're going after is massive , they chose growth over integrity and doing things "that don't scale" but that have "traction".

I agree with the author , the founders should come clear about the marketing and the status of Self Hosting and Open Source... Supabase is no where near Open Source as it promised when it was published on HN few months ago... It's getting closer to a "MuleSoft/Serverless Inc" type of thing that lets you connect your own providers...

Don't get me wrong , I'm saying this because I'm an Enterprise Architect in one of the largest Bank in Europe , I desperately need an Open Source Firebase Clone to move 300+ Developers and Business Analyst into a Cloud First / Product Focus model away from legacy Cobol Enterprise App, Supabase seemed the ideal candidate.

Unfortunately it has been a huge deception.

Every component of Supabase is MIT, Apache 2, or Postgres licensed - apart from the dashboard

The code to self host it is in our main repo: https://github.com/supabase/supabase/tree/master/docker

I do think we could have better/cleared docs, which we can fix up tomorrow.

Re investment: we raised 6M, and we are under no pressure to trade our integrity for growth. We have open-source-friendly and patient investors (Mozilla, Coatue, YC), and a nice group of developers: https://supabase.io/blog/2021/03/25/angels-of-supabase

Is there a difference between Firebase's "open source" and Suprabase's "open source"? Is Suprabase more open than Firebase in some manner, or does "an open source Firebase alternative" just mean "a Firebase competitor that also open sources its client side tools?" Is some part of the Firebase code closed source or less "Open" where the Suprabase equivalent is not? I haven't used Firebase much, so maybe I'm missing a big distinction.

> Is some part of the Firebase code closed source or less "Open" where the Supabase equivalent is not?

All of the Firebase backend is proprietary, and their client code is open source.

The Supabase backend is here: https://github.com/supabase/supabase/tree/master/docker

This is the set up we use for every project on our hosted platform. These backend tools are either built by Supabase, supported by Supabase (we employ maintainers), or licensed with OSI-compliant licenses.

Our client libraries are all open source, Apache 2.0 licensed.

Supabase is open source in every definition of the word. I think the problem is our self-hosting docs, so we'll spend the day improving this.

Ah, gotcha. So Supabase has backend that is also open source which could theoretically be used for self hosting? Yes, that is a difference. It wasn't clear to me from the docs. Thanks!

Firebase is completely closed source and make it extremely hard to migrate any moderate size project.

Supabase builds on open source parts that everyone is already familiar with. Postgres for data store instead of firestore (which is a proprietary nosql Google cloud database with many quirks to keep you in). GoTrue for Auth which is an open source project by netlify. Real-time to provide Postgres changes over sockets open sourced by them. There are many parts which make up "supabase".

Supabase hosting provide a unified experience through their dashboard and manage all these parts for you. That isn't open source.

The actual UI kit for that is open source, though.

Dashboard doesn't stop you from migrating your backend infrastructure somewhere else. It does result in degraded developer experience which can be the biggest distinction.

They provide a Docker image, Dockerfile and a docker-compose to run the whole stack.

I'm assuming it should be relatively easy to point their client at your own instance and they should work.

What more do you want?

I think what more they want is the dashboard, which isn't open-source or self-hostable. Sort of fair ask, but also pretty fair for Supabase not to provide that IMO.

They also want better self-hosting docs, though IMO it's fair for that to be primarily driven by community forums.

https://hasura.io/blog/firebase2graphql-moving-from-firebase...

Why do you need a firebase clone? Can't you just use postgres the traditional way?

Supabase started because we open sourced a "change data capture" server on top of Postgres[0]. We then chatted developers to see if they wanted to use it. In our conversations, many of the developers were using Firebase because it was "just easier" to get started.

We really like Postgres, so we decided to make it as easy to get started as Firebase. We aren't modifying Postgres, or trying to turn it into something proprietary. We want migration to/from to a simple pgdump wherever possible. We provide some tooling around it to make it a better experience (for example, auto-generated APIs using PostgREST).

[0] https://github.com/supabase/realtime

On a side note: YC encourages naughtiness. This may, on rare occasions, leak into practices that some consider "unethical". And it must be noted, the term "unethical" can be interpreted in so many different ways.

PG said: "Startups often have to do slightly devious things". See https://techcrunch.com/2011/05/24/y-combinators-paul-graham-...

Reddit used an "army of fake accounts" with no open objection from YC. Is this unethical? Depends who you ask. I personally think it is slightly unethical. See https://news.ycombinator.com/item?id=4139876

I can see their reasoining. Everyone does it. If they didn't do these practices, it would be a competitive disadvantage

Finally, I do not agree with the rude tone of parent comment. There's a way of addressing people. I want to thank the Supabase team for their fantastic work + insights. I realize their need to stay competitive. Perhaps they should instead say they are "Open Core", which will remove most criticism.

YC does not go along with unethical practices. I'm not involved with that side of the business but they're serious about it and have disowned companies (by returning their investment and excluding them from the YC community) for being unethical.

I'm confused about what the issue in this case is. It sounds like some people are complaining that the product isn't open source because it's not self-hostable, while the founders are saying that it both is open-source and self-hostable? This sounds like a misunderstanding to me.

Even if it's not a misunderstanding, but rather a difference of opinion about how words should be used, that's not likely really an ethical issue. Rather, the definition of 'open source' is a classic flamewar topic that people regularly post zealous denunications about (including fiery charges of unethicalness and the usual "you should be ashamed" etc.). Of course this is not helpful—it just leads to flamewars, which are off topic on HN, and makes clear communication harder.

It does seem like "open core" is emerging as a term for startups that have open-sourceiness in some sense but not in every sense. That's one way to short-circuit flamewars and we've helped at least a couple YC startups launch themselves that way. But I don't know if it would be a solution in the present case because I don't understand what the issue really is.

(I'm not saying any of this because I think you personally need to hear it! I'm just posting it here out of caution, because if I jump into the argument directly, people will accuse me of putting a moderator thumb on the scale. We have to moderate HN less, not more, when a YC startup is involved: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...)

Simply put it hits a nerve because the community is inundated by companies saying one thing and doing another when if they had just been straight forward in the first place it would have been no big deal. These one-off dramatic events (like Google shutting down a minor service) and comments (like "it's Founders are highly unethical") are often small-fries or based on weak and ineffective arguments. But they are straws on the camels back and the camel is overburdened like a Valheim character carrying too many items.

I believe accusations of YC being unethical is a secondary affect of this zeitgeist as well. Whether it's the musings of PG or a portfolio company that goes off the reservations on extremely rare occasion, people connect the dots back through YC and see some culpability - even if YC's influence over poor decisions of founders is non-existent or contextually irrelevant. YC is in the supply chain and comments like "Startups often have to do slightly devious things" do not help.

Granted its unfair for Supabase or YC to be smeared by the general discontent of parts of the community. However it's also true that they are in positions of leadership and privilege (and candidly also often multi-millionaires) and should expect some flak as a result.

I think all Supabase's CEO or PR person should do now is post a short timeline outlining Supabase's public statements of being a self-hostable product (or lack thereof), clearly define the company's position at the time of any statement(s), clearly define what their position is going forward, and make a brief show of humility and apologize for not being as clear as they could be to their users. Granted this takes time, and its a singular internet comment evoking the response - but it would negate the negative sentiment and provide a basis for defending against similar statements in the future.

Anyways, I won't miss the opportunity to thank you for the support and moderation you do for the community, its been a valuable resource for me and I hope my personal perspective contributes to the general conversation.

Agree with what you said. I do not want to paint YC and PG as unethical, that would be wrong. I've reworded. Thanks for the write-up.

I am not sure what you mean by the watered-down docker-compose setup since it is the same one we use internally. Have you tried running the setup - https://github.com/supabase/supabase/tree/master/docker?

Is your complaint that the dashboard is not open source?

> We use open source to build our software (hey nothing special here : bazillion companies do that)

That's not true. Supabase improves and builds the open source ecosystem it uses.

In the case of PostgREST, we've added performance improvements that could very well be in a private fork(which other companies have done), but Supabase, in the good spirit of open source, decided to make these changes upstream.

The same goes for realtime, the team has been improving its performance to an enterprise-grade and making all these changes open source.

Even the storage API[1] presented here is OSS.

I believe all of these efforts are a net win for the open source community at large. Zealotry doesn't help anyone.

[1]: https://github.com/supabase/storage-api

I am a little confused by your description. I do not use Supabase but the source appears to be available on github and is actively updated. Are you claiming that because they do not provide clear documentation on how to self host they are not open source? Perhaps a good Samaritan could read through the repository and write some basic documentation which is enabled by virtue of being open source.

The problem is not with providing documentation.

They are not providing the missing source codes to put together a self hostable solution. Essentially they are not open source. Otherwise writing documentation is trivial by one of the community members.

What is missing aside from the dashboard?

Supabase is definitely open-source.

To the founders of supabase: don’t let people like this deter you. Their misplaced anger and self-righteousness says more about them than it says about you. If your software is good, we will use it. If it’s not, we won’t. There’s no need for poisonous behavior either way.

Supabase dashboard (which is the core of the actual product, the rest being open source tools) isn't open source or self hostable.

I think most F/OSS YC companies are adopting the GitLab model. Which is why may be they have put their UI code behind closed doors, because the "buyer-based open core" business model is, in part, based on it: https://www.heavybit.com/library/video/commercial-open-sourc...

The comment I'm replying to is a pretty hot take (maybe too hot), but IMO the real test will be when someone else tries to run a Supabase-aaS platform.

The unspoken implication of "self host" is "for yourself and no one else", but there's a bit of a difference between Supabase and the project it's using underneath -- I can absolutely run GoTrue or Postgrest aaS, but I assume that Supabase will change their minds on their license stance if someone does the same and undercuts their margins.

Why not just pick BSSL and be done with it like Sentry does -- no one gets mad at Sentry. Maybe it's the allure of getting people excited about your project and contributing to it?

Another weird thing is that projects picking AGPL (which is their right in every way) usually signals a similar intent, but AFAIK AGPL doesn't actually stop you from running an aaS, as long as you don't modify the source.

One more weird thing -- why doesn't anyone ever make a Firebase clone that is just... API-compatible with Firebase libraries? Being able to use the Firebase SDK itself but talk to a different set of cheaper servers is what everyone in this niche really wants right?

I have a proof of concept for that :) (the db is PostgreSQL of course)

Make the license BSSL (or AGPL, or whatever you want), and if you don’t already have it get out there and make your “fuck you” money, because that idea seems like almost a sure thing!

Having to so none of the marketing and just showing up on “firebase pricing” or “firebase cheaper” searches or whatever feels like a slam dunk, and since you’ve picked postgres you’ll probably have a nice well trodden path to reliability and perf

All of their code is available with OSI approved licenses. It’s factually open source.

You’re making huge mental leaps about their intentions. There’s no need for the vitriol by calling their team “highly unethical”.

Realtime seems to be the "magic" part of Supabase, and the code is there as well as a docker image.

The rest are other open source projects. Are you really expecting them to provide their full stack including user management and billing?

Can also attest to this. One of the companies I advise looked into them recently before realizing the “open source” is marketing folly. Quite disappointed in YC not doing their due diligence with them.

I'd be happy to chat to the this company to clear up any misconceptions. Is it because we have a hosted platform that they think we're not open source?

Our source code is available and permissively licensed in our github org: https://github.com/supabase, and we are very particular about picking MIT/Apache2/Postgres licensed tools for the stack.