gnome


17
Apr 11

looking for a programming analogy- if there is one

As I’ve mentioned before, there are a lot of analogies between programming and legal work.

I’m working on an upcoming post to explain a specific application of a legal concept. Unfortunately, I think this is one of those few concepts where there is not a ready programming analogy. I’d love for someone to prove me wrong, since the programming side of my brain is slowly going to pot. Here goes:

In law, there is the concept of “rules” and “standards.” Basically, rules are precise- they allow a judge to simply look at the facts, apply the rule, and voila- you know whether the rule was violated. An example would be “The speed limit is 55.” If you’re driving 56, you’re in violation- even if, say, you’re speeding to the hospital with your pregnant wife. Alternately, if you’re driving 54 you’re fine- even if it is pouring rain. Rules are good because they are easy for the public to understand (no need to consult with a lawyer) and because their application (should be) very evenhanded, but good, fair rules are very hard (in many cases essentially impossible) to write.

A standard, on the other hand, is more vague- something like “The speed limit is whatever speed is safe to drive at under the circumstances.” This might not allow you to go 56 to the hospital, but would definitely not allow 54 in the rain. These are bad in some ways because they are trickier, case-by-case, hard to predict the outcome of beforehand, and involves judgment on the part of all parties, but (arguably) produces better outcomes a lot of the time- assuming you can trust the parties doing the judging, and you can put up with the cost of taking the time to make the decision.

So… for those of you who have lasted this long: are there analogies to this in software? The closest thing I can think of is strong typing vs. weak typing, but generally, since computers are incapable of dealing with standards, there aren’t many examples I can think of. Am I missing/forgetting something?


24
Mar 11

Joining W3C PSIG as an Invited Expert

Just a note to say that I’ve been invited to join the W3C‘s Patents and Standards Interest Group as an Invited Expert. I’m pretty pleased by this and am looking forward to contributing immediately. Invited Experts speak for themselves, not other organizations, so I will not be representing Mozilla or anyone else, but hopefully I’ll be able to add something to the discussion on my own and help move W3C and the open web forward.


15
Nov 10

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

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. []

18
Jul 10

A Pre-GUADEC Request

I’m preparing for my GUADEC keynote and have a request for material that would be useful. Specifically, does anyone have a good group picture from the first GUADEC? This is the best I’ve found so far, but I seem to recall there were better. Please comment or email me (luis at this domain) if you’ve got one. Thanks.


12
May 10

Sponsoring a GNOME hacker (oops!)

Become a Friend of GNOME

While I was moving, and taking the bar exam, and getting married, and all the other stuff I did last year, it turns out I screwed up. People had sponsored me through GNOME’s adopt a hacker program, and I… well, I botched it- the postcards people had signed up for fell through the cracks.

No longer! My apologies go out to:

  • Owen
  • Eetu
  • Sergio
  • Eduardo
  • Chris
  • Jon
  • Robert
  • Donald
  • Markus

Your postcards are finally, I promise, in the mail; though admittedly my handwriting is illegible at the best of times so you’ll have to take my word for it that the postcards are thoughtful and meaningful :)

For everyone else: now is a great time to force me (or other hackers) to write you! You get the warm, glossy postcard, as well as the warm, glossy feeling of having helped get GNOME folks together to work on your software.


23
Sep 09

pathetic, part II

My system failed to functionally come back from suspend yesterday, which appears to have cost me a substantial part of what was the final draft of my wedding vows and ceremony. This is the second time in the past few months I’ve lost big chunks of important work because of a system crash.

Maslow's Hierarchy of Needs, from Wikipedia

Maslow’s Hierarchy of Needs, from Wikipedia, by factoryjoe, used under CC-BY-SA

I’m reminded of Maslow’s hierarchy of needs. Self-actualization (freedom of choice, of action) is pretty nice to have but it turns out it doesn’t do you much good when you fear for your safety or lack the ability to feed yourself. Software freedom feels fairly similar- at this point tonight, admittedly sick, angry, and stressed, I’d be pretty happy to pay for a shiny pair of handcuffs if I knew it would do c. late-90s basics like ‘work reliably,’ ‘resume and suspend’, etc.

Best wedding present GNOME (not to mention X and the kernel)1 could give me: dedicate a release cycle (or three) to implementing test-driven development. No features, no ‘regular’ bug fixes, just writing tests and implementing the necessary build tools so that those tests are run on every commit. End the stability regressions and get us on the right track to compete with modern user-centric OSes. We used to be more stable than they are; we can be and should be again.

  1. GNOME could call it 2.90; zeitgeist and shell could spend the time actually figuring out a use case, ahem []

19
Aug 09

who writes the kernel^W gnome?

The new ‘who writes the kernel’ paper is out; an interesting read as always. I’m still waiting for someone to take the scripts and run the same analysis for GNOME, especially since GNOME’s data is all in git now. Should be a short project for someone, I’d think, and very valuable for the community as a whole to better understand who contributes and why.


10
Aug 09

thanks, friends

A few days before the bar I got a ‘wish you were here’ postcard from Gran Canaria. I promise I only choked up a little bit. :) It meant a lot to me.

Thanks to everyone who signed it- I miss you guys (and gals) too :)


14
Jul 09

FLOSS Law Review

I thought I was done with law review blogging for a while, but apparently not! The International FLOSS Law Review has just published their first issue, with what looks to be a fair number of interesting articles. I look forward to seeing how it progresses.


12
May 09

LWN interview on Stormy and other subjects

This weekend Linux Weekly News interviewed me on a variety of topics, but primarily on Stormy and GNOME’s finances. It has now been posted. It is behind the LWN paywall for now, but will be available more generally in the future. (I urge everyone to subscribe to LWN; it is an excellent publication.)

In the meantime, perhaps the best summary of the important part can be extracted from the comments, lightly edited for coherency (commenter in bold/italic, me in blockquote):

Why don’t you take a look at how KDE e.V. is run? AFAIK, they don’t pay in 6 figures to anyone and still manage to get the job done in terms of sponsorships and are not looking for a bailout.

We’ve been operating in a manner similar to KDE e.V. since our last Executive Director left, so we’re familiar with the part-time administrative assistant model of doing things. Some things work fairly well when you’re organized that way; others do not.

Goes to show the mindset of the upper echelons of the GNOME project.

I agree completely. It shows that our mindset is that we were unwilling to sit still and tread water. Our mindset was that we wanted to move aggressively forward and change how GNOME related to the outside world. I hope I was clear in the interview of all the various ways in which Stormy helps us do that.

Now, you can certainly question and say bad things about the timing and judgment of those steps. We did expect this to be financially challenging, but we misjudged how badly it would challenge us.

But I think if you want to question the mindset either I didn’t explain our proactive mindset very well in the interview (possible) or you have a very limited vision of what something like the Foundation can do for our community. Certainly I’m very proud of standing for that active, aggressive view of what the Foundation can achieve, and I think most GNOME Foundation members agree with that (though I completely understand if they are chagrined at the financial situation.)


This work by Luis Villa is licensed under a Creative Commons Attribution-ShareAlike 3.0 United States.