The last time we had a web monoculture (IE6), it was not a pleasant experience. MS had decided it was over, they won, no more need to invest resources in that (and really, they would have preferred you write native Windows apps, but IE-only web pages which still only ran on Windows was a good second choice to them). It's also easy for a single dominant vendor implementation to impose terms on required periphery tech even if the primary standard is open (see the fate of Apache Harmony)

You could argue the Python/Linux case are safer because:

* They are themselves independent open source projects. While Chromium is open source, if Google pulled out, I'd expect the remaining development effort to be on par with e.g. Pale Moon

* You could argue there _are_ multiple implementations of Linux-as-OS, if you're not just looking at the kernel. See Ubuntu, Red Hat, Arch, Alpine, etc. There's no standards body (unless you count stuff like POSIX or LSB, but then they are only subsets of functionality compared to what users expect of a full OS) but still things become standard by community consensus (e.g. systemd)

> While Chromium is open source, if Google pulled out, I'd expect the remaining development effort to be on par with e.g. Pale Moon

I don't think that's quite true, for several reasons:

* The biggest external contributors (Opera, Samsung, and Intel) put in more development effort than Pale Moon has, by a wide margin. (I think non-Google contributors to Chromium outnumber those working on Opera's Presto at its peak, though less than Opera's desktop product and Presto at that time.)

* Last time we saw any browser vendor leave the browser engine business (i.e., Opera killing Presto), we saw plenty of people jumping ship to keep working on browser engines (and not just those let go), so if we were hypothetically in a Chromium monoculture it's unlikely that Google pulling out would stop every Googler currently contributing from continuing to do so.

Also, when it comes to the Linux kernel, remember that both Windows and FreeBSD implement the Linux kernel syscall ABI too, which you can argue means they are alternative implementations of the kernel.

Let me answer your first question with few examples:

When Chrome started taking off in 2010, they introduced unique ID per browser user that's sent to their servers. This has nothing to do with the web standards, but it's non optional added feature.

When gmail took off in Canada, Gmail started requesting an actual phone number, to open an email account.

The above are examples when company starts having advantage.

When a company starts having monopolies, expect stuff like mandatory signons just to browse and such.

In China for example, you must register with RL creds if you want to post for the masses online.

TLDR: monocultures are bad, monopolies are bad.

As soon as the binaries start betraying their user, there needs to be an alternative. Open source goes a long way to prevent the people in defacto control from adding things like requiring unnecessary accounts, naggers, ads, telemetry, backdoors, excessive bloat, etc. But sometimes the maintainers can't be reasoned with beyond a tolerable point and a lot of software and people already rely on it heavily. If the thing is a standard then someone needs to fork (if open source with a proper license) or reimplement. If it's a closed, proprietary foundational piece of software (OS, driver, word processor, compiler, browser) then someone needs to create an alternative from scratch. Those alternatives may very well start betraying the user at some point in which case, goto 10. e.g. We don't need a competing Linux because Linus is currently on our side.

And in fact, a viable competitor alone is often enough to stop abusive behavior from the market leader. If the market leader knows that they will quickly use market share if they start abusing the users, they will not abuse the users.

So a competitor like Linux or Firefox is helpful even if market share never gets very high.

Python has multiple implementations like numpy and others that i am not familiar with. Python not having a clear spec is a disadvantage, although it is pretty stable language.

C++ has standards and all compilers implement them and people stick to standards, no idea what you are talking about when you say "embraces and extends with optional non-standard features".

Linux implements the user interface standard called Posix api and portable programs stick to it.

How do you know what you are writing against is going to work tomorrow, if there is no standard?

Python has multiple implementations such as CPython, Cython, PyPy, IronPython, Jython. However, because the de facto CPython has no spec, every other Python implementation has behavioral differences from CPython and there is no real way to resolve all the differences without heavy burdens.

Do you want one already very large company to be the only browser provider? That company could start to make its implementation less user friendly/less friendly to competition; but users would have no alternative but to use it. e.g. "Let's track everyone's usage, and prevent adblockers".

Not sure that applies to language implementations. Imagine if C++ started trying to send user data to some organisation.

Python's a very good example of the problems you get into with a single implementation defining the platform (by fiat, or de facto), even if it's controlled by a completely benign and incorruptible entity.

The problem is that then bugs in your implementation become part of the de facto standard that defines your platform. Downstream code is very likely to depend on those bugs. You can't fix those bugs without breaking things. Your platform accumulates warts at a higher rate than it otherwise would. Any attempt to make major changes to the platform implementation becomes incredibly difficult because of the need to maintain bug-for-bug compatibility.

All these things have clearly happened to Python. It's one reason why despite massive efforts over a long time, there is no fully compatible Python JIT today.

If you follow Chromium development you will quite often see developers consider whether it's going to be safe to fix some bug in Chromium's behavior. Quite often part of the justification that it is safe is "Firefox doesn't have this bug, so major Web sites probably don't depend on it".

You are comparing a global standard everyone has to use to individual projects. The web is a standard, the rest are individual projects that no one is forced to use and all have n number of alternatives. They are completely different things.

Here is the thing. Many people simply do not care about things like open source even though they may use it.

Even when Stallman and Linus started many people didn't. Now the difference is these guys are doers and helped created a uniquely rich ecosystem that gives real choice to every forward generation and something to build on.

But open source typically works with small team starting things and then growing. The out of control complexity, sometime gratuitous is a real blocker as you need large teams to implement right off the bat.

Since open source cannot pay anyone or afford large teams in the beginning so this effectively rules out open source alternatives and choice. This is a pretty nasty outcome, but people have to care about these things just like Stallman and others did and fight it persistently with an eye on consequences of decisions taken today and undue complexity.

The web in terms of browsers and corporate sponsored projects like Systemd come to mind. Both will need large teams to develop alternatives ie other corporates, and thus de facto rule out open source projects and choice.

iOS and Android mitigate some of the problems by cutting off backwards compatibility at some point. "Yeah, your app broke in the new iOS/Android ... fix it". Python's tried some of that, but because people can carry on supporting/using Python 2, the result has been a crippling fork.

Linux kernel devs spend a lot of energy trying to maintain compatibility with warts, and still break things once in a while. Also the Linux kernel interface, while complex, is nowhere near as complex as the platform-level API for iOS/Android/Web.

How would Stylo have been possible in the world where Chromium was the only browser engine?

Chromium has not, and will not, accept Rust code in the tree.

I don’t think there is a need, however market forces will ensure that competition exists. If the incumbent starts to betray the user alternatives will automatically arise.

That's optimistic and naive. See Intel/AMD. The problem there is that the cost of attacking the incumbent is billions of dollars, and generally you see no ROI at all until you've spent multiple billion.

Market forces can ensure that competition will exist as long as barriers to entry are kept low enough that people can afford to compete. The larger the barriers are, the more aggressively an incumbent can be abusive without needing to fear competition.

But the use of an alternative is only possible, if the alternative is on/near the same level of usablity as the product that is market leader. If it's not the case, than most users won't switch and there is also the factor of the "mental burden" to switch to a product you're not used to and stay in the "preferred loop".