[GRASS5] A request for control

[Bernhard Reiter]

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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 236 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20000920/e5566190/attachment.bin