Response to "Getting Fedora Out of the If-Then Loop"
mmcgrath at redhat.com
Fri Feb 19 23:11:50 UTC 2010
On Fri, 19 Feb 2010, Christoph Wickert wrote:
> Am Freitag, den 19.02.2010, 15:55 -0600 schrieb Mike McGrath:
> > On Fri, 19 Feb 2010, Christoph Wickert wrote:
> > > There is no official document that says this, but there is at least one
> > > board member who claimed that "spins are a detriment to Fedora". He
> > > didn't outline why he thinks so, but the statement still stands. And it
> > > hurts, at least for the people who work on the different spins.
> > >
> > :: sigh :: I can't wait to not be on the board again so I can express an
> > opinion.
> Your are free to express your opinion and I'm not going to hold the
> board responsible for your statements. But when you make such a
> statement I would at least expect you to give reasons for your opinion.
<I only speak for myself and not the board>
I've expressed this several times. Hosting, QA (especially when it's not
done) has a cost. The LXDE spin made us look incompetent when it didn't
boot. Building the spins, testing the spins. All of it has a cost even
if you don't see it. I think the spins are a distraction to the different
SIGs that make them and a distraction to marketing and everyone else and
as such I feel they do more harm then good.
If you care about $SPIN then 99.9% of your work should be concerned with
the post-install experience. Live media is neat, and useful as a
trial/marketing tool. But they shouldn't be the primary way we're
distributing our product. You can't even do package selection right now
with them which is why I'm for a regular checkbox installer.. the way it
was years ago.
My argument isn't about KDE or LXDE, it's about the spins. If I want KDE
or LXDE, it should be part of the installer. Once installed everything
points in one location anyway. Beyond that preupgrade (when it works.. it
didn't for F12) takes care of things from there.
Meanwhile, since we don't have the resources to master a single master
repo I don't think we should be splitting it out into multiples with
different support cycles any time soon which is what we'd need to do if we
were going to do 'spins' properly.
I feel very strongly about this because I, and others, have dedicated
years at this point to Fedora and, perhaps alone, I really see doom on the
horizon (this is completely up for debate). Here's my view of what the
next couple of years look like for Fedora.
>From my view of the data, we're losing installs over time.
>From my view of the data Ubuntu is gaining installs over time.
Prediction: When RHEL6 ships, we're going to see a major dip in users just
like we did when RHEL5 shipped.
Prediction: We are horribly positioned to get those users back. This will
have negative impact on the new contributors we get. At the same time,
Ubuntu's community will continue to grow stronger.
Within 2-3 years, at our current pace, Fedora just won't be interesting to
people. Users won't be interested because the alternatives have been able
to focus on things like usability goals and that focus is very much at
Without the users, the developers and other projects won't be interested
in having their stuff on Fedora. Neat projects like boxee, etc won't even
consider us, again because the alternatives have the users. This is
especially true for the younger/in-school groups to which media is
extremely important. I also consider this group to be a growth market
that we won't be in touch with.
Since we've been talking about this for about a year now without any
decision to change (much less actually starting to change) I don't see how
we're going to hit our RHEL6 window to get those users back. It's a
missed opportunity for the type of transformative change we need and
 Also why I've been working on http://boot.fedoraproject.org/
 To explain the Fedora -> RHEL relationship. It's been my personal
experience both in use and in evidence from the logs that as RHELX gets
older, people slowly move back to Fedora for newer versions of things.
When RHELX+1 comes out, they move back to RHEL/CentOS so they don't have
to worry about the update cycle until their needs change again and they
need newer versions.
More information about the advisory-board