Open-source support: Can it scale?

Open-source software had a very good 2009, and all indications are 2010 is on track to be even better.

Enterprises turned to open source to shave money in the economic downturn and are staying with it now to drive greater innovation and productivity.

This brings great hope to open-source vendors, anxious to cash in on open source's rising popularity, but it also introduces some specific challenges as they scale their organizations to meet demand.

Specifically, since support is the lifeblood of any open-source business, how can companies expand their support capabilities while simultaneously scaling profitability? The two don't necessarily go together.

Exacerbating the problem, support in an Enterprise 2.0 world is doubly challenging. Important information can reside inside the firewall but also in public forums, wikis, forges, and other community sites. Asking support reps to look across all these data repositories can mean looking in five or six different places.

This isn't efficient over the long term, and it means that support organizations can struggle to meet enterprise SLA requirements, which is bad for the overall growth of open-source usage in the enterprise.

JasperSoft, a company I advise, is a case in point. The company recently announced that its software has been downloaded more than 10 million times and that it has more than 125,000 registered community members in more than 150 countries. Gartner piled on, reporting JasperSoft to be the fastest-growing business intelligence vendor in 2009, open source or proprietary.

Great news, right? Well, sort of.

While growth is good, it also has created severe challenges for Jaspersoft's support organization. I talked with Matthew Geise, who runs support at JasperSoft, and he related to me the difficulties inherent in manually slogging through Jaspersoft's documentation, internal and external wikis, Salesforce.com case management system, and the JasperForge.org community site looking for information.

JasperSoft helped alleviate the problem by deploying Exalead CloudView. Geise was able to create a unified search box for JasperSoft's support reps that examines all of JasperSoft's disparate data sources. He estimates that the improved support boosted efficiency by more than 40 percent, a finding that is consistent with Aberdeen research.

Not bad.

So, maybe this is a way forward for open-source vendors that don't want to sell proprietary extensions in an open-core model. I suspect, however, that improved support operations will remain just one piece of the overall story. No matter how efficient one can make support, there are still far more efficient and profitable models out there. (Google, anyone?)

Hence, while support will remain a critical component of open-source offerings, I suspect we'll see it become one of several menu items that open-source companies offer. Those that do it most efficiently will earn outsized returns, but only if they marry support to other value-adding services/software.

Does this mean open source is becoming more like the traditional software model it seeks to displace? Perhaps.

Rod Johnson, founder of SpringSource, argued a few years ago that enterprises should only acquire support from vendors that have substantive control over the code in question, which makes a lot of sense (the source of the code will be best able to support the source code) but also undercuts the "no vendor lock-in" ethos of open source.

This ethos, however, appears to be much more important to the vendors that sell open source than those who actually buy it. With 95 percent of enterprises Gartner surveyed maintaining or growing their SaaS deployments in 2010, there doesn't seem to be a shortage of companies looking for simplicity at the cost of flexibility.

I'd argue, therefore, that while it's good to find ways to streamline traditional support to boost profit margins, open-source vendors would do even better to find ways to marry the efficiencies of supporting SaaS deployments with the ease-of-use such software can offer customers. Perhaps providing a "get-out-of-SaaS-free" card in the form of source code?

The cherry on top.