Slashdot Mirror

The main things I read in JWZ's message on his site are:

• Software development is hard. Mozilla is a huge project, and just getting it off the ground has taken much longer than he wanted. The sheer size of the code base made it hard to make small changes or even understand what was going on, which confounded and discouraged new developers coming on board (or trying to). This is a problem I'm sure many developers can appreciate. As a product ages, its code base tends to grow, which makes both understanding and modification more difficult.
• Distributed software development is really, really hard. Mozilla/Netscape found it necessary to do a sginificant amount of work on the problem, and as a result developed new tools like Bonsai and Tinderobx as well as the methodologies surrounding them. Why? Existing tools available to support distributed development are woefully inadequate, and most people don't even know what a development methodology is.
• It's hard to get contributors if they can't get quick gratification. It has to be possible to download the code, see it work, poke at it, change it, and see the effect of your changes. Quickly. One of the major problems he pointed out was that people couldn't do this to Mozilla, so it wasn't worth their effort to contribute. In other words: Just because you open-source something proprietary doesn't mean people will jump on your bandwagon. You have to make it easy for them to do so, which takes extra effort.

I would argue that the perception that Mac programmers are better at UI design is the result of the fact that Mac programmers have always been held to a higher standard. The Mac has always been a no-muss-no-fuss machine, and Mac users expect that across the board. For example:

• You never have to worry about interrupts. And no user should. It's absurd that anyone other than low-level systems programmers should ever be concerned with such minituae of making a system function correctly.
• You don't have to worry about everything breaking when you remove something. If you want to get rid of an application, you drag it to the trash, and you're done. None of this "registry" crap.
• You don't have to worry about whether your machine can talk to its components and peripherals, because it just does. People like to say that Windows has plug-and-play, but we all know it's plug-and-pray. Even if it works, you probably have to reboot six times before everything actually goes correctly. On the Mac, you can load up a whole bunch of new drivers while it's running and then restart. And you never have a driver issue that wedges the machine to the point you can't even install what you need. (I once saw someone install a whole new motherboard on his PC. It turned out that he couldn't get at the CD-ROM drive, because he needed a new PCI-to-PCI bridge driver. Wehere was said driver? On a CD.)

For all it's marvelous technical chrome (which, believe me, I love as much as the next geek), Linux is still hard to install, hard to configure, a nightmare to maintain, and a total powderkeg when upgrading.

As the author of the article quite rightly pointed out, it's about the culture of the programmers, but also of the users. Part of the reason Mac software is, on average, as good as it is, is that the users wouldn't pay for it if it sucked. Mac users expect a high degree of stability, a consistent interface, a low learning curve, and an obsessive attention to detail and excellence when it comes to UI. Mac programmers know this, because they're also usually Mac users.

On the other hand, Windows (the world's most unstable, slow, and bloated [P]OS) has continued the myth that "that's just how computers are". Bullshit. That's how poorly designed systems are. However, Windows programmers (and users, as well as many Linux programmers/users) don't know the difference because of the environment they have always had and have come to accept as the norm.

The Mac has shown (for many years) that a higher standard is achievable. The problem is that we've continued to accept that our OSs and applications be difficult to setup, maintain, and upgrade. We must overcome our complacency with crashes, reboots, and obscure systems; we must learn to be dissatisfied with our systems; we need to develop a sense of when a system isn't right, instead of just accepting it as is. Under the OSS model, that's the only way they will ever become better.