Re: Proposed Memebership Guidlines

[Adrian Custer <acuster nature berkeley edu>]

Hello everyone,

{NB This has been made obsolete because the proposed guideline has been
adopted. However, the foundation should still address this issue.} 


The GNOME foundation membership guidline as it now stands will be
superbly useful in the near term, the next few years, but, by alienating
the very people GNOME intends to help, will be detrimental to the GNOME
project over the long term. The foundation needs input from "pure users"
so as to plot a direction and encourage work on parts of the platform
that are most critical to users but might be less obvious to the
"anarchic community" of developers and other contributors.

In the near term, getting to GNOME 2.0 and even beyond is so much a
question of infrastructure that the needs of the platform are perhaps
clearer to the programmers than to anyone else. However, for GNOME to
address user needs or move beyond the duplication of current kinds of
software to develop new tools for users, GNOME will have to include
those users in its very core. As a non-developer but knowledgeable
computer user, I can see a gap between the desires, interests and
enthusiasm of developers and the needs of users. The GNOME foundation
must take it upon itself to bridge that gap because no one else will.

The opening paragraph of the Membership policy is set as a response to
the question of who is elligible for membership. This paragraph balances
quite nicely the desire to include only those who make "non-trivial"
contributions against the reluctance to exclude anyone in the community
who might belong for any reason. Since the membership committee is able
to review any application and make exceptions for any interested user,
there is little danger that anyone be excluded despite being interested
in the platform over the long term. My concern is over the explicit
committment that the GNOME foundation makes to be driven by the users as
opposed to assuming it is capable of guessing what their needs will be. 

Now developers are obviously users so they can easily identify many
needs that all users may have. There is also a very good line of
communication between users and developers albeit through bug
submissions and mailing lists which require a relatively sophisticated
user. I can already see a problem arising either when a computer user
has a pressing or overwhelmingly important need which never makes it to
the developers or when there are user needs that developers do not
share.

I have two examples of user needs that I realized developpers would
never run into, a non-gnome example and a gnumeric example . The library
system in this university allows you to renew your books online through
a telnet interface. This requires you to enter a bunch of information
and then type "ren #" for each book in the list of books you have
checked out. I met a historian grad student with 200+ books checked out
who would spend an hour every month renewing her books. At the school's
"linux user's group I asked why no one had ever writen a client or
expect script to do this automatically. It turned out none of the coders
ever went to the library. To this day, there is still not a nice client
available for all the students to use--it makes me hang my head in
shame, knowing there is a better way to do things, one that's just
beyond my capabilities.

As a second example, I've spent a lot of the past year playing with
gnumeric and using it for my research. The developers are doing an
absolutely amazing job with the spreadsheet. From the perspective of
linux users in the scientific community, the lack of a good spreadsheet
has been the biggest drawback to the use of a free software based
platfrom over the past seven years. So a user from the scientific
community might tell the foundation that a spreadsheet is overwhelmingly
more important to their adoption of the platform than a component
architecture. (I know this is not the only perspective---it's just an
example of developers not sharing the same needs as users.)  Consider
also a particular use of a spreadsheet when a user  inputs 8000+ lines
of data. I doubt any developer has ever spent two weeks just inputing
data into a computer. There are some serious issues which arise during
that kind of work, the kind of work users actually do, which make a
spreadsheet usable or useless. From a users' prespective, these elements
will make or break the ability to use the software and yet may be so
trivial and boring from a developer perspective that it won't get
addressed until the big issues are resolved. This is fine while there
are massive other needs but does have costs in terms of getting users to
the GNOME desktop.

These examples merely illustrate that there are times when developers
are going one way and users needing something else. Since the users
cannot develop on their own, and the developers are busy doing other
important (or fun) work, there is a real threat that a gap opens up. I
think the GNOME foundation should address this gap as the effort
matures. Part of this may include trying to open other channels of
comunication to new users, reaching out to the older users to find the
most needed pieces, encouraging work which is less interesting but more
useful and possibly encouraging an active part of the user community to
join the foundation.

I hope that these thoughts help the foundation consider where it is
headed. Thanks for all the great work and congratuations on getting off
the ground. 

cheers,
adrian custer

dept of entomology
uc berkeley
acuster nature berkeley educational