[GRASS5] A request for control

[Markus Neteler]

On Tue, Sep 19, 2000 at 07:17:36PM -0700, Rich Shepard wrote:
>   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.

[...] 
>   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.
I feel this is exactly my intention. If only two programmers would be
there, it would take much more time to fix bugs. To distinguish between
stable and development releases, I suggested long time ago:
http://www.geog.uni-hannover.de/cgi-bin/minorweb.pl?A=READ&L=grass5/2000/5/4/2
.. see related mails in this thread.

>   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.
I fully agree.
 
[...]

>   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).
This was already sheduled for this summer. As summer starts to pass by,
we can go the feature freeze. No problem from my side.
 
>   2) A development/experimental version 5.1 be opened. This is known to be
> unstable and is not recommended for production environments.
See my above mail(s).
 
>   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?).

Well, to be clear here: Bruce Byars did not participate in GRASS 5
development from Oct 1999 onwards (GPL release). We did not receive and
source code from Baylor since that time (except some HTML pages).
To confirm please read the NEWS archive:
http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/NEWS.html

and ChangeLog (CVS):
http://www.geog.uni-hannover.de/grass/grass5/source/ChangeLog

At least "ChangeLog" is definitive objective as being generated by
the CVS itself.

I am not shure how Baylor is involved in GRASs 5 development. There is
a rumor about a new GUI, but it is not published yet.

I do not want to start a flame war here, just clarify some points.
Maybe the board of people to decide things should be more than one
person.

Just my 0.02 Euro here.

>   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.
For me an open source project is between dictatorship and anarchy, so
something like democracy. As many people are spending their time and
money in the project, they *are* allowed to take part in decisions.
The current way of development is quite good. As I am taking part in
GRASS development since end of 1997, I have some experience. Comparing
to 1999 the year 2000 is much more prosperous.

I think you can't say that the current developers (alex, andreas,
bernhard, bill, cho, david, frankw, job, john, justin, markus, michel,
radim = CVS developers + individual support) don't knwo what they
are doing. The strategy is quite clear:

 1. fix the existing bugs (I document them in BUGS file)
 2. improve GRASS with missing functionality (otherwise it won't
    survice)
 3. improve stability

To release GRASS 5 stable, we need a feature freeze and focus on
point (1). If you look into the ChangeLog file, you can see that
already a large amount of work has been done here!
 
>   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.
Well, this is another thing work is going on:

- Justin is working on a standardization of environment variables,
  a new "init" system linked to tcl/tk but open to GTK and others
- Frank Warmerdam has already written a preliminary GRASS I/O library
  to interface the GRASS database to external software (like OSSIM etc.)
- Radim has written/improved an *independent* DMBS driver which can be
  linked to ODBC and others (it is not an ODBC dependent driver!)
- etc.

So the developers are on that way you propose.

[...]
>   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.
If you compare development speed to former years, we have a high speed
development situation at time. No question: The stable release should
be published soon. But we have to track down the bugs first. And still
severe bugs are being detected. You are encouraged to test the basic
functions of current GRASS 5 release and extend my preliminary test suite
(find in source code).

Kind regards

 Markus Neteler

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