My line of thinking was that it takes X units of effort to implement feature Y. If two companies develop competing products, then 2X units of effort have been used to accomplish 1 feature Y.

If both of those companies are working on the same product, then it might follow that 2X units of effort would lead to the implementation of feature Y and feature Z. Or that feature Y is implemented in less time.

Those kind of assumptions are highly idealistic and theoretical, usually don't hold true in the real world.

It depends a lot upon the talent of the people involved, their past experience, their knowledge, and so forth. It also depends on the systems in question.

The amount of effort needed to build some particular functionality can vary immensely between two experienced developers working for the same organization on the same system. It usually varies even more so when multiple organizations are involved, or multiple systems are involved.

A monopoly is bad for competition, but do we need competition in a market where pricing is irrelevant? It's better to have all vendors collaborating on a standard engine than multiple proprietary ones. What are the negatives?

You need competition for technical evolution. Pricing has nothing to do with this.

As pointed out elsewhere in this thread, a WebKit monoculture will stifle technical innovation in web rendering engines, because they'll be constrained with being (bug-)compatible with WebKit.

Why? how is competition better than collaboration?

webkit routinely gets breaking changes, it was never constrained because of compatibility concerns over non-standard features. Wouldn't having a load of developers in different environments, working on the same codebase actually accelerate innovation? Something could go from W3C/WHATWG draft to implementation in a matter of weeks, then we wouldn't have things like css3 gradients or flexbox syntax changing completely after years prefixed in the wild.

> it was never constrained because of compatibility concerns over non-standard features.

Seriously? You should go read the www-style archives or public-html archives or the relevant W3C bug databases sometimes for all the things the WebKit folks refused to implement (and still do) precisely because of such concerns.

> accelerate innovation?

Innovation and feature addition are not the same thing.

Please explain to me how building a rendering engine that scales well to 64 cores would be accelerated by starting with WebKit as a base, for example.

While likely true, the value of multiple UAs as opposed to a monoculture is that it increases the likelihood that a revolutionary implementation that _can_ scare well to large number of cores would be able to get any traction at all instead of just being stillborn because it doesn't duplicate all the bugs of the monoculture.

So my point wasn't that one would build such a UA by starting with Presto. My point was that there are distinct advantages to competition over everyone using the same rendering engine.

What you're describing is "innovation" in its weakest form. It's basically incremental improvement, rather than real innovation.

Real innovation is far more drastic and disruptive. When it comes along, it often meets heavy resistance from those who are entrenched, especially when these people may not benefit from it. This is true even within open source projects. Unorthodox ideas will often be brutally crushed, even if the benefits they provide are immense.