Strategy for fixing Bug #1

[mikecorn]

The 5 points are OK but there are deeper problems with Linux that need 
to be solved first. Ubuntu is the best Linux, but is not doing anything 
to fix the real issues, IMO.

This is a (short) rant about what is wrong with Linux, so if you are 
sick of reading about this you can just delete it now. I write because 
most such rants miss the point (for example ESR's essay).

Linux Problems
- too many bugs and rough edges in applications
- error messages are hidden in log files, incomprehensible, or do not exist
- technical and user docs are often missing, erroneous, or outdated
- docs are in chaos: man, info, http, text, websites, tar
(or sometimes findable only with Google)
- developer goals are not aligned with common user needs
(FOSS is not customer or market-driven)
- development is not managed (1000s of independent projects)
- developers care about creative freedom, not about utility, standards,
compatibility, fit and polish, quality documentation, etc.
- app development is 90% overlapping, a huge waste
- Linux distros are diverging, making app portability and support too 
difficult for software providers. (Software I developed using Ubuntu 
runs unmodified on about half the other Gnome distros I have tried. 
Problems: package naming, file names and locations. KDE distros often 
fail for lack of Gnome libraries - a hurdle most users are not 
willing/able to overcome.)
- the LSD project is an attempt to create some useful standards and 
cross-platform tools, but Mark Shuttleworth has stated he does not 
believe in this.
- software providers want standards, so that installation and support 
does not have a different "gotcha" with each distro. MS Windows provides 
a single standard, which is more important than its weaknesses (viruses, 
etc.).

When Michael Dell was asked about providing Linux pre-installed, his 
response was "which one?". From his viewpoint, he has to either pick one 
distro or try to support many distros. He believes neither option is 
viable for his business, and I think he is right.

If you think I am wrong about this, please explain. I will listen.

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
>
>