[GRASSLIST:4492] Fwd: Marketing

[James Plante]

On Oct 1, 2004, at 6:26 AM, Bernhard Reiter wrote:

> On Fri, Oct 01, 2004 at 10:34:49AM +0200, Paolo Cavallini wrote:
>> I believe GRASS is a fundamental piece of software for many 
>> organization.
>> What we mainly need is stabilization, and especially marketing. What 
>> I have
>> found is that most potentially interested people do not even know of 
>> GRASS,
>> and of those who know, most think to 5.0, with very limited vector 
>> support,
>> etc.
>
> Yes, the word about GRASS has to go out to the world.
> There have been a couple of initiatives by the German GRASS User 
> Association.
> Intevation and FreeGIS also tried to get GRASS into many channels.
>
>> I have therefore been interested by the marketing initiative for 
>> OpenOffice:
>> http://marketing.openoffice.org/
>
> It is very interesting to read the LWN assessment
> of the paper marketing plan that has been published before the 
> conference.
> (http://lwn.net/Articles/104125/  subscriber-only content until 
> Thursday.)
>
> Quote:
> 	OpenOffice.org has to step carefully around its patron.
>
> 	the plan gives valuable insights into an important free
> 	software project which is at a sort of turning point. It indicates
> 	that the project intends to concentrate on "selling" OpenOffice.org
> 	to vast numbers of users rather than on engagement with the free
> 	software community. More OpenOffice.org users can only be a good
> 	thing; one can only wish the project luck in achieving its goals.
> 	
>> Would someone have the skills (background in businness/economics, 
>> perhaps) to
>> set up such a project for GRASS? I can collaborate to it, if 
>> necessary.
>
> Any more marketing efforts for GRASS would be great.
> The problem I see is that Sun is behind OO and puts in most of the 
> people.
> GRASS would need to take the step towards more
> commercial (Free Software) deployment.
> Intevation tries to sell GRASS since a few years now
> and I believe it to be difficult.
> Without those sales there will not be much hard effort behind
> large scale marketing.
>
> (Before someone jumps on this: In my experience using a Free
> Software license with strong protection works in favour of the long
> term adoption of GRASS.)
>
> Bernhard
>
I live in the state of Tennessee, USA. At present, our state property 
tax assessment division is embracing GIS for mapping and maintaining 
property assessment records. Implementation deadline is 2008. Their 
platform? Windows (ugh!) Their GIS choice? ArcView/ArcInfo ($$!!). 
GRASS wasn't even considered, despite budget constraints at every 
level.

In order to make inroads into this massive market, GRASS needs to be 
more user friendly, and 7.0 seems to be a good starting point. More 
needs to be done, though. A brand-new GIS user needs to be able to 
download, convert, and display free data at county level. These data 
are already freely available from USGS (DEM's & DOQ's) and the Census 
Bureau. Inexpensive DRG and DOQQ data are readily available. I've been 
toying (as opposed to "working") with GRASS since 5.0, and I still have 
not had the time to "figure out" how to import TIGR data so as to get 
the roads, as well as the street names, out of TIGR data.

If you're taking guidance from OpenOffice, look at the import filters. 
You open Writer, tell it to "Open..." an Excel or Word file, and it 
simply does. One need not specify that the Word document is 51.34 pages 
long, contains 3000 words, 15 illustrations, and is formatted for 8.5 x 
11" paper. It just opens. GRASS will have to at least approach this 
level of utility in order to take the lead in the GIS field. One should 
need only to select Import, and aim 5.7 at a TIGR file. A dialog should 
offer one the option to import only a few of the layers (by selection) 
or all of them. The end user doesn't care whether the data are vector 
or raster, and probably doesn't know the difference. One should be able 
to point GRASS at a folder of .e00 files, and select the ones to 
import.

The database connectivity should be more user friendly as well. One 
should see the words "ODBC" and "JDBC" only under the "Advanced" tab of 
the database selection dialog. (I know -- at present there is no 
database selection dialog. GRASS needs one. Again, OpenOffice shows a 
good way to approach this.)

At present, the full utility and power of GRASS is available mostly to 
those of advanced education and of comfortable familiarity with 
programming. Someone reports a problem, and a helpful user responds 
with, "Oh, just change the $GISBASE_CONFUSION constant to a float and 
recompile." The questioner is entirely comfortable with the solution, 
and gratefully implements it. To expand in popularity, you must 
remember that most potential users of GIS at the office/clerical level 
don't know a constant from a float, and have no clue how to recompile.

The level of support for GRASS is truly astounding. I wouldn't be as 
far along as I am (which isn't very far due to time constraints) 
without people like Marcus Neteler and Lorenzo Moretti. For other 
users, Hamish, Michael Barton, and others have responded to some 
tremendously complex requests (complex to me, at least) with fixes 
posted to CVS sometimes the same day.

But to really make inroads into the GIS market, a GUI similar to 
OpenOffice in ease of use is necessary. GRASS is so powerful that it's 
overwhelming to a newbie. Take this question: How do I trim the borders 
from my maps? Answer: v.patch in=thisfile, thatfile out=anotherfile 
anotherControl=5 and many other parameters. All this is transparent to 
the skilled *nix user, but is incomprehensible to one whose experience 
is limited to GUI's.

Why not have a menu selection that works like this: Open-->(select 
mapset). Edit-->Zoom (set region). Edit-->Combine maps::Select 
additional map (v.patch). Displayed map now shows two maps, joined at 
the correct edge. Layers-->add layer::Select layer.

End users should not see a command-line unless they want one--and it's 
important that the CLI be retained as an option.  The Tcl/Tk interface 
works, but an integrated interface is needed.

Jim Plante
<jimplante at charter.net>





Jim Plante
<jimplante at charter.net>