The Open Source Business Model

In the GI "interoperability" domain, the "chatter" regarding open source softwares really interests me. I've had the opportunity to develop upon and deliver solutions with both open source projects and commercial products.

The geospatial open source community has had success. I attribute a couple of phenomena for this:

1. Early adoption of interoperability standards and availability of functional software in the Open Source community (they were there first)
2. Slow adoption of interoperability standards by "known" software vendors (wait and see approach)
3. Mandated interoperability requirements for "government" entities (US and Europe require it now, but how?)
4. Early "success" for limited use cases in prototypes with open source softwares
5. Good "marketing" jargon

The open source communities have really done a good job at targeting and developing the "basic" GI requirements. The open source community provides a good "cartoon web map" experience, several 2.5 D globe viewers and there are some good SDK's as well, GeoTools, GDAL and PostGIS.

"Behind the scenes", there is undoubtedly a business model behind open source software...don't believe the philanthropy when you here that there isn't. The main contributors of open source software make money, unfortuantely, it' s the only means of existence in the industrial world.

So what is the Open Source Business Model? It's both services and the traditional software product model.

Service Model - with the very limited use cases available in open source, any adopter of open source must "develop" their requirements through customizations, extensions and integration with other systems. To what extent this is required is dependent on the complexity of the use case. Support for the product falls into this category as well. Taking an average developer rate of $70 x 8 hrs x 5 days = $2800/week. There's always some level of Project Management that is required as well in contracting that is traditionally "billable".

Software Product Model - again, with the limited use cases available in open source, the contributors to the project can be directly contracted to develop features. The contributor will collect the requirement and develop the capability "direct" into the open source project and delivery it. Many of the "heavy" requirements are done in this mode.

The commitment from commercial vendors to the interoperability standards has arrived, so point #2 is becoming rather a mute point.

There's a saying that really suites the current scenario..."you get what you pay for". There's a stability, reliability, quality, performance, documentation, feature velocity and progression that are inherently required of all commercial products. If you spent money on it, you expect it to work well, fast and progress with future releases. Most customers also require a long term commitment and vision with the product that assures them that it is going in the direction that meets future needs as well.

There's also an economy of scale issue here. You can produce cartoon maps in a 'free' database today and it's only going to cost 15k for the services....great, but what about tomorrow and where will that implementation be in 2 years? Are you sure that open source project will be around in 5 years? Most open source projects are extremely "fragile" because they are "driven" by a small critical core of contributors that essentially 'manage' the project.

There's undoubtedly pushback to many open source projects in Enterprise deployments from IT. They are traditionally difficult to get "approved" by IT groups. IT likes to see proven, well established products that have references, case studies and a track record before they approve it themselves. They also require "accountability" and a formal channel for support and bug fixes. IT is a primary stakeholder and a huge contributor to the decision making process for enterprise software. This again leads us into the discussion of Brand Equity.

In the end, the decision is more than pure economics, it's about meeting the users needs (today and thinking about tomorrow), having confidence that the "product" will work and be there for you in the future.