Category: design

Free as in … ? My LibrePlanet 2016 talk

Luis Villa12 Comments
Speaker in a classroom in front of a slide. The slide is plain text and reads “imagine a world in which every single human being is liberated by software”

Below is the talk I gave at LibrePlanet 2016. The tl;dr version:

  • Learning how political philosophy has evolved since the 1670s shows that the FSF’s four freedoms are good, but not sufficient.
  • In particular, the “capability approach” pioneered by Amartya Sen and Martha Nussbaum is applicable to software, and shows us how to think about improving the capability of people.
  • There are a bunch of ways that free software, as a movement, could refocus on liberating people, not code.

I did not talk about it in the talk (given the audience), but I think this approach is broadly applicable to every software developer who wants to make the world a better place (including usability-inclined developers, open web/standards folks, etc.), not just FSF members.

I was not able to use my speaker notes during the talk itself, so these may not match terribly well with what I actually said on Saturday – hopefully they’re a bit more coherent. Video will be posted here when I have it. [Update: video here.]

Most of you will recognize this phrase as borrowed from the Wikimedia Foundation. Think on it for a few seconds, and how it differs from the Four Freedoms.

I’d like to talk today about code freedom, and what it can learn from modern political philosophy.

Last time I was at Libre Planet, I was talking with someone in a hallway, and I mentioned that Libre Office had crashed several times while I was on the plane, losing some data and making me redo some slides. He insisted that it was better to have code freedom, even when things crashed in a program that I could not fix without reading C++ comments in German. I pointed out, somewhat successfully, that software that was actually reliable freed me to work on my actual slides.

We were both talking about “freedom” but we clearly had different meanings for the word. This was obviously unsatisfying for both of us – out common language/vocabulary failed us.

This is sadly not a rare thing: probably many of us have had the same conversation with parents, friends, co-workers, etc.

So today I wanted to dig into “freedom” – what does it mean and what frameworks do we hang around it.

So why do we need to talk about Freedom and what it means? Ultimately, freedom is confusing. When card-carrying FSF members use it, we mean a very specific thing – the four freedoms. When lots of other people use it, they mean… well, other things. We’ll get into it in more detail soon, but suffice to say that many people find Apple and Google freeing. And if that’s how they feel, then we’ve got a very big communication gap.

I’m not a political philosopher anymore; to the extent I ever was one, it ended when I graduated from my polisci program and… immediately went to work at Ximian, here in Boston.

My goal here today is to show you that when political philosophers talk about freedom, they also have some of the same challenges we do, stemming from some of the same historical reasons. They’ve also gotten, in recent years, to some decent solutions – and we’ll discuss how those might apply to us.

Apologies if any of you are actually political philosophers: in trying to cram this into 30 minutes, we’re going to take some very, very serious shortcuts!

Let’s start with a very brief introduction to political philosophy.

Philosophers of all stripes tend to end up arguing about what is “good”; political philosophers, in particular, tend to argue about what is “just”. It turns out that this is a very slippery concept that has evolved over time. I’ll use it somewhat interchangeably with “freedom” in this talk, which is not accurate, but will do for our purposes.

Ultimately, what makes a philosopher a political philosopher is that once they’ve figured out what justice might be, they then argue about what human systems are the best ways to get us to justice.

In some sense, this is very much an engineering problem: given the state of the world we’ve got, what does a better world look like, and how do we get there? Unlike our engineering problems, of course, it deals with the messy aspects of human nature: we have no compilers, no test-driven-development, etc.

So before Richard Stallman, who were the modern political philosophers?

Your basic “intro to political philosophy” class can have a few starting points. You can do Plato, or you can do Hobbes (the philosopher, not the tiger), but today we’ll start with John Locke. He worked in the late 1600s.

Locke is perhaps most famous in the US for having been gloriously plagiarized by Thomas Jefferson’s “life, liberty, and pursuit of happiness”. Before that, though, he argued that to understand what justice is, you have to look at what people are missing when they don’t have government. Borrowing from earlier British philosophers (mostly Hobbes), he said (in essence) that when people have no government, everyone steals from – and kills – everyone else. So what is justice? Well, it’s not stealing and killing!

This is not just a source for Jefferson to steal from; it is perhaps the first articulation of the idea that every human being (at least, every white man) is entitled to certain inalienable rights – what are often called the natural rights.

This introduces the idea that individual freedom (to live, to have health, etc.) is a key part of justice.

Locke was forward-thinking enough that he was exiled to the Netherlands at one point. But he was also a creature of his time, and concluded that monarchy could be part of a just system of government, as long as the people “consented” by, well, not immigrating.

This is in some sense pretty backwards, since in 1600s Europe, emigration isn’t exactly easy. But it is also pretty forward looking – his most immediate British predecessor, Hobbes, basically argued that Kings were great. So Locke is one of the first to argue that what the people want (another aspect of what we now think of as individual freedom) is important.

It is important to point out that Locke’s approach is what we’d now call a negative approach to rights: the system (the state, in this case) is obligated to protect you, but it isn’t obliged to give you anything.

Coming from the late 1600s, this is not a crazy perspective – most governments don’t even do these things. For Locke to say “the King should not take your stuff” is pretty radical; to have said “and it should also give you health care” would have also made him the inventor of science fiction. And the landed aristocracy are typically fans!

(Also, apologies to my typographically-sensitive friends; kerning of italicized fonts in Libre Office is poor and I got lazy around here about manually fixing it.)

But this is where Locke starts to fall down to modern ears: if you’re not one of the landed aristocracy; if you’ve got no stuff for the King to take, Locke isn’t doing much for you. And it turns out there are a whole lot of people in 1600s England without much stuff to take.
So let’s fast forward 150+ years.

You all know who Marx is; probably many of you have even been called Marxists at one point or another!

Marx is complicated, and his historical legacy even more so. Let’s put most of that aside for today, and focus on one particular idea we’ve inherited from Marx.

For our purposes, out of all of Marx, we can focus on the key insight that people other than the propertied class can have needs.(This is not really his insight; but he popularizes it.) I

Having recognized that humans have needs, Marx then goes on to propose that, in a just society, the individual might not be the only one who has a responsibility to provide those needs – the state, at least when we reach a “higher phase” of economic and moral development, should also provide.

This sounds pretty great on paper, but it is important to grok that Marx argues that his perfect system will happen only when we’ve reached such a high level of economic development that no one will need to work, so everyone will work only on what they love. In other words, he ignores the scarcity we face in the real world. He also ignores inequality – since the revolution will have washed away all starting differences. Obviously, taken to this extreme, this has led to a lot of bad outcomes in the world – which is what gives “marxism” its bad name.

But it is also important to realize that this is better than Locke (who isn’t particularly concerned with inequality), and in practice the idea (properly moderated!) has led to the modern social welfare state. So it is a useful tool in the modern philosophical toolkit.

Fast forward again, another 100 years. Our scene moves down the street, to Harvard. Perhaps the two most important works of political philosophy of the 20th century are written and published within four years of each other, further up Mass Avenue from MIT.

John Rawls publishes his Theory of Justice in 1971; Robert Nozick follows up with his Anarchy, the State, and Utopia in 1974.

Rawls and Nozick, and their most famous books, differ radically in what they think of as justice, and what systems they think lead to the greatest justice. (Nozick is the libertarian’s libertarian; Rawls more of a welfare-state type.) Their systems, and the differences between them, are out of our scope today (though both are fascinating!).

However, both agree, in their ways, that any theory of a just world must grapple with the core fact that modern societies have a variety of different people, with different skills, interests, backgrounds, etc. (This shouldn’t be surprising, given that both were writing in the aftermath of the 60s, which had made so clear to many that our societies were pretty deeply unjust to a lot of people.)

This marks the beginning of the modern age of political philosophy: Locke didn’t care much about differences between people; Marx assumed it away. Nozick and Rawls can be said, effectively, to mark the point when political philosophy starts taking difference seriously.

But that was 40 years ago – what has happened since then?

So that brings us to the 1990s, and also to 2016. (If you haven’t already figured it out, political philosophy tends to move pretty slowly.)

The new-ish hotness in political philosophy is something called capability theory. The first work is put forward by Amartya Sen, an Indian economist working with (among others) the United Nations on how to focus their development work. Martha Nussbaum then picked up the ball, putting in a great deal of work to systematize it.

When Sen starts working on what became capability theory, he’s a development economist trying to help understand how to help improve the lives of his fellow Indian citizens. And he’s worried that a huge focus on GDP is not leading to very good outcomes. He turns to political theory, and it doesn’t help him: it is focused on very abstract systems. John Locke saying “life, liberty, property” and “sometimes monarchs are OK” doesn’t help him target the UN’s investment dollars.

So his question becomes: how do I create a theory of What is Just that actually helps guide decisions in the real world? Capability theory, in other words, is ultimately pragmatic.

To put it another way, you can think of the capability approach as an attempt to figure out what effective freedom is: how do we take freedom out of textbooks and into something that really empowers people?

One of the key flaws for Sen of existing theories was that they talked about giving people at worst, negative rights (protecting their rights to retain property they didn’t have) and at best, giving them resources (giving them things or training they couldn’t take advantage of). He found this unconvincing, because in his experience India’s constitution gave all citizens those formal rights, but often denied them those rights in practice, through poverty, gender discrimination, caste discrimination, etc.

And so from this observation we have the name of the approach: it focuses on what, pragmatically, people need to be capable of acting freely.

Some examples may be helpful here to explain what Sen and Nussbaum are getting at.

For example, if all men and women have the same formal access to education, but women get fewer job callbacks after college than men with identical resumes, or men refuse to care for children and aging parents, then it seems unlikely that we can really claim to have a just society.

Somalia, circa 1995-2000, was, on the face of it, a libertarian paradise: it gave you a lot of freedom to start businesses! No minimum wage, no EPA.

But it turns out you need more than “freedom from government interference” to run a business: you have to have a lot of other infrastructure as well. (Remember, here, Locke’s “negative” rights: government not stopping you, v. government supporting you.)

These examples suggest that answering political philosopher question #1 (“what is justice?”) requires more than just measuring access to resources. What you want to know to understand whether a system is just, you have to measure whether all people have the opportunity to get to the important goals.

In other words, do they have the capability to act?

This is the core insight that the capabilities approach is grounded in: it is helpful, but not enough, to say “someone has the natural rights” (Locke) or “some time in the future everyone will have the same opportunity” (Marx).

(Is any of this starting to ring a bell?)

Capability approach is, again, very pragmatic, and comes from a background of trying to allocate scarce development resources in the real world, rather than a philosopher’s cozy university office. So if you’re trying to answer the political philosopher’s question (“what system”), you need to pick and choose a few capabilities to focus on, and figure out what system will support those capabilities.

Again, an example might be helpful here to show how picking the right things to focus on can be important when you’re aiming to build a system that supports human capability.

If you focus on only one dimension, you’re going to get things confused. When Sen was beginning his work, the development community tended to focus exclusively on GDP. Comparing the Phillippines and South Africa by this number would have told you to focus your efforts on the Philippines.

But  one of the most basic requirements to effective freedom – to supporting people’s capability to act – is being alive! When we look at it through that lens, we pretty quickly see that South Africa is worth more energy. It’s critical to look through that broader lens to figure out whether your work is actually building human freedom.

This is, perhaps, the most contentious area of capability theory – it’s where writing is being done across a variety of disciplines, including economics, political philosophy, sociology, and development. This writing has split into two main areas: the pragmatists, who just want to figure out useful tools that help them improve the world, and the theorists, who want to ground the theory in philosophy (sometimes as far back as Aristotle).

This is a great place to raise Martha Nussbaum again: she’s done the most to bring theoretical rigor to the capability approach. (Some people call Sen’s work the “capability approach”, to show that it is just a way of thinking about the problem; and Nussbaum’s work “capability theory”, to show that it is a more rigorous approach.)

I have bad news: there is no one way of doing this. Some approaches can include:

  • Local nuance: What is valued and important in one culture may not be in another; or different obstacles may exist in different places and times. Nussbaum’s work particularly focuses on this, interviewing people both to find criteria that are particularly relevant to them, but also to attempt to identify global values.
  • Democracy: Some of Sen’s early research showed that democracies were better at getting people food than non-democracies of similar levels of economic development, leading to avoidance of famines. So “what people prioritize based on their votes” is a legitimate way to understand the right capabilities to focus on.
  • Data: you’ll almost never see a table like the one I just showed you in most political philosophy! The capability approach embraces the use of data to supplement our intuitions and research.
  • Old-fashioned philosophizing: it can be perfectly appropriate to sit down, as Richard did, and noodle over our problems. I tend to think that this is particularly important when we’re identifying future capabilities – which is of course our focus here.

Each of these can be seen as overlapping ways of identifying the best issues to identify – all of them will be useful and valid in different domains.

Shared theme of that last slide? Thinking primarily about people. Things are always a means to an end in the capability approach – you might still want to measure them as an important stepping stone to helping people (like GDP!) but they’re never why you do something.

There is no one right way to pick which capabilities to focus on, which drives lots of philosophers mad. We’ll get into this in more detail soon – when I talk about applying this to software.

Probably the bottom line: if you want to know how to get to a more just system, you want to ask about the capabilitiesof the humans who are participating in that system. Freedom is likely to be one of the top things people want – but it’s a means, not the end.

So now we’ve come to the end of the philosophy lecture. What does this mean for those of us who care about software?

So, again, what do political philosophers care about?

The FSF’s four freedoms try to do the right thing and help build a more just world.

If you don’t have some combination of time, money, or programming skills, it isn’t entirely clear the four freedoms do a lot for you.

The four freedoms are negative rights: things no one can take away from you. And that has been terrific for our elites: Locke’s landed aristocracy is our Software as a Service provider, glad the King can’t take away his right to run MySQL. But maybe not so much for most human beings.
This brings us to our second question – what system?

Inspired by the capability approach, what I would argue that we need is a focus on effective freedom. And that will need not just a change to our focus, but to our systems as well – we need to be pragmatic and inclusive.

So let me offer four suggestions for free software inspired by the capability approach.

We need to start by having empathy for all our users, since our goal should be software that liberates all people.

Like the bureaucrat who increases GDP while his people die young, if we write billions of lines of code, but people are not empowered, we’ve failed. Empathy for others will help us remember that.

Sen, Nussbaum, and the capability approach also remind us that to effectively provide freedom to people we need to draw opinions and information from the broadest possible number of people. That can simply take the form of going and listening regularly to why your friends like the proprietary software they use, or ideally listening to people who aren’t like you about why they don’t use free software. Or it can take the form of surveys or even data-driven research. But it must start with listening to others. Scratching our own itch is not enough if we want to claim we’re providing freedom.

Or to put it another way: our communities need to be as empowering as our licenses. There are lots of great talks this weekend on how to do that – you should go to them, and we should treat that as philosophically as important as our licenses.

I think it is important to point out that I think the FSF is doing a lot of great work in this area – this is the most diversity I’ve seen at Libre Planet, and the new priorities list covers a lot of great ground here.

But it is also a bad sign that at the new “Open Source and Feelings” conference, which is specifically aimed at building a more diverse FOSS movement, they chose to use the apolitical “open” rather than “free”. That suggests the FSF and free software more generally still have a lot of work to do to shed their reputation as being dogmatic and unwelcoming.

Which brings me to #2: just as we have to listen to others, we have to be self-critical about our own shortcomings, in order to grapple with the broad range of interests those users might have.

At the begining of this talk, I talked about my last visit to Libre Planet, and how hard it was to have a conversation about the disempowerment I felt when Libre Office crashed. The assumption of the very well-intentioned young man I was talking to was that of course I was more free when I had access to code. And in a very real way, that wasn’t actually true – proprietary software that didn’t crash was actually more empowering to me than libre software that did crash. And this isn’t just about crashing/not-crashing.

Ed Snowden reminded us this morning that Android is freely-licensed, but that doesn’t mean it gives them the capability to live a secure life.

Again, here, FSF has always done some of the right thing! You all recognize this quote: it’s from freedom zero. We often take pride in this, and we should!

But we also often say “we care about users” but only test what the license is. I’ve never seen someone say “this is not free, because it is impossible to use” – it is too easy, and too frequent, to say “well, the license says you can run the program as you wish, so it passes freedom zero”. We should treat that as a failure to be humble about.

Humility means admitting our current. unidimensional systems aren’t great at empowering people. The sooner we admit that freedom is complex, and goes beyond licensing, the quicker we can build better systems.

The third theme of advice I’d give is to think about impact. Again, this stems from the fundamental pragmatism of the capability approach. A philosophy that is internally consistent, but doesn’t make a difference for people, is not a useful philosophy. We need to take that message to heart.

Mako Hill’s quantitative research has shown us that libre code doesn’t necessarily mean quality code, or sucessful projects. If we want to impact users, we have to understand why our core development tools are no longer best-in-class, and fix them, or develop new models to replace them.

We built CVS, SVN, and git, and we used those tools to build some of the most widely-used pieces of software on earth. But it took the ease of use of github to make this accessible to millions of developers.

Netsplit.de is a search engine for IRC services. Even if both of these numbers are off by a factor of two (say, because of private networks missing from the IRC count, and if Slack is inflating user counts), it still suggests Slack will have more users than IRC this year. We need to think about why that is, and why free software like IRC hasn’t had the impact we’d like it to.

If we’re serious about spreading freedom, this sort of “post-mortem” of our successes and failures is not optional – it is a mandatory part of our commitment to freedom.

I’ve mentioned that democracy is one way of choosing what capabilities to focus on, and is typically presumed in serious analyses of the capability approach – the mix of human empowerment and (in Sen’s analysis) better pragmatic impact make it a no-brainer.

A free software focused on impact could make free licensing a similar no-brainer in the software world.

Dan Gillmor told us this morning that “I came for the technical excellence and stayed for the freedom”: as both he and Edward Snowden said this morning, we have to have broaden our definition of technical excellence to include usability and pragmatic empowerment. When we do that, our system – the underlying technology of freedom – can lead to real change.

This is the last, and hardest, takeaway I’ll have for the day.

We’ve learned from the capability approach that freedom is nuanced, complex, and human-focused. The four freedoms, while are brief, straightforward, and easy to apply, but those may not be virtues if our goal is to increase user freedom.

As I’ve said a few times, the four freedoms are like telling you the king can’t take your property: it’s not a bad thing, but it also isn’t very helpful if you don’t have any property.

We need to re-interpret “run the program as you wish” in a more positive light, expanding our definitions to speak to the concerns about usability and security that users have.

The capability approach provides us with questions – where do we focus? – but not answers. So it suggests we need to go past licensing, but doesn’t say where those other areas of focus might be. Here are some suggestions for what directions we might evolve free software in.

Learning from Martha Nussbaum and usability researchers, we could work with the next generation of software users to understand what they want, need, and deserve from effective software freedom.

We could learn from other organizations, like UNICEF, who have built design and development principles. The graphic here is from UNICEF’s design principles, where they talk about how they will build software that improves freedom for their audience.

It includes talk about source code – as part of a coherent whole of ten principles, not an end in and of itself.

Many parts of our community (including FSF!) have adopted codes of conduct or similar policies. We could draw on the consistent themes in these documents to identify key values that should take their place alongside the four freedoms.

Finally, we can vote with our code: we should be contributing where we feel we can have the most impact on user freedom, not just code freedom. That is a way of giving our impact: we can give our time only to projects that empower all users. In my ideal world, you come away determined to focus on projects that empower all people, not just programmers.

Ultimately, this is my vision, and why I remain involved in free software – I want to see people who are liberated. I hope after this talk you all understand why, and are motivated to help it happen.
Thanks for listening.

Further reading:

Image sources and licenses (deck itself is CC BY-SA 4.0):

 

 

Reinventing FOSS user experiences: a bibliography

Luis Villa3 Comments

There is a small genre of posts around re-inventing the interfaces of popular open source software; I thought I’d collect some of them for future reference:

Recent:

Older:

The first two (Drupal, WordPress) are particularly strong examples of the genre because they directly grapple with the difficulty of change for open source projects. I’m sure that early Firefox and VE discussions also did that, but I can’t find them easily – pointers welcome.

Other suggestions welcome in comments.

Software that liberates people: feels about FSF@30 and OSFeels@1

Luis Villa12 Comments

tl;dr: I want to liberate people; software is a (critical) tool to that end. There is a conference this weekend that understands that, but I worry it isn’t FSF’s.

Feelings are facts, by wrote, CC BY 2.0

This morning, social network chatter reminded me of FSF‘s 30th birthday celebration. These travel messages were from friends who I have a great deal of love and respect for, and represent a movement to which I essentially owe my adult life.

Despite that, I had lots of mixed feels about the event. I had a hard time capturing why, though.

While I was still processing these feelings, late tonight, Twitter reminded me of a new conference also going on this weekend, appropriately called Open Source and Feelings. (I badly wanted to submit a talk for it, but a prior commitment kept me from both it and FSF@30.)

I saw the OSFeels agenda for the first time tonight. It includes:

  • Design and empathy (learning to build open software that empowers all users, not just the technically sophisticated)
  • Inclusive development (multiple talks about this, including non-English, family, and people of color) (so that the whole planet can access, and participate in developing, open software)
  • Documentation (so that users understand open software)
  • Communications skills (so that people feel welcome and engaged to help develop open software)

This is an agenda focused on liberating human beings by developing software that serves their needs, and engaging them in the creation of that software. That is incredibly exciting. I’ve long thought (following Sen and Nussbaum’s capability approach) that it is not sufficient to free people; they must be empowered to actually enjoy the benefits of that freedom. This is a conference that seems to get that, and I can’t wait to go (and hopefully speak!) next year.

The Free Software Foundation event’s agenda:

  • licenses
  • crypto
  • boot firmware
  • federation

These are important topics. But there is clearly a difference in focus here — technology first, not people. No mention of community, or of design.

This difference in focus is where this morning’s conflicted feels came from. On the one hand, I support FSF, because they’ve done an incredible amount to make the world a better place. (OSFeels can take open development for granted precisely because FSF fought so many battles about source code.) But precisely because I support FSF, I’d challenge it, in the next 15 years, to become more clearly and forcefully dedicated to liberating people. In this world, FSF would talk about design, accessibility, and inclusion as much as licensing, and talk about community-building protocols as much as communication protocols. This is not impossible: LibrePlanet had at least some people-focused talks (e.g.), and inclusion and accessibility are a genuine concern of staff, even if they didn’t rise to today’s agenda. But it would still be a big change, because at the deepest level, it would require FSF to see source code as just one of many requirements for freedom, rather than “the point of free software“.

At the same time, OSFeels is clearly filled with people who see the world through a broad, thoughtful ethical lens. It is a sad sign, both for FSF and how it is perceived, that such a group uses the deliberately apolitical language of openness rather than the language of a (hopefully) aligned ethical movement — free software. I’ll look forward to the day (maybe FSF’s 45th (or 31st!) birthday) that both groups can speak and work together about their real shared concern: software that liberates people. I’d certainly have no conflicted feelings about signing up for a conference on that :)

Why feed reading is an open web problem, and what browsers could do about it

Luis Villa43 Comments

I’ve long privately thought that Firefox should treat feed reading as a first-class citizen of the open web, and integrate feed subscribing and reading more deeply into the browser (rather than the lame, useless live bookmarks.) The impending demise of Reader has finally forced me to spit out my thoughts on the issue. They’re less polished than I like when I blog these days, but here you go – may they inspire someone to resuscitate this important part of the open web.

What? Why is this an open web problem?

When I mentioned this on twitter, an ex-mozillian asked me why I think this is the browser’s responsibility, and particularly Mozilla’s. In other words – why is RSS an open web problem? why is it different from, say, email? It’s a fair question, with two main parts.

First, despite what some perceive as the “failure” of RSS, there is obviously  a demand by readers to consume web content as an automatically updated stream, rather than as traditional pages.1 Google Reader users are extreme examples of this, but Facebook users are examples too: they’re no longer just following friends, but companies, celebrities, etc. In other words, once people have identified a news source they are interested in, we know many of them like doing something to “follow” that source, and get updated in some sort of stream of updates. And we know they’re doing this en masse! They’re just not doing it in RSS – they’re doing it in Twitter and Facebook. The fact that people like the reading model pioneered by RSS – of following a company/news source, rather than repeatedly visiting their web site – suggests to me that the widely perceived failure of RSS is not really a failure of RSS, but rather a failure of the user experience of discovering and subscribing to RSS.

Of course, lots of things are broadly felt desires, and aren’t integrated into browsers – take email for example. So why are feeds different? Why should browsers treat RSS as a first-class web citizen in a way they don’t treat other things? I think that the difference is that if closed platforms (not just web sites, but platforms) begins to the only (or even best) way to experience “reading streams of web content”, that is a problem for the web. If my browser doesn’t tightly integrate email, the open web doesn’t suffer. If my browser doesn’t tightly integrate feed discovery and subscription, well, we get exactly what is happening: a mass migration away from consuming (and publishing!) news through the open web, and instead it being channeled into closed, integrated publishing and subscribing stacks like FB and Twitter that give users a good subscribing and reading experience.

To put it another way: Tantek’s definition of the open web (if I may grotesquely simplify it) is a web where publishing content, implementing software that consumes that content, and accessing the content is all open/decentralized. RSS2 is the only existing way to do stream-based reading that meets these requirements. So if you believe (as I do) that reading content delivered in a stream is a central part of the modern web experience, then defending RSS is an important part of defending the open web.

So that’s, roughly, my why. Here’s a bunch of random thoughts on what the how might look like:

Discovery

When you go to CNN on Facebook, “like” – in plain english, with a nice icon – is right up there, front and center. RSS? Not so much. You have to know what the orange icon means (good luck with that!) and find it (either in the website or, back in the day, in the browser toolbar). No wonder no one uses it, when there is no good way to figure out what it means. Again, the failure is not the idea of feeds- the failure is in the way it was presented to users. A browser could do this the brute-force way (is there an RSS feed? do a notice bar to subscribe) but that would probably get irritating fast. It would be better to be smart about it. Have I visited nytimes.com five times today? Or five days in a row? Then give me a notice bar: “hey, we’ve noticed you visit this site an awful lot. Would you like to get updates from it automatically?” (As a bonus, implementing this makes your browser the browser that encourages efficiency. ;)

Subscription

Once you’ve figured out you can subscribe, then what? As it currently stands, someone tells you to click on the orange icon, and you do, and you’re presented with the NASCAR problem, made worse because once you click, you have to create an account. Again, more fail; again, not a problem inherent in RSS, but a problem caused by the browser’s failure to provide an opinionated, useful default.

This is not an easy problem to solve, obviously. My hunch is that the right thing to do is provide a minimum viable product for light web users – possibly by supplementing the current “here are your favorite sites” links with a clean, light reader focused on only the current top headlines. Even without a syncing service behind it, that would still be helpful for those users, and would also encourage publishers to continue treating their feeds as first-class publishing formats (an important goal!).

Obviously solving the NASCAR problem is still hard (as is building a more serious built-in app), but perhaps the rise of browser “app stores” and web intents/web activities might ease it this time around.

Other aspects

There are other aspects to this – reading, social, and provision of reading as a service. I’m not going to get into them here, because, well, I’ve got a day job, and this post is a month late as-is ;) And because the point is primarily (1) improving the RSS experience in the browser needs to be done and (2) some minimum-viable products would go a long way towards making that happen. Less-than-MVPs can be for another day :)

  1. By “RSS” and “feeds” in this post, I really mean the subscribing+reading experience; whether the underlying tech is RSS, Atom, Activity Streams, or whatever is really an implementation detail, as long as anyone can publish to, and read from them, in distributed fashion. [↩]
  2. again, in the very broad sense of the word, including more modern open specifications that do basically the same thing [↩]

Format(ting?) of Forever

Luis Villa18 Comments

Mark Pilgrim had a great post1 a little while ago where he talked about Docbook as ‘The Format of Forever’, but HTML as the ‘Format of Now.’ He also argued that (since technical books were constantly outdated) generating technical books in the Format of Now instead of the Format of Forever made a lot of sense.

I’m working on a project that I’d like to see as a long-term, Format of (nearly) Forever kind of work. Specifically, it is my grandfather’s autobiography, which I’d like to see as a long-term enough work that I can give it to my own grandkids some day. As a result, I’ve been wrestling on and off with two questions: (1) what is the right ‘Format of Forever’ and (2) once you’ve chosen that source format, what is the best ‘Output Format of Now’? Thoughts welcome in comments; my own mumblings below.

Great-great-grandpa Lewis Hannum.

Grandpa, of course, wrote in the ultimate in formats of forever: typewriter. I scanned and OCRed it shortly after he passed away using the excellent gscan2pdf2, and have been slowly collecting other materials to use to supplement what he wrote – mostly pictures and scans of his Apollo memorabilia, but also family photos, like Grandpa’s Grandpa, Lewis Hannum, pictured above.

I’ve converted that to what I think may be the right ‘Format of Forever’: pandoc markdown, plus printed, easily re-scannable hard-copy. I’m thinking that markdown is the right source for a couple of reasons. Primarily: plain, simple ASCII text is hard to beat for future-proofing. Markdown is also easier to edit than HTML3.

The downside with markdown is that, while markdown is terrific for a very simple document (like grandpa’s writing is) I’d like to experiment with some slightly non-traditional media inclusion. For example, it would be nice to include an audio recording of my brother at the 1982 Columbia Shuttle launch, or a scan of Grandpa’s patent. Markdown has some facilities for including other files, but they appear to be non-standard (i.e., each post-processor handles them differently). Even image inclusion and basic formatting often feels wonky. HTML would make me happier in that direction, I suspect. And of course styling the output is a pain, though I think I have various ideas on how to do that.

Thoughts? Tips?

  1. vanished since I originally drafted this, but link kept for reference [↩]
  2. Which, for the record, was roughly 1,000 times better than Canon’s bundled scanning crapware. [↩]
  3. which is sort of pathetic; how come we still don’t have a decent simple HTML editor? [↩]

A Quick Note on Conspicuous Text, also known as ALL CAPS

Luis Villa32 Comments

[Quick followup: (1) Matthew Butterick, of Typography for Lawyers fame, has added a thoughtful comment that anyone reading the post should read; and (2) to be clear, nothing here is my original work or thought – it’s all a convenient, collect-in-one-place paraphrase of ideas from the excellent Manual of Style for Contract Drafting and Typography for Lawyers, both of which should be on the desk of every corporate lawyer.]

Anil Dash asked about ALL CAPS Friday, and then someone in my (very fun) letterpress class at the San Francisco Center for the Book asked me a related question. So here is a quick post on the lovely subject of ALL CAPS.

A copy of the MPL with yellow text instead of ALL CAPS.

The basic question: Why do lawyers use so much ALL CAPS and what can a normal human being do about it?

Some laws require that text in a form or contract be “conspicuous” – i.e., that they be made harder to miss. The most common example of this, in the US, are requirements that disclaimers of warranty1 be conspicuous, so that consumers don’t miss them. You’ve all seen these blocks, and most of you have skipped over them. In the US, the law that requires conspicuous text for warranty disclaimers is typically a descendant of the Uniform Commercial Code (“UCC”) § 2-316.2 Practically speaking, this kind of requirement makes sense – it highlights areas that legislators have decided are particularly important and so can’t be hidden in the nooks and crannies of a document.

Unfortunately, historically, the only easy way for lawyers to make text “conspicuous” on a typewriter was ALL CAPS. Unfortunately, at some point along the way, many lawyers confused the technology (typewriters) for what was actually legally required. And so this is where we stand now – many lawyers will insist that ALL CAPS are required, when they really aren’t.

So if not ALL CAPS, what actuallyisrequired? This varies from rule to rule, unfortunately. But in the UCC, conspicuous is defined as text a reasonable person “ought to have noticed”, which includes:

“(A) a heading in capitals equal to or greater in size than the surrounding text, or in contrasting type, font, or color to the surrounding text of the same or lesser size; and

(B) language in the body of a record or display in larger type than the surrounding text, or in contrasting type, font, or color to the surrounding text of the same size, or set off from surrounding text of the same size by symbols or other marks that call attention to the language.”

(From UCC 1-201(b)(10); same text also appears in UCC 2-103(1)(b)(i).)

The Mozilla Public License, which I recently led the revision of, uses two different approaches, both supported by the UCC’s definition of conspicuous text. In our HTML version, we use text “in contrasting … color to the surrounding text of the same size” – i.e., we color it yellow. (When printed, this comes out as a box around the text.) In our plain text version, we use text “set off … by symbols .. that call attention to the language.” In other words, we use hyphens and vertical bars (|) to draw a box around the text.

So that’s the bottom line answer: in many cases (and certainly in the most common use case by American commercial lawyers), ALL CAPS isn’t required; instead, something “conspicuous” is – which could mean using symbols, colors, font size, or any number of other typographical tricks to make things both visible and easier to read.

Is This Always The Case?

Unfortunately, while most American statutes in this area appear to follow the UCC and require “conspicuous” text, defined quite broadly, this isn’t always true. An interesting list of such exceptions is in the comments to this blog post. These are exceptions; not the rule, but lawyers should be aware of them. Many of the exceptions, interestingly, are where writers of rules have included text that must be included precisely in a form or contract, and the rule-writers have INCLUDED TEXT THAT IS ALL CAPS in their draft text. That is often bad form – but it’s important to follow the rules in such cases.

Citations That Are More Authoritative Than This Blog Post

You’re saying “this is all very interesting, Luis, but I can’t give your random blog post to my lawyer next time he tells me that my Terms of Use need ALL CAPS.” Well, here are what lawyers consider the best kind of citation – a citation to printed books with page numbers, one of them even a publication of the American Bar Association.

“A Manual of Style for Contract Drafting,” Ken Adams, at 15.32-15.41.

“Typography for Lawyers,” Matthew Butterick, at 86-89.

Each of these say (often with more style and detail than I’ve said here) basically the same thing – use ALL CAPS sparingly, if at all. To get a flavor for each of them without buying the books (though I think every commercial lawyer should have both of these books on their desks) the authors have each blogged on these subjects: Adams’ blog post is here and Butterick’s is here.

So Why Do Lawyers Still Use ALL CAPS?

Because we’re risk-averse. Until judges, legislators or our clients demand that we change, we will stick with what works (or perhaps more accurately in this case, we will stick with that hasn’t yet failed).

There are the occasional signs that judges are starting to wake up to the issue: In re Bassett, 285 F.3d 882 (9th Cir. 2002) says “Lawyers who think their caps lock keys are instant “make conspicuous” buttons are deluded”; Stevenson v. TRW, Inc., 987 F.2d 288 (5th Cir. 1993) endorses use of bold or larger type rather than ALL CAPS; and  California courts have even held that ALL CAPS text in an inconspicuous location in the document may not be conspicuous even though it is in ALL CAPS. Broberg v. Guardian Life Ins. Co. of America, 171 Cal. App. 4th 912, 922 (2009).

The judicial situation is helpful, but realistically, until more clients demand it, it’s not going to change. So here you go. :)

 

  1. i.e., the part where the contract says “this product I’m selling you could well be broken or unusable, and that isn’t my problem” [↩]
  2. The UCC is a ‘model code’ – basically, states copy the UCC, edit it as they see fit, and then use that for their own commercial code. e.g., UCC 2-316, in California, becomes California Commercial Code 2316, with similar but not necessarily identical text. [↩]

do “open UIs suck”? or do “UIs without vision suck”?

Luis Villa32 Comments

Tim Lee is quite close to something very smart here, I think, and related to something I’ve been pondering for a while: why are so many open source software UIs typically bad?

Tim’s primary  answer, I think, not wrong: good design generally results from having a strong vision of what good design for a particular piece of software should be. “Cult-like” may be overstating it, but good software does need a strong vision, and the holders of the vision need the means to get developers to buy into, execute on, and stick with that vision.

So Tim gets the answer right- but I think his framing of the question is actually a little off, in a way that merits discussion.

The first mistake Tim makes is that when he says “open UIs suck.” This is not false, but it is misleading. The more general rule is that most UIs suck; open UIs are just a subset of that. So implicitly contrasting open and non-open UIs is not necessarily very informative. Plenty of proprietary companies and proprietary design models create and implement lousy designs. Microsoft, of course, was historically the canonical example of this (though Office 2007 and Windows 7 are great strides in the right direction) but Android, which Tim picks a bit on, is perhaps an even better example- nothing about Android’s design and development process is open in any meaningful sense, and… the UI is pretty bad. So Tim’s post would have been much more useful as an analytical tool if he asked “why do most UIs suck?” and then concluded “lack of vision,” instead of asking “why do open UIs suck.”1

The second mistake Tim makes is the assumption that open projects can’t have strong, coherent vision- that “[t]he decentralized nature of open source development means that there’s always a bias toward feature bloat.” There is a long tradition of the benevolent but strong dictator who is willing to say no in open projects, and typically a strong correlation between that sort of leadership and technical success. (Linux without Linus would be Hurd.) It is true that historically these BDFLs have strong technology and implementation vision, but pretty poor UI design vision.2 There are a couple of reasons for this: hackers outnumber designers everywhere by a large number, not just in open source; hackers aren’t taught design principles in school; in the open source meritocracy, people who can implement almost always outrank people who can’t; and finally that many hackers just aren’t good at putting themselves in someone else’s shoes. But the fact that many BDFLs exist suggests that “open” doesn’t have to mean “no vision and leadership”- those can be compatible, just as “proprietary” and “essentially without vision or leadership” can also be compatible.

This isn’t to say that open development communities are going to suddenly become bastions of good design any time soon; they are more likely to be “bottom up” and therefore less vision-centered, for a number of reasons. Besides the problems I’ve already listed, there are also problems on the design side- several of the design texts I’ve read perpetuate an “us v. them” mentality about designers v. developers, and I’ve met several designers who buy deeply into that model. Anyone who is trained to believe that there must be antagonism between designers and developers won’t have the leadership skills to become a healthy BDFL; whereas they’ll be reasonably comfortable in a command-and-control traditional corporation (even if, as is often the case, salespeople and engineering in the end trump design.) There is also a platform competition problem- given that there is a (relatively) limited number of people who care about software design, and that those people exclusively use Macs, the application ecosystem around Macs is going to be better than other platforms (Linux, Android, Windows, etc.) because all the right people are already there. This is a very virtuous cycle for Apple, and a vicious one for most free platforms. But this isn’t really an open v. closed thing- this is a case of “one platform took a huge lead in usability and thereby attracted a critical mass of usability-oriented designers” rather than “open platforms can’t attract a critical mass of usability-oriented designers”. (Microsoft, RIM, and Palm are all proof points here- they had closed platforms whose applications mostly sucked.) Finally, of course, there isn’t just the problem of getting vision- there is the problem of execution. Manpower is always hard, especially when you can’t really fire people, but I think Firefox and GNOME (among other projects) have proven that you can motivate volunteers and companies to contribute to well-thought-out projects once a vision is articulated. It definitely isn’t easy, though!

Tim is not the first or the last person to say “open” when they mean “disorganized,” particularly in the context of UI. It is an easy mistake to make when, well, free software generally feels very rough compared to the alternatives. Free software communities that want to appeal to a broader set of people are going to have to do a better job of  rising to the challenge of this problem, and create circumstances where designers not only feel welcome, but feel empowered to create a vision and feel supported in their implementation.

  1. Tim doesn’t help his analytical problem here by not defining what he means by “open UIs”; given that he uses Droid as an example, what he is discussing are “source-available UIs” but given this tweet what he may mean to discuss is “UIs designed from the bottom up”, which are, I believe, a related but analytically distinct thing. [↩]
  2. The best current example I can think of as a design BDFL is Jon McCann in the context of gnome-shell. [↩]

the linux desktop’s change problem

Luis Villa33 Comments

[NB: this could easily have been titled ‘the software industry’s innovation problem’, since the problem applies broadly to all sorts of software development, and what I’m talking about as ‘change’ is often referred to as ‘innovation’, a word that has been twisted almost beyond recognition. I’d like to focus on this little corner of the industry today, so the linux desktop’s change problem it is for now.]

A couple things recently (combined with writing this post the other day) made me think about the difficulties in bringing change to the linux desktop.

  • talking with someone about distributor innovation brought up this post by Vincent. Solid post that I mostly agree with (bottom line: distributor changes done without upstream input are doomed to failure) but the comments raise a challenging and difficult-to-rebut counterpoint: distributor changes done with lots of upstream input have a history of being watered down, shouted down, and hence failing to make revolutionary change. Incremental or additive change, fine; revolutionary change, not so much.
  • discussion of javascript in the desktop reminded me of Pyro. Obviously Pyro wasn’t perfect, but the speed with which it was shouted down, despite the advantages it might have brought (easy web integration, someone else doing optimization and a11y for us, etc.) was very troubling. To paraphrase what a friend said at the time, ‘developing an online desktop in GTK seems like flying a private jet to an environmental rally- it might be justifiable, but it suggests you aren’t really that serious about the benefits of the new system you’re claiming to embrace. If you really think the web is that great, you have to take Pyro seriously.’ What can we learn from the differences in their receptions?
  • discussion in this bug about the Sugar filesystem is fairly typical of what happens when you try to implement radical change- people used to the old system focus intensely on the transition costs (it doesn’t work RIGHT NOW and my old system WORKS RIGHT NOW DAMMIT) and give varying levels of thought (usually little) to the potential upside of the change- maybe tagging and search really have vastly more potential than hierarchies now that our computers have more capabilities than they did in the time of Aristotle. Kudos to the Sugar folks for persisting despite that resistance.

This isn’t to say that resistance to change is always a bad thing. Plenty of people have brought fairly cracked out ideas to the GNOME table that deserve to be shouted down; Sugar would certainly have been helped by better communication about their vision, a strong dash of pragmatism and a better sense of how to pick your battles; and Pyro might have been better received if the presentation at GUADEC hadn’t been frequently described as ‘condescending.’ But there is a theme here- lots of shouting down of new ideas is being done. Sadly, you can even make a fairly good argument that this is the default reaction to new ideas.

For a long time, this problem didn’t matter that much to the linux desktop. There were plenty of problems to solve just to get usable at all, competitors put out shoddy products, innovation by others happened very slowly if it happened at all, and there was no disruptive change in the basic model for delivery of apps. This basic state of affairs lasted for nearly 20 years. But now things have changed- the linux desktop has matured to the point where the answer to ‘what next?’ can at least sometimes be something other than ‘fix bugs’, Apple is doing real user experience innovation, Windows is feeling price and quality competition (say what you will, but XP and Office 2007 are miles better than Windows/Office 98), and the web is simultaneously revolutionizing how people collaborate and how almost all modern end-user software is developed and delivered.

It seems like a critical question for the linux desktop, then, to figure out how to make radical change happen, since our competitors are eating away at our traditional advantages while making radical change themselves. It can’t be just incremental change (gradually improved usability) or additive change (bolt on a11y on top), because competitors are delivering all those things and then some. Freedom helps here, especially in the very, very long term, since end-user modification and individual control are not features that Apple and Microsoft can ever offer, and which web services can offer only with great difficulty. But that is a very long term solution. In the mean time, if you don’t want to just imperfectly clone everything they do and then wait for freedom to work its magic, merely being as easy to use as OS X or as accessible as Windows won’t help- something bigger and more substantive has to change.

The question is how to do this change, given the resistance I’ve already suggested is rampant? I’m afraid I have no magical bullet to resolving this resistance to change, but I have some suggestions:

  1. The first one is a non-suggestion. The solution is not to do innovation in-house and closed off from the public. Do it that way, and you have all the difficulties that stem from being proprietary (lack of resources, lack of feedback, etc.) and you’ll never get any of the benefits of being open (free assistance in maintenance, free integration in other products, etc.), since odds of it being integrated upstream are extremely low (for good reasons). ‘I want the PR value’ is also not a good reason; the positive PR value you get from that sort of thing lasts only one release cycle, while the damage to your community reputation is permanent. Obviously some balances must be struck so that we can get ideas from as many sources (corporate and community) as possible, but too often pleas for balance are really ‘I don’t know how to do innovation any other way, so I’m doing it this way, sorry’ in disguise.
  2. actively encourage incubation of new technologies. Anyone willing to work on changes in a branch should be encouraged with all the resources we have, and with a serious no-stop-energy policy. Constructive, non-bikeshedding feedback only– those running an incubator should feel completely empowered to ban or mute people who aren’t contributing constructively. There is a time for non-constructive feedback, but that time is at the last possible moment. Think of premature stop energy as premature optimization- the costs are almost always higher than the payoffs. To do it right, you have to understand the problem first, and the best way to do that is to encourage someone to do the design and prototyping and write the code.
  3. Move development to git or bzr ASAP. Part of incubation of new ideas is to fork early and often, with tools that lower the barrier to creating and testing changes, and which make it as easy as possible to merge those changes back once it makes sense. (Great to see that Behdad is working on that.)
  4. Make testing changes easy. Greg seems to be pushing hard for this in the Sugar space, which will be terrific for them in the long term. Some of the push for jscript in GNOME seems to be driven by the same concern- quicker cycles of iteration mean more small changes, quickly, which helps development of new ideas.
  5. Encourage a JFDI culture. Part of the problem with bikeshedding is caused by developers who think they are required to talk about things at great length before doing them. A great developer should be transparent, by publishing as much information as they can while they work, but if you’re well trained and well prepared you need not wait to get public feedback on that information before going forward. The best feedback will still be there for you when you’re done- and likely it’ll be even better in reaction to your work. (Note that transparent JFDI implementation after some early internal design thinking is probably a solid feasible halfway point between ‘do it all in-house’ and ‘do it all in the open.’)
  6. Encourage a serious innovation culture. We need to be able to tell the difference between serious innovation (what the web is doing to collaboration and development; changing how users experience games) and ‘innovation’ (ooh! shiny!) It would be great if development as a whole (and linux in particular) started to be consciously aware of the difference- that would go a long way towards resolving the imbalance between the two categories. (We did some of the same sort of thing in creating a GNOME culture around ease of use, so it isn’t impossible, though it has been less conscious of late- which is a definite problem, easily visible in some of the newest UI bits.)
  7. develop sustainable design best practices: the practices used by designers tend to be optimized for small, tight-knit groups, and many designers strongly believe that too many cooks spoil the broth. Learning how to do iterative, long-term, expert-driven-but-not-dominated design that can respect and incorporate community-driven feedback would be huge. As best as I can tell, no one really knows what such a process would look like yet. Figuring that out should be an explicit goal for someone- perhaps Mozilla (now that they’ve purchased Humanized) or perhaps a university program in design.

It would be great if this post started some serious discussions of the problem and solutions; I certainly don’t pretend that I’m an expert in innovation or that I’d have all the answers even if I were such an expert. And at the end of the day, the #1 reason there isn’t much ‘serious’ innovation- anywhere- is that innovation is really damn hard. That I can’t solve either… but some of the other issues should be resolvable as well.

[Ed. later: I removed some childishly snide KDE links, and apologize for the snarky tone therein. I do think that KDE 4’s ‘innovations’ are a prime example of confusing ‘shiny’ with ‘innovative’, but I should have said that flat out rather than doing it the way I did. Note that that may well be a better way of failing to innovate than complaining about- and killing- new ideas before they ever get to the user; either way I think both GNOME and KDE have a real problem here, which is why I said ‘linux desktop’ and not GNOME in the title.]

almost-post-vacation software playing/lazyweb/misc.

Luis Villa10 Comments

I still have one more week of vacation, which means I’ve been starting to play a bit with software to get my brain off law for a while. Some notes:

  • lazyweb: as previously mentioned, I’ve got a remote control which, to the computer, looks like a keyboard. For an upcoming project I’d like to remap the keys (make the current pgup button ‘n’, pgdown ‘p’, etc.), ideally from a script (so that I can easily turn it off and on) or perhaps from a hotplug event. Still need to figure out how to do that; any pointers welcome.
  • firefox: for a while I’ve been using Kiwi Cloak to modify my web-surfing habits (Greg, you might want to check it out) I’ve spent a tiny bit of time modifying it; it is now an XPI (so I can activate/deactivate it separately from the rest of greasemonkey) and forwards to my tasklist when I try to enter a verboten site.
  • Tracks: I installed Tracks trunk on my server. I’ve been using the last stable release since some time before law school, and like it a lot. Trunk is more of the same goodness, now with a tickler, which is spectacularly awesome. (Reminder: if you’re working on an alternative file manager, you should really read Getting Things Done and build something that works like that.)
  • opensearch: spent a couple hours (during the Clemson-UNC game) yesterday figuring out how to add opensearch to altlaw.org. Still not very discoverable, even in FFox 3, but hopefully will be a nice touch for altlaw when it goes live.
  • apple: I went to apple store yesterday to buy a new computer for my mom. The store was packed. It is mindblowing how good their industrial hardware design is- the new keyboard will probably end up following other Ives work into MOMA’s design collection. How is it that no other PC manufacturer has figured out that people want good design and are willing to pay a premium for it? Are they really all that margin obssessed that they can’t figure out that there is a luxury business out there waiting to be seized? (Leopard was unimpressive, other than Time Machine; have already had to hard reboot once in less than a day’s use.)

Back to law a week from today, after (with?) a one-day stop at the Princeton Cloud Computing Workshop. Schedule for the semester looks to be Corporations, E-Commerce, Privacy, Advanced Copyrights, and Telecommunications, but I may tweak it.

in the ‘why free software is still not winning’ category

Luis Villa4 Comments

“Some may say iPhone [is the most advanced smartphone] but there is no more than great usability … on it.” —Avi

Ah, yes, no more than great usability. Apple will have to content themselves with the $100+ million they made that first weekend, because I’m sure that as soon as the world figures out iphone has only great usability the world will beat a path to a more fully featured competitor’s door.

[Later: Avi counters very well. I shouldn’t have called him out specifically; it was just that the quote screamed ‘usability is just useless shininess’ rather than ‘usability is a critical feature which I weighed against other critical features, and which was not enough to make up for the lack of those features.’ The first attitude is all too common (not just in open source, but proprietary software has other mechanisms in place to control the tendency which we don’t have yet) and drives me up the wall.]