can Vercel give any assurance that they won’t add a reliance on their closed-source cloud offering for the package? especially given their ownership of next-auth too
i really loved better-auth’s DX but the nature of their database adapters means it’s relatively easy to switch over to another provider/library
From what I remember, next-auth is kind of dead and Better Auth developers have been maintaining security of next-auth for some time now. (or was it Vercel that did the maintaining?)
Better Auth is the go-to solution for many people using Nextjs, so it makes sense that Vercel puts some effort in maintaining it.
I have never had issues running Nextjs in regular containers, it is just a good open source solution, I don't see why it would be any different with Better Auth.
how is this related to better auth ? In my understanding, keycloak and better auth are fundamentally different. I would compare keycloak more with Ory for example.
Keycloak and Better Auth aren't as fundamentally different as you may think! Better auth supports authn/z, being an identity _source_, being an identity provider, being an OIDC/SSO provider (so others can login using better auth), rbac, SAML/SCIM, and a ton more. It's actually really powerful! Most folks found better auth as an alternative to next-auth/auth.js - but better auth does a lot more than those.
It's a good reminder, because in the auth landscape I wish I had just picked up Keycloak and stuck with it. Commercial auth is a bad value proposition and not the kind of infrastructure where you want to have acquisition churn happening often.
The self-hosted space is another headache. I wasted so much time trying to make smaller self-hosted auth solutions work, since Keycloak has a reputation for being heavyweight.
I looked into the Ory stack extensively trying to actually use it as advertised for self-hosted / open-source auth. It's aggressively gimped and its SSO features are emphatically _not_ open-source and are gated behind licensing, with no way to find out until you're actually running it.
It's also just unfinished. Their "stack" is a lot of cobbled-together Go mixed with incompletely rebranded acquisitions like SAML Jackson (now "Polis"), which they managed to gut so completely it went from a best-in-class OSS library to unusable.
Probably the first time reading that the Ory stack is unfinished! Sorry you had a frustrating time, but there's 10 years of development and many happy customers + adopters who see it differently! Polis / Boxy still works as before, we didn't gut or take away anything.
Open source development needs to be paid by someone - most of the time people complaining about paying for software are working themselves (for money!) in some company making huge bucks, or looking up to "successful (as in money) tech leaders".
For Ory, B2B login is a good value differentiator, because it's required by companies selling to other companies meaning they can spend some money on licenses to further develop software.
Ory powers the largest technology providers, and super small solo projects. It's robust, stable, Apache2 licensed. It's the best CIAM tech out there that's free (!!).
In the end, everyone is entitled to their opinion but the "open source can't make money" train is honestly a bottom tier opinion and I'm tired of reading it on HN, probably written by people making $100K+ a year for writing software and using open source daily (without paying a dime).
It's like the people complaining that Wikipedia is collecting too many donations, while they cheer on Apple or Anthropic or whoever raking in billions of dollars.
Somehow, only if it's open source / non profit it's bad to make money. If it's proprietary nobody gives a damn. Says a lot about society.
>Open source development needs to be paid by someone - most of the time people complaining about paying for software are working themselves (for money!) in some company making huge bucks, or looking up to "successful (as in money) tech leaders".
There is software that is cutting edge and always changing, and those types of products need to be paid for much more than software that is stable.
With a stable product like Auth (which requires only security fixes and minor features), the 'pay per MAU' model employed across Auth companies is unreasonable
A combination of the people and companies using the product for free or selling its support (like RedHat and IBM for KeyCloak) along with an open license allowing it to be offered as a cloud service should be sufficient?
If you want to pay per monthly active user for the rest of your life, up to you.
Vercel have raised multiple rounds, last one was in 2025 and $300m. So we don't know what the VC's are going to demand for revenue targets. https://en.wikipedia.org/wiki/Vercel
Auth is not stable, it‘s constantly changing and evolving and also a lot of work to keep secure, and scalable. Auth is critical infrastructure and certainly not free. Most companies with homegrown at some point go to a vendor because it is so much work to DIY.
I can’t speak for Vercel‘s goals or pricing - but Ory is evidently still open source while many others went other routes!
i'm curious, outside of new models of authn (such as passwordless, totp, hash algos etc) and new models of authz (rbac, zero trust, etc), what else is "constantly changing"?
even the items i mentioned only change every 5 years or so, in my experience. i accept that there will be a lot of work preventing attackers from gaining unauthorized access, but again this feels partially solved by just rejigging the authn flow (rather than username -> password -> totp (leads to password sprays), just do username -> totp -> password)
If you're willing to take the pain of setting up an actual authz model, I've found OpenFGA^ to be really nice. We used it to set up some pretty complex authz involving cross-agent/user/org creation and sharing of data. It's not _simple_, but it is effective.
Thank you. This is very interesting. I'm excited to see an open source project adopt a zanzibar-oriented approach to resource management. This is exciting!
Just before I hurl myself at this for several days/weeks -- where were the pain points? I'm usually wary of new projects in this space but OpenFGA looks pretty mature already
The main pain points around using a Zanzibar-like approach (typically called Relationship-based access control) are:
(1) The need to write relationships and keep them updated in the permissions database. Often, this requires writing to both the application database and the permissions database, at the same time. On the SpiceDB side, we provide a Postgres FDW [1] to make this easy IF your application data lives in Postgres
(2) Representing complex permissions in ReBAC schema can be a challenge (at first) if you're coming from an ABAC system - you need a slightly different mental model for ReBAC, where (as its name implies), permissions are reachable via the relationships between objects, rather than attributes on objects.
(3) ACL-aware searching: this is a very hard problem in authz in general and gets slightly harder with ReBAC.
The separation of the search index and the permissions database makes it harder to integrate and computing permissions, at scale, is incredibly complex. For SpiceDB, we have Materialize to help solve this problem [2].
I really want to love KeyCloak. I've had really bad experiences with weird uptime bugs and crash loops that kept me from giving it an honest retry over the last couple years.
It also really shows its age, imo. The interface is clunky, roles and groups having overlapping responsibilities is confusing, making custom UIs for it makes me feel ancient, etc.
I really can't complain though. There is simply no alternative that's as open atm. It's also not easy to make one ( I tried :( ).
Showing its age is also a pretty significant plus, for such a critical part of one's infrastructure. That means it's been beat up on and run through the ringer for a decade plus at this point and had lots of chances to fix CVEs and other bugs. Not to say there won't be more, but being older and time-proven for an IdP is a major positive.
Keycloak is awesome, but whenever I used it the documentation gave me too little guidance. On how to use it in the right way, without having to customize it too much.
Rolling auth by yourself is very messy. Storing tokens correctly, rotating and using correct tokens, with correct parameters and so on. Endless footguns.
Oh man, it really depends(tm). If you are building a small internal app, sure, but you'd often still be better off leveraging a social provider or employee directory.
I work in the auth space (for FusionAuth) and we run into plenty of folks that started out rolling auth themselves. Just username and password right? A bit of hashing, salting and leveraging a built-in crypto library.
But then you need to add account recovery. And then MFA. And then registration. And then progressive registration. And then webhook integration. And then passkeys. And then SAML integration. And the delegated SAML setup. And then and then and then.
You're distracted from your core application by feature requests for your login system.
You have lots of options nowadays. Use a library provided by your framework (Rails, Spring, and Django have them), use a tool like Better Auth, use a third party system like FusionAuth or Auth0. But don't build undifferentiated functionality that impacts your user experience.
PS Of course, where I stand depends on where I sit, but I firmly believe that you should not build an auth system the same way you should not build a database.
This is kinda like the ORM vs no-ORM argument. I think that off-the-shelf auth will accelerate your development for sure (like an ORM) but eventually, you are going to feel constrained by the framework/tool you are using. You will need to work around it. You will find that using it 'correctly' results in poor performance, and so you deviate here and there. Pretty soon you tell yourself, "man I should have just used SQL" or "man, I should have just rolled my own auth". At least ~20 years of software dev has taught me this.
For an MVP or a prototype, I think it's okay to use an off-the-shelf tool. For something serious that will have long-term legs, I would do it myself. I hear all of your concerns and arguments and agree there are a lot of footguns. But again, having spent the better part of my adult life using and interfacing with these tools, I have an innate understanding of how to model auth correctly (separate it from the user, separate users from an 'org' or 'team' entity, etc).
You said it though, 'it depends' is really the right answer here.
That's a great analogy. My only addition would be the nuance of that data modelling is way more flexible than authentication (and this is said as someone who is continually surprised by the business requirements, standards, and complexities of auth). Data modelling, after all, needs to handle the entirety of reality (at least what can be mapped to a computer). So you're more likely to outgrow it.
I've heard plenty of stories of folks moving from homegrown auth to a off-the-shelf solution, but that's because I'm in the off-the-shelf auth space.
It'd be super interesting to hear stories of folks who went the other way, and outgrew their service provider's auth.
You are building your app with a single user in mind. They can create <thing> (blog posts, photo albums, code repositories, you name it). Eventually you realize, sometimes people are working in teams or groups. Multiple people need to have access to <thing>. So instead of architecting from the get-go that a <thing> is owned by a user (usually with some kind of FK, like an owner_id, or user_id) you want to start by having an abstraction there right out the gate. Things are owned by a team or org, and a user belongs to an org.
This is why a lot of SaaS you use these days will come with a "default project" or "default team" that might just be 1:1 with your own person. But injecting that abstraction layer makes it super easy down to the road to allow other individuals to join or participate in the management of those entities.
I work at Clerk - same opinion here. Rolling your own auth is a trap. It's super easy when you are just getting started with your product and I cannot count how many times I have seen developers boast about how they rolled their own auth and now they aren't "locked in" to a vendor and are saving tons of money etc.
But the truth is, if you scale up as a company, it will end up costing you more in engineering salaries to re-create and maintain all the auth features you will need to support like @mooreds mentioned above than just using an auth library/vendor in the first place. And if you don't scale up, you are unlikely to push outside of the cheap or free tiers of any auth vendor you do go with, so it's a wash. Every reputable auth vendor has a pretty generous free tier.
It feels scary to go this direction because what happens if you blow up and then it becomes ultra expensive and now you're "locked in". All the time I see developers put hundreds of thousands, or millions of MAU into an auth vendor's pricing calc then gawk over the projected monthly bill and decide to roll their own. But the reality is that this doesn't happen. By the time you have that many MAU, you're typically paying out many multiples of that in engineer salaries alone, and paying an auth vendor a fraction of a single engineer's salary to handle your auth is substantially better value than hiring a team to build and maintain your own from scratch.
We have churned our fair share of large company customers over the years, as has every other auth vendor. They have all been because they needed feature we didn't have, not because the price was too high.
Unfortunately its a common misconception, it feels easy, however auth is a lot more harder to do it right, specially when it comes to recovery. A simple example, protocol like TOTP (time based OTP) uses the concept of shared secret and almost every implementation stores the secret as it is in their databases
I never suggested not to do, this was not the intention. I was just sharing the fact that its not easy. Also doing auth can have different level of depths too so its highly subjective on goals.
I think it is pretty obvious why they often get conflated. There is substantial overlap between the two. "Who you are" and "what can you access" are tightly related. Of course they do not need to be, but it's not a surprise that in the majority of situations they are.
Uggggg I just implemented Better Auth for our new product - time to start looking for backup plans. I used to be a huge Vercel fanboy but everything they have done in the last few years turns into a complicated mess.
This is amazing although I would really like for them to explore filling the backend gaps. An acquisition of Trigger.dev or Inngest would be the obvious move and nobody would be surprised. Thoughts?
I used Better Auth for my mobile app backend. It works okayish. My biggest complaints are the OpenAPI specification gets little care, as it mainly caters for JS frontend, and breaking changes in patch version are more common than most packages.
why not instead fork repo just in case but still use better auth until proven wrong? In case they go evil you just build from you forked one. At that point you would still have to either maintain your own auth or better auth fork.
With current AI your agents probably still will be better with maintaining a fork. Auth libs have pretty limited API surfaces comparing to e.g. ui frameworks.
I prefer to maintain my code, tailored for my need, than maintaining a massive library that has support for every authentication method there is, while trying to be as generic as possible and fit every business.
Using something third party isn’t free - even for zero monetary cost there’s integration cost, documentation, support, and maintenance uncertainty.
The choice between rolling your own and third party is already a trade-off. The future uncertainty around third party services without a clear business just tips the scales, it’s not the whole justification.
the team at Vercel has been my biggest inspiration and always reflected many of the reasons we started working on Better Auth. This would allow us to focus more on what made better-auth great in the first place It hasn't even been 2 years since we started but thank you everyone from the open-source community for helping us make an impact in short amount of time. There is a lot to do to improve on open source auth and im really excited to be back focusing full time on building
Yeah, Vercel has already done this before like with Nuxt, Svelte and other. But I also do want to have a better story for auth with all those frameworks and Nextjs as well.
what will be your role at Vercel? Aren't you afraid that you might lose control over the project's future - becoming a cog in a much more complex system?
Congrats BetterAuth! It was the system I was considering before I rolled my own auth system around the passwordless concepts of: OTP + Passkeys + Google login. It is quite nice and simple and I've ported it to 3 separate projects now just via LLM:
On one hand I love how much easier the email + OTP / passkey flow is on the dev side, I find it _very_ frustrating as a user of services. User+password combos are straightforward at least.
Passwords are definitely not better than passkeys for login flow as a user, at least not on MacOS / iPhone, etc. I just tap my finger onto the fingerprint reader on my MacBook or I just look at the camera on my iPhone - biometrics for the win.
But you need something as a backup to passkeys so I choose emailed OTP, but it isn't meant to be the primary way to log in.
It's one of those things you shouldn't trust LLMs to such an extent; that part should be very solid because the consequences of bad practices are getting to front page of hacker news :)
depends what LLM you are using but most frontier models have seen almost every github/doc/best practices its very hard to get something like supabase/lovable type of mess unless you purposely prompt it to be bad without much inner knowledge but even then it is rectifiable with the right prompts
Everything is "rectifiable with the right prompts" if you handwave the hallucinations it makes (which yes, even frontier models do. Or I guess all companies that had major outages within the past months were using fossil models).
And it's funny this same argument can be said since Sonnet 3.7. But the issues still pop up.
So, it's just a matter of time until they destroy this project in favour of their cloud interests. Such a shame, it is (was) a nice open source project.
> Vercel is not a problem. Pumping millions of dollars into the JS ecosystem through sponsorships and events to define the development landscape in terms of what helps your bottom line... that's bad.
> What Rauch is doing is the developer equivalent of private equity squeezing, and what's insane is how well it's working.
Open source isn't really open any more. It's just pre-acquisition. I'm happy to the creators for their payday but honestly just happy I opted out of BetterAuth building my latest product.
Is it about the license? I see less and less new projects using GPL, and a lot of MIT(ish) licenses.
Most complex open source projects like Linux for example have a lot of contributions by corporations. The GPL kind of forces them to participate in open source, instead of just creating internal forks.
GPL and even LGPL are tricky for libraries though.
I think it's more about the bait and switch marketing optics of offering a "core" part of your codebase as "FOSS" to get the extra brownie points by doing so, while it's at the same time littered with caveat emptors, and imports from "enterprise licensed" code for the features that business care about.
Also all the "commercial open source" or COSS seems to lean into that, its a valid strategy to monetize open source, but should be done transparently and being very upfront about its bait-y nature to businesses or enterprises imho
I don't see companies using open source lining up to support the developers. Good for developers to come up with some monetization strategies to keep their software alive.
so does anything change or will change for better-auth FOSS consumers? Or not really and that mostly depends on what Vercel imposes as new direction going forward? I guess vercel is a good home for foss projects, at worst they'll make first class adoption on their ecosystem without actively hampering others etc
It's not that easy to get back a scammed funds because these scammers are very smart and they will cover their traces but if you manage to find a trustworthy and reliable Recovery company because many scammers are out there disguising as Recovery agents and will only take your money without recovering your funds, I was a victim of such myself after loosing all my funds to cryptocurrency scam. I sort for a help and I met few recovery agents, I was scammed by a particular one again Luckily for me I was referred to these legitimate company and they where able to recover my money back to me. You can as well contact them on RECOVERYDAREK AT gmail DOT com for a help.
How is BetterAuth in terms of vendor lockin? For a hobby project, I once tried a provider which stored all data within itself and required API calls for every user request. Then I tried Hanko which just authenticates and can be replaced relatively easily (very easily if no passwords IIRC).
mrcwinn | a day ago
ftchd | a day ago
electriclove | a day ago
bstsb | a day ago
i really loved better-auth’s DX but the nature of their database adapters means it’s relatively easy to switch over to another provider/library
Jnr | a day ago
Better Auth is the go-to solution for many people using Nextjs, so it makes sense that Vercel puts some effort in maintaining it.
I have never had issues running Nextjs in regular containers, it is just a good open source solution, I don't see why it would be any different with Better Auth.
Raed667 | a day ago
khurs | a day ago
https://www.keycloak.org
https://www.cncf.io/blog/2023/04/11/keycloak-joins-cncf-as-a...
nvegater | a day ago
vaishnavsm | a day ago
(some of those features are enterprise only)
Natfan | 23 hours ago
jzebedee | a day ago
The self-hosted space is another headache. I wasted so much time trying to make smaller self-hosted auth solutions work, since Keycloak has a reputation for being heavyweight.
I looked into the Ory stack extensively trying to actually use it as advertised for self-hosted / open-source auth. It's aggressively gimped and its SSO features are emphatically _not_ open-source and are gated behind licensing, with no way to find out until you're actually running it.
It's also just unfinished. Their "stack" is a lot of cobbled-together Go mixed with incompletely rebranded acquisitions like SAML Jackson (now "Polis"), which they managed to gut so completely it went from a best-in-class OSS library to unusable.
aeneas_ory | a day ago
Open source development needs to be paid by someone - most of the time people complaining about paying for software are working themselves (for money!) in some company making huge bucks, or looking up to "successful (as in money) tech leaders".
For Ory, B2B login is a good value differentiator, because it's required by companies selling to other companies meaning they can spend some money on licenses to further develop software.
Ory powers the largest technology providers, and super small solo projects. It's robust, stable, Apache2 licensed. It's the best CIAM tech out there that's free (!!).
In the end, everyone is entitled to their opinion but the "open source can't make money" train is honestly a bottom tier opinion and I'm tired of reading it on HN, probably written by people making $100K+ a year for writing software and using open source daily (without paying a dime).
It's like the people complaining that Wikipedia is collecting too many donations, while they cheer on Apple or Anthropic or whoever raking in billions of dollars.
Somehow, only if it's open source / non profit it's bad to make money. If it's proprietary nobody gives a damn. Says a lot about society.
khurs | a day ago
There is software that is cutting edge and always changing, and those types of products need to be paid for much more than software that is stable.
With a stable product like Auth (which requires only security fixes and minor features), the 'pay per MAU' model employed across Auth companies is unreasonable
A combination of the people and companies using the product for free or selling its support (like RedHat and IBM for KeyCloak) along with an open license allowing it to be offered as a cloud service should be sufficient?
If you want to pay per monthly active user for the rest of your life, up to you.
Vercel have raised multiple rounds, last one was in 2025 and $300m. So we don't know what the VC's are going to demand for revenue targets. https://en.wikipedia.org/wiki/Vercel
aeneas_ory | a day ago
I can’t speak for Vercel‘s goals or pricing - but Ory is evidently still open source while many others went other routes!
Natfan | 23 hours ago
even the items i mentioned only change every 5 years or so, in my experience. i accept that there will be a lot of work preventing attackers from gaining unauthorized access, but again this feels partially solved by just rejigging the authn flow (rather than username -> password -> totp (leads to password sprays), just do username -> totp -> password)
kommunicate | a day ago
vaishnavsm | a day ago
It's Apache 2.0 and a CNCF incubating project.
[^] https://openfga.dev/
kommunicate | 23 hours ago
Just before I hurl myself at this for several days/weeks -- where were the pain points? I'm usually wary of new projects in this space but OpenFGA looks pretty mature already
jschorr | 23 hours ago
(1) The need to write relationships and keep them updated in the permissions database. Often, this requires writing to both the application database and the permissions database, at the same time. On the SpiceDB side, we provide a Postgres FDW [1] to make this easy IF your application data lives in Postgres
(2) Representing complex permissions in ReBAC schema can be a challenge (at first) if you're coming from an ABAC system - you need a slightly different mental model for ReBAC, where (as its name implies), permissions are reachable via the relationships between objects, rather than attributes on objects.
(3) ACL-aware searching: this is a very hard problem in authz in general and gets slightly harder with ReBAC. The separation of the search index and the permissions database makes it harder to integrate and computing permissions, at scale, is incredibly complex. For SpiceDB, we have Materialize to help solve this problem [2].
[1] https://github.com/authzed/spicedb/tree/e9d636d2b58dd9e92c44...
[2] https://authzed.com/docs/authzed/concepts/authzed-materializ...
Disclaimer: I'm CTO and cofounder of AuthZed and we build SpiceDB (https://spicedb.io), the most scalable OSS implementation of Zanzibar
vaishnavsm | a day ago
It also really shows its age, imo. The interface is clunky, roles and groups having overlapping responsibilities is confusing, making custom UIs for it makes me feel ancient, etc.
I really can't complain though. There is simply no alternative that's as open atm. It's also not easy to make one ( I tried :( ).
andrewstuart2 | a day ago
andix | 23 hours ago
slig | a day ago
mooreds | a day ago
Anything that makes it easier for developers to build secure applications is a win!
huflungdung | a day ago
whalesalad | a day ago
nicce | a day ago
lackoftactics | a day ago
mooreds | a day ago
I work in the auth space (for FusionAuth) and we run into plenty of folks that started out rolling auth themselves. Just username and password right? A bit of hashing, salting and leveraging a built-in crypto library.
But then you need to add account recovery. And then MFA. And then registration. And then progressive registration. And then webhook integration. And then passkeys. And then SAML integration. And the delegated SAML setup. And then and then and then.
You're distracted from your core application by feature requests for your login system.
You have lots of options nowadays. Use a library provided by your framework (Rails, Spring, and Django have them), use a tool like Better Auth, use a third party system like FusionAuth or Auth0. But don't build undifferentiated functionality that impacts your user experience.
PS Of course, where I stand depends on where I sit, but I firmly believe that you should not build an auth system the same way you should not build a database.
whalesalad | a day ago
For an MVP or a prototype, I think it's okay to use an off-the-shelf tool. For something serious that will have long-term legs, I would do it myself. I hear all of your concerns and arguments and agree there are a lot of footguns. But again, having spent the better part of my adult life using and interfacing with these tools, I have an innate understanding of how to model auth correctly (separate it from the user, separate users from an 'org' or 'team' entity, etc).
You said it though, 'it depends' is really the right answer here.
mooreds | a day ago
I've heard plenty of stories of folks moving from homegrown auth to a off-the-shelf solution, but that's because I'm in the off-the-shelf auth space.
It'd be super interesting to hear stories of folks who went the other way, and outgrew their service provider's auth.
sbkis | a day ago
whalesalad | a day ago
This is why a lot of SaaS you use these days will come with a "default project" or "default team" that might just be 1:1 with your own person. But injecting that abstraction layer makes it super easy down to the road to allow other individuals to join or participate in the management of those entities.
jenius | 22 hours ago
But the truth is, if you scale up as a company, it will end up costing you more in engineering salaries to re-create and maintain all the auth features you will need to support like @mooreds mentioned above than just using an auth library/vendor in the first place. And if you don't scale up, you are unlikely to push outside of the cheap or free tiers of any auth vendor you do go with, so it's a wash. Every reputable auth vendor has a pretty generous free tier.
It feels scary to go this direction because what happens if you blow up and then it becomes ultra expensive and now you're "locked in". All the time I see developers put hundreds of thousands, or millions of MAU into an auth vendor's pricing calc then gawk over the projected monthly bill and decide to roll their own. But the reality is that this doesn't happen. By the time you have that many MAU, you're typically paying out many multiples of that in engineer salaries alone, and paying an auth vendor a fraction of a single engineer's salary to handle your auth is substantially better value than hiring a team to build and maintain your own from scratch.
We have churned our fair share of large company customers over the years, as has every other auth vendor. They have all been because they needed feature we didn't have, not because the price was too high.
sandeepkd | a day ago
whalesalad | a day ago
sandeepkd | 23 hours ago
djfobbz | a day ago
esafak | a day ago
whalesalad | a day ago
agrippanux | a day ago
__s | a day ago
ebeirne | a day ago
magnio | a day ago
fnoef | a day ago
Glad I decided to roll my own auth rather then using some library. I had a feeling that eventually they will join Vercel.
notatoad | a day ago
but to me that’s less risk than our auth getting bought by somebody whose business goals don’t necessarily align with mine.
pzo | a day ago
With current AI your agents probably still will be better with maintaining a fork. Auth libs have pretty limited API surfaces comparing to e.g. ui frameworks.
fnoef | a day ago
slig | a day ago
notatoad | 20 hours ago
The choice between rolling your own and third party is already a trade-off. The future uncertainty around third party services without a clear business just tips the scales, it’s not the whole justification.
bekacru | a day ago
the team at Vercel has been my biggest inspiration and always reflected many of the reasons we started working on Better Auth. This would allow us to focus more on what made better-auth great in the first place It hasn't even been 2 years since we started but thank you everyone from the open-source community for helping us make an impact in short amount of time. There is a lot to do to improve on open source auth and im really excited to be back focusing full time on building
oooyay | a day ago
mavelikara | a day ago
bekacru | a day ago
orliesaurus | a day ago
bhouston | a day ago
Talk: https://ben3d.ca/blog/passwordless-login-system
Live Demo: https://passwordless.ben3d.ca
Demo Code: https://github.com/bhouston/passwordless
If you are building a user system with a database already, adding passwordless auth is easy.
quibono | a day ago
giancarlostoro | a day ago
bhouston | a day ago
But you need something as a backup to passkeys so I choose emailed OTP, but it isn't meant to be the primary way to log in.
zuzululu | a day ago
lackoftactics | a day ago
zuzululu | a day ago
RideOnTime22 | 23 hours ago
And it's funny this same argument can be said since Sonnet 3.7. But the issues still pop up.
zuzululu | 15 hours ago
slig | a day ago
RichardChu | a day ago
mariopt | a day ago
jgeurts | a day ago
Jnr | 21 hours ago
BoorishBears | 21 hours ago
https://news.ycombinator.com/item?id=45393382
https://news.ycombinator.com/item?id=45398577
I've said before:
> Vercel is not a problem. Pumping millions of dollars into the JS ecosystem through sponsorships and events to define the development landscape in terms of what helps your bottom line... that's bad.
> What Rauch is doing is the developer equivalent of private equity squeezing, and what's insane is how well it's working.
mrcwinn | a day ago
ndom91 | a day ago
Best of luck over there!
nightski | a day ago
andix | 23 hours ago
Most complex open source projects like Linux for example have a lot of contributions by corporations. The GPL kind of forces them to participate in open source, instead of just creating internal forks.
GPL and even LGPL are tricky for libraries though.
tough | 22 hours ago
Also all the "commercial open source" or COSS seems to lean into that, its a valid strategy to monetize open source, but should be done transparently and being very upfront about its bait-y nature to businesses or enterprises imho
Jnr | 21 hours ago
I don't see companies using open source lining up to support the developers. Good for developers to come up with some monetization strategies to keep their software alive.
hankyone | 23 hours ago
tough | 22 hours ago
byyll | 20 hours ago
yesidoagree | 18 hours ago
Suzie121 | 13 hours ago
customentity | 5 hours ago
aitchnyu | 4 hours ago
FlxMgdnz | 3 hours ago