从ArcGIS8.x系列开始接触ESRI的产品的朋友最早的话一般都是用MO(ESRI现在已经不直接支持)，到目前的ArcGIS9.2系列，ESRI已经建立了一套完整的地理空间数据处理、管理、分发的产品线，ESRI和许多其他美国的优秀软件一样有着牢固的软件体系架构的支撑，这是国内软件无法望其项背的，毕竟Intel、IBM在美国，MicroSoft(Sqlserver)，google在美国、Oracle在美国、AutoDesk、Bentley在美国，我们只有东软、华为、瑞星、超图等公司（网易，sohu,阿里baba似乎不太靠谱），就像踢足球，我们的国奥的确很牛B（国奥进土伦杯决赛了），就像有些软件确实很牛B，但你从整体上还是有很大的差距，没有形成一种文化，没有积累。
但我们还是有后发优势（例如盗版，呵呵），在ArcGIS8系列的时候，MapInfo还是很有市场的，SDE也还比较稚嫩，记得有一次老板赶着去投标，要我务必在第二天上飞机前把SDE装好，结果我一宿没睡也没有搞定，后来发现是SDe与Oracle的版本兼容问题，换了个版本就好了，当然也发现当时找个盗版的SDE是多么的困难，很多同学都拖我买ArcInfo，呵呵，现在MapInfo虽然还是在生产端很有市场，但感觉已经在Esri的光环下黯然失色。Oracle spatial固然牛B，但SDE在大数据量管理上面确确实实让众多GIS厂商、众多GIS用户叹服，可以说ESRI现在的优势99%来源于SDE一点都不夸张。而SDE是三层体系架构的，一般公司技术上难以实现（GeoStar负责数据库端开发的资深人员2003年跟我谈到过），虽然实现空间数据在Oracle中的存储和读取相对来说是简单的，一般采用Oracle Spatial的方式。
之后就到了ArcGIS9系列产品了，8.x系列下面的AO开发说实话还是比较变态的，客户端必须安装ArcGIS，打包的时候很难办，很多接口本身也不稳定，但那个时候国内的GIS软件都还没有进行组件化（有些软件公司去年2006才完成所谓的组件化，而ESRI早已把大船开往了SOA），所以AO显得是那么强大。到2003年的时候，很多单位要进行AO开发都缓下来了，等待ArcEngine的出现。我当时跟几个博士一起去接一个规划的项目（实力有限，泡汤了），他们宁愿等ArcGIS9之后再开发。Engine出来了，esricore被分成了许多的库，在9.1,9.2等后续版本中又陆续进行了细分，接口增增删删，而其间中国大陆的Engine开发简直是如火如荼，凡GIS二次开发必谈Engine，ESRI已经实现了产品的重组，大舰起航了~~
与桌面端应用遥想呼应的WebGIS产品，ArcIMS，ArcGIS Server，其实很多搞过WebGIS二次开发或底层开发的人都会有一丝遗憾，甚至汗颜，因为Google map、google earth的出现，这个在后面再说吧。ArcIMS在4.0系列的时候，前期是非常成功的，基于arcxml的webgis开发也一直有上佳表现，但似乎也有相当一段时间停滞不前，直到arcgis9.0的ArcGIS server才缓缓出现，但不久就被Google蒙羞了，蒙羞的不仅是整个GIS界，也不能全怪我们太书呆子了，毕竟微软也是在AJAX上面下了一昏招，搞得灰头土脸的。目前出现了太多的电子地图网站，mapbar,vrmap的51map，map.baidu，口碑网等很多都开始了，另外skyline,microsoft,google等公司都开始了3d earth，而NASA的worldwind甚至要做整个太阳系，而目前的1.4版本才发行不久，里面已经有月球、火星等等的数据，开源让worldwind百尺竿头更进一步。
ArcIMS和ArcGIS的变种是基于ArcIMS的瓦片技术，从目前应用的角度来说其实速度快，已经满足了应用的要求，但这些东西都是在表层做文章（当然了搞测绘和GIS的似乎总是把简单问题复杂化，这么多年了也没看分析个啥），ArcIMS即将和MO一样退出GIS历史的舞台（至此所有ESRI产品全部基于AO了），但ArcGIS Server能挑起WebGIS的重担吗，ArcGIS Server是GIS业界最牛B的产品之一了，但越来越发现GIS面临的挑战不是局限在GIS内部，而是整个IT业界，这块蛋糕是许多IT厂商觊觎已久的，换个思路，或许是GIS终于开始强别人的蛋糕了：）因为这个原因，我并不看好ArcGIS Server的发展，当然也看到了ESRI在GIS界的高处不胜寒和势单力薄，这也是ESRI的危机所在。
国产GIS软件没有面临这样的问题，似乎ESRI是他们最大的问题，一些靠数据赚钱，一些靠数据采集软件、测量软件赚钱、而另一些靠ESRI赚钱。GIS平台做得好的不多，超图、中地真心希望你们一路走好。当然，回应第一段的内容，GIS的发展不能光靠GIS公司，整个中国的软件开发环境、整个中国的IT教育环境（主要是大学教育）、甚至是政府机关（主要的GIS消费者）都需要不断改革，共谋发展。打倒美帝国主义！
我所在的浙江省测绘局省库项目开发采用的都是清一色的美式装备（Engine+SDE+ Oracle）,我们做的水利厅项目也是一样，政府部门数据关键来不得半点闪失，所以国内软件还难当大任，但我相信每个中国人都是希望用咱自己的软件的~~真的.
==========
文章转载自（作者：李恒山）：
http://cisalee.spaces.live.com/blog/cns!391B06E9D146EEC5!131.entry?action=post&wa=wsignin1.0
==============
china3view个人评论：ESRI公司的产品发生了ArcView->ArcInfo->ArcGIS的演变，而开发组件产品也同时发生了Avenue(依附ArcView环境)->MapObject(能独立分发，但功能较弱)->VBA（依附ArcGIS环境）->ArcObject（依附ArcGIS环境）->ArcEngine（完全独立分发，可以实现几乎所有的ArcGIS功能）。这可以看出这个一流公司根据市场做出的调整，也说明其技术的实力。当然，现在在Google和开源技术的影响下，一些非政府部门而言将会有更多的选择。在做数据展示的时候不论local还是web都可以考虑Google Earth或Google Map。而在后台数据库管理方面，虽然作者说的ArcSDE功能强大，但是现在也已经受到了PostgreSQL的挑战，使ArcSDE也不得不为其提供专门的接口，而且开源的PostgreSQL 好象有后来居上的劲头，你可以到http://www.postgresql.org/ （英文，官方站点）和http://postgresql-chinese.blogspot.com/（繁体中文）查看其有关信息。末了，转载一篇关于ArcSDE和PostgreSQL的对比文章。
==============
ArcSDE comes to PostgreSQL? 转自：http://geotips.blogspot.com/2006/08/arcsde-comes-to-postgresql.html
It has long been rumoured that ESRI might move their "database neutral" ArcSDE to the ultimate "neutral database", PostgreSQL. I have heard versions of this idea since around 2003, but I never thought they would come to pass. So, mea culpa, all the people I told "it will never happen"... it has!
Yes, ESRI is currently in the process of developing support for PostgreSQL. We have done all the necessary testing to ensure that this will continue to be a viable product in the future. We plan to release this capability sometime after ArcGIS 9.2.
So, what does this mean for PostGIS? Same thing it means for Oracle Spatial -- not very much. ESRI may, or may not, support using PostGIS native spatial geometries as the geometry type in ArcSDE. For Oracle, the default ESRI position has always been their SDEBINARY performs better than SDO_GEOMETRY, so it does not sound like using native types holds any particular allure for ESRI.
Even if ArcSDE does support PostGIS types, the ArcSDE versioning model means that all changes to the geometries will have to be done through the SDE API, in order to ensure the versioning metadata remains consistent.
Still, from a read-only perspective, if ArcSDE does support PostGIS as a geometry type, then the following architecture becomes possible, which could represent a big opportunity for some jurisdictions:
(DBMS) PostgreSQL Database
(ESRI Pound of Flesh) ArcSDE for PostgreSQL using PostGIS geometries
(Desktop Editing / Cartography) ArcGIS
(Desktop Viewing) QGIS
(Analysis Engine) GRASS
(Web Map Publishing) Mapserver
(Web Feature Publishing) Geoserver
If, on the other hand, ArcSDE on PostgreSQL only supports SDEBINARY, then this will be a non-event from an open source interoperability point of view. I look forward to hearing some reports from the ESRI UC -- someone button-hole those ArcSDE developers and find out what the plan is!
