If you'd like to learn more about resource forks on the Mac, which were a very clever solution to a difficult set of problems, please read this, written by the person who created them:
If you want to know more about the invention and early history of the Macintosh in general, there's tons more at http://www.folklore.org (or in the book based on it, Revolution in The Valley, by Andy Hertzfeld).
Quoting from the article: "Not all new ideas represent progress. (Do I really need to spell this out? It seems so.) But ideas should not be rejected based merely on a lifetime of having lived without them."
Only a tiny subset of the population cares about fast cars. A larger portion cares about expensive cars, of which supercars are only a small subset. Many people are dazzled by wealth. Far fewer know or care anything about performance.
The sentence in question is not an assertion about Apple's feelings towards PCs. It's recommended pairing of action and motivation. "Joe should marry Sue because he loves her, not because she's rich." Whether or not Joe loves Sue is another matter.
The problem with the Porsche 918 is that it's a solution to a problem almost no one has. It uses racing hardware to solve commuter problems. Great, but…why? Is there any public road out there that really takes advantage of 820 horsepower? Seriously, what routes have been designed for these speeds? Anything that benefits from 820 horsepower will benefit more from lighter weight and a better CD.
I like the idea of the Porsche 918. I like going balls out just for the hell of it. I just don't think it's a car that anyone can really use.
As I noted in the article, there are many more axes of innovation beyond just performance. But performance is definitely one of them!
Apple's pursuing top-end performance with gusto in its laptops and mobile devices. But its desktops have been left to languish, not even using the fastest available off-the-shelf CPUs and GPUs (let alone using custom high-performance silicon designed in-house, a la the latest iOS devices).
I'd say we already see the benefits of having so many people work together on WebKit. Would we be better off if Google had to create and maintain its own desktop and mobile web rendering engine from scratch? If there's a monoculture problem in mobile web browsing, it's due to the disproportionately large percentage of it that's done using Mobile Safari on iOS. Single-vendor/closed-platform will always be a problem. WebKit is neither.
Yes, over-use of vendor prefixes in CSS and other browser-specific features is bad. But that's an authoring issue as much as it's a WebKit issue. Having -moz-, -o-, and -webkit-* plus JavaScript shims to hide the differences in multiple browsers is a great argument for standards, but not a great argument for a larger variety of independently developed and maintained web rendering engines.
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.
> 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.
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.
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.
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…
Let’s check back in a year. I don't share the fear of WebKit bugs that are present in every single implementation of WebKit in use today (I'm not even sure the disk filler qualifies) and that "can't be fixed because they'll break the web." Individual products that incorporate WebKit can and will choose how much bug-for-bug compatibility to maintain with each new version, and I don't think those decisions will all match up.
The concept of "WebKit's implementation quirks" implies that WebKit is a single thing when in fact it's (already) a huge diversity of different things.
WebKit is also constantly changing, so even the current (small) set of "implementation quirks" that really are 100% identical in all products that use WebKit will not stay the same very long.