[GRASS-dev] discussion: replacing ps.map

Tue Mar 27 14:08:11 EDT 2007

Hello,

On Tue, Mar 27, 2007 at 07:26:27PM +0200, Jachym Cepicky wrote:
> hi
> 
> 2007/3/27, tlaronde at polynum.com <tlaronde at polynum.com>:
> >Hello,
> >
> >On Tue, Mar 27, 2007 at 04:50:51PM +0200, Jachym Cepicky wrote:
> >> Hallo,
> >>
> >> [....]
> >>
> >
> >I'd like the developers of my dear sibling project to explain me a
> >couple of things.
> >
> >1) How can you constantly repeat that you are not sufficiently numerous
> >to maintain GRASS when the CERL team was mainly, as it seems from the
> >copyrights, 4 men. How can you explain that KerGIS has kept everything,
> >does not plan to throw out things, has added things, while there is only
> >_1_ developer (part time developer since I have other products to
> >develop too ; and progress is slow, but constant)? Do you simply
> >claim---that would be valid---that open source is simply not efficient?
> 
> Correct me, if I'm wrong, but I would say, that currently, if you
> would clue all part-developers together, you would not get more than 5
> full time developers. Most of us have very small experience with C,
> which is essential. GRASS has growed a bit, since the CERL times -
> compared to this, I would expect, that the ratio between lines of code
> and number of developers is significantly worst today.

You are wrong on the engineering side. The number of lines of code,
especially for GPL GRASS, is not the correct criterion, since there has
been a lot of duplication; you are still AFAIK shipping contributed and 
moderately useful code; and since a huge portion of added code is on the
user graphical interface with several distinct and orphaned alternatives.

What I mean is that the difficulties you---as a team---are facing, are
difficulties you created. no-one can make excuses from a situation one
has created :)

>[..] 
> >
> >3) How can you propose to drop ps.map(1) while the MapServer
> >alternative:
> >        a) does not provide the same features as ps.map(1)---no legend, no
> >        scalebar etc.---;
> 
> are we talking about same mapserver? http://mapserver.gis.umn.edu

Yes from the very link you sent.

> 
> >        b) relies on PDFlib Lite, that is a stripped down version of the
> >        commercial PDFlib, whose licence would be suddenly acceptable while
> >        you frown at OpenMotif or QT?
> 
> Sorry, I did not study licences of all possible dependencies, which
> mapserver has. I saw, mapserver is able to produce PDF, which is nice
> format to me. I agree, PS would be better. If this would mean to
> install non-free library, we have to find another solution and I thank
> you for your information.
> 
> >
> >4) How can you plan to "outsource" even more things, while what has made
> >ESRI the leader, compared to the second in position, is the consistancy
> >of the offer, that is components that fit together.
> 
> Once, we will have half of ESRI's developers, we can start to write
> everything from scratch.

I have read somewhere that, for example, KerGIS was a plan to rewrite
everything from scratch. That's absolutely wrong. I had planned to start
everything from last CERL made release. If I had to start from scratch,
there would be now undoubtely almost nothing to use. CERL GRASS was a
chance.

For GPL GRASS, you do not have to start everything from scratch. You
have to start from what does exist already. And if we put apart late
contributions on Imagery, that are a nightmare on themselves on a
maintenance point of view, the remaining, once a clarification and a
reorganization is made, is sufficiently sound to _evolve_. The key point
being that a developer touching the code does not introduce even more
noise, duplication, but tries to understand and strengthen the code
first. Being centripetal, not centrifugal.

GRASS GPL has already a "product". It should be organized---that was/is
the aim of the KerGIS reorganization---so that putting scarce
developers' resources on a component (once orthogonalization is done),
can lead to an evolution, part by part.

I doubt ESRI has hundreds of programmers (and tenths of developers). And
if this is the case, I suspect that a huge part is devoted to
integration of ESRI products on sites, or development of customizations.

>[..] 
> >
> >The needs in hardcopy for GRASS/KerGIS do not require the full power of
> >PS being implemented in the components, since one can always relieve on
> >other really free programs to create specialized images (MetaPOST for
> >example), and the GRASS tool has only to be able to include these images
> >(eps) (and mind you, one solution of the MapServer PDF output is simply
> >to embed a PNG rendering in a PDF wrapper...).
> >
> >
> >As I have already wrote, KerGIS has strictly no interest in GRASS GPL
> >going right against a wall. Unfortunately, I have sometimes the feeling,
> >reading your mailing list, that you behave like a cloud of flies hitting
> >the Windows(TM)...
> 
> I do not understand this, sorry. My English is too poor for this.

I don't know what part you did not understand.

If this is the first one: technically speaking, not a lot has to be done
to allow to create even more sophisticated maps with ps.map(1).

If this is the last one: GRASS GPL has, as it seems, a steering 
committee. You---the team---should stop being short sighted and consider
every problem apart, and start designing a _global_ plan with a general
view of GRASS. A GIS is a _system_ that is a _consistent set of tools_
designed to work together.

Start by the big picture, and stop focusing on "details".

And if the answer is, every time something does not work immediately as
one expects: just throw this away and use something maintained by
someone else, I fear for the future of GPL GRASS...

I know that there are arseholes claiming that "with open source, you do
not need developers since what you need has already been developed by
someone". But if this curious sentence was to be true, there would be
absolutely no code to share, since nobody would ever have done the
work in the first place...
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C