LiMo Foundation Blog

In the last few years the open source software movement has grown significantly from a trail-blazing group of visionaries to a mainstream movement that is touching almost all areas of the desk, server and mobile software worlds.Over the past decade Teleca has engaged in a wide range of open source mobile software projects and communities such as Android, Maemo, OpenMoko, etc. In this article, we attempt to use this experience to help you to successfully leverage open source software while avoiding common pitfalls and leave a mutually beneficial legacy for the open source software community.

In Part 1 of the article we’ll look at why you should or should not leverage open source, the “open is free” misperception, choosing the right open source development model, contribution strategy and the license that is best suited to you.

Why?  Rather than why not?

It is always extremely important to know why you have decided to take a particular course of action and using open source software is no different.  However, it is far too common to hear "why not" as the answer when asking company’s about their motivations to engage with open source communities.  As this article will highlight using open source software does not just impact a company’s R&D organisation but frequently touches many other functions as well.  It is therefore, vital to have a clear understanding as to why leveraging open source software is the right option for you.  This will also help to shape individuals' actions, provide them with guidance and help the company as a whole to shape its wider activities with regards to open source community involvement.

Open does not mean FREE!

One of the common misconceptions about open source is that it is free. While you can gain access to millions of lines of code without cost, this typically does not enable you to deliver a finished product. Typical software development activities such as integration, regression testing or development of feature enhancements still need to be performed. Given that everyone potentially has access to the same code, the challenge is to build a high value differentiated product with open source code alone.  Typically, leveraging open source allows you to re-factor where you spend your valuable development dollars but it does not typically reduce development spend. However it should enable greater investment in innovation and differentiation that you can build on top of the open source code, and a lower investment in the core plumbing and building block software.

It’s a different development model

Leveraging open source software is not just about finding free code on the web and integrating it into your development project. It has implications for your overall development model. Open source projects often use Agile or Scrum approaches as opposed to traditional waterfall development models widely found in large companies.  It’s also important to define a community engagement strategy and contribution policy – if, when and how you plan to give something back to the open source community.

Define a contribution strategy

To maximise mutual benefits and provide clarity and direction for your development teams, it is important not to be viewed as a “free rider”; simply taking and never giving back; so a contribution strategy should be developed as early as possible. For example, consider whether you will contribute complete components or bug fixes; will you contribute during development of your product, at service launch or post launch? You also need to decide if you will provide maintenance and integration support for your contribution; especially if you’re seeking to have your code integrated within future baseline releases.

Failure to define a contribution strategy can also have significant hidden future costs.   For example if you are building a Linux based platform and developing additional components that you know will become standard, such as a DLNA stack, then you run the risk that a competitor may contribute if you don’t.  This may result in the core baseline software containing components that are less functional or core APIs that are not longer fully compatible with the components you have developed.  You may then need to make modifications or re-integrate onto each new baseline release, stealing valuable development hours from creating the next great new thing.

Select your Licence with care

One of the most daunting challenges can be understanding the licensing models and the implications they have for your development activities.  It is worthwhile investing some time and money to understand which licences you should utilise and which ones are not appropriate for your development objectives.

Typically, when coming to open source for the first time the focus is on GPLs (General Public Licences) also known as copyleft licences.  These often require that derivate works are licensed under the same terms and conditions and that source code is made freely available along with a number of other key requirements.   However, not all licences in open source are GPL, with two other main categories existing known as Licence Contracts and Permissive Licence Notices.  These are friendlier for those wishing to develop commercial products.  For example Android, the Linux based mobile device platform, developed by the Open Handset Alliance, uses an Apache 2 licence (Licence Contract) which allows companies to use the source code in devices and to make modifications without the need to contribute or open source them provided they include the licence text (on an Android based device this can be found in the settings/about screen).

It is also important to fully understand which licences can be used in combination and which cannot, as not all licences can co-exist within a common software block.

Some good sources for more information on open source licensing models are the Open Source Initiative (www.opensource.org) and the Free Software Foundation – FSF (www.gnu.org).

Part 2 of this article will address the importance of testing and debugging code before contributing it, identifying the right business model and setting up a maintenance plan for the code you have contributed.