LiMo Foundation Blog

LiMo Foundation has recently published a new version of the LiMo Platform and SDK Roadmap that describes our plans for the Release 3.0 of LiMo Platform in the near future, as well as information on a further release of the Platform and associated SDKs due later in 2010.

Roadmapping within an organisation such as LiMo that relies on voluntary contributions from its members is a significantly different activity from roadmapping within a conventional software company. In this post I'll briefly explore some of these differences.

Within a conventional software company, the roadmapping activity is ”conceptually” simple - in essence it's a negotiation between the marketing/requirements function of the company (which acts as a proxy for the customer) and the engineering/delivery function of the company. (As an aside the level of politeness and constructiveness in which this negotiation is conducted tells you a lot about the general health and likely effectiveness of a company; watch out if you're working inside a company where this negotiation is acrimonious and is conducted at full volume!).

The marketing/requirements side often need to strike a balance between serving the company's existing market and customer base versus attempting to address new markets and pursue new customers. In a company that has a clearly defined business and product strategy in place, this debate can be conducted in a structured and considered way. But in the absence of such strategies, or if the organisation as a whole does not buy into the strategies that are in place, then this debate can lead to a roadmap that satisfies no-one.

But what is always a moot point is the conflict between the marketing side's desire to be able to predictably announce future product releases (naturally containing a wealth of new features) versus the engineering side's reluctance to sign-up for potentially unknown amounts of work.

The Agile movement has arisen in part as a way of easing this conflict between marketing and engineering. Engineering working closely and iteratively with customers throughout the design of a software product and responding to changing needs removes to some extent the need for a "top-down" product roadmap in the first place.

(Though Agile methodologies, if applied dogmatically, can raise new problems).

But one of the key prerequisites for successful deployment of Agile methodologies is that the customer is also committed to the Agile world view, and participates fully in the development process. For companies developing a software”platform” (as opposed to a software”product”) this can present difficulties. Firstly, a software platform is an inherently complex offering which touches on many customers who may have many use cases in mind that the platform developer is unaware of, and which the customer may not wish to discuss. But more particularly, in the consumer electronics and mobile handset markets, the platform's customers will have hard deadlines and feature requirements for their product that must be delivered with high predictability and reliability - e.g. a handset delivered in time for the Christmas market which meets network operator's device requirement specifications. For these reasons, Agile methodologies (which may certainly still be useful within the development process) do not remove the need to produce software platform roadmaps that are realistic rather than aspirational both in timing and scope.

We now move from conventional software companies to organisations that rely on voluntary contributions of time and development effort from members or from open source projects. By definition, contributions that are voluntary are necessarily tentative - the developer(s) can change their minds or have external calls on their time that cause their timescales to slip. Furthermote, the developers of open source projects tend to set a higher quality bar on releases of their software than developers within most commercial organisations since they are operating within a social environment that rewards quality (see Eric Raymond's writings ) making them choose quality over meeting deadlines.

The process by which a roadmap is drawn up must reflect these realities.

Instead of a hard-nosed negotiation between marketing and engineering sides as often happens within a company, drawing up a roadmap in such organisations is a more fluid and delicate process that requires an understanding of each developer's plans, predicted timescales and motivations.

Given the inherent uncertainty in the timescales for the underlying development projects, organisations putting together a software platform that relies on voluntary contributions tend to favour an approach that can be characterised as "release when it's ready". However, it is interesting to note that perhaps the most successful Linux distro of recent years, Ubuntu, does not take this approach. Ubuntu follows a "time-bound" approach, with releases every six months. The Debian project has traditionally favoured a "release when it's ready" approach (Debian 5.0 was released almost 2 years after 4.0) but even Debian has recently moved towards a time-bound approach by adopting time-bound release freezes. The reason for the success of the time-bound approach to platform releases is simple - it delivers more functionality more quickly to the customer. A willingness to set more modest functionality goals and/or drop functionality from a release means that the platform can be released with high predictability and reliability, and is not delayed by problematic functionality in one area - the long pole in the tent.

With regards to LiMo Foundation, we are currently gearing up to produce Release 3.0 of LiMo Platform, but the recently published roadmap might be thought of as version 1.0 since this our first public roadmap.

Following the logic discussed above, we have adopted a time-bound approach in the planning of our next two releases, and intend to continue using a time-bound approach when charting future releases in the roadmap.