Analysis of the patents in suit, and their potential applicability to HTC product (and Android...), can be found elsewhere.

There has also been considerable speculation as to Apple’s “end game” (apparently protection of innovation may not be the motivation!)

The use by Apple of the ITC as one of the forums in which to assert their grievances/patents is noteworthy.  For those not familiar with the US International Trade Commission (“ITC”) it’s a quasi judicial/administrative body designed to prevent counterfeit (and US patent infringing) product getting into the US. Expedited process rules mean “investigations” (as cases are known) are concluded quicker, and more cost effectively, than cases in the US Courts. The ITC can’t award damages but can, if a complaint is upheld, issue an order barring the import (by the respondent – HTC here) into the US of infringing product – a draconian remedy if ever there was one!

As is usual, Apple has also issued US District Court proceedings (in Delaware) against HTC.  This is to recover damages (money...) but will take longer to conclude than the ITC case.

It’s also likely that a third battle front will be opened, by HTC, in the US Patent Office, where they could seek re-examination of some of the patents being asserted by Apple. Any successful re-examinations could, at least in part, help frustrate (or at least slow down) the ITC and Court cases.

Settlement can never be discounted in disputes such as this, but the initial soundings mean this looks unlikely in the short/mid-term.

I’ll monitor progression of this one with interest.

For me personally, the following caught my attention:

The geeks do PR (and apparently still no evil)!!

Google delightfully stole the limelight while Nokia was sulking away in their posh Barcelona hotel suite. (But hey, GSMA is really starting to push the boundaries….is anybody listening?) Coming back to Google, Eric Schmidt delivered a sensational keynote presentation on Tuesday – “Mobile First” and make sure you stand right in the intersection between Computing, Connectivity and Cloud. Gosh, can’t these guys suffer from the “demo effect”? They just sailed through all these speech and image recognition demos – really cool stuff!!

The WAVE that rides the ocean (BADA)

Samsung’s WAVE device based on the BADA Platform hit the Spanish Mediterranean city with all the fireworks or should I say all the splashes – Super Amoled, Integrated Address Book, Social Networking Hub – you name it, it’s got it……..except for…… multi-touch (damn Apple and its patents!!)

The giant wakes up from its slumber

In a desperate attempt to reverse its flailing smartphone platform unit, Microsoft rushed` to deliver Windows Phone 7.0. Ok, I admit it’s cool (except for the name) – it’s something I’d like to play with(checkout Zune, XBOX and Bing on the device) but hey, didn’t Apple do something similar about 2 years ago. More importantly, why are the PC and Internet companies so intent on turning the traditional handset manufacturers into fulfilment houses and the operators into dumb pipes? (I know Eric, you said they are valuable partners)

We are not dumb pipes!!

Fight-back time from the mobile operators – united they stand to fight the Internet and PC giants but what a dumb name - Wholesale Application Community! But as the saying goes, it’s the intention that counts and the spirit to fight back is indeed very much there! The app market is way too fragmented today and this common platform leveraging established standards such as BONDI will provide a seamless way for app developers to target billions of subscribers and build sustainable business models around mobile application development and distribution. (you can see I’m biased ;-) we love operators in LiMo!)

Meego (or Me Too?)

Linux still seems to be very much the flavour of the day in the industry and consolidation in any way or means is good in an industry that endeavours to reduce fragmentation but always seems to be announcing yet another platform. N900, Nokia’s first commercial device on Maemo, did receive good reviews even though developers knew a major Qt overhaul was about to take place breaking compatibility with future versions. I can see why Meego makes sense for Intel and but I have yet to figure out the Nokia angle….

Last words

All of the above can be interpreted as “good” or “bad” depending on which camp you are in.

In terms of the “ugly”, it’s most certainly the lack of law and order that several of the MWC 2010 visitors (including myself) had the misfortune of experiencing in the city of Gaudi. The authorities most certainly need to take some drastic actions to cut down on the number of muggings and armed robbery that visitors are subject to in the streets of Barcelona throughout the duration of the Congress.

Adios Barcelona!

• ACCESS
• Azingo
• LG
• NEC (Founder)
• NTT DOCOMO (Founder)
• Panasonic (Founder)
• Samsung (Founder)
• SK Telecom
• Telefónica
• Verizon
• Vodafone (Founder)
• Wind River

LiMo Foundation’s 2010 officers are:

• Executive Director: Morgan Gillis, LiMo Foundation
• Chairperson: Kiyohito Nagata, NTT DOCOMO
• Vice Chairperson: Sun Gi Hong, Samsung
• Vice Chairperson: Phillip Carter, Vodafone
• Treasurer: Ryoichi Sugimura, Panasonic
• Corporate Secretary: Alastair Sheehan, LiMo Foundation

Congratulations to all of the board companies and officers - we'll look forward to their leadership throughout 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.

In Part 1 of this 2 part series, we looked at the circumstances whereby an open source strategy would make sense, the reason why “open is free” is false notion, the importance of choosing the right open source development model, contribution strategy and the license that best suits  you.

Protect your reputation - don’t contribute bad code

Always remember you only have one reputation and while it takes a long time to build, it can vanish in seconds.  It is just as important to test and debug code contributions to the community as it is for internal releases.  Contribute buggy code and you will quickly be seen as a poor community member and your code may not be integrated into future baseline releases.  Other impacts may include your ability to attract the right talent to your business, especially if you are looking to hire from within the open source community or on your overall brand especially if software quality is an essential brand ingredient.  That said, releasing alpha and beta code is perfectly acceptable providing you make it clear that this is what it is and document the known issues.   So, keep it clean, protect your reputation and you’ll become a respected member of the community.

Identify the right business model

One of the common debates in open source is how to make money from it in a way that is acceptable to the community.  In our experience there are a wide range of valid business models that can happily co-exist with using open source software or indeed providing support services to those that are engaged with the community.

For example, a number of companies build full software distributions, usually based on Linux, that include a wide range of open source software but fully integrate it into a useable platform.   Normally consultancy, support, maintenance and adaptation services are provided around these distributions.  Many companies, including Teleca, provide integration services taking open source components and integrating them in product base lines. Relying on the base open source components to build value added products is frequently not realistic and therefore, services designed to provide customisation or extensions to these components are perfectly valid business models.  These are many examples of companies that are making a strong living from working with the open source community.

Appreciate that people don’t like to pay ransoms

While there are many valid business models, there are also business models that can alienate the open source community.  One such model is what we call asking people to pay ransoms – i.e. contributing core engines or components to an open source community with the intent of then making users dependent upon you for overly expensive customisation and extension services. The community will quickly reject this model and before long your components will have been removed from the baseline in favour of alternative contributions.  It can be surprising how fast the community can move when faced with being held to ransom.

Maintenance is NOT free

While there are many good justifications for making open source contributions, expecting free maintenance is not one of them as the basic dynamics of open source quickly underlines.  Most open source projects and communities rely on the goodwill of the members; be it on their personal time or sponsored by their employer.  However, you cannot contract with the community to provide SLAs for maintenance support, achieve commitments for defect analysis, fix bugs or set bug fix priorities. So my advice is simple - if you are delivering a commercial product or service then you need a simple maintenance plan to support your code.

Summary

Hopefully, the learning’s highlighted in this article will help you to develop an effective and rewarding model for leveraging and engaging with the open source community.  The core theme is simple, plan in advance and think through not just what software components you want to leverage but your overall engagement model with the wider community as the move to leverage open source has ramifications that ultimately touch many if not all areas of a business.