Your app will be held back by requiring to create an account with email and password.
Most of the users just use "Login with Google" or other well known OAuth providers and also want to try the product before creating an account.
When I switched from user / password to OAuth I couldn't believe how many users choose it. I could deactivate traditional user & password login and nobody would notice it.
That's fascinating! I mostly don't use "sign in with X" anymore since my password manager flow is pretty fluid at this point (so making a password is easy and secure). I guess for the many people who are less comfortable with password managers, a 1-click sign up/in is very useful.
I'll add my 2c, and say that even with a really fluid password manager flow, "signin with X" is usually a 1-click entry (possibly 2 for scope authorization), rather than a signup form + leaving the site to click through an email verification.
I'd much prefer 1password to do it's "you last signed in with github here" popup, than just have easy new passwords created.
Having a password manager plug-in thing installed on every web browser that I might use seems pretty arduous to me (not to mention I also then have to trust the plug-in). The fact that LastPass for example had a major breach doesn't help either.
To each their own I guess… I find it insanely easy to install the bitwarden plugin. All the plugins sync through my Mozilla account anyway. Definitely do not use Lastpass.
So it seems to be based on their own experience. The parent comment says this:
"When I switched from user / password to OAuth I couldn't believe how many users choose it. I could deactivate traditional user & password login and nobody would notice it."
If profit would be reinvested it would be zero and not negative - there is no profit to be reinvested - they need fresh investor blood from time to time ;-)
I can't really agree with the testing part. I worked with many projects where I came across Issues which definitely could have been prevented by more automatic unit / E2E tests.
I imagine the engineers who wrote the code for the Boeing 737 MAX MCAS or the Tesla engineers who accidentally wrote log files to the internal flash thought the same. Maybe another team member could show the author why these tests are important...
TBF, he does write "I do see the importance in many of the things I just listed [one of them being testing], but they sure do take the fun out of the act". And I, for one, agree with that. Testing is important, but in practice it's often just another dumb metric (e.g. achieving x % code coverage), which however doesn't say anything about whether the tests are actually helpful or just call the code so it's "covered"...
The problem here (in my mind) is that hindsight is 20/20, so you can always look at a bug and say that a test could've prevented it. But in the author's case, it sounds like they still have bugs despite all the tests, so I guess the people writing the tests just aren't very skilled? And if that's the case, couldn't a more skilled engineer just write better code to begin with?
I totally get tests as a way to prevent known incidents from happening again. But tests as a way of preventing unknown issues seems dubious to me.
> But tests as a way of preventing unknown issues seems dubious to me.
True. At my previous job, I used a new C compiler [1] that revealed a bug due to undefined behavior [2]. It was a two-line fix, but my manager at the time refused to accept the fix unless I 1) made a test that showed the error, and 2) write tests to show other instances of this type of bug. The test would have been useless since I used an unsanctioned C compiler, and (due to the nature of the bug) I'm not sure if static analysis would have found the bug anyway.
[1] Test driving the latest Ubuntu Linux installation for development.
[2] The code worked as expected on the business-supported C compilers (it's undefined behavior, anything can happen). Even valgrind didn't catch the error (we were using that at the time) because of the way the code was generated.
The frog on a dissection table approach to software development seems like it is probably a primary cause of incidents involving lost surgical tools in production.
In traditional development you didn't have one organ in a harness, then 3 organs in a harness, etc, having modified them to have no thickness that could hide something from a unit test. That's as different from the functioning frog as the dissected one.
There are endless permutations that are possible in this modern ideal that are all correct for some or all testing purposes, during all test runs, and in every system the average project participant will ever see up close.
They are wrong in production, vastly outnumber correct production configurations, and confuse any discussions about the attempt to port things to production as they are more canonical to the group than production itself.
That's not to say there aren't ways to do this style of multiple test types correctly, only that I think it was done with more care at each level instead of less as layered redundancy needs particular properties or you get holes that all line up, configuration for tests that make it to production, etc.
The Issue with these two explanations from the board is that this is normally nothing which would result into firing the CEO.
In my eyes these two explanations are simple errors which can occur to everybody and in a normal situation you would talk about these Issues and you could resolve them in 5min without firing anybody.
I agree with you. But that leads me to believe that they did not, in fact, have a good reason to fire their CEO. I'll change my mind about that if or when they provide better reasons.
Look at all the speculation on here. There are dozens of different theories about why they did what they did running so rampant people are starting to accept each of them as fact, when in fact probably all of them are going to turn out to be wrong.
People need to take a step back and look at the available evidence. This report is the clearest indication we have gotten of their reasons, and they come from a reliable source. Why are we not taking them at their word?
Ignoring the lack of credibility in the given explanations, people are, perhaps, also wary that taking boards/execs at their word hasn't always worked out so well in the past.
Until an explanation that at least passes the sniff test for truthiness comes out, people will keep speculating.
Right, except most people here are proposing BETTER reasons for why they fired him. Which ignores that if any of these better reasons people are proposing were actually true, they would just state them themselves instead of using ones that sound like pitiful excuses.
Whether it be dissecting what the Kardashians ate for breakfast or understanding why the earth may or may not be flat, seeking to understand the world around us is just what we do as humans. And part of that process is "speculating sensational, justifiable reasons" for why things may be so.
Of course, what is actually worth speculating over is up for debate. As is what actually constitutes a better theory.
But, if people think this is something worth pouring their speculative powers into, they will continue to do so. More power to them.
Now, personally, I'm partly with you here. There is an element of futility in speculating at this stage given the current information we have.
But I'm also partly with the speculators here insofar as the given explanations not really adding up.
Think you're still missing what I'm saying. Yes, I understand people will speculate. I'm doing it myself here in this very thread.
The problem is people are beginning to speculate reasons for Altman's firing that have no bearing or connection to what the board members in question have actually said about why they fired him. And they don't appear to be even attempting to reconcile their ideas with that reality.
There's a difference between trying to come up with theories that fit with the available facts and everything we already know, and ignoring all that to essentially write fanfiction that cast the board in a far better light than the available information suggests.
Agreed. I think I understood you as being more dismissive of speculation per se.
As for the original question -- why are we not taking them at their word? -- the best I can offer is my initial comment. That is, the available facts (that is, what board members have said) don't really match anything most people can reconcile with their model of how the world works.
Throw this in together with a learned distrust of anything that's been fed through a company's PR machine, and are we really surprised people aren't attempting to reconcile the stated reality with their speculative theories?
Now sure, if we were to do things properly, we should at least address why we're just dismissing the 'facts' when formulating our theories. But, on the other hand, when most people's common sense understanding of reality is that such facts are usually little more than fodder for the PR spin machine, why bother?
Cool, but I looks like the creator didn't really look deep in the competition. Many of the question marks in the comparison table can be replaced by a checkmark.
I looked more closely at the simpler ones, since simplicity was a baseline requirement for me when I went looking for a server to meet my needs. If the docs for something were too complicated to even determine if it supported the features I need then I tended not to spend much time digging through them.
Indeed. It is slightly misleading at first glance. But the author has stated that it is incomplete. ZITADEL(https://zitadel.com/), for example, pretty much checks almost all the boxes.
> ZITADEL doesn't support anonymous clients. Honestly, it's not the best practice anyway.
How would you accomplish the same thing using best practices? The closest is dynamic client registration without requiring an initial access token, but that still requires clients to support the protocol, and I know at least the Jellyfin and Discourse OIDC plugins do not. And even if they did what do you gain over anonymous auth?
