Re: [chat] Re: The Linux Article Of The Year

[invisible ink <jdub@xxxxxxxxxxxxxx>]

Marcel Kunath:

> In 2000 (after 2 years using suse and frequenting the mailing list) I was
> giving feedback to SuSE regarding their admin tool yast and what features
> it lacked. I got told off and their reply was basically "nobody would ever
> want such feature". Two years later yast2 had the feature implemented I
> was asking for. By that time I had lost interest in SuSE. It's not the
> fact that it took them two years to implement it. It was the fact that
> they didn't acknowledge that a user made a implementation request they
> would eventually get around to. They don't use an open bugzilla format so
> one never knows what is going on with SuSE development efforts. 

Unfortunately, in that case, you're not really talking about contributing to
an Open Source project. Whatever the availability of the YaST source code,
the project is run essentially as a proprietary software effort, much in the
same way as Red Hat's admin tools, etc (though they do run a mostly-public
bugzilla, and sometimes take patches from external developers).

> Then last year I gave Gentoo a couple of pointers (re: portage and 
> distfiles flexibility and portage and --security) and there was little 
> response. The features are getting talked about more often now (on 
> bugzilla) and I figure eventually they will be implemented. 

Sounds like you're going after big projects that take a while to accept
changes. That's pretty normal -> a project with many users will err on the
side of stability, and introduce large scale, intrusive or otherwise wide
reaching changes slowly. Perhaps you should start with a smaller project in
more immediate need of your help?

> The developer community has to realize there are two ways to contribute.
> The standard phrase: "go code it yourself" just doesn't apply anymore
> since Linux is not a field made up of code monkeys only.

By the same token, "he who codes, wins": Ultimately, it's the person who
writes the patches and maintains the software that makes the decisions. We
can change that slightly to "he who does the work, wins" in many cases, but
often enough it comes down to the lingua franca of Free Software: code.

> There is the people who can code and then there is the people who are
> technologically literate but don't want to code but plan, come up with
> ideas and give feedback to the coders, and help manage development issues
> (e.g. HR, project management, documentation, etc.). 

The trouble with this is the pure weight of "smarty-pants non-coders" on the
people doing the "real work". Apologies for the choice of words there. ;-)
Here's a pissweak ASCII art breakdown of your average garden variety Free
Software project:

                      /\
                     /  \    <- beatified leadership
                    / LS \      "benevolent dicatator for life", etc.
                   /______\
                  /        \
                 / officers \   <- trusted leadership
                / in command \     module maintainers, "lieutenants", etc.
               /______________\
              /                \
             /  contributing    \   <- hackers who regularly contribute and
            /           hackers  \     may be responsible for smaller chunks
           /______________________\
          /                        \
         / contributing documentors \   <- many other important contributors
        / translators, artists, etc. \     and less regular hackers
       /______________________________\
      /                                \
     / deeply interested user community \   <- bug reporters and list posters
    /____________________________________\
   /                                      \
  / teeming hordes of users and customers! \   <- quiet majority
 /__________________________________________\


At the top you have what I call the "beatified leadership" - the people who
have an almost spiritual leadership of the project. It may not be in every
day direction, but they are invoked as yardsticks for almost everything. See
Larry Wall, Guido van Rossum, Andrew Tridgell, Linus Torvalds, etc.

The "trusted leadership" are the lifeblood of progress and change. Some
manage particular chunks of a project (on module or niche lines), some are
well-known contributors to every facet. These people are generally the most
actively involved group in day-to-day hacking and management. See the Linux
"trusted lieutenants", GNOME's module maintainers and sub-project leaders.

Then you have a large group of regularly contributing hackers, generally
working on bug fixes, smaller features, contributing to architectural plans,
etc. There is often a divide between employed hackers and volunteer hackers
here -> volunteer hackers (more often than not) simply don't have the time
to shift up to critical module maintenance or project leadership roles,
depending on the project. Consider projects like Apache, Linux, GNOME, and
others that have attracted dedicated support and contribution from various
companies.

Larger again is the group of documentors, translators, artists, usability
testers, Q&A testers, and less regular hackers. These are contributors to
sub-projects or parts of the project that require specific skills. Together,
it is a very large group, generally outnumbering the developers.

The "deeply interested" user community is the subsection of users you'll
find on community websites, mailing lists, Slashdot, etc. They'll often help
other users and contribute bugfixes or minor documentation. They make for an
awesome force when rallied together!

Then you have "normal" users and customers, who use your project but are not
interested enough to contribute or get involved directly. Once upon a time
they were almost always technical users who would be involved in other Free
Software projects (so understand how the process works), but these days,
it's very likely that you'll have users who either a) are completely
non-technical and/or b) don't even know they're using your stuff! :-)


So, to contribute in the ways that you've mentioned, you basically have to
go through everyone up through "deeply interested users" to "officers in
command". I can say from experience that it's a massive, massive challenge
to do that! :-) Normally such input would be filtered through sub-project
leaders or module maintainers, bug tracking systems, etc.

Now, that's not a bad thing -> you cannot completely flatten the project
structure, because it would be even more stressful on the small group of
people who do most of the work; you cannot remove the meritocracy because
it's the best low-tech, low-bureaucracy method we have for measuring trust
and contribution.


I'd launch into an account of my experiences with GNOME, but this mail is
long enough as it is. ;-)

- ii

-- 
  Penguinillas Pack GNUzis