Disappearance of GIS?
From Wikipedia.
Vector1 asks if GIS is going to disappear. Disappear is too strong of a word – I think subsumption is more likely.
Internal Combustion Engine Subsumption
Look at what happened to engines. A hundred years ago they were the hot new technology – both internal combustion as well as electric. In those days you had to be intimately familiar with the physics of combustion to operate a motor vehicle. Now I rarely open the hood of my car. So in a sense engines have disappeared, but really they were subsumed by the automobile. What remains is a higher level object – the car – with only a few terms (like ignition) here and there hinting at what lay underneath.
1918 Sears Catalog
By 1918, the Sears, Roebuck and Co. catalog offered a 5-pound Home Motor, suitable for a variety of applications … there was a Beater Attachment (“whips cream and beats eggs when used in connection with the Home Motor”), a Fan Attachment (“includes fan and guard, which can be quickly attached to Home Motor”), a Churn and Mixer Attachment (“for which you will find many uses”), Buffer and Grinder Attachments (“will be found very useful in many ways around the home”), and, last but not least, a Vibrator Attachment (“includes three applicators and handle”)
– Wired.
Electric Engine Subsumption
Instead of being subsumed by single technology – like the automobile – I think GIS will be subsumed by many technologies. This is what happened to the electric engine. As this Wired article points out, Sears originally sold general purpose electric engines for consumers who would attach it to different applicances. That didn’t work out too well. I believe impedance matching is critical to good engine design. Since the impedance imposed by inertia and friction on an auto varies little from on auto to another, standardization and economies of scale allowed that industry to flourish. On the other hand, the appliances Sears was targeting had a comparatively wider range of impedances. The result has been a much greater variety in the electric engine gene pool. Even though the electric motor industry never had a city – much less a basketball team – named after it, it seems to be in better shape than the internal combustion engine industry.
Nanomotor from Science-a-gogo.
ArcGIS Engine Subsumption
The range of impedances around which Geospatial engines must be designed is rapidly growing. Unfortunately, the licensing model for ArcGIS Engine seems like it was written in Detroit. Finer grained licensing is needed. For example, maybe the AxMapControl is too heavy (all that COM baggage) for a particular use case. I’d like to write my own multithreaded WPF based mapcontrol, maybe leveraging DeepZoom (assuming I can get my head around SilverLight). My licensing costs should reflect the amount of ArcObjects I use. As someone who makes a living building apps from ArcObjects, I don’t want to end up in the same boat as the United Auto Workers.
The Memory Leak 
You make a good point. But I am not sure that the idea is to reduce the concept of travel to the nuts and bolts in the engine and all other parts, that have been subsumped.
The United Auto Workers missed their calling. They were masters at building engines. Although they missed (so far, except for Daimler) the call of electric cars, their goal ought to have been to invent whatever devices were needed to ‘travel’ (at this time in a sustianable world).
By comparison GIS in the cloud as about reaching the potential of spatial information in society – in all ways, in all endeavours. It is the opportunity for whole new approaches to solving problems.
I’m not sure how this got reduced to licensing?
ESRI’s licensing model does not allow ArcObjects to be easily subsumed into other technologies, where they are just a small component of a much larger system. The problem exists on the desktop and perhaps even more so in the cloud. I’ll leave it to others to elaborate how this is not an issue with open source.
In the cloud, if I build a virtual machine on EC2 using the Java version of ArcObjects, I don’t think I can legally spin up additional cpus. There is no such licensing model. Licensing needs to be flexible not only in terms of what proportion of arcobjects are used, but also in how it scales in response to load spikes – shifting gears in other words.
“Engineers” these days have specialized skill sets, typically far removed from engine design/operation. Likewise, soon maybe “GIS Professionals” too will have specialized skill sets working on problems far removed from spatial data – hopefully with such titles as “Cloud Licensing Specialist”.
The better, and truthful, analogy here is that a GIS expert is akin to a Mechanical engineer. They both understand the underlying processes, techniques, and applications.
The problem with both is that education and industry tends to get too wrapped up in specifics. Learning about just certain types of engines or applications instead of broader concepts. Licensing comes into this because of how the large software companies give software for free to students or are forced to become experts in a proprietary technology and then ensure this technology will continue to be used in their jobs.
So move beyond simple questions of licensing and technology of a single supplier and look more broadly to other providers, solutions, and tools. See what web based or open-source alternatives give you the leverage you want to use with new techniques (distributed computing).
Kirk, it has also occurred to me that ArcGIS may not be intended for use in *your* cloud. Perhaps you’re supposed to sign up for the ESRI/Microsoft/Google cloud.
Hey Sean –
That would be fine with me, as long as it supports the use case I’ve outlined here:
Now that you mention it, it would probably be much easier for ESRI to limit arcobjects to their cloud than to enforce a licensing policy for deployments in other clouds. Who knows, maybe someday ArcGIS Online will live up to its name and go beyond simply providing data.
I think the hard part for ESRI would be keeping track of payments between the different entities. Amazon is way ahead in that game. Currently ESRI’s only channel for developers to deploy extensions to a broad audience is ArcScripts, which are free so there is little incentive for participation.
Also, the forces Thomas Friedmann describes in his book “The World is Flat” are worth considering. Think about how much flatter the GIS world would become if developers in India and China could write cloud based geoprocessing tools and extensions.