What’s wrong with these guys, why aren’t they deploying using the market leading proprietary tools? My guess is, they just don’t know any better.
The real action these days is web application development, and the action there is in frameworks like Rails, Django, Drupal, Plone, and the like. What tools integrate better with those environments? What tools are developers using those environments likely to find and try on their own? Open source blooms in green fields. Looking at ESRI-dependent government agencies and wondering “where is the open source?” is like looking at the Bronx and wondering “where are all the flowers? “
This link to a 9m Clay Shirky talk showed up in the comments of my last post from the always-connected Allan Doyle.
I really like the anecdote about trying to explain Perl support to C++ programmers. The idea that “support comes from companies, exclusively” seems imported from an earlier time, when the statement was literally true. Before the internet, the only reasonable place to get expert support (or quality software, for that matter) would be a largish company. Folks whose professional expertise was forged during that time seem, except for some freakish exceptions, to find it hard to mentally transition to the new order of things.
Wow, some very interesting new data points on how ESRI is positioning itself in the marketplace relative to open source in a new interview of ESRI monarch Jack Dangermond at CRBonline.
Q. What is your attitude towards open source?
A. ESRI is philosophically very supportive of the open source movement and we have engineered our tools so they live inside an open source sandwich. They run on Linux and other open source systems. We have some significant components of our tools that are open source such as Spatial Statistics, which we purposefully kept in Python open source environments.
First, some interpretation. What is this “open source sandwich” and where can I get one, I’m feeling hungry! I assume the reference is to a deployment architecture where the base layers of operating system (Linux) and database (PostgreSQL) are open source, the middle tier application server (ESRI ArcServer) is not, and the user interface layer (Openlayers? ExtJS?) is open source.
The subtext is that ESRI is not so interested in controlling the whole stack, soup-to-nuts, anymore, which of course is not all true. ArcMap still really requires ArcServer (née ArcSDE) for direct database editing – even if you “direct connect” to your Oracle Spatial or PostGIS you need the ArcServer license. For many ArcMap customers, “what works with ArcMap” is still the first and only question driving purchasing decisions, and the answer to the question remains “another product from ESRI”. However, in places where they don’t have their customers’ balls in a vice (server-side, web services), ESRI is being forced to integrate better with third party software. Thank you, market discipline.
Q. Do you face much competition from open source?
A. I don’t think we do. It’s a political movement as well as a technical effort. People who buy our products don’t typically want to buy open source because they want to acquire total integrated support for their mission critical applications. Do we want ambulance dispatch running on a system that’s not as well supported? Arguably a commercial product can bring about better support these days, maybe that won’t be the case in the future. But at this point our general philosophy is that we like the open source movement, we not challenging it, or challenged by it, and we welcome it into the geospatial community because it’s a hotbed of open research that we benefit from and like to contribute to.
Shades of Microsoft, an enjoyable icing of FUD, and a roadmap for open source competitors, should they be willing to follow it.
Would you buy software from this man?
We start with “it’s a political movement”, almost a non-sequitur, but the point is to tie open source in readers’ minds to very political folks like Richard Stallman, the Barry Goldwater (“extremism in the defense of liberty is no vice”) of open source. This is much in the tradition of Microsoft’s early positioning against open source, which was to highlight the GPL and Free Software Foundation as much as possible – pick the face most objectionable to mainstream customers, point and say “that there is open source, you really want some of that?!”
Having intimated that open source is anarchist basement hackers (incidentally, our own tendency to speak about an “open source movement” plays into this harmful connotative framework), Jack moves to the meat of his argument, that ESRI provides “total integrated support” and open source does not. Attempting to rub salt in the wounds, he tosses in an ambulance dispatch example (Jack, I want my ambulance dispatch running on a system that, first and foremost, works).
Of course, to believe that ESRI has an advantage in the realm of “total integrated support”, you have to first believe that the support available from ESRI is worth paying money for.
Most important, Jack is ceding arguments about technical superiority here. It’s not about software anymore, it’s about support. And the gauntlet is thrown down – if your company can create a credible open source whole product you can play with the big boys. Mind you, a good deal of the psychological comfort decision makers draw from things like “support contracts” comes from enterprise size, and there’s a serious chicken-and-egg problem to be dealt with there for open source enterprises.
Warning to Mapserver users: There is a bug in PostGIS 1.3.4 which will cause PostgreSQL to crash when used in conjunction with Mapserver and LINE layers. We should have PostGIS 1.3.5 out this week, which will fix the problem. In the meantime, reverting to version 1.3.3 will remove the problem.
This bug will affect any PostGIS application that calls the ST_Multi(), Multi(), ST_Force_Collection() and Force_Collection() functions with a LINESTRING as an argument. Mapserver happens to have a Force_Collection() as part of the main draw routine for PostGIS, so it is very likely to exercise the bug.
If you are seeing crashing behavior in conjunction with LINESTRING types, this bug is probably the source. It was introduced in 1.3.4 when fixing an similar bug for CURVE types. Regina Obe is currently beefing up our regression suite, so that the odds of introducing similar bugs in the future are much lower.
Update: PostGIS 1.3.5 has been released to address this bug.
Warning to Mapserver users: There is a bug in PostGIS 1.3.4 which will cause PostgreSQL to crash when used in conjunction with Mapserver and LINE layers. We should have PostGIS 1.3.5 out this week, which will fix the problem. In the meantime, reverting to version 1.3.3 will remove the problem.