Just as important as the technical problems with Unix itself and the challenges consequent on its success are the cultural problems of the community around it. There are at least two serious ones: a lesser challenge of internal transition, and a greater one of overcoming our historical elitism.
The lesser challenge is that of friction between the old-school Unix gurus and the new-school open-source crowd. The success of Linux, in particular, is not an entirely comfortable phenomenon for a lot of older Unix programmers. This is partly a generational problem. The raucous energy, naïvete and gleeful zealotry of the Linux kids sometimes grates on elders who have been around since the 1970s and (often rightly) consider themselves wiser. It's only exacerbated by the fact that the kids are succeeding where the elders failed.
The greater problem of psychology only became clear to me after spending three days at a Macintosh developer conference in 2000. It was a very enlightening experience to be immersed in a programming culture with assumptions diametrically opposed to those of the Unix world.
Macintosh programmers are all about the user experience. They're architects and decorators. They design from the outside in, asking first “What kind of interaction do we want to support?” and then building the application logic behind it to meet the demands of the user-interface design. This leads to programs that are very pretty and infrastructure that is weak and rickety. In one notorious example, as late as Release 9 the MacOS memory manager sometimes required the user to manually deallocate memory by manually chucking out exited but still-resident programs. Unix people are viscerally revolted by this kind of mal-design; they don't understand how Macintosh people could live with it.
By contrast, Unix people are all about infrastructure. We are plumbers and stonemasons. We design from the inside out, building mighty engines to solve abstractly defined problems (like “How do we get reliable packet-stream delivery from point A to point B over unreliable hardware and links?”). We then wrap thin and often profoundly ugly interfaces around the engines. The commands date(1), find(1), and ed(1) are notorious examples, but there are hundreds of others. Macintosh people are viscerally revolted by this kind of mal-design; they don't understand how Unix people can live with it.
Both design philosophies have some validity, but the two camps have a great deal of difficulty seeing each other's points. The typical Unix developer's reflex is to dismiss Macintosh software as gaudy fluff, eye-candy for the ignorant, and to continue building software that appeals to other Unix developers. If end-users don't like it, so much the worse for the end users; they will come around when they get a clue.
In many ways this kind of parochialism has served us well. We are the keepers of the Internet and the World Wide Web. Our software and our traditions dominate serious computing, the applications where 24/7 reliability and minimal downtime is a must. We really are extremely good at building solid infrastructure; not perfect by any means, but there is no other software technical culture that has anywhere close to our track record, and it is one to be proud of.
The problem is that we increasingly face challenges that demand a more inclusive view. Most of the computers in the world don't live in server rooms, but rather in the hands of those end users. In early Unix days, before personal computers, our culture defined itself partly as a revolt against the priesthood of the mainframes, the keepers of the big iron. Later, we absorbed the power-to-the-people idealism of the early microcomputer enthusiasts. But today we are the priesthood; we are the people who run the networks and the big iron. And our implicit demand is that if you want to use our software, you must learn to think like us.
In 2003, there is a deep ambivalence in our attitude — a tension between elitism and missionary populism. We want to reach and convert the 92% of the world for whom computing means games and multimedia and glossy GUI interfaces and (at their most technical) light email and word processing and spreadsheets. We are spending major effort on projects like GNOME and KDE designed to give Unix a pretty face. But we are still elitists at heart, deeply reluctant and in many cases unable to identify with or listen to the needs of the Aunt Tillies of the world.
To non-technical end users, the software we build tends to be either bewildering and incomprehensible, or clumsy and condescending, or both at the same time. Even when we try to do the user-friendliness thing as earnestly as possible, we're woefully inconsistent at it. Many of the attitudes and reflexes we've inherited from old-school Unix are just wrong for the job. Even when we want to listen to and help Aunt Tillie, we don't know how — we project our categories and our concerns onto her and give her ‘solutions’ that she finds as daunting as her problems.
Our greatest challenge as a culture is whether we can outgrow the assumptions that have served us so well — whether we can acknowledge, not merely intellectually but in the sinew of daily practice, that the Macintosh people have a point. Their point is made in more general, less Mac-specific way in The Inmates Are Running the Asylum [Cooper], an insightful and argumentative book about what its author calls interaction design that (despite occasional crotchets) contains a good deal of hard truth that every Unix programmer ought to know.
We can turn aside from this; we can remain a priesthood appealing to a select minority of the best and brightest, a geek meritocracy focused on our historical role as the keepers of the software infrastructure and the networks. But if we do this, we will very likely go into decline and eventually lose the dynamism that has sustained us through decades. Someone else will serve the people; someone else will put themselves where the power and the money are, and own the future of 92% of all software. The odds are, whether that someone else is Microsoft or not, that they will do it using practices and software we don't much like.
Or we can truly accept the challenge. The open-source movement is trying hard to do so. But the kind of sustained work and intelligence we have brought to other problems in the past will not alone suffice. Our attitudes must change in a fundamental and difficult way.
In Chapter 4 we discussed the importance of throwing away limiting assumptions and discarding the past in solving technical problems, suggesting a parallel with the Zen ideas of detachment and ‘beginner's mind’. We have a larger kind of detachment to work on now. We must learn humility before Aunt Tillie, and relinquish some of the long-held prejudices that have made us so successful in the past.
Tellingly, the Macintosh culture has begun to converge with ours — MacOS X has Unix underneath, and in 2003 Mac developers are (albeit with a struggle in some cases) making the mental adjustment to learn the infrastructure-focused virtues of Unix. Our challenge will be, reciprocally, to embrace the user-centered virtues of the Macintosh.
There are other signs that the Unix culture is shedding its insularity as well. One is the convergence that seems to be going on between the Unix/open-source community and the movement called “agile programming”.[164] We noted in Chapter 4 that Unix programmers have seized happily on the concept of refactoring, one of the preoccupations of the agile-programming thinkers. Refactoring, and other agile concepts like unit-testing and design around stories, seem to articulate and sharpen practices that have heretofore been widespread but only implicit in the Unix tradition. The Unix tradition, on the other hand, can bring groundedness and the lessons of long experience to the agile-programming party. As open-source software gains market share it is even conceivable that these cultures will fuse, much as the old-time Internet and early Unix cultures did after 1980.