Services and Support Business Model

The Model

One of the most common business models around opensource is that of providing services and support. With this model, typically the main contributors to a popular project either start a firm (Marc Fleury with JBoss) or are hired by a firm (the Geronimo developers with GlueCode) and position themselves as the premier provider of support contracts and professional services.

The Rationale

Typically it has been noted that services-based businesses do not scale as well as licensing-based businesses. The basis of this conjecture is that the marginal cost of selling another license is $0, while providing services has a linearly-scaling cost structure. This of course ignores the cost of sales, which can be substantial when dealing with enterprise-grade software. Once the cost of sales calls, advertising and commissions have been factored in, the cost associated with each additional license sale is non-negligible. Certainly sales of services also cost money, but the environment is different. Additionally, support contracts have some of the highest margins in the business, as they are like seldom-used insurance policies. While software licenses may have a higher margin, support and services has a larger market. For every $1 spent on traditional licensed software, a company spends $2 on related services and support.

Significantly less effort is spent selling services to an existing customer compared to selling licenses to a new prospect. The value of an established relationship should not be underestimated. Customer acquisition costs are more than customer retention costs.

By basing a services model around opensource products, the barrier to creating inter-company relationships is drastically lowered. The costs to both parties are reduced. Friction is eliminated. With commercial software, a relationship can only be established after many stakeholders, including finance and purchasing, have signed off. Opensource, on the other hand, is adopted easily by the rank-and-file developers who are simply attempting to get a job done. If your business revolves around opensource, there are many relationships that you are not even aware of yet. For this reason, active involvement in the community is required to learn of and keep in touch with your users and potential service customers.

Marketing and Sales

With this business model, the path to a prospective customer is initially through the developer not the executive. Marketing to a developer is entirely different from marketing to the CIO. Developers are quite immune to traditional marketing exercises (though, they still love free swag and will hardly ever turn down a t-shirt). With opensource, they get to examine the steak, not just the sizzle. The technical evaluation of the product is the first and often the only activity involved in the decision to use and opensource product. With proprietary product licensing, this due diligence is many times performed late in the cycle after the decision has been all but made. The goal initially is not to mine for customers, but to encourage adoption of the opensource product thereby enlarging the potential market for your services.

Of course, developers don't sign the checks, which presents a challenge. A two-pronged marketing and sales approach is required when building a services business around opensource. The first prong requires technically competent individuals cultivating relationships with the developers on the ground. Mere marketers cannot perform this job as they tend to lack the technical understanding to truly be of help to the customer.

Both the project developers and advanced users are the ideal people to approach the technical staff of your potential customers. It is their job to qualify genuine prospects for the part of your sales team that wears ties. By interacting with prospects at the technical level within the project community, you can gain valuable customer insight and approach the firm from a position of knowledge. Your own developers, through interacting on mailing lists and other conduits, have their fingers on the pulse of your prospects. They need to be able to tell when a user's organization should be approached from the top-down to sell services. Then you can approach the relationship with focus.

This leads to the second prong of an opensource services marketing plan. Once potential clients have been identified by your developer marketers, traditional marketing and sales staff can approach the firm from the top of the prospect's organizational hierarchy. If the marketers and developers have correctly identified potential customers of services and support, though, the sales cycle for the qualified customers will be much shorter than trying to cold-sell licensed product into the firm.

Once your product has been included into a customer's system, the sale of services and support can be framed as risk avoidance and cost reduction. No longer are you having to convince the target firm of the benefits of your software.

Self-Selected for Success

Organizations that perform blue-sky development take a calculated risk that a market actually exists for their product. Opensource products, on the other hand, are similar to a pilot project to test the water. The health of an opensource project can be fairly easily judged. The actual market can be nicely analyzed. Individual developers can start small, providing consulting time to users of the project. As the market growth accelerates, a bona-fide firm can be formed to satisfy the demand. This model is well-suited for being successfully applied in a bootstrapping fashion.

Examples

A quick survey of the space presents several examples. IBM is quickly growing its services business and supports much opensource development, including Linux and the Apache Software Foundation. SourceLabs, SpikeSource, JBoss, and GlueCode all revolve around various opensource projects, relying on services and support for their revenue. Optaros recently appeared, and appears to provide solutions that happen to be based around opensource projects, somewhat landing in the middle between SourceLabs and IBM.

Conclusion

The services and support model encompasses many nuances in its execution. Regardless of the specifics, the approach to marketing and sales requires different talents than for a licensing-based model. The technical engineers become the gatekeepers for successfully initiating a sale into a prospect. You must treat them