Strategy for fixing Bug #1

[Constantine Evans]

If you are going to continue this thread, could you please do so on
sounder instead devel-discuss? This sort of discussion really isn't
appropriate or relevant for devel-discuss.

Thank you,
Constantine Evans

Wes Morgan wrote:
> 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
>