[mapserver-users] simplicity

[Obe, Regina DND\MIS]

I agree with all the comments stated.  One nicety which I don't know if it's
too much trouble - would be to have or if there are any laws against it is
to have a source package that includes all the other source packages that
mapserver depends on or at least the more commonly used ones or at least
have them all downloadable from the mapserver site (rather than just
pointing to other sites).  For two reasons - 

1) Since a lot of the other stuff is opensource too - it too is constantly
changing so you never know if your compiled code doesn't work because you
are not using the right version of the other dependencies and then god
forbid if you put the package in the wrong place in your source tree - then
you've got to change everything else.

2)  I don't mind compiling my code too much, but one frustration I've had
with trying to follow the documentation on compiling (at least windows one -
I assume the same applies with others)  - is when I finally download the
source for freetype or whatever there own compile instructions and version
numbers have changed and then all my paths are screwed up trying to compile
- so the whole section on how to compile my freetype on the mapserver site
goes out the door.  Now i have to use JAM to compile freetype because it
doesn't come with a config script and then figure out where to throw these
packages so that my other stuff can find it etc.  I won't even bore you with
my frustration of figuring out which variant of gd.1... I need.


 

-----Original Message-----
From: Puneet Kishor [mailto:pkishor at GeoAnalytics.com]
Sent: Tuesday, December 25, 2001 4:06 PM
To: Paul Ramsey
Cc: mapserver-users at lists.gis.umn.edu
Subject: Re: [mapserver-users] simplicity


Hi Paul,

Here's some of my responses to your thoughtful reply.

On Tuesday, December 25, 2001, at 02:03 PM, Paul Ramsey wrote:

> No flames here. As an experienced unix systadmin, I do not find the 
> mapserver
> install particularly hard, but I know that it is not remotely simple 
> for the
> unversed.

without boring you all with my background, I would say I am an advanced 
computer user. Yet, after the first blush, I find trying to successfully 
compile a program perplexing. After a string of failures, that 
perplexity degenerates into boredom. As I said in my earlier email, I 
spent more time installing Mapserver successfully than I did creating an 
application with incorporating Mapscript and MySQL. It should really be 
the other way around.

Maybe it is the Mac-user in me. Mac users have always expected that they 
would spend more time using their programs than they would 
troubleshooting them. And while the rest of the world found that to be 
weird, we had a great time using beautiful programs on a beautiful 
operating system.

One should _not_ need to be an experienced Unix sysadmin to find the 
install easy. One should be most anybody to find the install easy.

> There are definately alot of dependencies (which incidentally is
> why it works -- if the whole thing was one monolithic piece of software 
> it
> would never have been finished).

I suspect you are correct. However, to a great extent Mapserver is now 
finished. It works. From here on it is a matter of adding more features 
to it. However, what it does now it does very well. What is required now 
is to make it easier to setup and get started.

> I actually started making a complete set of RPMs of both the mapserver
> package and all the required support libraries, with the proper options
> compiled in, etc. Took quite a while, and is still only about 2/3 done.
> (libgd w/ gif, postgresql w/ postgis, proj, ogr, gdal, mapserver, 
> mapscript
> of various flavours ... it's about a dozen different RPMs by the time 
> you're
> done).

Ya, that's what I have started doing for MacOS X. And that is the 
conclusion I am getting at. However, I am motivated by the following, 
assuming I stick to one OS, that is MacOS X in this case --

1. most all MacOS X installs are almost identical... different only if 
the user has made any specific, concerted changes to the directory 
hierarchy and the set of tools that Apple provides. If they have, then 
they are experienced in Unix ways anyway, and they don't need a prepared 
package from me... they can do it themselves.

2. as long as I declare right up front some of the assumptions and 
pre-requisites clearly, the user is getting into charted waters. Such 
declarations might be --

	- this package uses Mapserver version xxx.xxx
	- this packages comprises gd version xx.xx, and this and that 
version xx.xxx, etc.
	- this package assumes you have this and that
	- installing this package will create the following directories for
you
	- etc., etc.

3. If the user wants anything more or less than what the declarations 
state in #2 above, they are on their own.

4. By doing the above for one specific OS, and for a preset package of 
versions and tools, I restrict the number of variations I would have to 
deal with. By reducing this complexity I make my job manageable. For 
those who want the cutting edge, they are welcome to go cut themselves.

5. By having a discussion forum that is manageable, and can be navigated 
easily via OS and issues-specific discussion groups, users will be able 
to find other users with a like set of problems and operating 
environment, and be able to help themselves. That way no one person 
would have to bear the cross of support. The email listserv right now is 
way too chaotic. Too many emails on too many different topics and issues 
flying in too many different directions.

Hence, my suggestion that Mapserver packaging be divided into teams 
responsible for specific OSs and even specific issues.

>  I sort of stopped with the knowledge that if I ever released the set I
> would have to either spend alot of time then maintaining that huge set 
> as the
> source code was improved and debugged, or else adopt an unfriendly 
> "tough,
> that's all you get" response to any help queries. The only thing more 
> work
> than doing something nice for an OSS community (writing doco, doing
> packaging, writing the program itself...) is *supporting* the thing once
> you're done.

Yup, but since the package you have made comes with the declarations, 
those who get into it know what to expect. They get a working program 
which may not have the very latest, greatest, and flakiest.

>
> So, the $100 question to you: if there was a pre-packaged, "just 
> install and
> run" mapserver suite, would you *buy* it? And if you would, what would 
> be
> your price point? Packaging is low in glory, high in maintainance and
> support. Which is why joints like Red Hat actually sell their packages.
>
> How much is a professional and reliable mapserver install package worth?

That is not a simple question to answer -- to me personally Mapserver is 
worth nothing. As an individual user I paid $70 for AppleWorks and $39 
for Quicken, etc. What use is Mapserver for me as an individual! I'd 
rather pay for $44 Expedia Streets and Trips so I can plan my next road 
trip to Glacier National Park.

On the other hand, a reliable and professional Mapserver install package 
might be worth as much as a couple of grand to my company, or to a 
client who right now is frustratingly tackling with ArcIMS. Maybe, they 
might pay a $300 license for Mapserver and then hire a consulting 
company to put up an excruciatingly complex mapping application for 
them. I dunno. I mean, how much are Apache and Perl worth to me... and 
Apache and Perl have achieved a fairly decent level of simplicity by now 
at least in their install procedures. Putting a $ value on opensource sw 
has always been difficult. But, it would be safe to say that we are all 
doing it not for money... maybe for bringing the big guys down, maybe 
for showing up the commercial vendors who charge a lot for their shitty 
products, maybe for the high we get for coding a good program, whatever. 
I am sure all of us want more and more people to use Mapserver. I 
believe that can be done by making it easy to get started.

I believe dividing the Mapserver project into several groups might be 
worthwhile. The core team can continue to work on the source code, 
making the program more powerful, more flexible, etc. OS specific teams 
can make packages that install and run easily on their respective OSes.

I hope others can join in this conversation and that something good 
comes out of it.

Cheers, and a merry x'mas.

pk/