[GRASS5] A request for control

[Rich Shepard]

  I'm am bothered by what I see happening to GRASS-5. To understand why I'm
bothered, and why I'm not blaming anyone for anything, let me tell you a bit
of my background.

  My first book on computers was given to me as a gift in 1959. Since then,
I've worked on mainframes, minis and micros of various flavors and running
various OSes. Over this time my interest has been on the computer as a means
to an end, not an end in itself. This means that while I have done extensive
scientific and (more recently) business application coding, I was never
interested in becoming a SysAdmin or expert in twiddling the OS. This
long-held attitude applies to my view of GRASS, too.

  Over the past 13 years, I've used GISes on many different projects because
it was the most appropriate tool for the job. Among the GIS software I've
used (ARC/Info on minis and PCs, Idrisi, MapInfo, and GRASS), GRASS is by
far the most compentent and useful.

  A major reason for this usefulness is the tight integration of GRASS and
ancillary software, specifically SWAT, R and PostgreSQL. However, this
integration and overall usefulness depends on a stable base. And this is the
cause of my unease.

  I see from the developer's list that too many of us have become wrapped up
in the development process and have apparently lost sight of the purpose of
the process: to produce a stable release that works on a number of
platforms.

  Part of the problem I see stems from different needs and interests by
GRASS users and developers; the same differences I saw with MapInfo. It
appears to me that the majority of development effort and control is held by
academic users. Whether for teaching, research or teaching students how to
write a GIS, the development process is frequently the goal for these folks.
Other users are in the private sector. We have limited time to spend on
GRASS development, but we need a stable product that is a means to an end; a
tool to solve real world problems. And someone is paying us to solve those
problems so we better be quick, good and acceptably priced. Governments,
agencies, regulators and the consultants they hire (from academia and the
private sector) are also looking for solutions to highly complex
environmental or resource allocation issues. These users also need a stable,
reliable platform they can count on.

  Another way of grouping us users is by the medium used for the display of
results. Some of us -- and we're definitely in this category -- must have
professional quality output on paper. Our analytical results are integral
components of permit applications, reports and published studies. Other end
users produce results on the computer monitor (e.g., police, fire and
medical emergency dispatchers) while still others want to serve maps up on
the Web.

  I don't think that I am alone in my unease. And I have some specific
suggestions to resolve my unease and make GRASS development and use better
for everyone.

  1) Bruce and Markus declare an immediate feature freeze. This means that
5.0 development is restricted to bug elimination and the completion of
included features (such as the MapInfo->GRASS translator which I am holding
up).

  2) A development/experimental version 5.1 be opened. This is known to be
unstable and is not recommended for production environments.

  3) I urge the adoption of the linux kernal development model.
Specifically, only one or two individuals add any code to the CVS tree. In
addition, recommendations/suggestions/demands for new features are submitted
to Bruce Byars at Baylor for a decision. No, we do not have a democracy here
because it's turning into an anarchy. Bruce was instrumental in having CERL
transfer GRASS to Baylor for continued development and he has a mature,
inclusive and valuable vision for the long-term development of GRASS. This
vision is needed to keep development focused. Bruce is the final arbiter of
all disagreements (we are all gentlemen here, aren't we?).

  4) We solicit need and use statements from the user community to remind us
all of the variety of applications for which GRASS is the solution. We all
tend to get wrapped up in our own situations and we lose sight of the bigger
picture of the real world. Sometimes our disparate needs mesh very well,
sometimes they conflict. I want to see Bruce make the decisions, and I'm
certainly willing to abide by them for the good of GRASS and the society it
has created.

  5) The GRASS core be separated from the front- and back ends. That is
there should be a standardized API for GUIs and databases. GRASS should not
have everyone's favorite (or desired) built in. For example, I'm working on
a gtk+ GUI front end; others may want one a GUI built with tcl/tk, java,
C++, python, or .... Same for the database back end. There will be a default
database, but it will be held on by the same hooks as any other. You can add
an ODBC driver to any database your organization mandates or you prefer. The
advantage of this model is that customization is maximized. The web site
would have an "options" area where any of us can post our favorite GUI,
database backend or other addon. Users can select whichever tickles their
fancies. This takes away the need for bloated code and hurt feelings from
those whose favorite idea isn't part of the core distribution.

  GRASS is maturing and gaining wider attention among potential users. We
need an orderly development process so as to not scare off these future
users and supporters. While I am willing to modify my suggestions here, I
strongly urge the control I've described as the only way GRASS will continue
to survive and develop over the next year and more.

  Thanks for reading this message. I take full responsibility for these
statements and I'll be happy to justify them more if need be. But, I want to
see changes made, and made very quickly.

Rich


Dr. Richard B. Shepard, President

                       Applied Ecosystem Services, Inc. (TM)
              Making environmentally-responsible mining happen. (SM)         
                       --------------------------------
            2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
 + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard at appl-ecosys.com


---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'