[GRASS5] A request for control

[John Huddleston]

Thank you Rich, I agree with you about the need for a
separation of stable and development versions.  CVS
facilitates this by allowing us to branch off for a new
development section.  Commits made to this branch do
NOT affect the main line or HEAD of the GRASS
system.  The use of branching is more a matter of training
and policy.

Second, Markus ( and I assume Bernhard ) are getting
mail messages each time any change is made to the system.
You may relax and feel confidant that if a contributor
has exceeded their comfort level, the user will be blocked
from using the write-only CVS.  I would hope that all
the work done to port GRASS to the NT platform has
benefited the system overall.  Over 1500 Gmakefiles
were hand edited to make the system conform to a standard.
and/or bring in the correct libraries.  The NT/2000 audience
is waiting for a GRASS release.  Your point is well
taken, GRASS is a tool that is working now and is a source
of income for most on the GRASS list.  On the other side of
the coin there could be more people who would fall into
this category if the Windows GUI worked.

Third, and a curious turn of events, ESRI's next release will
no longer support Avenue scripts and will not support shapefiles.
All the developers who have put time and money into developing
in these two areas will not have an upgrade path.  Grass5 can
be an avenue (no pun intended) to those who want an open
GIS.  The ideas that developers bring to this forum are partly
to enhance the product and partly a result of pressure brought
on them to employ emerging technologies.

Perhaps we can take a neutral stance on this, perhaps lock
down some core GRASS source directories, and leave open
areas for development.  However, I would still urge us to
think creatively.   To most of us this comes from an open
system that welcomes our work.

John Huddleston


----- Original Message -----
From: "Rich Shepard" <rshepard at appl-ecosys.com>
To: <grass5 at geog.uni-hannover.de>
Sent: Tuesday, September 19, 2000 8:17 PM
Subject: [GRASS5] A request for control


>   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'