I believe you stated the problem in a way that its unsolvable. Charge your customers money, so you can work for them. I'm not nearly as certain as you are that Netscape failed because it was charging money. Netscape just stopped updating for multiple years at the height of the browser wars.
For Firefox in particular, I would 100% be willing to pay for it. Individuals like me who will pay are rare, but companies that will pay aren't. I think the answer for modern Mozilla is a Red Hat style model. Charge a reasonable amount of money. Accept that someone is going to immediately create a downstream fork. Don't fight that fork, just ignore it. Let the fork figure out its own future around the online services a modern browser wants to provide.
Then, lean hard into the enterprise world. Figure out what enterprise customers want. The answer to that is always for things to never, ever change and the ability to tightly control their users. That isn't fun code to write, but its profitable and doesn't run counter to Mozilla's mission. That keeps Mozilla stable and financially independent.
Mozilla will maintain lots of influence to push forward their mission, because hopefully their enterprise customer base is big, but also they are the ones actually doing the work to make the downstream fork possible.
> I believe you stated the problem in a way that its unsolvable.
I think you misunderstood me. I asked a question because the answer is far from obvious. If the solution to this problem was obvious, we wouldn't be having the same discussion on HN every 6 months when a new press release from Mozilla comes out.
I am very much interested by what people think the solution should be. Now, you mentioned Enterprise customers which is interesting because usually what I have read on this sort of threads was that Mozilla had made many mistakes (I agree), Mozilla should change their ways by removing this feature or adding this feature but almost everyone conveniently forgets that at the end of the day someone has to pay for all this stuff.
> Charge your customers money, so you can work for them.
Which is what I mentioned in my comment. Start charging people. The problem is how do you convince the general public to use Firefox instead of Chrome or Edge, especially is you need to pay for the software?
If privacy was a selling point, then Meta would have closed shop many years ago.
> I'm not nearly as certain as you are that Netscape failed because it was charging money. Netscape just stopped updating for multiple years at the height of the browser wars.
It doesnt matter because we will never know. The reality is that people expect to browse the internet for free. Asking them for cash has never been done at this scale.
If Mozilla was to start charging money tomorrow, you would find that many people would object to that and most people would simply move to Chrome because why not?
> Then, lean hard into the enterprise world. Figure out what enterprise customers want. The answer to that is always for things to never, ever change and the ability to tightly control their users. That isn't fun code to write, but its profitable and doesn't run counter to Mozilla's mission. That keeps Mozilla stable and financially independent.
I understand the comparison with Red hat but I am doubtful that this model will work. Red Hat helps companies ship stuff, it makes people more productive, it increases the bottom line. What would a paid version of Firefox do that makes people more productive or makes companies money that they couldn't get from Chrome? I am genuinely asking because again, it's mot very clear to me.
> Mozilla will maintain lots of influence to push forward their mission, because hopefully their enterprise customer base is big, but also they are the ones actually doing the work to make the downstream fork possible.
That is big assumption that has not been proven at this time. I think that making any sort of plans based on hypothetical paid version is highly speculative.
I wouldn't mix OAuth and OIDC up when thinking about this. OAuth is a chaotic ecosystem, but OIDC is fairly well standardized.
OIDC actually does have a discovery mechanism standardized to convert an email address into an authoritative issuer. Then, it has a dynamic registration mechanism standardized so that an application could register to new issuers automatically. Those standards could absolutely be improved, but they already exist.
The problem is that no one that mattered implemented them.
If you want to get anywhere with something like this, you need buy-in from the big email providers(Google, Microsoft, Yahoo, and Apple) and the big enterprise single sign on providers(Ping, OneIdentity, and Okta). All of those companies already do OIDC fairly well. If they wanted this feature to exist, it already would.
Instead, it seems like big tech is all-in on passkeys instead of fixing single sign on.
They don’t allow third party browser engines. If they didn’t allow web view they are effectively banning third party browsers completely. I can’t imagine that would make their anti trust problems any better.
Although, it does seem like they could get more granular in app approval, which I am sure iOS devs would not like, but users would. For example, "If your app's primary use case is navigation of the open web, you may use WebView to handle 3rd party links. However, if that is not the primary purpose of your app, web links must open in iOS."
Either that, or give me a setting for each app, which the dev can set the default on. "Open links in Safari."
There’s a permission for Location at least, “In App Web Browsing” can have that permission disabled. Web Views don’t seem to have similar treatment otherwise, afaict. I’d sandbox them aggressively if I could .
I use Adguard which has a Safari integration that appears to apply to Web Views (based on the absence of ads), though I don’t have proof of that.
The reason is that defaults are powerful. Languages tend to have an owner in a position to declare a default for a language. No one is in a position to declare a default for polygot environments.
This also explains why the only places where these polyglot systems seem to be really common is at giant companies, where they have the power to enforce that stuff is interoperable. If your employer tells you to do extra work to make sure that your package can be used by others in the company, you're going to do it, but if you're working on some personal open source project and have the luxury of deciding what to prioritize, most people are generally not going to be spending time on figuring out polyglot build systems and will just use whatever's easiest, which will generally be whatever the language's default is.
For Firefox in particular, I would 100% be willing to pay for it. Individuals like me who will pay are rare, but companies that will pay aren't. I think the answer for modern Mozilla is a Red Hat style model. Charge a reasonable amount of money. Accept that someone is going to immediately create a downstream fork. Don't fight that fork, just ignore it. Let the fork figure out its own future around the online services a modern browser wants to provide.
Then, lean hard into the enterprise world. Figure out what enterprise customers want. The answer to that is always for things to never, ever change and the ability to tightly control their users. That isn't fun code to write, but its profitable and doesn't run counter to Mozilla's mission. That keeps Mozilla stable and financially independent.
Mozilla will maintain lots of influence to push forward their mission, because hopefully their enterprise customer base is big, but also they are the ones actually doing the work to make the downstream fork possible.