Strategy for fixing Bug #1

Wes Morgan cap10morgan at gmail.com
Tue Dec 26 18:48:17 UTC 2006


Most of you have probably seen ESR's recently-slashdotted essay about
what Linux needs to do to conquer the desktop computing world by the
end of 2008 (and why we need to do it by then--hint: because of the
32-to-64-bit transition). If not, you can read it here:
http://www.catb.org/~esr/writings/world-domination/world-domination-201.html

Here are the "what it will take win" points from the essay:

    1. Drivers for all major existing hardware.
    2. 32-bit legacy platform emulation.
    3. Surviving the killer app.
    4. Enabling preinstalls.
    5. Support for all major multimedia formats.

We're in pretty good shape on numbers 1 (we have the source code for
lots of legacy hardware drivers, so 64-bit support is a recompile
away) and 3 (because of the rise of web apps, an OS-specific killer
app is less likely). But we need to do some work on 2, 4, and 5. In
fact, solving 2 and 5 are dependencies (but not the only ones) of
solving 4.

So, we need good multimedia support out-of-the-box (to the point where
we have something OEMs can pre-install on new computers) and solid
Win32 software support (the bulk of legacy 32-bit software that can't
easily be moved to 64-bit Linux will be Win32 apps). We don't have
time to wait for the legal situation to improve, nor do we have time
to wait for our efforts to persuade content providers to use open and
free codecs to come to fruition. The 2008 deadline is pretty hard, as
the essay shows. (Because of the 32-to-64-bit transition. I know, I
was skeptical too, but read the whole essay.)

It seems to me that Ubuntu is easily the front-runner of desktop
Linux, for a number of reasons I needn't go into here. I'd really like
to see it position itself to tackle bug #1 (Microsoft's majority
market share) via this 64-bit transition window, but I think we need a
strategy to do so.

Specifically, I believe Ubuntu should work closely with Linspire to
bundle their "Codex" (basically a CD full of licensed proprietary
multimedia codecs) with Ubuntu. (See the last paragraph of the essay.)
This could take the form of charging for the "multimedia" version of
Ubuntu that comes with this CD, as well as making it extremely easy
(put the CD in the drive and click "OK") to install the Codex later on
any Ubuntu system. We could even charge a little extra or ask for
donations to support giving away this "multimedia" version of Ubuntu
to schools or other non-profits. And possibly, in countries with less
screwed-up laws than certain other countries (I'm looking at you,
U.S.), we could just give this CD away.

This would then be the version of Ubuntu that we would encourage OEMs
to put on new systems, and the installer would ask people to insert
the Codex CD during installation. (And if they didn't have one, the
installer could ask if a user wanted to purchase the Codex right then,
take the payment info, and then download and install the Codex in one
fell swoop.)

But the most important thing would be this: As the authors of the
above essay stress, Ubuntu would want to go into this situation with a
clear plan for getting out of it at some point. Once Linux is the
dominant desktop distro, we should stop playing the proprietry codec
game and start demanding open codecs. Ubuntu should set a policy that
all use of the Codex be phased out by 2015 (or whatever), and then
incremental phases leading up to that to transition us away from it.
Maybe even set market share triggers (for example, when Linux desktop
market share hits 30%, drop codecs X, Y, and Z from being supported in
the next release) in order to drive demand for open and free codecs.
An easy target to set is to drop MP3 from the Codex in 2010 when its
patents expire (and instead bundle it with the OS directly).

In theory we could just keep doing the Wine-bundling until users no
longer demanded it, so I don't think we need a sunset policy on that
like we do for the proprietary codecs. One thing the essay points out
that we should keep in mind, however, is that our bundled Wine must
NOT emulate Win64. Otherwise, we'll have the OS/2 effect where it's
Win16 support was so good, no one bothered writing OS/2-native apps
because the one Windows app covered those users too. We don't want
Win64 to == Win64 and Lin64 support.

What do Ubuntu devs and interested community members think of this? I
definitely want to help drive this effort where I can, but I want to
see where folks are at first. Should I make this a spec (should
probably be two specs)? The Codex doesn't really exist yet, but the
basic idea is obvious enough that a first draft could be put together
for that, and the Wine stuff is probably already out there in
spec-land to some extent.

I think if we go into this with our eyes open and a plan for using the
leverage we would attain to move things back towards the open and free
end of the spectrum, we could have much greater progress towards
closing bug #1 than if we continue doing what we're doing now. Like
ESR says in the essay, "We can't set the standards until /after/ we
take over the world."

Wes Morgan

-- 
"Small acts of humanity amid the chaos of inhumanity provide hope. But
small acts are insufficient."

- Paul Rusesabagina, Rwandan and former hotel manager whose actions
inspired the movie Hotel Rwanda




More information about the Ubuntu-devel-discuss mailing list