Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

[Chris Gianelloni <wolf31o2@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3980 bytes --]

On Tue, 2006-01-03 at 09:28 -0800, Donnie Berkholz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Simon Stelling wrote:
> | My point is, either you have to generalize each project's goal to a real
> | triviality or you have to define a goal which doesn't match some
> | project's goals. Conclusion: Let it be.
> 
> Not necessarily. I just wrote on my blog [1] about this, and got a
> constructive comment [2], which I'll talk a little about.
> 
> Here's one example of a global goal: Reduce the learning curve of Gentoo
> and increase its usability.

The problem here is that the two don't necessarily correlate.  They
*can* but many times they don't.

A common thing I have heard about the comparison between Windows and
Linux is this:

In Windows, it is easy to learn how to do the simple things, and
extremely hard to do the complex things, if possible, at all.

In Linux, it is hard to learn how to do the simple things, yet it gets
easier to use the system as one uses it more and more.

As a prime example, I strongly believe that making Gentoo "as easy as
possible" can only come about by reducing its usability.  If there is a
large number of choices, no matter how well documented, it isn't easy
for a beginner.  The only way I can see to make installing Gentoo "as
easy as possible" is by removing choice and functionality to the point
of it being a few clicks of the mouse and everything being done for you.
The problem is that anything that is stated generally can be taken to an
extreme.  If you say "as easy as possible" then I think unattended
identical installations for all Gentoo machines.  After all, what's
easier than that?

I would *never* agree to this, nor force any member of any project that
I am a part of to participate in such an endeavour, so you now already
have at least one person opposed to it.  Would action be taken against
me?  Who knows.  The point is that we do not get paid.  You cannot force
volunteers to do things they do not want to do.

There are workable solutions to this problem, but none that I see as
very effective for us.

For one, we could leave things alone.  This works fairly well for a
project even as large as ours.  Sure, there are people out there that
think that this doesn't work, but the truth is that they might be
looking to have Gentoo become something that it is not.

Second, we could "fire" most of the developers and move to a paid
developer pool.  This would ensure that developers would do what they're
told.

Third, we could come up with some form of enforcement (CEO, council,
whatever) capable of "firing" developers that stray too far from the
proposed Gentoo goals.  This will quickly bring back the "cabal" screams
and will probably result in the very quick diminishing of the Gentoo
developer pool.

I think part of the problem is that many people are forgetting exactly
what Gentoo really is.  Gentoo is not a distribution of Linux.  Gentoo
is not anything more than a loosely bound group of developers all doing
their own thing in a collaborative and collective manner.  You cannot
use corporate thinking to manage such a beast.  We don't have mission
statements.  We don't have road maps.  We don't have quarterly earnings
and market projections.  We simply exist.  The only way we can give
Gentoo a direction is by restricting what we, as developers, are allowed
to do.  The only real restrictions we have right now are "be civil" and
"don't break stuff".  Anything beyond that is inhibiting one of our
greatest strengths, our individuality and individual ideas.

Do you want to be a part of a project that doesn't allow you to
implement some cool new feature because it might make Gentoo slightly
harder to use for some people and that's against the mission statement
so not allowed?

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]