We hire the lead maintainer for PostgREST Steve [1] to primarily work on PostgREST since it’s a core part of the Supabase stack as you mentioned
I just think without some sort of pre-agreement for it, or way of avoiding it, whether intentional or not this way of 'supporting' a project also (or even instead) buys control of it, doesn't it?
(I've never used PostgREST, I'm not referring to anything that may or may not have actually happened, just musing.)
if you know a model that works where we could have clear boundaries, we'd be happy to explore! in the meantime, I hope you can look at the past few years of development to get an appreciation of whether we have maintained an arms-length relationship
some other non-obvious ones:
- most of the client libs are a result of supabase: https://postgrest.org/en/stable/ecosystem.html#client-side-l...
- we sponsor a contributor, managed by steve (I believe he mostly works on performance): https://opencollective.com/supabase-postgrest/expenses
steve joined supabase in June 2020 (before our seed round). iirc the project was earning something like ~$300/m in donations which he was splitting between the contributors. it's basically impossible for open source projects to sustain themselves (IMO) through donations
This has been working well until now and if you follow PostgREST's development, you'll notice that all enhancements are vendor-neutral and keep the original design.
We're a much smaller team but we took some inspiration from PostgreSQL distributed model (no single company owns development) for this.
[1]: PostgREST author https://github.com/begriffs
[2]: Also part of the PostgREST team and major contributor https://github.com/PostgREST/postgrest/graphs/contributors