As the PostgreSQL Elephant continues
its march toward yet another release, I’ve been thinking quite a bit
about the role users of software should have in its user interface
design. Today I proposed something that makes a database parameter
people used to have to worry about, and that wasn’t obvious at all
how to set, and makes its value largely automatic. That’s a pretty
unambiguous forward change; users were annoyed, good default behavior
established, and that default behavior suggested as a patch. If it’s applied I’d be shocked to find anyone who considers that a bad
decision.
There’s been a similar discussion of
how to rework the user interface around database checkpoints. Right
now, the speed at which data is written to disk by a checkpoint is
impacted by three values the user can specify. The interaction
between these is documented well enough, albeit in a way that
reflects the complexity, and some users find the behavior it gives
performs well. It’s quite possible that in order to make things
better for the typical user, there is going to be a performance
regression in some cases relative to the current code. Using a
different implementation that changes the effective scale of the
parameters will result in subtle timing changes, and they won’t
necessarily all be positive. In this situation, the best we can do
as a development community is collect enough benchmark data to make
that call. It may be that improving the worst-case scenarios
slightly detunes things relative to the earlier implementation. If
the net result turns out to be easier to adjust–replacing multiple
complicated settings with a single one, as I suggested might be the
right direction here–on average that should be better. At some
times it’s necessary to let go of the old approach in order to get
one that is better.
But this is how much we’re concerned
about breaking behavior users rely on. There a large focus on
backward compatibility and only adding things in a way that doesn’t
remove the old approach in PostgreSQL development. Sometimes there’s
no choice though: you have to push toward a new approach. In cases
where both old and new behavior are completely legitimate, ever
reaching even a clear majority opinion is hard. That’s often the
case in user interface design. While you can benchmark that with the
right tools and professionals, but it’s rarely done in the
open-source community. Getting a community consensus out of that mix
of very personal opinions is difficult.
I was reminded again of how not to
handle user feedback as a developer by getting some updates today
about a long-annoying regression in how gnome-terminal, my nominal
preferred command line terminal, handles keyboard input. The problem
first gelled into a bug report almost exactly two years ago, on an
Ubuntu tracker, only to migrate to the underlying
source of the regression: an intentional change by one of the GNOME
developers to eliminate behavior they found inappropriate. There was a ticket opened requesting a fix, but it never much beyond be insulting to all involved.
I’ve been active enough in the latter
ticket’s history that I don’t need to repeat my argument here.
Essentially, all I wanted was a check-box configuration option to
make returning to the old behavior possible. I even started working
on doing just that, digging into the code to suggest workarounds,
only to realize that there was no way this would ever get merged. My
suggestions were focused on trying to find a common ground that would
please everyone. It’s very clear the developers just don’t care
about that though. They are doing thing the way they like, and
everyone else doesn’t matter. That I was told it would take “a
few hundred” complaints before this would be considered important
boggles my mind, considering that control key use in the terminal is
not exactly the most popular thing. There were tens of reports,
every single complaint received was unified in the preferred
resolution, and the only person who disagreed was one of their
developers.
We get some complaints from people that
the PostgreSQL community is filled with developers who prefer
technically pure solutions over just giving the users what they want.
That’s true to some extent, such as the continued resistance to
adding show tables as an alternative way of finding the
database in your database. But all of that discussion has been on
topics where the discussion gives very mixed opinions; many people
have strong opinions on both sides. If every user agrees about a
design, which is the case with this gnome-terminal issue, rejecting
those opinions as still being not right is the height of developer
arrogance.
One of the more interesting examples of
this sort of thing involves the developers of the Pidgin IM software
changing how the chat window text sizing works in their program.
Users revolted. There’s a good example of the old and new behavior with some
analysis at CodingHorror.
Everyone was ticked by the way the
developers seemed to ignore their feedback. Their perception was
that the community feedback was irrelevant to the developers, because
they felt their design was better than the old one regardless of what
the users thought. Someone wrote a plug-in to restore the old
behavior. And then there was an official split. The mission
statement
of the resulting fork, originally called “Fun Pidgin” and now
called “Carrier Instant Messenger”, is an interesting read in how
they feel user-centered development should work.
Jeff Atwood’s CodingHorror discussion
of this suggested four ways such a fork might turn out. He left out
a very important one: the possibility that by splitting the
community efforts, both forks would die, with neither having enough
resources to compete against the alternatives. While Pidgin isn’t
dead yet–it’s some distance from “run down the curtain and joined
the bleedin’ choir invisibile”–they’re less important than they
used to be, and this whole debacle didn’t help their cause. As of
Ubuntu 9.10, Canonical replaced Pidgin as the primary IM client
shipping with that very popular Linux distribution. Instead they put
GNOME Empathy in its place. Would that have still happened had the
Pidgin community not fractured and become associated with such bad
PR? Possibly, but that certainly didn’t help their case.
That the same sort of user-ignorant
decisions are being made in regards to a popular GNOME project like
gnome-terminal is amusingly (I laugh rather than cry) heading toward
a similar situation. Two months ago it was announced that Ubuntu was
moving significantly away from using the full GNOME software stack in their next release. Note very carefully what happened there.
Mark Shuttleworth is saying they hired professional UI designers, put
them to work figuring out would work better for the desktop user
experience, then presented the results to the GNOME community.
Rather than accept this extremely valuable work and thank Canonical
for doing that research, they rejected enough fundamental ideas that
there was no middle ground possible. Ubuntu is now forking in a big
way toward the Unity project, as the only path left to “do what our
users want”. Based on my own interaction I’ve had with the GNOME
developers during the years since I ran into this one annoyance, the
reaction Mark got doesn’t surprise me one bit.
We’re still at the point where it’s not
clear how this Unity split will end up turning out. What I expect is
that this whole thing is going to lead into a sort of double failure
situation, too. There will be a bunch of duplicated development that
doesn’t on its own produce anything useful at first. The initial
releases will have terrible quality control–this stuff takes
forever to get right. And by splitting the developer base, it’s
quite possible neither group will have enough people left to ever end
up doing a good job, leaving us all with multiple poor Linux desktop
options (again) rather than one unified one everyone is lined up to
improve. I was hoping by now that the way Nokia has been improving
the license to Qt might finally make considering how to eliminate
having both Qt+GNOME. That instead Linux is getting yet development
project on top of the mix, and naming it Unity of all things, is a
terrible joke.
But I was talking about databases…one
of the interesting things about PostgreSQL is how many forks it has
generated. The generous BSD license had led to multiple
closed-source commercial forks; I used to work at a company that made
one. Netezza was the first of these to ultimately gel into a serious
commercial production. And the Greenplum Database was recently
purchased by EMC, it’s a very successful product. What hasn’t
happened is any of the open-source forks becoming viable replacements
for the main distribution. Unless you have the sort of large
resources a major company can bring to bear on engineering, it’s
easier to get the community to accept your ideas than it is to try
and do an independent implementation of them. Straight community
PostgreSQL just keeps being the right choice.
The PostgreSQL community argues a lot,
and is hostile toward a lot of things people ask for; we even have a
list We Do Not Want to do.
These are for the most part things that just aren’t technically
feasible to build without downsides that are not always obvious to
those requesting them. If a user makes a case for why a change would
make for a better user interface to something in the database, and
there aren’t any technical objections to why it will cause a problem,
that change is considered. What I’ve never seen in the community is
any of the developers lining up against a unanimous, unambiguous user
preference–where that option could be made available with no
downsides–simply because they don’t like it that way. If you’re a
developer of an open source project wandering to where hubris has
trumped humility that badly, don’t be surprised if your users will
anger enough to fork. And one of these days, you may discover that
the forks or re-implementations that do pay attention to what people
really want will displace you.