People know me as an advocate of free software, which is an ethical and political view, but at the same time, I’m a fairly non-technical user and hence often drawn to commercial software which is geared towards consumers. For example, I have used Windows XP for many years, even as I made presentations on peer production and free software. I have switched for some time to Ubuntu, and while it works generally and loads faster, I have a lot more problems with it that I used to have with XP. And even this Linux-Desktop Ubuntu is available because a commercial company, Canonical, decided to puts its weight behind it. I think the key issue is that developers have technical skills, develop free software for their own needs, and have no particular incentive to work for users/consumers with a low skill base.

A related issue occurred recently as well. As I wanted to spread the word about the Berlin Commons Conference, and in particular its videos, I discovered that some of them were done in the open format Ogg Theora. Open yes, but no clear embed feature is available. This means I cannot easily virally spread them to where people are. In this instance, it seems that openness is opposed to sharing, that sticking with a open format actually restricts access.

The conclusion for me is that we still need hybrid modalities, where the strength and weaknesses of open systems, well explained here by Tim Lee, are balanced by commercial entities who have an eye for the needs of users/consumers. The latter do not have to be profit-maximising companies that enclose software and knowledge, like Apple, but can be entities that are friendly to the open commons approach, yet are geared to a marketplace and in need to satisfy those needs.

Below, an explanation of the differential advantages of open vs. closed forms of manufacturing and production.

I actually disagree with the argument that open interfaces are bloated. Rather my own critique is that they always assume that a user has the willingness and time to seek out rather complex solutions, instead of facilitating actions by people with minimum time and knowledge about technical matters. Why should a good driver like me (searcher/content producer), necessarily also be a good mechanic? These qualties do not necessarily go hand in hand. Open systems and free software should take this into account, and not expect everybody to have their own level of expertise. But are open communties structurally aligned to the needs of users/consumers, if they are not structurally dependent on them, as market players are?

(the structural dependency issue is explained well in John Gruber, see below)

Excerpted from Timothy B. Lee:

“There’s been a lot of debate recently about the iPhone/Android competition and the implications for the perennial debate between open and closed technology platforms. In the past I’ve come down fairly decisively on the “open” side of the debate, criticizing Apple’s iPhone App Store and the decision to extend the iPhone’s closed architecture to the iPad.

In the year since I wrote those posts, a couple of things have happened that have caused some evolution in my views: I used a Linux-based desktop as my primary work machine for the first time in almost a decade, and I switched from an iPhone to a Droid X. These experiences have reminded me of an important fact: the user interfaces on “open” devices tend to be terrible.

The power of open systems comes from their flexibility and scalability. The TCP/IP protocol stack that powers the Internet allows a breathtaking variety of devices—XBoxen, web servers, iPhones, laptops and many others— to talk to each other seamlessly. When a new device comes along, it can be added to the Internet without modifying any of the existing infrastructure. And the TCP/IP protocols have “scaled” amazingly well: protocols designed to connect a handful of universities over 56 kbps links now connect billions of devices over multi-gigabit connections. TCP/IP is so scalable and flexible because its designers made as few assumptions as possible about what end-users would do with the network.

These characteristics—scalability and flexibility—are simply irrelevant in a user interface. Human beings are pretty much all the same, and their “specs” don’t really change over time. We produce and consume data at rates that are agonizingly slow by computer standards. And we’re creatures of habit; once we get used to doing things a certain way (typing on a QWERTY keyboard, say) it becomes extremely costly to retrain us to do it a different way. And so if you create an interface that works really well for one human user, it’s likely to work well for the vast majority of human users.

The hallmarks of a good user interface, then, are simplicity and consistency. Simplicity economizes on the user’s scarce and valuable attention; the fewer widgets on the screen, the more quickly the user can find the one she needs and move on to the next step. And consistency leverages the power of muscle memory: the QWERTY layout may have been arbitrary initially, but today it’s supported by massive human capital that dwarfs whatever efficiencies might be achieved by switching to another layout.

To put it bluntly, the open source development process is terrible at this. The decentralized nature of open source development means that there’s always a bias toward feature bloat. If two developers can’t decide on the right way to do something, the compromise is often to implement it both ways and leave the final decision to the user. This works well for server software; an Apache configuration file is long and hard to understand, but that’s OK because web servers mostly interact with other computers rather than people, so flexibility and scalability are more important than user-friendliness. But it tends to work terribly for end-user software, because compromise tends to translate into clutter and inconsistency.

In short, if you want to create a company that builds great user interfaces, you should organize it like Apple does: as a hierarchy with a single guy who makes all the important decisions. User interfaces are simple enough that a single guy can thoroughly understand them, so bottom-up organization isn’t really necessary. Indeed, a single talented designer with dictatorial power will almost always design a simpler and more consistent user interface than a bottom-up process driven by consensus.

This strategy works best for products where the user interface is the most important feature. The iPod is a great example of this. From an engineering perspective, there was nothing particularly groundbreaking about the iPod, and indeed many geeks sneered at it when it came out. What the geeks missed was that a portable music player is an extremely personal device whose customers are interacting with it constantly. Getting the UI right is much more important than improving the technical specs of adding features.”

2. John Gruber: The Open Source Usability Problem is Structural

“The undeniable truth is this: successful open source software projects tend to be at the developer-level, not the end-user level. I.e., successful open source projects have programming interfaces, not user interfaces. Apache, Perl, Python, GCC, PHP, the various SQL databases. The list of fantastic open source developer software is long.

The list of fantastic open source GUI software is short. This is not a function of chance.

The open source revolution has done nothing to change the fact that the best-designed, most-intuitive user interfaces are found in closed-source commercial software.

I’m not saying all commercial software is well-designed, nor that all free software is poorly-designed — what I’m saying is that software that does provide a well-designed, intuitive interface tends to be closed and commercial. The bigger the software, the more likely this is to be true.

The most obvious explanation is that the open source model does not work well for producing software with good usability. Everything in Raymond’s article hints at this truth. (Not to mention MPT’s aforementioned essay, which addresses this directly.)

Good user interfaces result from long, hard work, by talented developers and designers.

The distributed, collaborative nature of open source software works for developer-level software, but works against user-level software. Imagine a motion picture produced like a large open source project. Different scenes written and directed by different people, spread across the world. Editing decisions forged by group consensus on mailing lists. The result would be unfocused, incoherent, and unenjoyable.

Movies are collaborative art, but require strong direction. So it is with end user software.”