Re: Questions for candidates

[Jeff Waugh <jdub perkypants org>]

<quote who="Pat Costello">

> I suppose what I am really trying to find out is, is there a collective
> desire to do something really big with the GNOME Desktop, to really ignite
> the world, to bring accessible computing to the huddled masses. Or is it
> all just a nice hobby for a small group of hackers? If the former, then we
> need to look at the culture of GNOME, if the latter, then the culture is
> fine by all accounts. 

As much as I dislike the phrase, I would have to describe your reasoning
above as a non-sequitur. How are these issues connected? To me, it does not
follow that our maintainer-centric structure means that we are unwilling or
unable to "do something really big with the GNOME Desktop". Here's why:

I believe that maintainership and leadership is a fundamental requirement
for us to move forward and kick Desktop arse. It is pleasing to various
classes of users that we have a Foundation Board, that we have a release
team that keeps us on schedule, and so on. These are the really obvious
forms of leadership within GNOME. But there are many areas of leadership.

You've defined "maintainers" very narrowly, essentially limited to the
people who say yes or no to patches in specific software modules. I don't
believe this is correct, and I raised it with Luis at GUADEC [1]. GNOME's
cross-project teams (i18n, a11y, docs, release, etc) generally have a leader
or co-leaders who are of similar standing in the project to software module
maintainers. All of these people cooperate to shift the project forward via
casual consensus.

As Dave pointed out, these maintainers may end up pushing the entire project
in a particular direction more effectively than module maintainers in some
cases. So, while there is some disadvantage in being removed from the code,
their breadth of influence across the project as a whole is greater.

Yes, it does take time, effort, diplomacy, social nous, passion and energy
to influence the project. All of those things raise the bar to a certain
level, but I don't believe they're artificial... Darwinism in action. I'm
here because I survived the gruelling trial-by-fire, which was particularly
hot because I'm not doing code things. :-)

So, I believe the maintainer structure helps us, and is possibly the only
sane way to manage such a massively distributed project. Note that we don't
have the kinds of maintainer-as-god problems that Debian has; that would be
going too far. Understanding responsibility - and feeling privileged to have
it - is hugely important to project stability and interest. This goes for
software modules, teams, everything.

Hmm, this email is getting long, so I'll fall back to the point form that my
brain works in:

  * We are a deeply succesful Free Software project, in many ways. We have
    an awesome community, with good balance.

  * We need to take advantage of our first-class Free Software structure,
    and enhance it where it has bugs.

  * Distribution of responsibility - which entails mentoring and spending a
    bit of time away from Emacs and talking with contributors - is going to
    be come more and more important. Think of Linus's lieutenants, but in
    the bigger, tougher, more widely distributed desktop space.

  * Ensuring we continue to work with other projects, rather than doing
    everything ourselves (Mozilla, OpenOffice.org, FreeDesktop.org, etc.)
    Oh, and "work with" doesn't mean "to the exclusion of". Co-maintaining
    code is a very good "working with"... yay GNOME Office! ;-)

Phew, and there's still a lot more to say on this topic,

- Jeff

[1] Luis put most team leaders in the 'outside influence on maintainers'
group in his diagram.

-- 
linux.conf.au 2004: Adelaide, Australia         http://lca2004.linux.org.au/
 
                    The Unix Way: Everything is a file.
                 The Linux Way: Everything is a filesystem.