Category Archives: Ubuntu

Ubuntu

Thesis done!

My thesis, based on my anthropological fieldwork in the Ubuntu community, is finally done, and I turned it in yesterday.

Since I began writing my thesis, I’ve had this as my background screen on my computer:

Don't go native!

Going Native‘ is losing your reflexive anthropological distance by becoming to closely involved with the field. It is taking on some of the cultural traits of the people you study, eventually reaching the point where you can’t even tell yourself apart from your informants.

Naturally, this is a bad point of departure for writing serious anthropological analysis, and I needed that daily reminder not to jump back in to the digital conversation flow on IRC and mailing lists and continue my direct involvement with Ubuntu, which would make writing this thesis so much harder (and most likely make the end result even worse that it has turned out..)

So I left the Ubuntu community for a while, longer than anticipated, actually, as it seems that Parkinson’s Law (stating that “work expands so as to fill the time available for its completion”) remains in effect.

Thus, I won’t be able to defend my thesis until late August because the University of Copenhagen summer break in July. And similarly, I won’t have time to make my thesis available on-line until then, partly because the people I quote in the thesis need to have a chance to read and approve of the data I make public, partly because I will be on summer holidays almost continuously until the 27th of July, and partly because my computer died recently, leaving me with little means of working on the go.

But as a little (tiny) appetizer, here’s the front page:

Thesis front page

Later on, I hope to sum up some of my experiences writing this thesis. I haven’t really been very good at posting updates on how my writing has progressed, but I suppose that is in part due to the thesis tunnel vision that sort of blocks out everything else.

Until then, enjoy the summer!

Debian as the research library of Free Software

I’ve had a quite interesting discussion with Lars Risan in the comments to my recent blog post on Launchpad about Lars’ paper on the role of technical infrastructure in Free Software development, and I think Lars does well to describe the central tension within these:

I think Debian is a tremendously interesting case when it comes to understand human cooperation. Because, not unlike what Eric Raymond pointed out long ago, there is the ??Bazaar? of Debian, the heterogeneity of the network. And there is the ??Cathedral? of it: The ability to structure the large amount of work to the degree that you can slip a Debian DVD into a Windows-computer, and turn it into a Debian computer in less than an hour. How far can you take this mix of ??cathedral? and ??bazaar?? How much bazaar can you have before it forks, and how much central control can or must you enforce upon the network? How can you build a system that enables the ??beauty of (hacking) mankind? to simply do good, and/or how much must you invoke something like the (partly fantasy figures) of the Ubuntu-Launchpad and the Debian-Cabal?

This much-discussed question of centralization connects well with the stated goal of World Domination that many Free Software communities state again and again in a typical “ha-ha, only serious” fashion.

Global domination is a centralistic quest to compete with the cathedrals of Windows and Mac OS, and to do this while maintaining the freedom of learning and technical exploration that is the essence of Free Software will inevitably be a balance act. It is one that all Linux distributions are performing with various degrees of success.

One way is, as Canonical proposes, to let companies define the supported Free Software that the end user might need, and guarantee that it is available and that it “just works”. Thus creating small pools of centralization – the specific traits of Ubuntu – merging with the larger decentralized pool of shared knowledge within the bazaar – Debian Unstable every six months.

Mark Shuttleworth describes this relationship as Debian as “the Tibetan Plateau of the free software landscape? upon which Ubuntu is built:

By contrast with Debian??s Plateau, Ubuntu is a cluster of peaks. By narrowing the focus and allowing the KDE, Gnome and server communities to leverage the base of Debian without treading on one another??s toes, we can create a K2, and a Kangchenjunga and a Lhotse. Ubuntu??s peaks depend on the plateau for their initial start, and their strong base. Ubuntu needs to be humble about its achievements, because much of its elevation comes from Debian.
[…]
Many people have asked why I decided to build Ubuntu alongside, or on top of, Debian, rather than trying to get Debian to turn into a peak in its own right. The reason is simple – I believe that Debian??s breadth is too precious to compromise just because one person with resources cares a lot about a few specific use cases. We should not narrow the scope of Debian.

At last year’s DebConf, a talk compared Ubuntu’s use of Debian to shopping at a supermarket, a one-stop shopping for your free software needs. This innocent analogy sparked a lot of discussion, with many of the Debianistas arguing that this reduced Debian to a giant collection of un-integrated software – which wouldn’t be very interesting at all. As Debian Developer Joey Hess put it:

My main motive for contributing to Debian is to make Debian the best distro I can; I don’t mind if others use that work, especially if stuff gets contributed back. But it’s long been clear to me that the most important added value to Debian is not adding another package to the shelf, but finding new ways to integrate our software together. When you’re working mostly above the level of individual software packages, to have your work mostly appreciated on the basis of “component contained in Ubuntu” is not very motivating.

Integrating and creating a universal distribution is still a central motivation for many Debian developers, who may find that Ubuntu is not only stealing their thunder but also compromising their ideals, again with no small amount of distrust towards the dealings of the opaque corporate entity that is Canonical.

But as Shuttleworth also notes, that when you seek narrow goals, it will come at the cost of openness and democracy. The Debian community is obviously unwilling to make such a trade, and as such, must look elsewhere for inspiration on how to organize themselves towards their goal.

Taking a cue from an earlier comparison of the Free Software communities to the scientific communities, I think it would be worthwhile for Debian to leverage their solid technical infrastructure towards becoming commonly agreed upon open standards to allow the exchange of knowledge and code will be possible on equal terms. In that way, I think that Debian is quite well poised to become a sort of ??research library of Free Software? – collecting the ??monographs? and ??articles? of code, cataloguing and organizing them for easy and open access.

Almost all Debian developers, and apparently 76 % of all Debian users,use Debian Unstable or Testing.

Debian Unstable, codenamed Sid, is the latest, most volatile version of Debian, where new packages are uploaded to, and changes to old packages are added on a daily basis. It contains all of the latest releases of the upstream communities, packaged and categorised. Debian Testing contains all of the packages that haven’t had a critical bug filed against them after spending 10 days in Unstable.

Only 24% of the Debian users use Debian Stable, since the releases are so rare as to only come out every 2 or 3 years – much too rarely to keep up with all the latest hardware and desktop applications, making Debian Stable relatively unattractive in the long term.

Since Debian Unstable (or Testing, for the less adventurous) fulfills the needs for both the users and the Debian developers, there is little incentive to make an Upstream Version Freeze and actually get a new release out, and since Debian is solely based on volunteer work (with suggestions to pay release managers meeting fierce opposition), bug fixing and release deadlines aren’t enforced that well, further slowing the actually release of the Debian Stable.

As Shuttleworth points out, Debian Unstable is “not subject to the same political tradeoffs that are inevitable when dealing with releases, architectures, dates, deliverables, translation, documentation and so on.” – it is the core strength of Debian.

As the developers I interviewed said again and again when asked what they get out of contributing to Free Software projects like Debian: “I get a system that works for me.” To some extent I think that is what Joey Hess’ means when he says that his main motivation for contributing is “to make Debian the best distro I can.”

Debian Unstable is not merely about keeping software up to date, but also about improving it, further integrating it within the Debian infrastructure. It is a research library in the way it is not only focused on gathering knowledge, but also on using it. It is also a laboratory where Free Software is shared and combined in new and interesting ways.

Maybe that would the most fitting analogy to what Debian really is: A research library containing all of the Free Software that lives up to set strict criteria. Offering all the development tools, libraries and applications up-to-date for new experimentation.

This would fit well with the Lars’ counter-argument:

Science is (also) extremely disunified (there are 22.000 different medical journals in the world. ??Medicine? (in singular) is known by no-one). And ??science? can live with this relative disunity. Can Debian? There is at least one difference: ??Debian? as a whole must occasionally come together to produce a release. A release which is unified enough for a computer to work. Fuzziness is simulated by computers, because they work only by strictly separated ones and zeroes. The knowledge of Debian, packed together as a release is pretty much a unity. A unity of which a large degree of coherence is required. The knowledge of science may be unified in an encyclopaedia, but, metaphorically, the discrepancies and glitches of that body of knowledge is so enormous, so ??buggy?, that it would make any computer halt very early in the boot.

Much like the knowledge of science only can gathered for release in an encyclopaedia that is outdated before it is even published, all of the software within Debian will also be outdated by the time it is released. Perhaps Debian should take inspiration from Wikipedia rather than other Linux distributions.

Wikipedia is a reservoir of such diverse knowledge that it would never be in a position where it could be published in paper form. It would require an insane amount of work, flamewars and unhappiness for all involved. It would require a centralization that simply is not present in the Wikipedia community.

But in spite of this, by far the biggest part of Wikipedia is eminently usable and accessible at any given time. As is Debian Unstable.

Perhaps the Debian community should take some comfort in this.

Why Launchpad isn’t taking off just yet

Lars Risan, a Norwegian anthropologist leading a group of researchers at the university of Oslo studying “The Political Economy of Free/Open Software” recently put up an interesting blog post about the Launchpad technical infrastructure’s effects on the relationship between Ubuntu and various upstreams, both with regards to Debian, but also with regards to the translation work done through Rosetta as opposed to directly in the upstream.

Risan raises some relevant issues that have received much discussion within the Free Software communities around Ubuntu, namely: What is Canonical’s intended purpose with Launchpad, and why isn’t it Free Software?

He finds that the main lines of argument revolves around the fact that Launchpad is Canonical’s flagship investment, and that the promises of freeing the Launchpad source code will only be kept once Canonical has secured the market for Open Source infrastructure, and that Canonical much like Google seeks to trade in free web services to profit from the unhindered access to the data – the translations, source code, bug reports, specifications and support tickets handled by the system.

While Mark Shuttleworth’s reply to these claims emphasizes that he has no problem if people prefer to use something like Pootle instead. And he concludes:

One thing I can say, though, is that a web service (or even a remote app service) can never create the same level of pain that a proprietary OS can do. Having watched what Microsoft has done, I’m largely motivated by a desire to ensure that countries like South Africa never have to pay a tax like that again.

And that’s fine. Like Google, Launchpad is intended to provide a service which you can choose to use or not. But as Risan points out, the service still isn’t very good. In his case study of how Rosetta works, he concludes:

At the moment, then, Rosetta seems not to be Adding Value ™. It is just adding mess. Neither is it evil. It is just bad.

As Risan does well to show in his paper, it is not a matter of whether Rosetta technically offers the necessary capabilities, but rather whether the infrastructure can work with the various upstreams – in Risan’s case the Norwegian translators of KDE – to make sure the latest translations are available in distributions like Ubuntu which depend on Launchpad for its translations.

The problem is that with Risan’s translations, Rosetta has simply supplanted the Norwegian KDE translators as the translation upstream, thus actually segregating the community rather than uniting it. And the reason for this may exactly be the Norwegian KDE translators’ hesitancy to drop Kbabel and other tools for Launchpad and Rosetta – a platform which many Free Software developers still do not entirely trust, nor will be willing to use until it becomes Free Software itself, or at least until it becomes so good that it would be too much work to build an alternative – like Google.

In this way, the adoption of Launchpad continues to be slow, not because of any bad intent from its architects or lack of interest from its potential users, but because it has been built without consideration for the social connections within and between Free Software projects.

Indeed, Launchpad is often described as seeking to “automate social connections between projects” so that patches and data can be exchanged as smoothly as possible with a minimum inter-community flame-wars (this fits quite well with Ubuntu’s relationship to Debian, where a number of developers continue – rightly or wrongly – to be unhappy with the patches that Ubuntu send back upstream).

When the project started, the Launchpad developers mapped out all the software repositories of the Free Software world and linked them together, but they did not map out the flow of information between these repositories or how its active inhabitants collaborate. Thus Launchpad does not reflect how the upstreams work, limiting their willingness to adopt it, and since they can’t customize it to fit their needs as they would otherwise do – the source code is still unavailable, after all – they simply stay away.

Unlike Google – whose services generally are so easy to use that they require little or no customization, Canonical’s Launchpad is a intricate behemoth of details. Even core Ubuntu developers who use it everyday do get lost in the system from time to time. It cannot be optimized for a single use case, since Free Software projects, though they appear much alike, have subtly and vastly different ways of collaborating – both due to community structures and dynamics, but mostly because of the many different tools they use.

Having the data is not enough. Understanding and incorporating the work flow of the upstreams is also necessary. And nobody will be able to do that better than the upstreams themselves.

This constant negotiation between the technical and the social is the main theme of my thesis, and though I can’t delve into the entirety of Launchpad, I do hope to elaborate further on some of these ideas about the role of technical infrastructure in Free Software projects.

Thesis writing

I met with thesis advisor (or supervisor – I’m not really sure about the proper English terminology here. I think advisor sounds more precise) yesterday to discuss the outline of my thesis.

As I had figured, he agreed that it was a good idea to design each chapter as independent essays with their own argument and conclusion which I could then connect into an overall argument by writing a “meta-text” into the main text referring to points made in other chapters where appropriate.

Our main discussion this time was on how to best build up a good structure to give the reader all the necessary pieces to understand the highly technical and specialized field the thesis is about. He demanded that I didn’t take too much for granted, not about the reader’s empirical or technical knowledge of the field, nor about the reader’s grasp of the anthropological theories I plan to use.

As he said, “most anthropologists like Bruno Latour and the concept of Actor-Network Theory for completely different reasons than most other academics: We find most of his points about the social construction of technology as blindingly obvious, but we do like the succinctness and stringence of his arguments. On the other hand, we aren’t too fond of his methods which seem crude to say the least. Other academics find his basic premise of socially constructed technology mind-blowing and stick to his methods as at least some way of dealing with this (to them) new way of perceiving the world.”

As it is, the relationship between the social and the technical will at the very centre of my thesis, but he warned me not to become too overenthusiastic about Latour and use him as a basis for discussion rather than as a conclusion in its own right. I find this exceptionally clever, especially since I was leaning towards doing this anyway, and it will only make my analysis so much clearer and sharper.

The main challenge of writing such a big lump of text like this thesis – it will end up at around 30.000 words – is getting them all in the right order. Building the argument in such a way that the reader will always read whatever seems most amazingly curious and interesting at that point. When writing chapter one, I have to find out what do the reader needs to know in order to read chapter 2? What framework do I build to make it as straightforward and accessible as possible?

So far, I’ve sought to develop each chapter around specific empirical cases to make the conflicts and theoretical issues at hand as concrete as possible. My advisor has kept telling me: Use the best cases! The ones you like the best! You will be delving into these and the more exciting and curious you find them, the better analyses you will write about them in the end!

So that’s where I’m at now. I’m starting out writing a chapter (what is going to be the third of six) with a solid overall structure in mind, and hopefully it won’t change too much in the meanwhile.

Leaving Ubuntu – for a while

My thesis advisor is really a quite clever guy. I had a meeting with him this afternoon to discuss the first draft of my fieldwork report that I gave him a couple of days ago, and he really pulled it apart:
“Where’s the anthropological distance? Where’s the methodological reflections?” he demanded, and I must have looked pretty stupid just then.

“You’re just using their categories, the way that they talk about things. You don’t really write about the differences in what they say they do, and what they actually do!” he continued. And I sat there nodding, mumbling “‘spose so”, not only feeling shamed for being accused of forgetting the basic tenets of anthropology, but even more so boiling with frustrated anger: What! I’ve worked hard at this! This report is the first concrete result of 7 months of fieldwork and 3 months of preparation before that! Don’t tell me what I know about this community!

But of course, he was right. He wasn’t doubting what I know or how I came about that knowledge. He was merely pointing out that it did not seem as if I had reflected very much on this myself. To him it seemed as if there had been a point in my fieldwork when I had begun to understand the inherent rules, ideals and social structures of the Ubuntu community so well that I had begun to take them for granted. That I had basically gone native to some extent, and that it would not be enough merely to take me out of the field, but also begin to take the field out of me.

I’ve only been out of the field for a few weeks, but even so, I still bring it with me on my computer. I’m still subscribed to lots of mailing lists, I still hang out on various IRC channels, read a lot of Planets, get bug mail and mails on wiki updates. I’m basically in touch with and exposed to the community all the time, even though I’m supposed to stop gathering data and start analyzing it. And as long as I keep these ties, I will inhibit my own reflective distance as an anthropologist.

As I’ve participated in this community, I have met so many passionate people with so much enthusiasm that it has been impossible not to be smitten by it. This passion is what has helped me to contribute and become so involved with the whole project, and naturally it is also what will make it so hard to leave the Ubuntu community, and the net of on-line communications which it consists of, behind for a while.

Yet that is what I’ll have to do in order to be able to reflect on all that I have learned, seen, and participated in over the last 10 months, I will need to leave the communication channels that the Ubuntu community consists of.

Today Ive unsubscribed from all the Ubuntu mailing-lists, logged off the IRC channels, stopped the wiki page-updates, unsubscribe the Planet RSS feeds, and step down from the Launchpad. I will divert my attention capital elsewhere, to my books, my fieldwork notes and my thesis, but it does not mean that I will stop using Ubuntu or encourage others to do so. I’d like to think that I can still share a bit of the work that happens in the community by using and sharing the system itself.

It’s been really great meeting all of you Ubunteros. You are some of the sweetest, most dedicated and geekiest people I’ve ever met. And I do feel honoured to have gotten to know all of you. I will keep my blog on the Planet Ubuntu, but only posts related directly to Ubuntu will appear here. I do plan to come back to the community once my thesis is done and my university obligations no longer conflict with my newly-found interest and passion for Free Software.

See you in 6 months’ time…

Opening the source

Now that I’ve officially finished my fieldwork, and with all the talk going on about Open Access Anthropology, I thought I’d try my own little Open Access experiment. I’ve decided to publish the question guide I’ve used for my fieldwork under the GPL. I’ve even indented and commented them in proper code fashion (or, at least, as far as I’ve been capable of emulating it).

Also, at suggestion of one of my informants, I’ve answered my own questions to offer my informants and other interested parties a bit more background in my own interest in computers, Ubuntu and the F/OSS world.

One of my hopes in doing this is that more people in the community will find interest in looking at the questions, and possibly even writing up their own answers. If that were to be the case, I would love to see them and incorporate them into my thesis. So send me any answers you feel like writing! 🙂

On Free Software Conferences

When I tell people that I do fieldwork among Free Software developers, I often try to relate it to more traditional anthropological ventures as a way to make it clearer to people what it is I do. Traditionally, anthropologists travelled to the part of the world that used to be colonized and lived among the conquered natives. Seeking to understand their social structures, their values and their rituals – basically their way of life.

So I compare Free Software projects to these native tribes that anthropologists usually study. For it is a community that is built around a common interest in computing and shared values around that interest. The difference is that it is a tribe that is defined not by its association to any specific place but rather by its use of a technology.

For most of the time, the interaction within Free Software projects are shaped by the technology they use – mailing lists, IRC channels, web forums, even VOIP phone calls, but once in a while they gather at conferences to create those real human face-to-face connections that add a vital, physical dimension to the social life of a project.

These ‘tribal gatherings’ have been described as ‘the quintessential hacker vacation’ and reminds me most of all of a (Boys’) Summer Camps. They are intense festivals celebrating all things hackish where the developers gather to wear themselves down with sleep deprivation, cumulative hangover, shared passion for technology and constant social interaction. The conferences offer excellent opportunity to revitalize and energize the developers’ interest and belief in the project.

Conflicts are resolved, plans are laid out, specifications are written, unexpected meetings happen and friends are made. A different degree of collaboration is made possible by the conference as the tribe convenes and for a week or two actually is a temporary village of its own.

This week such a village has been erected by the Ubuntu community at the Google Headquarters in Mountain View, California. More than 160 Ubuntu developers, community members and upstream developers have convened from around the world in order to review and plan the next release of Ubuntu, due in April 2007.

The Ubuntu community differs from many other Free Software projects in their close relationship to Canonical – the company that employs a number of the core Ubuntu developers, drives the tight time based release schedule, and organizes the very focused and professionally planned Ubuntu Developer Summits to which they sponsor a good number of the community members and upstream developers from projects such as KDE, LTSP and GNOME whose work is central to Ubuntu.

This means that a snapshot of the Free Software world as seen from an Ubuntu perspective gathers every six months to collaborate and get to know each other in person – something that often proves to be invaluable when it is augmented through the digital means of communication where a previous awareness of a person’s personality and physical presence can make the difference between understanding and conflict.

Since conferences are such an integral part of Free Software development, the location and organization of the conference is essential, and this got me thinking. With Google hosting this conference, the facilities are generally in very good order. Unfortunately, the hotel where most of the developers are staying are 15 minutes away by bus and the logistic problems of ferrying people back and forth are not insubstantial.

Other conferences in other locations have other problems(such as bad food, bad bandwidth and bad conference facilities) so my thought is: Why not make a hotel specialized for the needs of free software projects? Based on my observations, I’ve drafted up an idealised list of requirements:

– Located close to an easily accessible

What Bikeshed?

Mark Shuttleworth’s recent post on the new gaudy desktop prettiness of Ubuntu has received a good deal of interest and discussion (more than 130 comments and counting).

Pretty much all of that discussion was summed up in one of those comments:

# Murray Cumming Says:
October 25th, 2006 at 7:31 pm

The bikeshed is brown.

The bikeshed in question is this one, and the idea behind it has proven to be one of the most powerful ways of explaining why so much energy is spent on inconsequential nitpicking in F/OSS projects. Especially when it comes to artwork and usability.

Why we have anthropologists

Native speakers can rarely explain the grammatical rules of their own language. In the same way, those who are most ‘fluent’ in the rituals, customs and traditions of a particular culture generally lack the detachment necessary to explain the ‘grammar’ of these practices in an intelligible manner. This is why we have anthropologists.

Kate Fox

I came across this quote in a little book by British popular anthropologist Kate Fox, and though it is a simplistic statement, I kind of like the way it presents anthropologists – it does makes us sound very important, doesn’t it?

Meanwhile, in my field of study, all of the computer people I interview prove to be very reflective and often discuss community structure and governance issues with a fair bit of detachment. So I often end up discussing these topics with them on equal terms. I wonder whether I can still call it anthropology… 🙂

I’m in Oslo this week, interviewing another couple of Ubuntu hackers, and learning even more about how it is to participate in Free Software development. I’m getting to the point where I have so much data that I’m really looking forward to beginning the thesis writing proper and see what sense I can make of all of this.

Installing Ubuntu 6.10

So with the release of the new version of Ubuntu, 6.10 (6 for 2006, 10 for October) I decided that rather than merely upgrading my system from 6.06 to 6.10, I would wipe clean my hard disk, wipe all my desktop settings and try to start afresh to see how long it would take me to get a clean, default install into a position where I’m happy with it.

One of the main reason for starting afresh was to separate my personal files onto another partition so that I easily could reinstall the system another time without risking all of my settings which I find to be such a sane idea that it might be considered for the default.

It worked very well. All I had to do was to create a third partition after the standard 2 (root and swap) and choose that as home in the installer. Easy.

So the installation went without a hitch, until I tried restarting the system without the CD-ROM in the drive and got the dreaded “Hard disk boot sector invalid” error. The system worked fine booting from the CD-ROM and I could then figure out how to reinstall GRUB and make the root partition bootable.

Then I could go on to adding all the extra software I use which isn’t in the default installation, and it for the most part worked really well, partly because I knew exactly which obscure names the applications I wanted were hiding behind, partly because the GNOME application installer just works really well. In general, Ubuntu is reaching the point where it is not just the best Free Software desktop out there, but the best desktop period. Much kudos to the hard working developers – especially those who managed to fulfill their hard work despite of my anthropological nagging and random visits. 🙂

The only issues (apart from the rather unfortunate boot sector debacle) arose when it came to the multimedia bits. With all the licensing issues surrounding the various formats, you’ll need to through a few hoops (and a lot of packages) to get all of it working. It will be nice have some centralized way to do multimedia codec installation in Ubuntu. Though installation of the installation of the kind of proprietary software that is fundamental for Internet use has become a lot easier by making most it available through the GNOME application installer, I really hope that we can make it even easier to make ready by creating a meta-package for it.

All in all, it took me a couple of hours to bring the system into a state where I felt that it was *my* desktop. Another few hours if you include the backing up and the downloading and burning of the CD-ROM. Not bad, but there’s room for plenty of more polish.

Note that all of this is in the “nice to have” category, and that it is the sort of thing that won’t bring developers out left and right to remedy this. But it is the kind of polish that will give people that positive surprise that will make them fall in love with their system. It’s the kind of saying “oh, we know you’d most likely want this as well. So we made it easy for you to get working” that evokes trust in the user. She will think “If they’ve thought about this as well, they must really have spent a lot of time making sure everything is works well.

Designer Emeritus Don Norman has written a wonderful little book on “Emotional Design” which sums up how this emotional relationship between the user and the used object (in this case an operating system) is created. Among other things, he asked people he met about their favourite things and their most positive experiences with technology. One answered:

I still tell people about my experience, years ago, at the Austin Four Seasons Hotel. I checked into my room to find a TV-Guide on the bed, with a bookmark placed on the current date.

Which exactly sums up the kind of positive surprise that good design should deliver. The kind of forethought that makes it a joy to use. For me, when installing Ubuntu 6.10, the surprise came when I saw the new default wallpaper:

Pinkish

There has been a lot of discussion about the new Ubuntu artwork, and the SABDFL has been working hard to impose his vision of a glitzy, saturated look. But this is actually pinkish. And too bright as well. What happened to the proper brown? Hoping for alternatives, a simple right click on the desktop brought up this wonder of chocolate loveliness:

Choc love

And I felt that positive surprise: “Ah! They thought about that after all.” To whoever did that wallpaper: Thank you! I’ll buy you a beer next time I meet you. It is almost edible in its chocolate love!

And that’s the conclusion of Norman’s book as well: Good design not only fits the user’s needs, it also enables the user to make the technology their own, to customize it to their own needs. As Norman quotes Harrison and Dourish:

A space can only be made into a place by its occupants. The best that the designer can do is put the tools into their hands.

This is especially true with computer programs where everything is potentially customizable, and the machine itself has so little emotional value attached to it to begin with. One recent example of appropriating this new space and turning into something personal was on Planet KDE, the aggregated communal blog for the KDE desktop project where a developer wrote about receiving and customizing her new laptop.

There even seems to be a whole F/OSS subculture focused on making the desktop look nice and glittery with all of the latest eye candy, sharing screenshots of their desktops, where people have a place to utter the essential words of Emotional Design: “I want this.”