Opinion piec­e by Adam Leach, principal analyst at Ovum

Open source is the emerging development methodology for mobile phones, reducing operational costs, harnessing innovation and shortening time to market for new devices and services. With both Nokia and Google already choosing an open source model for their mobile platforms over the past twelve months, the pressure is on independent software vendors (ISVs) in the mobile market to adopt an open source strategy.

ISVs need to evolve to meet new customer expectations

ISVs need to be familiar with open source environments to be able to respond to demands to integrate customers’ solutions into those environments. In addition, OEMs and operators will start to expect similar levels of transparency and collaboration on key areas of interest for them. As a result, ISVs will need to evolve their business practices to meet these new expectations, in some cases embracing an open source business model.

From a product perspective, adopting an open source strategy can involve as little as deciding to use an open source component, through treating open source as a supplier, to deciding to adopt an open source licence for the entire product. In both instances the risks associated with the use of open source need to be managed.

ISVs need to evaluate new ways of generating income

Adopting an open source licence for an entire product development for a company that does not derive its main revenues from software royalty involves less risk. Google, for example, make its money through advertising, not selling software; Sun Microsystems makes most of its money through selling servers, not software; equally, Nokia’s business is based on hardware sales. So open sourcing products for these companies poses fewer issues and does not require completely re-engineering their businesses.

For a pure software vendor that derives all of its revenues from software licensing, the move towards a complete open source strategy has a greater amount of risk associated with it.
Vendors looking to pursue this strategy will need to consider which aspects of the product offering will derive income.

Potential areas of revenue will include:

professional and value-added services – companies looking to use open source in a commercial context will require professional services and product indemnity, which are potential means of revenue
high-value features – in addition, software vendors need to understand the higher-value aspects of their product offering and structure pricing around these. For example, Funambol (the open source mobile messaging company) structures its prices so that mobile operators using some advanced features of the solution pay a premium for those services
licence protection – another aspect which should be explored is propensity of customers to be insulated from copyleft licences (the name given to licences such as the GPL which require that any code that is derived from the original code is contributed back to the community). Many customers would be prepared to pay to be insulated from a copyleft licence in this case the software vendor could develop a version of the product under a copyleft licence (e.g. GPL) and therefore benefit from the open source development methodology but also make available an alternative (functionally equivalent) version under a proprietary licence.
The same due diligence needs to be applied to open source suppliers

When evaluating an open source component for use within a commercial development, a vendor should ensure the same due diligence is applied to the assessment of the software as would be used for any other new software supplier. This would include detailed product analysis to determine if the software meets functional and non-functional requirements, as well as benchmarking against other suppliers (open source and proprietary).

In addition to this, an assessment of the licensing terms needs to be made to ensure the obligations of the licence are met; this may also involve deciding how the component is integrated into the overall software stack.

Support and indemnity are the next important considerations. Open source projects will generally provide limited support, usually supplied on forums from community members. An open source project will not provide any indemnity to the users of the code. Deciding how to approach this issue will depend on the component itself and its importance within the product and how aligned it is with the core competency of the engineering team and the company. If the component is of low value (basic commodity) to the overall solution or if there is limited technical knowledge of the domain then a professional open source company should be considered to provide these value-added services.

However, if the component is strategically important to the product and there is sufficient technology knowledge of the domain within the company then a direct approach should be considered by getting involved with the open source project and contributing to its ongoing development.

Source:cellular-news