This is a response to a MacOpinion column, "The Cathedral and the Bizarre".
Interestingly, the number one problems with Linux, from a consumer perspective, are that it doesn't have a standardised UI...
You are absolutely right; but what would you propose to do about it? an edict? From whom? People will do what they want. Just as much as Steve Jobs enforced consistency in early Mac apps, he's reinventing everything now, and as Tog puts it, designing around his ego instead of sound usability principles. So even a single leader who "knows the right thing" cannot be relied upon long-term. Anyway many open source applications (as opposed to Linux itself, the kernel) are meant to be cross-platform, and this complicates the issue; witness Mozilla, which has its own UI on every platform, ignoring the conventions of the platform that it's running on. And they tout it as a plus - "look how consistent we are, it looks and feels the same everywhere." Sun made the same mistake with Swing (and then added pluggable look-and-feel to correct it).

So I think the most that can be hoped for is that the ongoing popularity contest will ultimately select which GUI toolkit is the winner, and most new apps will be written using that. It seems to be down to GTK/Gnome vs. QT/KDE; Motif and Athena widgets have mostly fallen by the wayside. You can't enforce a standard without also quashing the diversity from which the next generation of software springs. It may be OK for the Mac UI to get long in the tooth and go on believing that it is the one true UI, but not for something as inherently "experimental" as Linux. If Linux becomes too mainstream for experimentation then there will have to be another alternative.

Perl itself is a testimony to the OpenSource mindset - it's a gruesome mishmash of inconsistent syntax and function calls...
I agree, I use it as little as possible. But this too shall pass. There are many alternatives already, even more in the works, and one of them will be more popular than Perl someday. Maybe it will be Python, one of the friendliest languages ever.
First, let me ask you a question: if you make your living by selling service on software, what's the motivation to make the software as easy to operate and maintain as possible? The answer? Well - not much.
This is a good point, in that the source of revenue is not so directly linked to the overall quality; but indirectly it still is. The customer gets to force the developers to deal with all the issues that they have created; and being developers, they will want to fix them once and for all rather than put bandaids on the same problems over and over, as long as schedule pressure or the marketing dept. do not prevent them. And they get to do it incrementally. In the shrinkwrap market, the need for a bugfix release is an embarassment, and therefore there will be pressure to just roll the fixes into the next regular release, and then they will be subject to more time constraints because the development of new features is supposed to be the real focus at that time.
...in OpenSource, there isn't really any direct competition.
Baloney. The difference is that an individual developer, instead of being a nameless faceless contractor, is staking his personal reputation on the quality of the software he releases. As in commercial software, the need to fix a bug is an embarassment; but unlike the commercial software world, the best way to alleviate the embarassment is to fix the bug pronto. Releases can be done often enough that a really embarassing bug might only exist for a few hours before the new users are downloading the newest release and they never see that bug. There is no way to do this with a shrinkwrapped CD.
Everything goes into the pool, good and bad. If you have a good idea, everyone else gets that good idea and it gets merged into all products - even the bad ones.
Breaking up software into small reusable components is the best way to ensure that the bad stuff can be weeded out; each bad component can be interchangeable with other alternatives, and some of them might be better. This is true for commercial software, but again the shrinkwrapped CD gets in the way; the company's intention is to make sure you have everything you need to run their app. They don't care how many of the DLLs that they distribute with it are just going to replace newer, less buggy ones that you may already have installed (or worse yet, clobber something in an NT Service Pack, so that after installing the app, you must reinstall the Service Pack.) But on the better Linux distributions, especially Debian, package management takes care of this. The installation of the package you want implies the installation of the latest version of all the dependencies, and this happens automatically. You will not normally get into a situation where something has to be downgraded to support a package, because most libraries are backwards compatible. (Perl is a bad counterexample though; Debian comes with at least two minor point releases of Perl, because they aren't compatible and some apps need one, other apps need the other. But this is not typical of other packages.)
This means that the real differentiation for OpenSource isn't marketshare or even marketability, but simply whether or not it can garner a following.
Huh? Market share is the goal. "Garnering a following" means the same thing as gaining market share doesn't it? The only difference is that the reward for more marketshare is different.
There are also many kinds of software which have lifespans just too short to make it sensible to bind the customer in a service agreement. Games are a good example. Most games are onetime sells.
Obviously. In fact if memory serves, it's one of Eric Raymond's examples of software which should not be open source, at least not at first. I think he would also agree with your points about Doom (that they released it as an educational resource after having made enough money off of it). But many commercial entities have no such concept of magnanimity; in their opinion, customers do not need to know how they built some product 5 or 10 years ago, even though it has no further commercial value.

You conclude with some praise for OS X, and I agree with that; I was thinking a while back that a Linux kernel combined with some of the Mac innovations (mostly the Finder, and the filesystem; resources are a very good thing, and the ability for apps to get found and used regardless where they are installed is a good thing.) would be the closest we've gotten to an ideal computing platform. But still not the ultimate computing platform. Desktop GUIs as we know them will yield to client-server UIs. People will be using a variety of gadgets, not just desktop PCs. They will want to use the same apps on all of them, and they will want the GUI to be rendered in an appropriate way for each of them. I think the next big step in GUI evolution will have to address this, and it will make all the other little tweaks over the last 15 years to the same old Xerox Parc UI look really trivial and quaint. I will be writing more about it (and soliciting collaboration) at www.metawidgets.org as soon as I find a place to host that domain. And beyond that, there are probably bigger innovations waiting in the wings.