[jcsiracusa]

It's not an arbitrary distinction. I see a continuum between products and "infrastructure technologies," and I think it's increasingly reasonable (and, eventually, desirable) for there to be more collaboration on a single, shared project (and less wheel reinvention) as we move toward the infrastructure end of the spectrum.

None of this precludes a changing of the guard in the future. Just ask the gcc guys about egcs and llvm…

[pcwalton]

LLVM is still fighting GCCisms. (They even had to implement a subset of GCC RTL to compile the inline asm!) The sheer amount of effort they had to go through in order to compile, say, Linux, is incredible.

Besides, by your argument, LLVM should never have been started, because they should have contributed to GCC. Yet I'm very glad they did, because LLVM is much more hackable and this flexibility has enabled many new projects, like Emscripten and llvmpipe.

[jcsiracusa]

That's not my argument. It's a cycle. People tried to contribute to gcc, but eventually reached some limits (real or imagined, it doesn't matter) and created something new. egcs was another, similar crisis with a slightly different outcome. This is all part of the process. It's never easy, but progress is made. And we all enjoy nice things between the big upheavals.

[dottrap]

The limits reached are very real. The technical problems are quite fundamental and serious, but possibly fixable. But the political problems make it impossible to solve these technical ones.

See Chandler Carruth's talk "Clang: Defending C++ from Murphy's Million Monkeys". At the beginning between 2:20 and 4:00, he quotes Richard Stallman's response to their proposed changes and demonstrates that using gcc is a non-starter.

http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...

[davidgerard]

And, most importantly, they are finally providing GCC some <i>desperately</i> needed competition.

[pyre]

  | LLVM is still fighting GCCisms

And yet this doesn't affect everything. Didn't Apple switch from gcc to the Intel C compiler? Does the Intel C compiler implement all of gcc's quirks?

[glasshead969]

Apple switched to LLVM from GCC. Chris Lattner, LLVM primary author works for Apple.

[pyre]

IIRC, I remember talk of Apple switching to the Intel C compiler ~ a year or so after the Intel switch. I'm not an Apple dev, so I don't have first-hand knowledge.

[dottrap]

No. I am an Apple dev. At least publicly, this never happened.

But Intel did have a presence at WWDC when the Intel switch announcement was made. Intel was trying to sell developers licenses to the Intel compiler (as they should).

[azakai]

Of course it doesn't affect everything, nor does it make anything 100% impossible. It just makes it potentially much harder.

A huge corporation like Apple will typically be able to overcome the additional effort.

[azakai]

> None of this precludes a changing of the guard in the future. Just ask the gcc guys about egcs and llvm…

By all means, ask the LLVM people about all the work they had to do to overcome the single-implementation status of gcc. clang must support gcc's arguments and behavior very carefully, and still cannot build all open source projects, simply because so many open source projects - including the linux kernel btw! - have been designed with only gcc in mind.

LLVM managed to overcome that through a lot of effort. LLVM is funded by Apple, a massive multinational, one of the largest tech companies in existence and of all time. Not all new projects have that luxury. In an ideal world, you don't need those kind of resources to challenge an existing implementation.

[jcsiracusa]

LLVM was created by one person, just like Linux. Both projects would not be where they are today without the efforts and monetary contributions of many others, including corporations. These are examples of the system working, IMO. Giants can be felled, tools and infrastructure can be improved for all.

[azakai]

If by "working" you mean linux succeeding through huge amounts of funding by IBM and others and LLVM through huge amounts of funding by Apple and others. Yes, both were founded by one person, but that is highly irrelevant here.

Both of your examples clearly show that it takes huge resources to overcome a single implementation in a field. That is far from optimal, it means the barrier is so high that innovation is being stifled.

As another example, look at the single-implementation status of Microsoft Office. Despite huge investments and efforts by multiple parties in the industry, it remains essentially unassailable.

The best way to avoid that is to not have a single implementation, but rather to have standards, and to have good open source implementations of those standards.

[jcsiracusa]

> Both of your examples clearly show that it takes huge resources to overcome a single implementation in a field. That is far from optimal, it means the barrier is so high that innovation is being stifled.

I think it's more optimal than the alternatives tried so far. You're ignoring the "period of peace" between upheavals during which (almost) the whole world is working together to make something better for everyone. That more than makes up for the difficulty of dethroning (or forking) the king when needed.

Office is a closed-source product controlled by a single company, not analogous at all to WebKit.

[azakai]

I don't disagree that there is a benefit as well, to a monoculture. It does avoid redundant effort.

But the cost is quite high.

10 implementations might be a lot of overhead. But a monoculture of 1 is too little. 2 or 3 might be an optimal number.

[jcsiracusa]

We already have two or three powerful entities working on WebKit, pulling it in whatever directions suit their needs. If they ever pull hard enough or far enough in different directions, it could tear (fork) and the cycle begins again. And anyone is free to learn from WebKit and create something better (as Apple learned from Gecko before adopting KHTML).

"Monoculture" is a loaded word. The differing priorities that might manifest in completely separate web rendering engines still have plenty of room to manifest when multiple big players are working on WebKit, with nothing stopping any of them from forking if the differences get too large.

(And anyway, Gecko does still exist, after all…)

[pooriaazimi]

In general, I agree with you. But in this specific case, we may not be able to extrapolate Linux/LLVM's success to web. Yes, you can create a toy kernel for yourself. You don't have to be POSIX-compliant from day one, or run OS/2 apps, or whatever. And you can create a more standard compiler that's not capable of compiling most programs that use gcc's esoteric features. They can have little niches for years, and slowly gain traction (from end-users and also developers).

But I don't think that you can do the same in browser space. If you want to create a new rendering engine, it absolutely, positively has to render 95+% of most-visited websites from early stages of development (before you "ship" a browser). Nobody would use a half-baked browser that's unable to render most websites. So, you have to also support WebKit's bugs-turned-into-standards.

In another words, you don't compile 500 different programs in a single day - if LLVM can compile the one program that your company is developing faster and better, it's a good fit for you. But you visit hundreds of websites a day. If a new engine can't display even 10% of them correctly, it'd a show stopper.

So, your choices are to either fork WebKit, or create a new engine that "simulates" most mainstream WebKit engines. Both result in WebKit becoming more and more of an standard.

[fpgeek]

As some one who (peripherally) lived through the gcc/egcs schism, I'd certainly love to hear their perspective on open-source monoculture. Somehow I don't think it would be nearly as monoculture-friendly as you do.