...there were several very qualified residents within the community who were interested in volunteering their time to help build (write portions of the application). Closed source software with overly restrictive licensing, even to the API's, would not allow these people to contribute to the project. This alone could have saved the city roughly a million dollars a year. If the city would have agreed to use some of the open source software instead, I estimate they could have saved nearly two million in the first year alone."

Jack proceeds to apply this context and principle to the small landscape architecture office:

"To answer your question regarding hardware and software for a small LA office, I have to answer that the way I would approach any project.  What are the specific needs of this small office?  Will word processing, accounting, some graphic packages alone meet their needs, or do they truly need a CAD and/or GIS tools?  What will they be using GIS for?

For me personally, I have grown extremely fond of the Mandrake Linux desktop.  I currently run Mandrake 9.1 on all my production hosts.  I am moving my 75 yr. old mother from MacOS 9 to it, as well as several computing neophyte friends that are tired of becoming crippled by Microsoft insecurities and vulnerabilities.  What I usually do for them is create dual boot systems and let them decide which OS they are more productive on.  You'd be surprised what direction true neophytes migrate to when given pure, unadulterated options, (hint; its not towards the Pacific northwest).

There are several CAD applications that run on linux, some GPL'd/open source and some commercial.  Additionally, if you're dead set on running AutoCAD, you can always run it through WINE (WINdows Emulator).  QCad does many basic 2D cad tasks efficiently.  It is 100% GPL'd and uses DXF as its native format.  It does a pretty decent job at reading in plans I created in AutoCAD 2002 and saved as DXF, although viewports, colors, linetypes, etc., sometimes get lost.  However, if you want to explore the limits, (forget AutoCAD), check out these commercial CADs for Linux including ARCAD and CYCAS, both by German companies.  Warning, tape lower jaw to ear lobes prior to viewing.  These are sexy, sexy CAD applications and rendering packages that will have you scratching your head wondering "why" we are so addicted to Microsoft and AutoCAD.  Varicad is another commercial cad perhaps more geared (no pun intended) to the industrial sector, and I've heard rumor to the effect that Bentley is targeting this market as well with plans for a linux port.

Some other great resources for CAD on Linux...

Linux CAD Links by Tech-EDV
CAD on Linux forum

Of course there is the obligatory Google search for CAD and Linux as well. 

GIS is a slightly different beast than CAD for many reasons.  Perhaps the most significant reason GIS is different is that no one commercial GIS contains all the functionality one could envision a need for.  As such, GIS is typically distributed in a  modular product approach.  In general, there are no full-featued GIS applications.  To perform GIS analysis in one realm, such as working with imagery or 3 dimensional terrain models using ESRI, one would have to purchase and install separately Image Analyst and Spatial Analyst respectively.  Relatedly, one of the most powerful advancements of recent in the geospatial realm is the ability to store geospatial data in a relational database management system (RDBMS) .  In the ESRI world, assuming this data will need to be shared amongst an office, this requires another ESRI product (SDE) and a third party RDBMS engine such as Oracle.

Sidebar:
Consider for a moment purely in terms of technology, ESRI has never been a technology leader.  Their advantage has always been in their aggressive and savvy marketing.  Jack Dangermond is nothing if not THE master Marketician.  From their onset they have historically tied their application to a vendor whose architecture may in fact be constrained and/or future markedly limited.  However, to their credit, it seems to have not affected them much and they have been able to effectively abandon ship and build a new one before they are in danger of, well, whatever.  They were originally developed on and for Prime Computer's platform exclusively.  The Arc Macro Language (AML) is built and modeled entirely on the Prime Macro Language.  Only when Prime's future was decidedly in the dumper did they work to port their application to Unix, but once again instead of taking the open architecture road, they opted NOT to use accepted standards like CORBA or a modern shell like Korn.  Instead they leveraged fading legacy shells and dismissed the need for an integration framework altogether.  Even within their own products, there was no way to access the functionality of one module without first exiting another, making their tools incredibly difficult to use.  When MapInfo corp released their flagship Windows desktop mapping application, they started to pull market share from ESRI.  ESRI's response was first the purchase of rival company Atlas, and then the release of ArcView.  Most ArcView users prior to 3.1 will tell you it was less than stellar, but a few miscues by MapInfo and the leverage of their workstation product's ArcInfo market share, and they darn near put MapInfo out of business.  They tend to follow what I have observed to be a very effective business model.  That is, let someone else invent the technology, we'll come in afterwards and just package and market it more effectively.  They have one obvious weakness, to latch on to other market leader technologies.  This time, however, they just might be getting in so deep that it will be difficult to retrofit.  They have once again placed all their eggs in a single basket by tying their entire future to the closed Microsoft DCOM architecture at a time in history where there is a grass roots swell hinting at a popular new direction, (albeit Microsoft would argue the new .NET direction changes all that, but I disagree and digress).    They could have chosen Java as their future, but for whatever reason they did not.  Java will survive without Sun.  DCOM and .NET are nothing without Microsoft OS.  For that matter, Java runs just fine on Microsoft OS's.

As I see it there are three major facets to GIS today; (1., managing geospatial data in distributed databases making it available to applications for (2., performing analysis on the data, and (3., displaying the results.  A fourth and somewhat trivial component today is the creation of geospatial data, although previously creating the data was thought to be a huge part of GIS.  Between recent technological advancements (GPS, remotes sensing, etc.), and the vast amount of legacy data sources that are available.  Gone are the days of spending countless hours of digitizing paper maps. 

For storing data there are commercial application servers that manage data stored in a RDBMS like ArcSDE from ESRI which really only play nicely with other ESRI products and applications.  However, once again they have the largest market share.  ArcSDE by itself has limited spatial analysis functionality, although it does have some.  It, however, has no inherent manner for displaying its data.  Extracting geospatial data from SDE without other ESRI tools is extremely difficult and essentially useless to an LA.  Other commercial geospatial application servers include Oracle Spatial from Oracle Corporation, which like ArcSDE stores spatial feature in its underlying RDBMS.  Unlike ArcSDE, however, Oracle Spatial has a number of inherent analysis tools for extracting data, and also unlike ArcSDE, you can extract spatial features without additional tools for tabular viewing.   Both of these GIS tools are available in Linux deployments. 

Autometric also has a spatial application server for an RDBMS called the Spatial Query Server, or SQS.  As a mattar of record, SQS existed long before either Oracle Spatial or ArcSDE.  Like Oracle Spatial, it too has inherent analysis functionality and the ability to extract spatial data without dependencies upon external applications.  However, it is only available with Sybase's RDBMS.  To the best of my knowledge, no Linux port is available. 

Most interestingly in the spatial data storage realm of recent has been the emergence of open source geospatial application servers that are once again, extremely powerful, well supported, and FREE.  The most interesting is something called PostGIS which is a geospatial application server for PostgreSQL.  PostgreSQL is a very powerful open source RDBMS in the realm of Oracle, Sybase and Informix.  It includes several of the advanced features of the commercial RDBMS's plus several they do not, like inherent support for geometric data types.  Additionally, PostgreSQL/PostGIS can be used with ESRI analysis and display tools instead of ArcSDE, much to ESRI's dismay.  Obviously it can be used in many other realms as well and is quite popular in use with open source based GIS web mapping applications.

One last note on spatial data application servers, the very popular web database engine MySQL,  now also has inherent support for geospatial data features, however it lacks some of the bells and whistles certain power users might need such as transaction logging and replication services.

In the application analysis and viewing realm, we are in the midst (or should I say mist) of a paradigm shift were technologies like Java and Simple Vector Graphics (SVG) allow us to do what was historically only possible in large and cumbersome platform specific applications (i.e., ArcInfo, GenaMap, MapInfo, etc.), with any standard web browser.  However, that "mist" is still clearing and/or evolving.  No one application, (similar to GIS applications actually), does it all. 

Most of the analytical tasks I can think of an LA might want to use a GIS for, (i.e., terrain mapping, viewshed analysis, visualization, inventory, etc.), are available in any number of free geospatial tools available to the masses.  I often advocate GRASS which admittedly is not for the weak of heart, but then again, what GIS is?   GRASS's startup effort is complex due to the fact that in order to get it to work exactly like you want, (which bells and whistles you'd like), you'll have to compile it yourself, although prepackaged bundles with easy installation instructions are available if you can live with the reality that you might not have access to all the possible tools.  Compilation is a task most Landscape Architects I'm guessing would shy away from.  On the other hand, ESRI, although doesn't require compilation, is cumbersome to set up for its own reasons including configuring and understanding license managers, hardware key maintenance, database installation (i.e., Oracle, etc.).

Again, depending upon the task, there are several open source GIS tools and resources available.  Instead of listing what each is and what they do, how about I provide you with a list of resources and references to them.   The two best I can think of are probably...

http://www.freegis.org/
http://www.remotesensing.org/

There you will find reference and links to a plethora of specialty tools for solving everything from simple to extremely complex geospatial analysis and display needs.  Combined with a geospatial application server like PostGIS and you can do anything any ESRI tool can do.  GRASS has native interfaces to PostgreSQL and PostGIS (PostGIS in 5.3 beta release).  For more on Grass...

http://grass.itc.it/

Couple of last thoughts...

I suspect it is also possible to use ESRI applications under Linux in a Windows emulator environment.  In addition to WINE, there are commercial Windows emulators for Linux as well.   A very good one is VMWare.  Emulators are nice in that you can have the best of both worlds, INCLUDING not getting shut down every three days because of a new virus prowling around.

Also, note that if Bently is migrating Microstation to Linux, it makes for one heck of a geospatial application framework, in addition to its CAD ability.  If they are in fact working on a Linux port, that would give them a HUGE advantage over rivals such as Autodesk and ESRI.

Sorry for the long windedness..."

-jv