[GRASS5] A request for control

GRASS GRASS developer
1

  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@appl-ecosys.com

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

2

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@appl-ecosys.com>
To: <grass5@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@appl-ecosys.com

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

3

Hello Rich

Rich Shepard wrote:

  1) Bruce and Markus declare an immediate feature freeze.

Agreed.

  2) A development/experimental version 5.1 be opened.

Agreed.

  3) I urge the adoption of the linux kernal development model.
Specifically, only one or two individuals add any code to the CVS
tree.

This confuses me. In the near future, I will be finishing my re-write of
the environment variable handling functions, and since this change is in
a library, I will need to update hundreds of files to accomodate the new
changes. I don't understand how I am supposed to submit these changes to
a single person. Furthermore, will this person have the time to review
and commit my changes along with all the rest? With CVS write access I
simply commit my changes to the development tree with a single cvs
commit command. I thought that was the purpose of a development tree, to
allow developers to commit their changes and have others test them.

The only way I see this model working is that the maintainer(s) would
have to be very dedicated to the system, making sure that new code is
committed in a reasonable amount of time. Since most developers of open
source software use their spare time for the project, it seems that it
would be difficult to find somebody that could make that kind of
commitment.

Please bear in mind that this is the first open source project that I
have actively participated in, thus my confusion could easily be based
on my ignorance of such projects. Could you please give more details on
how this model works?

In addition, recommendations/suggestions/demands for new features are
submitted to Bruce Byars at Baylor for a decision.

I agree that somebody needs to make decisions but I would recommend at
least a small committee be formed instead of a single person. The reason
for this is that if the single person is forced away from the project
for some reason (vacation, hospitalization, etc) for an extended period
of time, then development will not stall. Also, I think that the
committee should include at least Bruce Byars and Markus Neteler.

This vision is needed to keep development focused.

Could either you or Bruce post this vision? I think it would be useful
for other developers to have a common vision to work towards.

  4) We solicit need and use statements from the user community

Agreed. Perhaps just a simple webpage for comments. The URL could be
included in the README files, the INSTALL file, the welcome message at
startup, etc.

  5) The GRASS core be separated from the front- and back ends.

Agreed, as you know I plan to take the first steps in that direction (if
I ever get back to it).

Anyway, just my 2 cents worth.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

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

4

Hello Rich,

thanks for speaking up about your concerns
about the GRASS development model.

In this mail, I hope to bring some clarification to the points
you have raised. As I am the one which basically does most of the
consulting of how the development process works I feel that
parts of your critical comments are going in my direction.
And in my overall opinion the GRASS development model is
improving constantly.

On Tue, Sep 19, 2000 at 07:17:36PM -0700, Rich Shepard wrote:

  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.

Can you give me some more examples on how you get this particular
impression?

  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).

Actually this kind of code freeze is already half way in place.

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

This has been proposed a couple of times now.
Markus wants some issues resolved first, but then we are looking
towards the stable release.

  3) I urge the adoption of the linux kernal development model.
Specifically, only one or two individuals add any code to the CVS tree.

We do have something like a linux kernel development model already
in place. Markus Neteler is the benevolent dictator of the GRASS5
series. Things are discussed on the development list and he
has the last word on it.

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.

I am not trying to dimish Bruce efforts for the GRASS community in
any here, we all know how much he did for the project.

When GRASS turned to have real free software license last year,
it was clear that it had to switch its development process to
that of a free software project. Free Software development processes
indeed are completly different from other software development processes.
They might even look chaotic or like an anarchy on first sight.
But they have proven to produce more stable software then
the conventional mechanisms. This is widely recognised.

(One paper often quoted is "The The Cathedral and the Bazaar":
http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ )

The key point with GRASS development is, that CVS is not loosing
the version history. Changes can easily watched by anybody and reverted
within a second. So we do have the most stable GRASS5 yet in there.
On this list you are seeing the tip of the iceberg of the discussion.
The changes made in the CVS are much more conservative.
Check the web interface: http://freegis.org/cgi-bin/viewcvs.cgi/grass/

  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.

We need input from the user community.
And we all appreciate them.

As for control. There is no _real_ control in a free software project.
At least not the way you are describing it. It does not exist for the
Linux Kernel ether.
You have to have a good management. And this only stays in power
with activity. Markus Neteler is the one doing the most coding work
for GRASS5. He also has a lot experience on managing the project.
This is, why he is the one having the last word.

But any arguments and code work is accepted on the grass development list.
I welcome any bigger role of you and Bruce on this basis.
This is a development mailing list and people will trust us more,
if we actually have a debate about arguments in here.
(You should see the Linux Kernel mailing lists.)

Personally I know that I have a tendency to aim for stability first
in a software project. Things going into a release of GRASS5 have to
be stable.

  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.

Yes. Though this is a plan for the development version.

I hope that I have addressed some sources of your uneasiness.
Please let the feedback coming in, so we can show you that we are
committed to a stable GRASS for its users.

Kind Regards,
  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

5

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@geog.uni-hannover.de with
subject 'unsubscribe grass5'

6

Hi all,

Well, I was waiting for something like this. First off, I have to say
thank you to all the developers out there who work so hard on
keeping things moving forward. This community has grown
tremendously in the past year.

Now a brief history lesson on GRASS 5.0. Markus and I agreed a
while back that there was the need for I guess what you would call
"project managers" for each new version of GRASS. This is necessary
for the following reasons. Each version is slightly different and there are
support issues with each. We agreed that 4.x would be our focus for
support, Markus and I were both working on 5 code but we felt that
since at the time he had a bit more time that we did, he would take the
lead for 5. (why that negative post?) We here at Baylor have since
been working on what will be GRASS 6.0 (real prelim stuff now),
experimenting with certain things. See how this was working?

Our staff provides a tremendous amount of personalized support for the
community, which we estimate has grown to 35-40k users (support can
go upwards of 60-75 email per day). We've been watching how things
have been evolving and are very pleased with the response from users.

However, I agree with Rich in that lately GRASS has become more of
a hackers tool than a useful GIS in some respects. Thus, I agree with an
immediate feature freeze.

We here work with commercial firms in some of our projects and I've
seen what happens to good products when too much is done to them.
Simple is better. Has anyone seen Corel Draw 9? It's so big and does
so much that it's unmanagable for everyday users. That is not what we
want in GRASS. CERL once posted a "timeline" for GRASS development
and at the end it was "implementation in every home". :slight_smile: The original team
had the vision of keeping things functional, a model which we have tried to
stick with.

I am willing (not excluding Markus) to start sheparding things along. We've
had a vision statement that I will also post. I think that user feedback is
extremely important and want to keep a positive dialogue. However, in my
past life experiences (away from academia) I can say that democracy does
not work when it comes to getting things done. Markus, email me with your
thoughts.

Now, to address what I know will come up. Just because you don't see us
everyday does not mean we aren't here. Our entire staff is only an email
away (Lisa and I are the focal points though). Points about how we are not
involved are TOTALLY WITHOUT MERIT. And publishing flaming
comments to that end are not constructive and unprofessional. We are part
of a laboratory that does much more than just GRASS work and to be honest
don't have the luxury of working each and every day on GRASS issues other
than support, which we have made a priority. If things move too slowly for
someone, I'm sorry. We've got to keep the lights on and food on the table.

Thus endeth my points. If anyone would like to discuss things with me, let
me know either by email or call me at 254-710-6814.

Bruce

Bruce_Byars@baylor.edu

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

7

Hi Bruce,

On Wed, Sep 20, 2000 at 09:51:44AM -0500, B. Byars wrote:

Well, I was waiting for something like this. First off, I have to say
thank you to all the developers out there who work so hard on
keeping things moving forward. This community has grown
tremendously in the past year.

I basically see the reason for this in the open development model
and the real free software license of GRASS.

We here at Baylor have since
been working on what will be GRASS 6.0 (real prelim stuff now),
experimenting with certain things.

I know that Bruce is the head for Grass4.3 and Markus for GRASS5.
And it is fine.

If Baylor is working on GRASS6 I hope that they will open their
experiments for the developers and the public. So we can try and
discuss them. Otherwise I cannot see how this can actually be a GRASS6.
So I am looking forward to see your proposal for the next version of GRASS.

(On the other hand nobody is keeping anybody from doing with GRASS what
they want, as long as the license is obeyed.)

Our staff provides a tremendous amount of personalized support for the
community, which we estimate has grown to 35-40k users (support can
go upwards of 60-75 email per day). We've been watching how things
have been evolving and are very pleased with the response from users.

This is good news. Thanks for sharing them.

However, I agree with Rich in that lately GRASS has become more of
a hackers tool than a useful GIS in some respects.

Can you give me any facts which support this claim?
From what I see GRASS5 development has accelerated and mostly towards
long term stability.

Thus, I agree with an
immediate feature freeze.

It is in the works and was proposed a couple of times now.
Though the manager for GRASS5 has to decide. (See Markus post.)

We here work with commercial firms in some of our projects and I've
seen what happens to good products when too much is done to them.

Agreed.

Simple is better.

This is exactly the direction in which GRASS is going.
I would be interested to hear why people might get the impression that
it is not the case.

We are part of a laboratory that does much more than just GRASS work
and to be honest don't have the luxury of working each and every day
on GRASS issues other than support, which we have made a priority. If
things move too slowly for someone, I'm sorry. We've got to keep the
lights on and food on the table.

Well there is nothing wrong with doing your things in your speed,
but I fail to see why GRASS should move at the same speed if there
people having the competence and the experience to move the development
faster and more stable.

Deciding the future of such a big project in completly private discussions
is probably not a good idea.
I am not saying that we should make a public vote about GRASS future,
but in the Linux Kernel developmemt, Rich was suggesting:
each step is discussed quite intensely.
This is also the way science works and I believe GRASS development
should work.

Regards,
  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

8

Markus Neteler wrote:

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.

Kind regards

Markus Neteler

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

Markus,

I fully support that you have been and continue to head up the GRASS 5
development. However, I just wanted to clarify that a lot of the work being done
at Baylor is in the user support area. We answer tons of e-mails from the user
community about how to set up and use GRASS when they come across problems and how
to accomplish the various tasks they wish to do. GRASS is definitely a worthy
team project, and the user community is anxiously anticipating a stable release of
GRASS 5.

Thanks,
Lisa

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

9

Hi David,

I have Blas compiled and it is available under the Cygwin environment
for Windows NT and 2000 as well as Solaris. DITTO with LAPACK.

Will my knowledge of Grass and its use in this application, I would
say right off that the best way to use Blas library is to incorporate
it in the src/CMD/head/os_specific/xxx files where xxx refers to
your specific platform. When you make a new or edit an old
Gmakefile, add the $(BLASLIB) to the library line. Ditto with
LAPACK.

You compile it locally on your machine. Put it into your
/usr/local/lib area and if necessary run a ranlib on it.

Give me some specific section in grass and I will help
you if you need some assistance.

John Huddleston

----- Original Message -----
From: "David D Gray" <ddgray@armadce.demon.co.uk>
To: "John Huddleston" <jhudd@lamar.colostate.edu>
Sent: Wednesday, September 20, 2000 11:53 AM
Subject: BLAS et al

John

Perhaps as you know something about the linear algebra routines, you
could advise me on one thing: Are there any special provisions that you
know of that might need to be taken care of in installing BLAS and
LAPACK into GRASS? I mean for things like cross-platform portability. I
am trying to decide whether we

1) Link to system libs, thus making these a dependency of GRASS.

or

2) Bundle BLAS and LAPACK with GRASS. Then there may be platform issues
in compilation.

On linux/unix/i386, we just need a link to g2c.h (or f2c.h) and a
prototype file, can be done with `f2c -P'. Markus has suggested a set of
wrapper routines, functions and macros, for making the special features
(re fortran) transparent to developers.

Option 1 would enable easier plugin to local optimised libraries,
whether created by hand (assembler routines etc. by the system vendor)
or something like ATLAS, but might be prone to version skew for others.

On another point, in your reply to Rich Shephard's posting on the
development model, you said:

John Huddleston wrote:
>
> [...]
> 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.

[my emphases]

Can you explain more precisely? I knew Avenue was getting dropped (and
Python maybe adopted), but I thought that shapefiles was just up for an
upgrade?

Thanks, regards

David

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

10

On Wed, 20 Sep 2000, Bernhard Reiter wrote:

  First, the mail server at Baylor (byvax2.baylor.edu) has been down all
day. A message I sent to CAGSR at 0600 (PDST) was not delivered by 1400;
they'll keep trying. This is the reason Bruce hasn't responded to any
messages.

We do have something like a linux kernel development model already in
place. Markus Neteler is the benevolent dictator of the GRASS5 series.
Things are discussed on the development list and he has the last word on
it.

  I've been following GRASS since about 1990; I lurked on the mail list at
CERL waiting for a no cost version to come out for those of us who were
UNIX-challenged.

  My understanding of the past couple of years is that the US Government,
specifically the US Army's Construction Engineering Research Lab (CERL)
officially transferred legal responsibility for GRASS to Baylor University.
Not to Bruce or Lisa, but to the University. In addition to the legal
responsibility, Baylor University assumed development responsibility. And
control.

  I've visited with Bruce, Lisa and crew at CAGSR and I've held many
discussions with them about the use of SWAT and GRASS for aquatic modeling
and hydrologic modeling. My experience is that they are easy going and
grateful for all the help they can get. They are also unstinting in the help
that they give. This does not mean that they have relinquished their legal
or contractual responsibility toward GRASS and the user community.

  My understanding, which may well be wrong, is that Bruce accepted Markus'
offer to lead the GRASS-5 development effort. This does not mean that he
relinquished overall control, just the day-to-day control. In the corporate
world, Bruce's role is that of CEO (responsible for strategy and the overall
well-being of the company) and Markus' role is that of the COO, directing
the daily routine so the company reaches the objectives set by the Board of
Directors and the CEO. It is the CEO who has the final say on everything.

  Regardless, all help is welcome; from end users, hacker geeks and the morbidly
curious.

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@appl-ecosys.com

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

11

Lisa,

your efforts in supporting GRASS users are greatly appreciated!

It is no shame and no secret that Baylor has not contributed much
source code lately. We know that supporting users is at least
as important as writing source code.

I hope to get more input from you about what could be made better
for the users. Unfortunalty I do not see much of the email you
get about grass. It there a way we could organise this email to
be more accessible or get the summary of the feedback to us (developers)?
There might be some problems which can be addressed from the
development side for the next versions.

From what I have understand now, we have to put even more pressure
on releasing a stable GRASS5 soon. Is Markus revised schedule going in the
right direction?

I feel that together we can organise User support and development
even better and be proud of the join effort.

Kind Regards,
  Bernhard

On Wed, Sep 20, 2000 at 11:26:29AM -0500, Lisa Zygo wrote:

Markus Neteler wrote:

> 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).

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

I fully support that you have been and continue to head up the GRASS 5
development. However, I just wanted to clarify that a lot of the work being done
at Baylor is in the user support area. We answer tons of e-mails from the user
community about how to set up and use GRASS when they come across problems and how
to accomplish the various tasks they wish to do. GRASS is definitely a worthy
team project, and the user community is anxiously anticipating a stable release of
GRASS 5.

Thanks,
Lisa

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

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

12

Bruce

I appreciate all that Baylor has done in jump starting Grass development
and then maintaining excellent support for Grass users. However, as a
developer, I have some concerns regarding your comments and I would like
to try to show you how I see things. Please note that some of my
comments could be interpreted as attacks on you (and Richard) but they
are not. I have been noted in the past that my writing style can be
interpreted that way since I tend to be straightforward when I am trying
to make a point. I will apologize in advance if you (or Richard) feel my
comments are harsh.

"B. Byars" wrote:

Markus and I agreed a
while back that there was the need for I guess what you would call
"project managers" for each new version of GRASS.

This makes sense for grass 4 and grass 5 since they are drastically
different. But why do we need a separate "project manager" for the next
version of grass? Are your ideas for grass 6 going to drastically change
grass again?

(why that negative post?)

I don't know which post you are referring to, but I can tell you why I
personally have resentment towards this thread (NOTE: the thread NOT the
people!!). From a developers point of view we were going along trying to
get the features we feel are needed for a good stable release such as
the new autoconf feature to improve installation, the environment
variable re-write so environment variables act as people expect them to,
and the new GUI startup procedure to simplify grass use. Then Richard
comes along and claims that there is a problem with the grass
development process but does not specify exactly what this problem is
except for a general statement that we are not heading in the right
direction. Then he suggests that we should turn to you to help us with
this problem.

I'm sorry, but to me this type of post seems like my boss coming to me
and saying I have a problem and that he knows how to fix it and then
walking away. This would obviously leave me in a state where I want to
run after him and say "I have no idea what you're talking about, please
explain". And yes, I would resent the way he informed me of my problem.

Do you (and Richard) now understand our bewilderment and confusion and
that we still don't really see the specific problem you are talking
about? Making a post claiming there is a problem and not stating
explicit examples of said problem leads to confusion and yes,
resentment.

So please, tell us what exactly is the problem. How are we going in the
wrong direction? Then we will understand and be able to address these
concerns.

We here at Baylor have since
been working on what will be GRASS 6.0 (real prelim stuff now),
experimenting with certain things.

Why haven't you posted any details of your proposal to the developers?
This is the first time I have heard of grass 6.

See how this was working?

Yes, and I do not agree with it. I see grass 5 being developed into a
stable version and then being further developed into grass 6. I do not
see it becoming stable, then being frozen and a completely different
source tree being used for grass 6. Are you actually proposing two
separate development branches? One for grass 5 and one for grass 6?
Won't grass 6 be based on grass 5? In which case, the developers need to
know what the future plans are. That way, when we write code, we can
write in preparation for the future. If there is one thing that really
bothers me, it is writing code, then having someone say they wanted it
done this way to accomodate a future feature, then having to go back and
write the code again the way I would have done it if I had known of this
future feature in the first place. Therefore, all future ideas for the
advancement of code should be discussed.

Another point I would like to make is that you have said you have done
preliminary work on grass 6. What if (in this hypothetical and VERY
unlikely scenario) none of the developers like your ideas. Will you
throw all the work you have done away? I doubt this will actually
happen, I am only trying to make a point that in open source
development, new features need to be discussed among all developers
before, during, and after the work is done. It is the only way to ensure
that the overall code structure remains synchronized properly.

Correct me if I'm wrong but it appears this is not the case with what
you have done with grass 6.

Our staff provides a tremendous amount of personalized support for the
community, which we estimate has grown to 35-40k users (support can
go upwards of 60-75 email per day). We've been watching how things
have been evolving and are very pleased with the response from users.

Great! That's super! I didn't realize we had so many users! I hope you
can maintain such a high level of support.

However, I agree with Rich in that lately GRASS has become more of
a hackers tool than a useful GIS in some respects.

Again, please explain the problem. We are failing to see your point of
view. We do not see grass getting more complex and bloated. We see it
getting simpler and more robust. Please show us what we're missing.

We've had a vision statement that I will also post. I think that user
feedback is extremely important and want to keep a positive dialogue.

Then why didn't you post it in this post? And your use of the past tense
indicates that you have had this vision statement for some time. Why
didn't you post it earlier? And if it has been finalized, why weren't
the developers consulted?

However, in my past life experiences (away from academia) I can say
that democracy does not work when it comes to getting things done.

True, but the developers need the opportunity to provide their input.
Even if they never provide any input, they still need that opportunity.

Points about how we are not involved are TOTALLY WITHOUT MERIT.

But how are we supposed to know this? Taking myself as an example,
before I read your post, the only thing I knew that Baylor was doing was
support for grass 4. Very few, if any, changes have been committed to
the CVS tree from Baylor in recent months. And you yourself have posted
no more than a few messages a month to the grass developers list in the
last three months. Please tell me what are the indicators that tell us
that Baylor has been actively contributing to the development of grass?
Please don't think I am attacking you. I realize that Baylor has other
things to do as do I and we can't dedicate all our time to the project.
I am just trying to show you how I see it as a developer. And as such, I
need participation from my leaders in order to determine if my work
conforms with the goals of the project. How am I supposed to know if my
code conforms to your vision statement when I don't even know what that
vision is? What do you think the lack of participation from Baylor in
recent discussions concerning code development signifies to us? What it
signifies to me, is that I have no idea whether or not you even know
what we are doing. Do you see my point of view? Yes, points about how
you are not involved may be without merit, but truly, how were we to
know?

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

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

13

Hi Bernhard,

I am very much in favor of Markus' schedule. I also appreciate all the hard work you
all have been doing.

I always try to pay attention to the developers' list. For the most part, the
suggestions from users have been in line with what the developers are planning or are
working on. Many of their questions deal with running GRASS and capabilities that are
present in GRASS (but they just have not read the manuals to know they exist). Another
big topic is importing data from other sources. Usually these exist or the developers
have been debugging them to work in GRASS 5. I have also directed some people to join
the GRASS mailing list because of their ideas. In the future, I can post some of these
ideas myself, but I thought it would come better from the actual users.

Overall, GRASS users are pleased to see that GRASS is still available and progressing.
Occassionally, we will receive an e-mail simply saying thanks for the hard work. I have
passed some of these along to Markus.

Thanks,
Lisa

Bernhard Reiter wrote:

Lisa,

your efforts in supporting GRASS users are greatly appreciated!

It is no shame and no secret that Baylor has not contributed much
source code lately. We know that supporting users is at least
as important as writing source code.

I hope to get more input from you about what could be made better
for the users. Unfortunalty I do not see much of the email you
get about grass. It there a way we could organise this email to
be more accessible or get the summary of the feedback to us (developers)?
There might be some problems which can be addressed from the
development side for the next versions.

From what I have understand now, we have to put even more pressure
on releasing a stable GRASS5 soon. Is Markus revised schedule going in the
right direction?

I feel that together we can organise User support and development
even better and be proud of the join effort.

Kind Regards,
        Bernhard

On Wed, Sep 20, 2000 at 11:26:29AM -0500, Lisa Zygo wrote:
> Markus Neteler wrote:

> > 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).

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

> I fully support that you have been and continue to head up the GRASS 5
> development. However, I just wanted to clarify that a lot of the work being done
> at Baylor is in the user support area. We answer tons of e-mails from the user
> community about how to set up and use GRASS when they come across problems and how
> to accomplish the various tasks they wish to do. GRASS is definitely a worthy
> team project, and the user community is anxiously anticipating a stable release of
> GRASS 5.
>
> Thanks,
> Lisa
>
>
> ----------------------------------------
> If you want to unsubscribe from GRASS Development Team mailing list write to:
> minordomo@geog.uni-hannover.de with
> subject 'unsubscribe grass5'

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)

  ------------------------------------------------------------------------
   Part 1.2Type: application/pgp-signature

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

14

On Thu, Sep 21, 2000 at 08:48:15AM -0500, Lisa Zygo wrote:

I always try to pay attention to the developers' list. For the most
part, the suggestions from users have been in line with what the
developers are planning or are working on.

Good. This is a good sign.

I have
also directed some people to join the GRASS mailing list because of
their ideas. In the future, I can post some of these ideas myself,
but I thought it would come better from the actual users.

We welcome both.
Some users might be reluctant to speak up at first, so
feel free to post your ideas.

Regards,
  Bernhard

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)