One of the things that large, conservative organizations have the most concern about when evaluating open source solutions is the issue of “support”, and the parallel issue of “sustainability”. Usually these issues are collapsed into one, and decision makers simply eyeball a software vendor and see if the company seems large enough to survive in the long term.
Of course, there are serious practical problems with this approach: the large sustainable company might actually provide very poor support; and, largeness alone is no guarantee of software longevity — just ask the customers of Seibel, or BEA.
Regardless of the practical problems, the size/sustainability decision criterion continues to be applied by managers evaluating software. For some organizations, the availability of traditional “support” is an over-riding criterion — they are just not allowed to use an open source solution if they cannot find a traditional support contract mechanism for it. So, in the general open source world, a few companies have carved out a niche as the “go to” locations for enterprise support in their product categories: Red Hat for Linux support, JBoss for J2EE support, MySQL for database support.
In the geospatial open source realm, support providers have been slow to get off the ground, and have been bedeviled by a difficult characteristic of open source spatial solutions — they tend to be made of many, many parts. If a consultant builds an application, using multiple open source packages, and delivers it to an agency, that agency might find that supporting all the components requires contracts with several different companies! Just finding relevant support providers for each part can be time consuming.
The solution to the problem is pretty obvious: find a one company that will support all the components of the application. But, where to find such a company? Support companies are hard to find, because providing credible support is hard to do.
In order to sell support for a single piece of open source software, a company needs to have in-house expertise in the software, so that customers can receive priority service. Having a suite of sub-contractors won’t do, because you can’t guarantee that a sub-contractor is going to be available when a customer needs help (now!).
In order to sell support for a whole stack of different open source packages, a company needs to have experts in-house for several diverse software packages. This makes the cost-of-entry to the software support business very high indeed — a whole stable of experts needs to be maintained through the lean early years when the number of contracts doesn’t cover the cost of the expertise.
Starting a viable open source support company is a classic chicken-and-egg problem:
- to provide a credible support offering, you need to have a large suite of experts on staff;
- paying those experts requires that you have sold a large number of support contracts; and,
- selling support contracts requires a credible support offering.
It’s a bad situation. In order to sell contract number one, a company needs all the support infrastructure in place at the very start, even though they won’t break even until they sell contract number twenty or fifty.
There are two conventional ways to start any company: to boot-strap, and to capitalize.
Boot-strapping, as we’ve seen above, won’t readily work. A company needs a credible support offering on day one, and they can’t provide that with a single founder working out of his garage.
Capitalizing, through traditional investment approaches such as venture capital, seems like a good fit, but for one problem: venture capital expects extremely high returns (10:1 and better), and all indications so far are that the open source support business is, at best, a business with modest returns. There are no big revenue hits from selling software (selling $0.02 DVDs for $10,000 is great business when you can manage it, but open source companies can’t) and you have to work for every support dollar. Particularly in a small niche like open source geospatial, the growth potential simply isn’t large enough to attract venture funding.
OpenGeo is going to break this vicious circle by fusing the support needs of large conservative organizations with the social goals of our parent organization, The Open Planning Project (TOPP). TOPP wants to get the tools to empower civil society into as many hands as possible, and those tools include the open source software we at OpenGeo are working on. Large organizations want access to a support provider with enough depth of expertise to credibly support their application stacks.
We are using the social development funding available to us through TOPP to build an organization with the depth of skills necessary to support a complete open source geospatial stack: database (PostGIS), application server (GeoServer), and user interface (OpenLayers & GeoExt).
We want to provide the most knowledgeable support possible, so many of the staff we hire are already leaders in the open source projects we support. Ensuring that project team members have employment working with their software also helps improve the strength of the projects themselves.
Last year, we released Geoserver Enterprise support, and this year we will be going one better — by providing support for a complete geospatial software stack. Our team is ready, and we have the whole stack covered. Our goal is to create the ultimate win-win-win for open source geospatial:
- Open source software wins, as developers are supported financially to work full-time on improving the software.
- Institutional customers win, as they finally have access to a one-stop support shop for complex open source spatial deployments;
- Open source users win, as the software they depend on accesses a sustainable funding stream to continue maintenance and development;
- TOPP wins, as they leverage a fixed initial investment in growing our team into long term, self-supporting development of collaborative planning tools; and,
- We win, by getting to do what we love for a living.
Look for more on our stack support in this space this spring.