Paragon Corpoation PostGIS Spatial Database Engine OSGeo.org The Open Source Geospatial Foundation UMN Mapserver Boston Geographic Information Systems       PostGreSQL Object Relational Database Management System
Home   About Boston GIS   Consulting Services  Boston GIS Blog  Postgres OnLine Journal  Planet PostGIS  PostGIS Funding

Purpose of BostonGIS

BostonGIS is a testbed for GIS and Web Mapping solutions utilizing open source, freely available and/or open gis technologies. We will be using mostly Boston, Massachusetts data to provide mapping and spatial database examples.

If you have some thoughts or comments on what you would like to see covered on this site, drop us a line on our Feed Back page.


GIS Tutorials on Opensource and OpenGIS technologies Tutorials
GIS Article comments Article and Tutorial Comments
Boston GIS BLog Rss FeedBoston GIS blog

PDF HTML All BostonGIS tutorials packaged together in an E-Book.


Tutorial and Tip Sites
Desktop GIS
External Data
GIS Events and Groups
GIS SDKs and Frameworks
External Resources
Glossary
GIS Blogs Around Boston
External GIS Blogs
External Papers Articles
GIS Quick Guides and References
OpenStreetMap and OpenLayers Tutorials
PostGIS, pgRouting, and PostgreSQL Tutorials
Part 1: Getting Started With PostGIS: An almost Idiot's Guide more ...
pgRouting: Loading OpenStreetMap with Osm2Po and route querying more ...
Part 1: Getting Started With PostGIS: An almost Idiot's Guide (PostGIS 2.0) more ...
OSCON 2009: Tips and Tricks for Writing PostGIS Spatial Queries more ...
PGCon2009: PostGIS 1.4, PostgreSQL 8.4 Spatial Analysis Queries, Building Geometries, Open Jump more ...
PLR Part 3: PL/R and Geospatial Data Abstraction Library (GDAL) RGDAL more ...
PostGIS Nearest Neighbor: A Generic Solution - Much Faster than Previous Solution more ...
Solving the Nearest Neighbor Problem in PostGIS more ...
PLR Part 2: PL/R and PostGIS more ...
PLR Part 1: Up and Running with PL/R (PLR) in PostgreSQL: An almost Idiot's Guide more ...
Part 3: PostGIS Loading Data from Non-Spatial Sources more ...
Part 2: Introduction to Spatial Queries and SFSQL with PostGIS more ...
Miscellaneous Tutorials/Cheatsheets/Examples
SpatiaLite Tutorials
Boston External Map Examples
SQL Server 2008 Tutorials
UMN Mapserver Tutorials
General Commentary
Compare SQL Server 2008 R2, Oracle 11G R2, PostgreSQL/PostGIS 1.5 Spatial Features more ...
Cross Compare SQL Server 2008 Spatial, PostgreSQL/PostGIS 1.3-1.4, MySQL 5-6 more ...
General Comparison between Open Source and Commercial Offerings

Printer Friendly

Comparison Between Open Source and Commercial Software

These opinions are strictly my own based on my own observations and experiences with both kinds of software and trying to understand the dynamics at play in each environment. I'm sure others share similar opinions. Also note that these are sweeping generalities and caricatures, but I think provide a good starting model for critiquing both.

Aside: Please note also that there is a lot of quibbling over semantics and some will argue that I am using the term commercial incorrectly since money is made from opensource software as well therefore opensource is a form of commercial software and what I really mean is proprietary software. Let me be clear and say that what I mean by commercial is that profit is made by the actual selling of the software and less important for this discussion, the software is closed source. The term proprietary while in some cases more fitting has too much of an air of copyright and legalese which I don't think is too relevant for this discussion. If a person owns a patent and allows people to use it freely, I would consider it proprietary and yet still opensource.

How do the Strategic Arsenal of Open Source and Commercial Software vary?

Below is a table that compares the various arsenals at the disposal of Open Source vs. Commercial software

Commercial SoftwareOpen Source
How do they get money?
  • Product Sales
  • Product Licenses
  • Product Renewals
  • SaaS - Software as service / Hosting
  • Consulting Sales
  • Support Contracts
  • Venture Capital
  • Consulting Sales
  • Support Contracts
  • SaaS - Software as a service / Hosting
  • Donations
Please note that SaaS is not an option for some software such as what I call sub-software or embedded software or developer tools software that is meant to live inside something bigger. There is a bit of a greyzone there.
How do they market?
  • Sales Team
  • Marketing Team
  • Advertising Dollars
  • Search Engine
  • Word of Mouth - Viral Marketing
  • Case Studies
  • Search Engine
  • Word of Mouth - Viral Marketing
  • Case Studies
What non-direct monetary benefits do they get?
  • Fame
  • General enjoyment in what they do
  • Fame
  • Support for sub-problems in consulting practice
  • General enjoyment in what they do
  • Increasing the demand of commercial products or services sold by the company by subsidizing the development of a complimentary product.
    I call this the Give me some free cookies and I'll buy your milk trick.
  • Decreasing demand of a product sold by a competitor by subsidizing the development of a substitute product. This is the death by kryptonite trick

How does arsenal control strategy?

Now it goes without saying that based on the above, the arsenal of Open source are pretty much a subset of the arsenal of commercial software except for a couple of items. Open source software can more readily get external organizations to help out with sub-problems since the solutions of these sub-problems are available to all. Commercial for most relevant cases doesn't have this tool because who wants to help solve a problem when you can't share in the spoils. Another important tool while less relevant except for widely used open source products or sub-products (embedded kits) is that of donations. Then there are the last 2 tricks which are largely employed by huge commercial software and hardware companies we normally consider as commercial software companies. Many smaller companies employ the same tactics as well though since it’s a relatively easy way to invest dollars and especially for the kryptonite trick - a potential good way to kill a larger competitor who owns the market. A lot of commercial software companies e.g. IBM, Oracle, Novell, Sun and Microsoft to name a few use open source software behind the scenes or purposely invest in opensource products either to destroy a competitor in an area they are weak in or encouraging the development of products that are complimentary to their own. This means they have some fairly high incentives to support such software via donations or direct help to expedite improvement.

Since open source at least on the onset has fewer tools at its disposal it spends more effort in those tools it does have e.g. making sure people working on the project like what they are doing, recognizing people (e.g. providing fame) to outstanding programmers, and trying to make the most users happy to leverage viral marketing.

Below is a table that compares the various strategies of both as a consequence of arsenal that each has at their disposal.

Commercial SoftwareOpen Source
Difficulty of Problems and what problems are there really?
  • Make simple problems appear hard
  • Make hard problems appear hard
  • Invent problems that don't exist or make rare hard problems appear ubiquitous
  • Make problems look no harder than they really are
  • Make problems look simpler than they really are
Building Customer/User Base
  1. Find rich customers that are not price sensitive
  2. Find ignorant customers that can be brainwashed
  3. Find customers with hard problems that no one else can solve.
  4. Non-paying customers that can turn into paying or can spread the word.
  1. Smart users that can help with development or support are better.
  2. Any user will do that can provide donations, provide consulting dollars or spread the word.

Okay this section is not quite as obvious as the other so let me explain my reasoning. Commercial software has a lot more money to spend on such things as standard marketing channels, sales and shrink wrapping, because they have more potential revenue streams. Also if you are getting venture capital money, you better demonstrate you are spending it by hiring more staff, spending more on marketing etc. Venture capital wants you to win big which means riskier strategies or go down trying.

On top of that commercial software needs to demonstrate that they have solved a hard problem that no one else has solved or make competitors solutions to problems seem hackish. So the marketing folks will use words like "You want to solve the problem the right way, don't you?", which often means "The hard way that only we know how to do." A corrollary to that is if a problem is really hard and you have solved it or can convince people you have solved it, make sure everyone knows that and make sure everyone thinks they have the same problem. That actually holds true for both commercial and open source but is generally easier to pull off for commercial software.

It always surprises me how many people think they need clustered servers, clustered solutions, and dynamic failover solutions. Reality check, if you've got only 300 people visiting your site in a day and 1000 page hit per day, you probably don't need a clustered solution, unless you are doing something super processor intensive and if you do need such a solution your software probably sucks. Can you really afford a true dynamic failure system that takes into consideration all possible contingencies of failure -e.g you have a power failure that kills all your servers, an expensive redundant line and offsite location. Yah I know in the future you might - but why don't you wait till the future to solve future vapor problems that may never come to fruition instead of muddling your current problems with future concerns. There is a fine line between planning for the future and letting the future destroy your present. Far too many people cross that line.

Alright so why does open source not fall into the same game. Hard problems require long painful treacherous solutions and lots of money to solve. Send an army into a war and say "Folks we are going into a hard war. We will probably lose or be in it for a while and by the way you won't get paid." I'm sure that will excite a lot of people to join your side. If your main strategy is to build a large user-base with no money, solving a hard problem that few people have is not exactly the best way. Now if you have a hard problem that many people have - try to convince everyone the problem is much much easier to solve than it really is. Commercial wants paying customers, open source wants lots of users that have the potential of becoming contributors either monetarily or via support. This means commercial needs to solve problems that people can't easily find a free solution for or at least convincing people of that premise which means they spend their effort solving hard problems, convincing people they have hard problems and less on easy problems while open source spends their time solving ubiquitous easier problems, trying to create a hack for harder problems that everyone has that will solve 80% of the hard problem but full short of the last 20%, and then seriously tackle the hard problems once they've built up a large enough user-base or consulting customer base that demands it.

What do these incentive structures mean to you as a consumer?

First off let us define the kinds of problems that are hard to solve. Now there is hard as in thinking hard and hard as in we need lots of people to do lots of work hard. Thinking hard requires brilliant people. Doing lots of work requires a pool of competent but not necessarily brilliant people lead by a brilliant person to control the flow. Having a crowd of developers with no clue what to do is just as ineffective and definitely more costly than having a few developers with a strong sense of direction. Ah now here lies the rub.

Optimization problems are thinking hard, but not necessarily working hard

Things like scalability take brilliant people and brilliant people while often going for where the money is don't always. Scalability problems that require a lot of work also require a brilliant leader to prevent chaos from ensuing. It often takes a brilliant person to recognize another brilliant person and smart people like to hang out with others that are equally as smart as they are. When a brilliant person is an originator of an open source project, its a fair game when you have a hard thinking problem.

What does this mean to you. It means the commercial solution is not necessarily more scaleable than the open source solution despite what nonsense those marketing folks have been peddling. So don't be fooled. Do your research.

Now there is an even more warped side to this, that may actually make open source more scaleable in some cases. Poor people with little money for expensive hardware and savvy people who have tried commercial and found its weaknesses and don't want to be penalized for having good hardware are drawn to open source. These people demand to get every bit of power they can out of their sometimes meager possessions. This means scaleable as in run well on cheap hardware is important. When something runs well on your meager 600Mhz single processor, most likely it will scream on beefier hardware and it may just run okay on your meager palmtop. Pricey Commercial software on the other hand is made for people who have money to burn, and also since a lots of server commercial software is based on things like per processor licensing, from a sales incentive, it may be purposely designed to suck on low hardware and scream on high hardware. That's why you get clauses like this will not work on more than 4 processors - get the enterprise version. Now with the enterprise version you are paying $40,000/processor instead of $10,000/processor but yeah I get all sorts of other goodies that I don't really need right now.

Large Commercial companies have money to wrap themselves up nicely and are masters of dog and poney shows, so they look good on the surface to the unsuspecting CFO/CIO who has a very shallow technology background and can be put in a trance with pseudo jargon like "API, ROI, Open Architecture, minimize downtime, minimize staff time, and no one ever got fired buying IBM" and glitzy demos. Of course this is not the same case for small commercial companies who are often in the same boat of having to skimp on marketing.

Graphical User Interfaces (GUIs) are labor intensive hard

Yes wizards that will hand-hold you every step of the way take lots of man-power to build. Input screens that will prevent you from doing foolish things also take a lot of time to build. For an immature open source project or one with little funding, this is a cost too high to bear. So you will find most open source projects, especially server-side products, at least starting out, will rely on configuration scripts that you must edit in a text editor rather than a GUI. This is both a curse and a blessing. To introduce a new feature in a configuration script, add a line to the config and code to your engine to recognize it and you are done. Do the same in a GUI based system, add a line to config, add code to engine, add code to GUI interface. More complexity. Plus once you understand how the configuration script works, making changes in a config file is often a lot faster than running thru a GUI of hand-holding steps. One approach caters to one crowd and another to another crowd. For some tasks though it is faster to use a wizard such as some code generation tasks and GIS graphical heavy lifting.

Well-designed Graphical User Interfaces (GUIs) are labor intensive and require a lot of design thought

I would say commercial has an advantage initially and then open source once it matures and gets non-developer users catches up a bit and may sometimes fully catch up. Open source software when it starts off, tries to attract developers and a developer's idea of a well-designed GUI is often a little warped. Warped in the sense that what is pleasing to a developer is probably only pleasing to 5% of the population in most cases. Developers tend to be suspicious when things magically happen where as most other people want to see a pretty screen, click a button, and see something magical happen without having to look behind the magic. Trying to satisfy both camps is an art that very few people have and is probably even more deficient among the developer crowd. The exception to this rule sometimes is when you are developing developer tools. Regardless good interface design is hard and probably harder for developers.





Post Comments About General Comparison between Open Source and Commercial Offerings
SQL Server 2008 Katmai will Include Spatial Support more ...
Boston GIS      Copyright 2024      Paragon Corporation