James addressed the idea that Esri is extending the core capability of ArcGIS to include functionality that, in the the not-too-distant past, would have been left to strategic partners and other third-party integrators. When I touched upon this last week, I came at it from the standpoint that it will streamline procurement for Federal users. This observation was driven by the fact that I was at the Federal GIS Conference and it made sense for that audience.
James is correct that end users will be happy with having all of this new capability “just in there.” But, in truth, I can imagine another reason for Esri to take this step. The fact is that a lot of third-party extensions to ArcGIS (especially for ArcGIS Desktop) really kind of stink. I won’t name any because I don’t need that can of worms in my life but it’s easy to find third-party extensions with poor UIs, bad exception handling, unacceptable performance and generally poor implementation that can just crash ArcGIS. If you are a “power user” that has a number of these third-party tools running in the same process space, who knows what they are doing to each other or to ArcGIS?
But ask yourself this: When ArcMap crashes, do you curse ACME Geospatial and that crappy extension they built or do you curse ArcMap? Admittedly, I’ve had ArcMap inexplicably crash on me without any third-party tools but every third-party extension adds just a little bit more risk that, most likely, will ding the user’s impression of Esri rather than that of the third-party developer. In short, bad third-party tools reflect poorly on Esri and perhaps even more so than the developer because most users can’t see the distinction at runtime. They just see that ArcMap crashed.
So, to mitigate this, I guess Esri could go all App Store on us and insist on some draconian process to get an extension “approved” or “certified” or some such nonsense. Or they could just build a lot of what these third-party tools do into the core product. If I’m Esri, I do the latter, saving myself a bunch of headaches and bringing these tools into my own development process, where I can control and support them. (I know…Or they could open-source the whole thing but that’s not going to happen so I’m not going there.)
After years of dealing with some fairly poor third-party tools, I certainly can’t blame Esri for heading in this direction.
Another issue is keeping the core and extension technology in sync. You never know when the next core release will break an extension written for an earlier release. For the same reason I favor Drupal over WordPress + extensions for web development.
Yes, configuration management of APIs after you’ve cultivated a large third-party community is a big undertaking. It will be interesting to see how some of the hosted, HTTP-based interfaces that have emerged recently respond to this over time.
WRT addons crashing Arcgis, surely esri are to blame for building a plugin system so easily able to crash the whole application?Any kind of sand boxing would surely cost less than bundling functionality into the core product (and actually keep their business partners .. in business?)
The point could be argued endlessly, and I don’t necessarily disagree with you as I’ve done such things myself. The larger question is the whether those third-party tools bring much value to the platform. (Meaning tools that just plug gaps in the out-of-the-box capability. Many domain-specific tools add a lot of value.)
I once had a developer of such tools describe their business model as “dashing in front of the steamroller and picking up dimes.” I’m not sure I’d be particularly concerned about partners who see their business that way.
I also think we’ll see better sandboxing in a future release but I’m not looking for it in 10.x.