[GRASS-dev] GRASS-TNG

[Michael Barton]

This illustrates both the advantages and disadvantages of working within the
existing team approach.

If you set off on your own, you can do this pretty much how your vision
leads you. You have considerable freedom of design and architecture. You
don't need to worry about how other people think a GIS should function,
backwards compatibility issues, of differences in software approaches.
However, you also face the issues that Maris and others have raised about
resources not just for development but also for maintenance over the long
term, questions of value added to the existing suite of programs, building a
user base, etc.

If you work within the existing framework, you get access to a large
user/tester base, an existing development community, development servers
(cvs and svn), a lot of good ideas, and other as  yet nebulous but growing
advantages of being in an OSGEO project (hopefully we will be). You also
lose considerable "freedom" in terms of how you approach software
development. You have to contend with other opinions, an open source
"Hippocratic oath" (first, don't break anything), backward compatibility
requirements of a very large user base, etc. We've gone through the
complications of electing a Project Steering Committee and maintaining an
active developer list to have a way to deal with these latter issues, but it
cannot help but slow the speed of development somewhat--and especially the
implementation of "radical" changes (We've been discussing a change in the
raster data model for how long?). Nevertheless, an important part of the
ongoing discussion in this community is to think about what an "ideal" GIS
should "look like" and how to go about implementing this. There are a lot of
heavy GIS users in this community that have excellent and forward thinking
ideas on this.

I think that the GRASS project is very open to improvements, including code
modernization and replacement. Like most such projects of such size and
scope, it has fewer contributors than it needs. But the goal is to provide a
top end GIS, not to maintain historical code for its own sake. Development
team members are regularly prototyping and implementing new and revised
code. There is also consideration of the pragmatics of how to maintain code
over time with volunteer developers.

If you'd like to develop a new GIS program for the experience and pleasure
of doing so, or simply aren't comfortable in a team environment, I guess you
need to follow your dream. However, speaking as one Barton to another ;-) ,
I think your efforts would have a lot more impact and better serve the
global community that needs open source GIS tools if you contributed to the
GRASS project (or another team effort like Saga or QGIS) where your work
could benefit from the synergy of collaborating with others that share your
overall goals. 

Michael


On 2/21/07 12:35 PM, "Radek Bartoň" <xbarto33 at stud.fit.vutbr.cz> wrote:

> On Wednesday 21 of February 2007 19:03:22 Glynn Clements wrote:
>> So you're essentially talking about re-writing a complete GIS from
>> scratch? In which case, why use the "GRASS" name?
> 
> I mean and I don't. It's because of a way how I approach to my project's
> design. I'm starting to think about an abstract GIS package for easy
> development of modules (which can be used same way as GRASS's ones) and how
> it should "ideally" look like. Then I/we'll be clarifying that idea to more
> details so that certain shape of it will appear. When we'll be satisfied with
> its shape then I would be the best time to proceed to some prototype
> implementation to prove that concept could work. And then it'll be just up to
> all developers current or new ones if some prototype part of implementation
> will stay or if they'll be replaced with current GRASS code or completely new
> and optimal one.
> 
>> GRASS' value isn't in its libraries, but in its modules. Those modules
>> depend upon the existing (crummy) API provided by the libraries.
> 
> Yes, I completely agree with that. but tall tree can't have wormy roots.
> 
>> AFAICT, the only part of the GRASS code which would be of any use for
>> the "TNG" project would be the fundamental algorithms contained in the
>> modules.
> 
> I agree again. I'm not afraid to take a C code of an module read it and
> rewrite it in clearer way if I would have powerfull tools to do that.

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton