(These are my opinions, and do not represent Sanborn in any way)

Ok – that out of the way, here’s my take on this discussion. Kudos for shaking things up – I always commend people for rocking the boat, even if I don’t always agree with them. In the case of Joe Francica and Adena Schutberg’s Open Letter to GIS/Geospatial Software Companies, I’m pretty mixed.

On the one hand I totally agree with the idea the data is now becoming a commodity – more easily purchased than created. To some extent I’ve seen this through the series of organizations I’ve worked for. Some took the view of always maintaining ownership of the datasets they processed, and others always passed the ownership on to the end client. The former now has secondary line of business leveraging a huge archive of data they can re-sell at low prices. Latter is still doing the “same old thing”.

Re: the Google Maps, and the myriad hacks (some of which are very cool). I think there are two key issues here:

1) Google Maps are fast and free. The use of a pre-defined map scales allows all the data to be pre-rendered, which makes serving them much much faster than custom rendering. On top of this, they run in Google’s super farm of servers. There is no way any geospatial company could offer this sort of infrastructure for “free” (granted it’s in beta, and they change the API from time to time).

2) It’s a very “cool” implemention of Web 2.0 / AJAX technology. This is perhaps the most important factor re: the hacks. Many developers want to start working with AJAX, and Google Maps is the hot new demo. GMail is also built using AJAX, and there were some hacks for it, but the eye candy factor of Google Maps really gave it the momentum. The combination of “cool app” with “cool technology” is what’s pushing the hacks, not the API per se.

The KISS (keep it simple, stupid!) concept is still alive and well, and should guide more GIS implementations. Unless people are GIS pros, having more than 5 tools makes something too complex. However, the trick is to use 5 tools to actually do something useful. One agregious example of too many tools is the ArcIMS HTML Viewer. You see this thing up on a zillion local government sites, and it’s pretty much useless to the end user. Now, before anyone accuses me of bashing ESRI, this is not their fault. They built a general purpose tool, which could do all kinds of things, and was easily implemented. The issue is that the groups who deploy it do not understand their end users (GIS Analsts, not Usability Designers). They had a mandate to “provide web access to the data”, and just rolled out this overly complex tool, and let the users “have at it”. The better web mapping sites, have custom user interfaces, which aggregate “GIS functionality” into blocks of “end user functionality” which are easily understood and used by the end user. However, the cost of these sites has been much higher than the “out-of-the-box” solution, and thus they are rare. 

This kind of gets around to another point – in order to be able to aggreagate the GIS functionality up to useful blocks, someone has to write the low level building blocks. This is what ESRI is doing when they are building the the other “80%” of the application functionality that the average user does not work with. There is no doubt that many many users of the ESRI product line don’t touch a lot of the functionality, but taken as a whole, I’d bet they’re using it all.

This is what happens when you build general use software. This results in a very wide feature set. If end users don’t like this, then they can have a stripped down package assembled from the components (bring in the consultants!).  If a company like ESRI were to try to roll out ”Slick, fast and simple” MapPoint-ish apps for every vertical market, they would not be able to innovate on the back end – the integration into the larger IT arena. As a developer, I have the advantage of being on the front line of this integration. ArcGIS server, while it has it’s issues, is certainly heading in the right direction of allowing spatial related operations to be integrated into the main business process, and not as a ”hacked” on addition.

This dovetails with my belief that “GIS” will simply become a subsection of IT. I see this going the way of databases. Today, the end users of databases need know almost nothing about them. There are a small group of people who maintain the database (DBAs), whereas the “data processor” postion that was common in the 70’s and 80’s is gone. I think that the “GIS Analyst” is headed down this road. Google Maps is the beginning of this transition. The vast majority of Google Maps users are not GIS people. They don’t know the complexity of data creation or spatial database managment, and they don’t care. The map is there, telling them what they want, when they want it. Hang on kids, because times, they are a changin’.