Havoc's Blog

Several
great
posts
from Luis.

I mentioned it in passing a few posts ago, but I still think the
“what is gnome?” on www.gnome.org could use a lot of work:
“GNOME offers an easy to understand
desktop for your Linux or UNIX computer.”

I’d kill the words “desktop”, “easy”, “Linux/UNIX”, and “computer” for
starters. What Luis has to say gets at some of the reasons.

I just decided to check with the original
GNOME charter which defines this goal for GNOME:

to create a computing platform for use by the general public that is
completely free software.

Now that’s more like it. And it would include many of the projects
that seem most exciting, whether Elisa, Nokia 770, Epiphany
or Ekiga. Or
One Laptop Per Child, Mugshot, Firefox, MusicBrainz, Wikipedia,
Creative Commons.
There are countless more projects out there. Pick your favorites. Some
of the projects are about code, others are more about communities and
shared information.

I’m not saying GNOME should try to compete with all those projects
or anything like that. But there’s no reason GNOME should stick to the
panel and file manager, either. It could work more closely toward a
coherent user experience spanning some of the vast range of projects;
and there are thousands of good ideas nobody is working on yet. And
what would it mean to start creating a coherent story across some of
these projects, a vision for a completely free-software computing
platform for use by the general public? Luis hinted
already that a platform isn’t just libraries and drivers
anymore. Nor is it yet another Linux distribution.

Make a list of the top things the “general public” (not “the
enterprise”) does with their range of computing platforms (phones,
set-top boxes, computers, web sites). Or, read
research about what people do (there’s one list on the seventh page
— labeled “vi” — of that PDF). How much of GNOME (the project, the people, not “the
desktop”) relates to the top 10 activities? If the open
source community wanted to be more relevant to the general public within 12 months, what kinds of things
would we work on?

(This post was originally found at http://log.ometer.com/2006–07.html#6)

Elijah,
my wife and I just spent Tuesday night in Newark. On a round trip through Newark on
Continental, we missed the connection both times due to a delayed
first flight, spent an hour sitting on the runway twice on two
different flights, and all four flights were delayed. It’s been a
while since I had so many screwups on one trip.

(This post was originally found at http://log.ometer.com/2006–06.html#23)

Some may have read our attempt to
summarize and bibliography design thinking, for an alternate take
Donald just found a great video
from Tim Brown, CEO of IDEO. At Red Hat we’re using a “7 steps”
way to explain things, Tim Brown one-ups that with 3 phases (inspiration,
ideation, execution) and then he nests more detailed steps across the
phases. Multilayered! Consider my mind blown by the IDEO experts.

More seriously, things I thought were really interesting in this video
included the emphasis on culture and empathy and not just process, and
I liked the discussion around the Venn diagram about how design,
engineering, and business relate.

BTW if you are grudgingly interested in this design stuff but
have “buzzword allergy” two recommendations I’d make
are the old
Nightline video
showing IDEO making a shopping cart (you
have to pay for it, but you can see the activities rather than read
about them) and Designing
for People which is from a pre-buzzword age. IDEO’s Art
of Innovation is pretty straightforward too.

Seth Godin started
some blog conversation
about getting people to switch from one product to another in an
existing category, interesting if you read the various comments and
posts some of which relate to Firefox, Linux, etc.

(This post was originally found at http://log.ometer.com/2006–06.html#13)

Good comments from Joe, inspiring me to
ramble a bit in a loosely-related way… I haven’t really written my
“personal thoughts” blog about Mugshot yet.

First, let’s not overcomplicate things by thinking there’s more to “get” than
there is… our goal was to get something out as quickly as we could
that showed the kind of stuff we wanted to do, with just 3 developers
initially (we’ve added one more now). On the one
hand I’m proud of what we’ve accomplished given the time and
resources, especially considering that we were a bunch of C
programmers who had to learn Javascript, CSS, Java, EJB3, databases,
ActionScript/Flash, Windows C++, COM, on and on all from scratch. And that
we went in various directions that didn’t work out before ending up
where we are.

On the other hand for this to be really exciting we have to do a lot
more. It would suck to do the lot more all behind closed doors for
another year, so we posted our codebase and our manifestos and notes
and hopefully some people will find it interesting.

One question I hope people
find interesting, whether as part of Mugshot or not: how can we go straight to people who
aren’t using Linux and open source already, and start providing
more of value to them more quickly? It’s an open question, I don’t pretend to
have the whole answer. With Mugshot we’re exploring only a small
fraction of possible angles on this. Firefox and Wikipedia are a
couple of existing successes. But there’s so much more to be
done.

Getting people to switch their whole OS, or even web browser, is an
inherently hard activity… while there’s steady
progress, my hypothesis is that we could move open source a lot farther and faster by
supplementing and enhancing these efforts with additional directions whether Mugshot
or One Laptop Per Child or [your idea here].

We have done some quiet non-tech-community marketing… Mugshot was stealthily live in
various forms for the last few months or so, first with our friends
and family, then with people from Google ads we ran on “customize your MySpace” type of
sites. The ads landed on a focused page about the “music on MySpace”
feature and we had some success with this.
We still have a
generic placeholder ad landing page that we aren’t using right this
minute, the old landing page was more focused on the “customize
MySpace” message (it probably always makes sense to hand-tune the
landing page to the context someone arrives from).

For signing people up a reality is that nobody will
watch a screencast or read a lot of text … we just have to make
signing up as simple as possible, and (more valuable) get to the
point where we have good word of mouth and friends are encouraging their
friends to try it. I won’t try to predict what that will require… if
we tune what we have a bit more it might be enough, or we might need
more or different offerings. The only way to find out is to try.

Writing the Google ad a while back was an interesting exercise because
there’s a brutal limit on number of characters and the ad has to work
in the context of a purpose-driven search or related page… I ended up using:

Current Song on MySpace
Free service - show what's playing
on your desktop, live on your page.

That’s just about the absolute max length Google allows. Remember this ad
ran on sites about customizing or creating MySpace profiles.
We don’t have immediate plans to run more ads (we have a ginormous
backlog of people wanting accounts already) but trying to write these
(and think of relevant places to run them) remains an informative
exercise — ideas welcome.

For the tech community a screencast is a fine idea, we’re hoping to go one better and just
clean off the “I would like an invite” list so people can try it out.

I do think the tech community’s “how is it
different?” question doesn’t exactly match how “normal people” would think
about it… especially when answered via equations: “links + social
networking + IM = yay!”, I have an
apropos blog post from
over a year ago before Mugshot existed. My gripe about this mode of thinking is
that it ignores specifics of the concrete user experience that matter
quite a bit, while also missing the “big picture” inspirational goals I was talking
about a minute ago. In the tech world we tend to focus too much on the
intermediate abstractions, neglecting both the big picture meaning and the
important details.

When arguing against the
“social networking” label I’m not trying to say that Mugshot is
the most revolutionary idea on earth, if only you understood it.

Instead, my idea is that for potential contributors, thinking
“social networking” or “links + social” or something like that won’t
get you on the same page as the existing Mugshot team. We’re trying to
think both more broadly (“open project,” “freedom,” “entertainment”, “design”)
and more specifically (prototypes and running code), and on our good
days we manage to focus on people’s needs.

Thinking about a category like “social networking” as the goal just doesn’t
work for me because it predefines what we can do. (I’m also not a fan
of goals like “a desktop” or “a web browser” or “a window manager,” by
the way, though in the past I obviously did think that way. If I were
dictator of GNOME today the first thing I’d do is change the project
definition on the front page of gnome.org to something broader and
more open-ended.)

What I’d like to encourage is either thinking concretely about the
details of user needs or the user experience, or thinking broadly
about all the stuff the project could do in the big picture, and keep
some allergy to thinking in terms of existing technology names or
trends (even when they apply, to me they’re just a bad place to have
my head).

Joe asks how Mugshot will change your life… I think that remains
to be seen. What we have so far might be pretty cool to people, or
it might be flawed in fundamental ways requiring some whole new
directions, or flawed in simple/cosmetic ways that we have to fix.

My dream is to have a great userbase in a year or two made up of
people who aren’t using Linux and open source today. Lots of “ifs”
stand in the way but that’s my ideal scenario and I think it opens
up lots of opportunities for open source (and projects such as GNOME)
if we can accomplish it. In any case I’d rather try than not try.

Putting this abstract debate aside for a minute 😉 at the moment
we’re wrestling with unglamorous Nautilus 1.0 type performance bugs, if you’re familiar with that bit
of GNOME history… e.g. leaking 8 threads per http request
(amazingly, a modern 64-bit Linux system appears to survive this for
hours at a time!). The good news is that we can get 1000% performance
wins with 1‑line fixes…

I have to stop talking and start hacking at this point 😉

(This post was originally found at http://log.ometer.com/2006–06.html#7)

Luis, a couple
quick fixes I can think of would be:

• add “swarm” notification to the group
  chat (see “Join Chat” on group pages), right now if you join there’s
  no way for other people to know there’s a conversation happening
• display AIM and other type of IM links on people’s /person pages,
  possibly also next to their name in the Mugshot chat for example so
  you can quickly start a private conversation

Good project ideas…

(This post was originally found at http://log.ometer.com/2006–06.html#6)

Long time no blog! I’ve been pretty busy coding for the last few months.

Just finished my Red Hat Summit
keynote segment announcing our new project, Mugshot.
Been working on this with Owen, Colin, and Bryan (all of GNOME fame) and a
couple newcomers Marina Zhurakhinskaya and Mike Langlie.

So much to talk about here I don’t even know where to start…
check out the project site.

For desktop developers: we coded an initial Linux client for Mugshot that ties it in to the
GNOME (or KDE) panel, Rhythmbox, and Firefox/Epiphany; but there are a
lot more neat features we could add to the desktop using Mugshot. We
have a library that adds additional protocol on top of XMPP using
Loudmouth, so
desktop add-ons could use that or could be added to the existing Mugshot
client process. We posted a bunch of
docs if you’re interested in messing with it.

(This post was originally found at http://log.ometer.com/2006–05.html#31)

Some new openings at Red Hat for those who might be interested, Visual/Graphic
Design, Software
Engineer, Software
Engineer. The software engineer descriptions have a lot of
specifics but if you have even some of the specifics and are a damn
good programmer we want to talk to you, don’t get hung up on details.
You don’t have to have prior open source experience as long as you
have other good experience. We are looking for people who can relocate to
Massachusetts.

Our coworker Marina will be at the MIT career fair (which I think is
next week), so if you’re interested in a job in our group you
might try to find her there. There are internships and
opportunities in other Red Hat groups to talk about at the fair as well.
We would love to work with some more smart MIT grads.

To apply for the jobs, submit your resume to the web site at the links
above, but feel free to send me a copy by email too or email me any questions.

BTW, I got swamped in at least 50 submissions for tripleverb, and haven’t been able to
justify spending half a day making screenshots and posting these.
Instead I’m idly scheming to automate the site somehow, then I
could plow through the 50 submissions knowing I wouldn’t have to do it
again 😉

(This post was originally found at http://log.ometer.com/2006–02.html#3)

I would like to add, that only weenies take over the aggregators by
upgrading their WordPress. Real men just write absurdly long blog
entries.

(This post was originally found at http://log.ometer.com/2006–01.html#3)

I went out and bought the December issue of Harvard Business Review to
check out the Christensen article I mentioned earlier;
it’s really a good one. While it’s titled Marketing Malpractice, it
applies equally to Engineering Malpractice and General Business
Malpractice.

It has a literal example of the tagline we’ve been using around
the office for this general line of thinking, “Design vs. Megapixel”:

Kodak scored another purpose-branding victory with its disruptive
EasyShare digital camera. The company initially had struggled for
differentiation and market share in the head-on megapixel and megazoom
race against Japanese digital camera makers (all of whom aggressively
advertised their corporate brands but had no purpose brands). Kodak
then adopted a disruptive strategy that was focused on a job — sharing
fun. It made an inexpensive digital camera that customers could slip
into a cradle, click “attach” in their computer’s email program, and
share photos effortlessly with friends and relatives. Sharing fun, not
preserving the highest resolution images for posterity, is the job -
and Kodak’s EasyShare purpose brand guides customers to a product
tailored to do that job. Kodak is now the market share leader in
digital cameras in the United States.

Lots of other great examples in the article, my favorite one is about
milkshakes. This is how both open source companies and open
source projects need to think about what they’re building.

What does the business or project do, for whom, in what context? How
will someone find the product when they need to do that job? Can you
walk through all the steps to do the job, not only the steps involving
your product?

Because software is infinitely flexible it’s even easier to fall into
the trap of the generic all-things-to-all-people than it is with the
consumer products in Christensen’s article. But ironically, the more
people we think could use our stuff, most likely the fewer
people really will. That’s why you
want to be both loved and hated: when the right people use your
product for the right job, they should love it; but if your stuff is really
good at that job it probably sucks at other jobs. One of the roles of
marketing is to set the right expectations for when and who should try
the product.

Christensen argues that a focused design with a “purpose brand” builds
the most customer goodwill, because you design the product to do a
particular thing for particular people, then guide those people (and
only those people) to try it out. Since they’re using the right
product for their needs, they have a good experience.

Christensen also makes the “experience design” point: it’s not
just about the physical widget or the software bits, it’s about how
you find out about it, how you obtain it, the intangible visual and
emotional design, surrounding services and community, …

This message should be great news for any open source business. If a
complete experience and solution involves a lot more than just the
bits, there’s plenty of business model to be had.

For example, despite all the stumbling about in the early days, Red
Hat Enterprise Linux turns out to be a pretty
complete experience design for solving a particular problem for
a particular audience (a UNIX substitute on commodity hardware for
enterprise customers). Engineering and marketing aligned in making
the product right for that job and selling it to the intended
customers for the intended purpose. (Don’t get me wrong, I don’t
think Red Hat is a shining example of agreeing with me on this
overall rant — not yet anyway! — but RHEL’s marketshare
with its intended audience is not an accident IMHO.)

All this seems like common sense, and it probably is. But in real life
it’s very very easy to get caught up in the corner cases, whether
you’re in marketing or in engineering. We need “corner cases don’t
matter” conditioning I think:

• What about… *smack*
• But these people will hate that… *smack*
• Couldn’t we also use this to… *smack*
• But that isn’t generic enough… *smack*
• But I wouldn’t like that… *smack*
• It doesn’t send email… *smack*

Maybe a big gong in all the conference rooms? That’s how they used to
train the “ums” out of us in speech class.

Let me try and be a bit more on-topic for some of the planet
aggregators my blog shows up on. Think about the history of GNOME (for
example) in this context. The job we were originally successful at was
an interface for developer/enthusiast-oriented Linux
distributions. GNOME was a UI optimized for tinkering. But there are
also strong tugs in other directions that have waxed and waned over
the years. For example, the needs of the “enterprise Linux”
distributions have played a major role (remember that their job to
date is to substitute for UNIX, and UNIX-traditional features are
therefore very appropriate). Other ambitions include the “corporate
knowledge worker” (Windows currently owns that market) or the vague
and poorly-specified “home user” (as Walter
Mossberg just pointed out, Apple has their design center there).

GNOME currently defines itself as “a desktop,” Christensen talks about
why this is wrong:

The great Harvard marketing professor Theodore Levitt used to tell his
students, “People don’t want to buy a quarter-inch drill. They want a
quarter-inch hole!” Every marketer we know agrees with Levitt’s
insight. Yet these same people segment their markets by type of drill
and by price point; they measure market share of drills, not holes;
and they benchmark the features and functions of their drill, not
their hole, against those of rivals.

If I look back on the last few years, substantially contributing to
this problem for GNOME is one of the (software-related) mistakes I
regret the most. I’ve personally been responsible for tugging in
several different directions, and had some of those directions much
too vague and poorly-specified in my mind, leading to fuzzy thinking
and thus fuzzy contributions to discussions. I can think of quite a
few flamewars I could blame on failing to sort out what kind of hole
we’re helping people to drill.

What are the options then?

It’s quite possible that GNOME should move more in the direction of
the Linux kernel. i.e. think of the customer as the developers of Maemo, various
specialized Linux distributions, thin client solutions, and
other focused products with a clear design center. Make GNOME a highly
modular set of parts that can be assembled and modified by downstream
development teams. This is the Linux kernel model, and also typical of
many libraries and compilers and other developer tools. But it’s
absolutely counter to a lot of our “everything upstream”/“forks are
bad” mode of thinking.

If GNOME embraced “building block” status wholeheartedly it might be
able to do that job a lot better. Some half-ass examples:

• The content and messaging on gnome.org could be oriented toward
  developers and explicitly point people away from “raw GNOME”
  (the same way few people use kernel.org kernels)
• GNOME-based derived projects such as Maemo (or Ubuntu, or RHEL)
  become the focus and adding more such projects defines GNOME’s success
• Perhaps one of those decentralized version control systems
  becomes a lot more interesting?

I don’t know. I’m sure that seriously thinking it through would reveal
a lot of good ideas. Here’s the point: deliberately focusing on being
a good building block for developers building derived products is
very different from becoming such a building block by default
due to lack of focus.

If GNOME doesn’t focus on being a “building block,” my personal view
is that some hard choices are in order. Who’s going to love it? More
importantly (to be sure the hard issues aren’t dodged), who’s going to hate
it? How do you clearly set expectations up front in the marketing and
positioning of the project? What about the visual design — if you’re
making something for bored teenagers is it going to be the same as a design
for hardcore UNIX admins? (Hint: hell no.)

What could the text on gnome.org say? Right now it says “GNOME is a
desktop suite,” this is broken. How could it describe the hole instead
of the drill? Who wants the hole and why?

I lean away from the “building block” road, because I’m just not sure
it works for something high in the stack like GNOME. It seems to
barely work for the kernel, and has been a bumpy ride for the X Window
System too. GNOME has too many user-visible decisions to make. But on
the other hand, building blocks seems like the most practical
direction for an open source project. This is a tough question.

GNOME is only one example I happen to be familiar with. Probably
every open source project could benefit from thinking about this
stuff.

A final thought. Since we have Christensen in this post already, let’s
drag in Geoffrey Moore as well. I think sometimes we talk about
“momentum users” and “early adopters” vs. “majority” as if they were
identical to “technical users” vs. “nontechnical users” or
“UNIX-accustomed users” vs. “Windows-accustomed” users.

That feels wrong. I would say, maybe first you have the set of
people who would benefit from your specific focused product. That set
might be “UNIX developers.” Then among UNIX developers, we have early
adopters who like to download and try the latest GNOME, and we have
the people who are still using twm in 2006.

In other words, in
Moore’s diagram the wedge labeled “technology enthusiasts” isn’t
all technology enthusiasts. It’s the subset of technology
enthusiasts who are also in the target audience the product
was designed for.

If I’m right about this, then getting lots of UNIX developers to early
adopt something does not lead to getting a lot of bored
teenagers to adopt down the line after you cross the chasm. It leads
to converting all the hardcore twm users down the line after you cross
the chasm. If you focus on UNIX developers, the total size of the
market in Moore’s diagram is simply the set of all UNIX developers,
not the set of all people in the world. Similarly, if you focus on
people who love music, there’s no reason to expect that the early
adopters will even know what UNIX is.

An implication is that as a company or project talks about
customers to focus on, it might be beneficial to have a description of
the customer that spans all the parts of Moore’s diagram, and then
perhaps discuss the early adopter and majority variants of that
description. But your early adopters should basically share the same
goals and attributes as the majority, aside from relative openness to
new products.

I haven’t re-read Moore’s book in a long time so this may already be
addressed there or just make no sense, who knows.

(This post was originally found at http://log.ometer.com/2006–01.html#3.2)

The tripleverbs are flowing in!
Todays discoveries include Squarespace, Caesar, Static Photography,
Flickr, Mono, Gather, Essembly, and Sonicare. Thanks to everyone who
discovered, shared, and celebrated new
tripleverbs.

(This post was originally found at http://log.ometer.com/2006–01.html#1)