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 12 months, the pressure is on independent software vendors (ISVs) in the mobile market to adopt an open source strategy.
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 range from simply deciding to use an open source component to treating open source as a supplier and deciding to adopt an open source licence for the entire product. In all instances the risks associated with the use of open source need to be managed.
Adopting an open source licence for an entire product development by a company that does not derive its main revenues from software royalties involves less risk. Google, for example, makes its money from advertising, not selling software; Sun Microsystems makes most of its money from selling servers, not software; Nokia's business is based on hardware sales. So open sourcing products for these companies poses fewer issues and does not require complete re-engineering of their businesses.
For a pure software vendor, the move towards a complete open source strategy is riskier. 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 need 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 General Public Licence (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 (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, 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 services.
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.