[GRASS-dev] Some ideas about future GRASS development

[Jarosław Jasiewicz]

Hi all!

That rather radical ideas I present here are rather for future, at least 
for GRASS 8, but I'd like present it now for long-term reflection.

Probably all notice that for over two years there is big increase in 
add-on repository (including me). There are modules of different 
quality: from fully GRASS toolsets, to shell or python scripts, from  
actively developed tools to abandoned, from all-purpose tools to very 
specialized etc. I also think that that activity will be grown due to 
substitute shell script by python

Similar situation is in main GRASS branch: there are modules for all 
like conversion tools, interpolation methods, georeferencing etc, and 
very specialized modules for very limited group of users (like wild 
fire), there are also some modules out of date.

I'm not enthusiastic about moving new modules into main branch. Almost 
every module has different coding style and it will lasting in future 
that GRASS would be difficult to maintain. On the other hand some people 
complains that some interesting modules are only available as add-ons (I 
assume for some reasons they cannot install it)

So my suggestion is to rearrange future GRASS form two layers (main 
branch/add-on) into three layers architecture:

1) GRASS core layer: much limited limited than now, only GIS environment 
and basic, all-puropse tools, slow changes, great stability
2) GRASS toolset layer: oficcial GRASS thematic tools and toolsets (like 
terrain analysis, hydrological analysis, photo-interpretation, landscape 
analysis etc,) every toolset with its maintainer, rapid development, new 
ready to use tools after quality control may appear here, also some of 
current main branch tool shall be moved to that layer
3) GRASS community layer:  everything else like experimental, actively 
development new tools, that what do not pass quality control, simple 
scripts, etc....

What benefits:
for developers and contributors: much clear situation and better 
publication path.
 Toolset layer should be much more open for new tools than current GRASS 
main branch

for users: faster access to new tools.
There is no doubt that new tools are faster developed (less risk) than 
GRASS core
 Binaries with toolsets could be maintained as separate 
apt/urpmi/pacman/yum/exe etc packages, so it may appear in linux 
repository separetly form GRASS core.

There is only loose ideas. Most of them are of course taken from R 
(core/toolsets/rest of packages; separate core and package development) 
but I think it is worth of some discuss ...

regards
Jarek