27 December 2007 - 15:37Tech support for open source projects

Customer service has emerged as one way to fund an open source package which grows so much that you cannot support it by relying only on code committed by random committers: you release the APIs under a particular license and you pay for the expenses by selling support subscriptions.
This obviously applies to one small part of the open source movement because there are open source projects which get funded in a different manner: RedHat sells customized versions of Linux, IBM provides corporate backing for various open source projects, pooling of corporate resources for maintaining other open source projects, etc…

As far as I know tech support is used for backing various open source projects such as a variety of Linux flavors, JBoss, Spring Framework, etc… Tech support relies heavily on the lack of knowledge of operating that open source package: you have some problems configuring JBoss’s transaction manager and the cheapest way to deal with it is to open a ticket with JBoss rather than try to jump in to the free code. Tech support is actually outsourcing the management of the knowledge required to operate a particular product and as such it feeds on the lack of knowledge about that product. If your product is big and hairy (think about a stack) but widely used you will make a lot of money from tech support. Tech support revenues grow as the complexity of operating that product grows because tech support is tied to the knowledge required to operate that product.

Tech support runs counter to light-weight frameworks, from their definitions they are light and easy to handle. Which makes you wonder about how would a framework championing light-weight development would be able to sell tech-support subscriptions. You will probably sell tech support to Fortune 500 companies which require support for most of the software they use (requirement which is probably a by-product of internal rules more than anything else) but anything else will probably be a tough sell. I understand a 20-person company buying tech support from JBoss for managing their application cluster better but I don’t understand why would the same company buy tech support for a lightweight container. By definition the usage of that container would be so straight-forward as not to make you need support, you should be able to solve a problem either looking it up on that framework’s forums or thru the documentation.

That’s why I am following Spring’s model with a lot of interest: the very goal they are trying to achieve (an easy to work with and non-intrusive framework) runs against the rationale of supporting that framework thru subscriptions to customer service. The steps that they are taking, such as releasing value added packages probably shows that supporting a light-weight framework is not very efficient and that you have to resort to a different model for funding it.
I would say that this new strategy is promising because these value-added packages will increase the knowledge required for efficient operation and implicitly the need for tech support.
Kudos to Spring Source for breaking away from an old model.

Later Edit: Tech support also relies on the complexity required for interacting with a particular product, be it an operating system, an application server, etc… The more complex the product, the bigger the need for tech support. Spring Source`s products so far were not complex to operate, on the contrary, their objective was to allow for transparent, non-intrusive development and ease of operation is part of this objective. With Spring Source move into value added packages they also move into more complex products (if you look at what Spring Integration is trying to achieve you will see a lot of very complex interactions between various products in the Spring Source stack). The more complex these products, the bigger the need for tech support. It will be interesting to watch how this will unwind.