Kim Polese shares her perception about the business models of the open source support companies.Excerpts with edits & comments:
- Any opensource product being used by organizations would need support. Commercial organizations want to reduce their costs, and want to know that their deployments are covered in case of trouble. Cost reduction isn't about doing everything in-house, it is about finding a solution that provides the right mix of services you need at a price point that makes sense.
- Consulting services are frequently concerned with customizations and tuning, and so may be offered relatively earlier in the open source lifecycle while the code is less complete. By contrast, traditional telephone support will become cost effective through economies of scale.
- On service bundle - The bundles will be familiar, as that of commercial vendors Where things will differ is in pricing models. Commercial vendors almost invariably charge a maintenance fee based on the license fee. Support fees may also be tied to this metric. With open source components, other benchmarks will be tried in an attempt to serve customer and vendor needs more precisely.
- Once an open source product reaches mainstream use, the need to extend or correct the code is reduced and the skillset comes back to communication, remote interaction, and the ability to seek and utilize diverse external information sources. There is an additional need to be keenly aware that your team-mates work for other companies, frequently competitors. It is therefore important in using external information sources like discussion fora and mailing lists to be aware of the difference between public and private information. Debugging problems in public while protecting sensitive corporate assets and proprietary information requires forethought and tact.
- One of the weakness of opensource is the lack of traditional productization - items such as install scripts, documentation, configuration tools, that will have to be provided by the provider of support services. The developers of open source frequently don't feel the need for good documentation, or the desire to devote the time required to write it. This is one of the parts of usual product release management that is lost by this development model. Similarly install scripts, configuration tools. Open source support organizations will be evaluated in part on how well they assist in this area.
- SpikeSource will focus on integration and certification of well established open source components, and will offer periodic updates and support services around those integrations. Because of economies of scale, SpikeSource will provide better certification, documentation, and configuration tooling than end-users can justify developing on their own. The product updates will follow a product management process and bug or security fixes will be provided in a separate stream from feature improvements to permit customers to better determine which upgrades they want to adopt when. Most of these updates will be sourced from the community, through active monitoring of development activity, but some will be developed in house in response to important problems that the community hasn't yet addressed. SpikeSource will substantially reduce the cost and uncertainty of integrating open source products into IT applications. With all these, am not sure of any sustainable open source support model - this is not in anyway different from a distributor - and to do all these requires scale - resources and reveneue!!
Category :Opensource
|
