Goodbye, Fedora

[Eric S. Raymond]

Rahul Sundaram <sundaram at fedoraproject.org>:
> We only have your analysis of the problem. Not a description of the 
> actual problem. That would be more helpful. Perhaps a bug report.

You have half of it.  rpm should be statically linked to avoid this sort
of cul-de-sac.  It's not like multople instances of it running are
going to be a frequent occurrence.

I can tell you the library in question was libcom_err, and I think I
deleted it when removing e2fsprogs-libs to get around a file conflict.
But with rpm not working I couldn't reinstall the library.  Boot failed,
ssh/sshd failed -- I had to kluge with netcat and tar just to back up
my files.  It was horrible.  

Alas, I no longer have the logs, as I lost them during installation.
I don't recall what the file was, but the conflict was completely
avoidable and would never have occurred if the repo and RPMs had been
in a sane state.
 
> >* Chronic governance problems.
> 
> More details required. I have a special interest in this.

I was thinking of the the endless internal wrangling over what to do
about the core/extras split, and the years the project has spent
failing to engage with third-party developers and repo maintainers.
That IRC-session parody of Fedora politics somebody wrote back around
2002 remains as painfully on-point today as it was then.

The Fedora project has never resolved the tension between Red Hat's
business need for it to be an adjunct of RHEL development and its core
group's stated aim to be community-facing.  The result is a sociology
that has increasingly combined the least useful features of a corporate
project with the least useful snakepit-like features of 'community'
politics -- as perfectly illustrated by the list response to my goodbye
note.

> >* A murky, poorly-documented, over-complex submission process.
> 
> Last time you claimed this, I requested you to point out specific issues 
> which you agreed to. That was never delivered. Your actual submission 
> was struck after the reviewer pointed out some things to fix

I was doing what I told Jesse Keating I'd do -- using that submission
as a probe of the process, and planning to write up a narrative of the
difficulties and some recommendations once it was done.  (I'll note
that I thought the reviewer did a good job of critique, so the early
indications were somewhat positive.)

The things I could address in that particular submission were trivial
and are fixed, as I noted in a comment attached to the bug. I was
waiting on resubmitting until Mike Smith shipped a new stylesheet RPM,
as that was critical to fixing the man-page glitches.

Now it's no longer my problem.

> >* Allowing RPM development to drift and stagnate -- then adding
> >  another layer of complexity, bugs, and wretched performance with yum. 
> 
> RPM indeed drifted but I dont think it actually stagnated. Anyway 
> http://rpm.org for more details. RPM doesnt do automatic dependency 
> resolving. Yum does. I did read somewhere your claim that introducing 
> yum was a big change that put Fedora in a position of advantage or some 
> such thing.

Yes, I thought so at the time.   But yum failed to live up to what I thought
was considerable early promise.  It remained painfully slow and buggy.
Improvements in dependency resolution that seemed conceptually obvious
to me were never made.

The most obvious of these would have been a clique analysis of mass
updates to fail the smallest possible subset hanging on a missing
dependency, rather than failing the entire update.  I used to be a
mathematician, I have the graph-theory chops to do something about
this, and I tried to contribute some refactoring patches that would
have led in this direction.  They were rejected, and I had other
things to do.

> >* Effectively abandoning the struggle for desktop market share.
> 
> Unless this is just about proprietary codecs, Red Hat continues to do a 
> lot of work on the desktop

To no visible result.  You had the developers, the first-mover
advantage, and the corporate backing; you lacked the vision and the
will to follow through.  Ubuntu shows what could have been done -- but
if you guys had executed correctly, Ubuntu's market- and mindshare
would be at best statistical noise (if it existed at all).

> >* Failure to address the problem of proprietary multimedia formats with
> >  any attitude other than blank denial.
> 
> We spend a lot of time even recently on FUDCon Boston 2007 discussing 
> this. See http://fedoraproject.org/wiki/Releases/FeatureCodecBuddy

Again, to no visible result.  And with zealots screaming their heads off
against it whenever the topic came up on fedora-devel.  I wound up
expecting that any Fedora 'solution' would be half-hearted and ineffective
and involve far too much sneering at users' actual needs and too little
effort spent on actually meeting them.  

The wiki page does nothing to disabuse me of this expectation by using
terms like "brainwashing".  The contempt for mere users this exhibits is
very revealing, and is a significant part of the reason I've decamped.

Meanwhile, Ubuntu and Linspire are actually addressing the problem at
its root.  They might get it solved in time to meet the 64-bit
deadline Rob Landley and I have seen coming, but Fedora clearly will
not.  So much for Fedora.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>