Under the Hood of Developer Marketing: Intel’s Scott Apeland

Developer Marketing – what is it, why is it important, how to develop it successfully? We’ve interviewed Scott Apeland who leads the Developer Program at Intel to share with us what it takes to succeed in this rapidly expanding field. This interview is part of our Under the Hood of Developer Marketing series where we ask leading practitioners what Developer Marketing and Developer relations mean to them, what they do to make it happen, and how they measure success.

Continue reading Under the Hood of Developer Marketing: Intel’s Scott Apeland

Unity leads the way in developer satisfaction

As software continues to eat the world (to paraphrase Marc Andreessen), software developers fulfill an ever more critical role in the progress of technology and, by extension, society. Supporting developer productivity is good for business. Those developers then become innovators – co-creators – that give a boost to your core business.

It’s also challenging. Developer programs consist of a myriad of activities, ranging from simple providing sample code and developer education, to tooling, to in-person events and online communication. It’s hard to be great at everything, and it’s hard to allocate effort and money effectively for maximum impact.

Every six months we benchmark top developer programs against each other. First, by measuring what developers value in those resources and activities, in all its diversity across several segments of the developer population. Second, by highlighting the best practice leaders: those vendors that are doing an excellent job in specific aspects of developer programs, to whom you can look for inspiration and insights on how to improve. There is no single leader across all of the 20 activities we measure – everyone can improve somewhere.

unity leads developer satisfaction

The top spot in terms of developer satisfaction is taken by Unity, with an overall developer satisfaction score of 75 out of 100. Unity shows exceptional performance on several attributes: tutorials, how-to videos & webinars, and official forums. This may be skewed by the fact that their products cater to a specific subset of developers (game developers) who might score attributes differently than others.

Google, Microsoft, and Mozilla are not only among the largest developer programs; they lead the pack in terms of developer satisfaction and engagement. Other major developer companies like Amazon, Facebook, Oracle, and Apple follow at some distance.

This doesn’t imply, however, that only the companies with the most traction and the biggest budgets can create excellent developer support programs. The living proof of that are Unity and Tencent. As we said, Unity has the highest developer satisfaction of all programs in our list. Tencent, the producer of WeChat who mostly addresses a geographical developer segment in China, has a developer satisfaction on par with Facebook and well beyond Twitter’s, and one of the highest levels of engagement in our survey. Other companies like Intel and Cisco may have moderate overall performances, but lead the way in important attributes such as training, technical support, or access to devices.

The study above shows data from the 12th edition SlashData Developer Economics survey. Over 21,200 respondents were asked which developer programs they used and how satisfied they are with them. These respondents came from 162 countries around the world and span mobile, desktop, IoT, cloud, AR/VR and machine learning developers and data scientists. The results were collected by SlashData over a period of six weeks between November and December 2016.

To access the full study drop us a note at sales@slashdata.co or download the brochure

Return on Developer Investment

My most fun job ever was as a C++ developer. Ok, I don’t have much grey hair yet, but I fondly remember the late 90s and the challenges of writing a background synchronisation application on a Compaq iPaq. And reverse engineering Mozilla’s Navigator into an XSLT parser.

My second most fun job ever has been building a company that helps the world understand developers, with research. We’ve come a long way – and a few pivots – from surveying the pulse of 400 developers in 2009 to 30,000 developers annually in 2016. That’s a lot of data – in fact more than our analyst team can chew.

It’s a privilege to be working with some of the biggest names in tech – I ‘ve learned a lot the past 2 years. Earlier this month, Amazon, Microsoft, Facebook, Adobe, Intel, Oracle and many more joined our first Future Developer Summit, and shared some of their best practices in how they work with developers. I ‘d like to share some the learnings here.

Return on Developer Investment.

You would think that with billions of dollars spent every year on building tools for developers, running hackathons, loyalty programs, tutorials and how-tos, evangelist and MVP programs – the platform leaders would have figured it all out. Yet, with so much money being spent on developer tools and marketing there is no standard for measuring the Return on Developer Investment.

Most companies represented at the Future Developer Summit shared how they measure success. At their inception, developer-facing orgs measure success by number of developers touched – but that’s a meaningless metric, a dinosaur from the age of print marketing. Some platforms are using NPS (net promoter score), polling their active developers once a year for how likely they are to recommend the platform. Many are informing product decisions based on developer comments (“will you ever fix that”?) – you’ll be surprised how many decisions are taken based on “the devs that I spoke to said..”.

Other developer relations teams are measuring success through the number of apps in the store, and the number of apps using signature APIs. In the case of open source projects, a popular metric is GitHub stars, forks and commits over time. The more sophisticated platforms track the Return on Developer Investment funnel from SDK downloads to app download and use. But there isn’t a consistent way to measure how the investments in hackathons, tutorials, how-tos, loaner devices, evangelism programs and some many more developer-facing activities are paying off for the likes of Google, Amazon and Facebook.

Quality of apps, not quantity.

Another theme of the Future Developer Summit was the need for quality, not quantity of applications at the start of an ecosystem. B2B ecosystems like Slack and Intuit prioritise quality; Poorly written messaging apps can damage not just the perception of Slack, but also the perception of chatbots in general. Similarly, a poorly written app for the QuickBooks platform can wreak havoc to sensitive financial data for thousands of small businesses. As a result both Slack and Intuit have very stringent app review processes, including weeks of testing, usability and security reviews. To improve quality for bots, Slack has pioneered a “Botness” program, bringing together bot platforms and leading bot developers; the aim is to “make bots suck less” i.e. improve the bot user experience and avert a long-term damage to the reputation of chat bots. There are already 250 members signed up and the next event is on November 4 in NYC .

The next Future Developer Summit will focus on best practices for developer relations. If you ‘d like to be part of the invite-only audience of platform leaders, register your interest at www.futuredeveloper.io

 

From MeeGo to Tizen: the making of another software bubble

[Just a short 1.5 years from MeeGo’s birth, Intel dumps it to shift focus to a new platform, Tizen, in partnership with Samsung. Guest author Dave Neary discusses the underpinnings of Tizen and why both MeeGo and Tizen are software bubbles].

VisionMobile - From MeeGo to Tizen: A software bubble in the making

Eight months after Nokia embarrassed Intel by withdrawing support for the MeeGo project, Intel has followed suit. On 27th September, Intel and Samsung announced the birth of a new mobile platform called Tizen. After only 19 months, MeeGo has been left parentless, and appears to be on life support. Tizen is, in fact, a successor of the Samsung Linux Platform, a reference platform of the LiMo operator consortium, with some components taken from the MeeGo stack.

Given that LiMo and MeeGo have both failed to set the mobile computing world alight, and Android has a four year head start, can we expect better things from their offspring? What has changed with this announcement? Is this Intel’s last chance to have a stake in a credible smartphone platform? And what  should Samsung, Intel and the Linux Foundation do to give their new platform a fighting chance at success?

The Birth of Tizen

Last year, when reviewing the progress which MeeGo had made in its first few months, we reserved judgement on the project, on the grounds that it was “too early to be able to tell how the final product will compare to iOS or Android”, but we noted that there had been some growing pains between Nokia and Intel.

Those growing pains stretched to breaking point earlier this year, when Nokia finally gave up on MeeGo and turned to Windows Phone to revitalise its smartphone products. Intel was left looking for a heavyweight consumer device partner to come in and lend credibility to their claim that MeeGo was no longer a one-man show. Rumours that LG would be joining the project failed to materialise. Finally, Intel ran out of patience, and partnered with Samsung on a new platform, Tizen, to be based on SLP (Samsung Linux Platform), a platform which Samsung have previously provided to the LiMo Foundation to be used as a reference plaform for its members.

While the move has obviously been in the planning for months, Samsung were perhaps encouraged to partner with Intel on the back of the news that Google has acquired Motorola Mobility in August – a view supported by their recent settlement of an Android-related patent dispute with Microsoft. In addition, as LiMo members, most notably Vodafone also ran out of patience, SLP was left as a platform without a home.

MeeGo on Life Support

How does MeeGo fit into the big picture now? High profile participants like GENIVI, China Mobile, Asus and Acer have committed to shipping MeeGo devices. Will they be based on the unreleased MeeGo 1.3, or the previous 1.2 release? Or will these companies move en mass to Tizen?

Given the lack of reaction from partners like GENIVI, we suspect that the Tizen announcement caught these vendors unawares. Jerermiah Foster, a community manager working for one GENIVI member, informed me that his company would reuse MeeGo 1.2 in the short term, and while Tizen looked interesting, there were no current plans to move development to the platform. He also confirmed that he found out about Tizen through the project announcement, and not before.

In spite of vendors withdrawing their support, part of the community is banding together to salvage their work. After Nokia pulled out of MeeGo, community developers working on the MeeGo Handset UX banded together to continue work (with several Nokia engineers) in the MeeGo Handset Community Edition, aiming to provide MeeGo support for the Nokia N900, N950 and N9 devices. In spite of the Intel announcement of Tizen, these developers have vowed to continue the development of MeeGo on ARM, and released the MeeGo Handset Community Edition 1.3 at the end of September. The current plan proposed by these developers is to create a lightweight core distribution based on Qt, under the brandname “Mer” (“MeeGo Rebooted”), on which vendors can build custom user interfaces. The MeeGo Handset Community Edition will be the first consumer of Mer’s core operating system.

The MeeGo community mailing lists are full of developers wondering where they stand now. The announcement suggests that no software will be released from the Tizen project for another 6 months. According to Joel Clark, MeeGo IVI Program Manager, the MeeGo 1.3 release has been shelved, and only incremental updates to the previous 1.2 release can be expected until then. While the MeeGo community certainly has some enthusiastic community supporters, it is unlikely that any major vendors will adopt the community-supported Mer.

Ironically, the move away from MeeGo comes at a time of potential wins for the project. Nokia’s MeeGo-based N9 is finally shipping, and getting rave reviews. And continued demand for netbooks has fueled the launch of several MeeGo based netbook and tablet products, including the Asus EeePC X101, the Acer Iconia M500 and other devices from Samsung, Lenovo and Fujitsu.

Perhaps Intel ran out of patience just as the project was about to take off.

Tizen = SLP, with a pinch of MeeGo

Technically, Tizen is a successor of the Samsung Linux Platform, a reference platform of the LiMo operator consortium, with some components taken from the MeeGo stack. The project governance and infrastructure, however, will look a lot like MeeGo. According to Imad Sousou, the director of Intel’s Open Source Technology Center, and head of the MeeGo project: “in the new project, a lot of things will be the same as they were in the MeeGo project”.

We also know is that the primary APIs for 3rd party developers are targeting HTML5 and WAC environments. WAC stands for Wholesale Applications Community, a set of APIs for building and delivering rich HTML5 applications, based on APIs from JIL (Joint Innovation Labs) and BONDI (a platform specified by the now-defunct Open Mobile Terminal Platform, OMTP). The Enlightenment Foundation Libraries (EFL), are also set to be a key part of the platform. We can infer two things from this: Qt will be taking a back seat in Tizen, if it is part of the platform at all, and it appears that SLP will be the basis of the Tizen platform.

One thing which has not changed from MeeGo is the wide range of participants being targeted by the project. At the moment, the target audience can best be summarised as “everyone”. Tizen is aimed at platform developers, integrators, vendors, application developers, and mobile enthusiasts. That’s a very wide range of target audiences, each with different needs and expectations. Not knowing your target customer is a surefire way to throw money down the drain.

Challenges, challenges, challenges

Tizen’s main difficulties at this point can be broken into three groups.

First, there will inevitably be teething problems between the project founders. The fact that Samsung have not yet mentioned Tizen in any press releases or announcements, and the lack of new information coming from Intel representatives since the launch announcement, suggests that there may be some communication issues to be worked out in the relationship. In fact, at this point it looks like the active partners have not yet agreed on what will and will not go into the platform. Intel and Samsung will have to work hard to overcome the cultural dissonance which is inevitable given the very different corporate DNA.

On top of this, unless something changes soon, there could be a major mismatch between the reality of working with Tizen and the public positioning of the project. The project isn’t yet open for business, and when it is, it will only be useful for a small subset of its target market. If it were a new project, they might get away with it. But with the legacy of MeeGo, Moblin and Maemo, disappointing early adopters could be a very dangerous thing to do for Intel and Samsung. Getting the project governance and community dynamics right from the start is vital to learning from the mistakes of MeeGo and Moblin.

Beyond the community, there are question-marks over Tizen’s potential to make an impact in the industry. Google’s purchase of Motorola Mobility, not just a patent portfolio play, has created a disturbance in the force around the Android universe. Samsung does not want to find itself competing with Google at the same as they are dependent on them for their smartphone platform. This creates an opportunity for Tizen which it is too immature to exploit. For third party developers, concentrating on HTML5 is great. But will there be a demand for a native API also? And if so, will Tizen be capable of providing the kind of unified developer experience you get on iOS or Android?

It will be interesting to see if Intel and Samsung manage to get substantial support from other ARM vendors. As long as Intel are seen as the main custodians of the project, that seems unlikely. It will also be interesting to see the effect which Nokia’s first Windows Phone based devices, due to be announced at the end of October, will have on the project.

The main challenge for the Tizen partners will be getting devices to market. The key constituency for the change, vendors who were committed to MeeGo before, appear to have been neglected during the announcement. Intel and Samsung need vendors to adapt the platform to sell more chips, to give breadth to the ecosystem around the project, and to give credibility in the industry that this is not a party of two.

The Long Road Ahead

To succeed and make a space for itself in the mobile ecosystem, execution will need to be flawless on Tizen. If the internal bickering which dogged MeeGo rears its head again, if the initial release of the platform does not meet vendor and community expectations in terms of functionality and quality, or if there is an 18 month wait for well integrated finished products running Tizen, then the project may not have a second chance to make good.

Tizen seems set to be another victim of misaligned incentives across several industry partners. Samsung is bringing SLP to the “standards” table simply to find a new home for it, now that LiMo is winding down. Intel is seeking another marriage of convenience, trying to tempt a major OEM to ship significant x86 chip volumes.

– Dave

[Dave Neary is a regular columnist at VisionMobile writing on how companies can work more effectively with open source community projects. Dave is the founder of Neary Consulting and  has also been an active member of the GIMP, GNOME, OpenWengo, Maemo and MeeGo communities, with over 10 years of experience in open source community issues. He can be contacted at dave (at) neary-consulting (dot) com]

Open Source community building: a guide to getting it right

[Everyone – from carriers to OEMs – is busy building developer communities. But many have failed and more have seen disappointing results. Guest author Dave Neary looks at what lessons history can teach us on community building and the key DO’s and DON’Ts.]

Open Source community building: a guide to getting it right

Community development in open source software is not just for geeks in sandals nor for niche Linux companies any more. It’s mainstream and it’s here to stay.

The recent analysis of companies contributing code to the Linux kernel shows that large companies including Novell, IBM, Intel, Nokia and Texas Instruments are getting serious about engaging in community development. Organisations such as the LiMo Foundation are encouraging their members to work with community projects “upstream”, that is, with the community rather than in isolation,  to avoid missing out on millions of dollars worth of “unleveraged potential” (PDF link).

A diverse developer community is critically important to the long term viability of free and open source projects. And yet companies often have difficulty growing communities around their projects, or have trouble influencing the direction of the maintainers of community projects like the Linux kernel or GNOME. Sun Microsystems and AOL are prominent examples of companies which went full speed into community development, but were challenged (to say the least) in cultivating a mutually beneficial relationship with community developers. There are many more examples – but often we never even hear about companies who tentatively engage in community development, and retreat with their tail between their legs, writing off substantial investments in community development. Xara, for example, released part of their flagship software Xara Xtreme for Linux as open source in 2005, before silently dropping all investment in the community project in late 2006.

What can go wrong? What are the most common, and the most deadly errors which companies make in their community engagement strategies? And how can you avoid them? Avoiding these does not guarantee success, but failing to avoid them may be sufficient to guarantee failure.

Where to begin?
The easiest and gravest error that companies make is to sprint headlong into free/open source development with unrealistic expectations.

The history of free & open source software development is filled with stories of companies who are disappointed with their first experiences in community development. The technical director who does not understand why community projects do not accept features his team has spent months developing, or the management team that expects substantial contributions from outside the company to arrive overnight when they release software they’ve developed. Chris Grams once described the Tom Sawyer model of community engagement – companies who expect other people to do their job for them. Make sure you don’t fall into that trap.

Doing community software development well takes time, even when you get everything right. And there are a lot of things you can get wrong.

So where to begin? Before you start community development, you should have thought about what you want to get out of it. Is Open Source a way to grow the brand and broaden distribution of your product, with the goal of generating leads? Do you need to grow an ecosystem of developers building on top of your platform? Do you want to include an existing project into your product to reduce costs, but customise it to fit your needs? Each of these goals, and any of the other reasons people develop software in the open, require specific strategies and tools tailored to the situation to succeed. Indeed, how you measure success will change depending on your goals.

The two common situations company find themselves in are collaborating with an existing open source community, or growing a community around a piece of software that you are releasing.

Joining a community
When joining an existing community, building trust and reputation takes time. The first step to working productively with a community is to understand the structure of that community. Who are its leaders, what are its priorities? If the culture of a project does not align with your business objectives, that may affect your decision to engage with it in the first place.

If you find that you can work with the project, and that the general goals are aligned (or at least, not misaligned) with yours, then the hard work can start. For example, Hewlett-Packard backed Linux early, at the expense of promoting its own proprietary Unix, HPUX. Ten years on, HP now ships close to 40% of all Linux servers. In contrast, Sun Microsystems decided to create an independent community around Solaris in 2005, releasing OpenSolaris under an Open Source approved licence which is incompatible with the GPL (the licence of the Linux kernel). The Sun sponsored project failed to create a substantial independent developer community from its launch until the acquisition of Sun by Oracle and subsequent closing of the OpenSolaris project in 2010.

Once you make the decision to collaborate, and you have chosen the project you want to work with, the first and most important decision is who will work on the project. This consideration often does not get the attention it requires from top management. The engineers who will be working on the project on your behalf will be representing your company. It will be their job to build trust with project maintainers, navigate the project’s roadmap process to ensure that their work is accepted upstream, and ensure your business objectives are met.

The choice of the people who will work with the community is particularly important; as Stormy Peters, former Executive Director of the GNOME Foundation, once wrote, companies are not people. In other words, companies can never be members of a software development community, although their employees may. Companies can be valuable institutional partners for projects, but to quote the Beatles and Karl Fogel, money can’t buy you love (or community support).

So now you have some engineers working with the community. What next? Havoc Pennington wrote some excellent advice in 1999 for engineers working with community projects. The one-line summary might be: “when in Rome, do as the Romans do”.

Often communities will have documented their norms – many projects, including the Linux kernel and modules in the GNOME project, have “HACKING” files under source control documenting expectations for contributions, and mailing list policies. For most communities, these can be summarised as “go with the flow, don’t rock the boat”. Miguel de Icaza, founder of the GNOME project and vice president of developer platforms at Novell, has written an article explaining the reasoning behind these policies.

One temptation which you should avoid at all costs is to leverage the trust which one contributor has gained to channel contributions from others into the project. This will only promote Shy Developer Syndrome in your team.

By all means, have your senior community guy mentor others in the team and help them through the process, but avoid making that mentor a gatekeeper, shielding the rest of your team from the community. Attempting this will always backfire when your gatekeeper moves on or when the community finds out that he’s committing the work of others and circumventing community norms.

Growing a community
Looking at the second scenario; growing a community. If you do decide to release software under a free software OSI approved licence, your first choice will be whether to set the project up as a community project or not, and to what level.

Simon Phipps has written about the different types of communities which can grow around a free software project. He describes communities of core codevelopers, non-core developers who work on add-ons, integrators who distribute and configure the software, but don’t necessarily modify it, and finally users of the software. Each of these communities have different needs, and require different approaches.

If you want to grow a community around your project, there are a few best practices you should follow:

Control: If you opt for rules ensuring that you decide what code will be added to your product’s core, you will lose many of the benefits of community projects. Some examples of rules which come from a desire to maintain control are a requirement to assign copyright for all contributions to the core product to you, or ensuring that only employees can commit directly to the main branch of your core product. There are many good reasons to maintain ownership of the core, but this decision will severely handicap community contributions. This does not prevent you from developing other types of community, however, such as a community of add-on developers or integrators.

Barriers to entry: Barriers that contributors have to overcome can come in different shapes: using unusual tools, requiring convoluted processes for bug reporting, feature requests  or patch acceptation, or legal forms you may ask people to sign before contributing.

Tools and infrastructure: Ensure that you provide your users with the opportunity to distribute their work and connect with other users – whether this be through a forge for modules, or through the use of Gitorious of Bazaar for source control. Contributing in your project should be seen as a social experience.

Community processes: Create a just environment – no-one likes to be considered a second class citizen. Document processes for gaining access to key resources like bug moderator permissions, commit access to the master branch, or editor access for the project website.

Budget appropriately: Commit the appropriate resources – building a community takes time and effort, and that means investment – primarily of human resources.
Having one guy who is the community manager dealing with the community and a team of 10 developers behind the corporate walls isn’t going to cut it. As Josh Berkus of PostgreSQL said in his “How to Kill your community” presentation, if your nascent community feels neglected, it will just go away.

Launching a new project is like launching a new product – except that acquiring a new community developer takes much longer, and is much more difficult and costly than acquiring a new user. In the same way that companies track SAC for new product launches, tracking the Developer Acquisition Cost (DAC) for your project is a key metric in evaluating whether you are doing the right things to grow your community.

Developers have lots of projects to choose from, and they tend to gravitate towards projects where co-development is the norm. So you have to be thinking about the contributor experience, and the value proposition to external contributors, all the time.

A clear and compelling vision, with lots of opportunities to contribute, and low barriers to collaboration, can help reduce the acquisition cost of community contributors, and similarly reduce the cost of acquiring new users and paying customers.

Avoid common anti-patterns
If Best Practices are behaviours that should be adopted, community anti-patterns are best practices gone wrong. If the reasons behind a “best practice” are misunderstood, you can end up imitating behaviour without getting the desired result, much like the Pacific cargo cults, building airstrips and hoping that planes land. Like seasoning, adding too much can ruin the dish.

In general: when you see the following patterns happening, you should work to counter-act them, both in the communities you participate in, and in your corporate citizen behaviour within those projects. Each of these patterns are common and tempting, because they represent best practices applied in inappropriate circumstances. And each of them results in a net reduction of community health.

Some common anti-patterns you should avoid are:

1. Command & Control – communities are partnerships. Companies are used to controlling the products they work on. Attempting to transfer this control to a project when you want to grow a developer community will result in a lukewarm response from people who don’t want to be second class citizens. Similarly, engaging with a community project where you will have no control over decisions is challenging. Exchange control for influence.

2. Water cooler – when your team gets too much work done in private, your community will not understand your motives and priorities. By working on mailing lists or other publicly readable and archived forums, you allow people outside your company to get up to speed on how you work.

3. Bikeshed – A “bikeshed” discussion is a very long discussion to make a relatively minor decision. When you feel like the community is dragging you down, know when to move from talking to doing.

4. Black hole – It can be tempting to hire developers who have already gained reputation and skills in projects you build on. Beware when hiring developers from the community – it may be that the community will be worse off. Ensure that working in the community is part of the job description.

5. Cookie licker – Picture a child who has had enough cookies, but wants to save the last one for later. So they take it off the plate and lick it, to ensure no-one else will eat it. The same phenomenon exists for community projects – prominent community members reserve key features on the roadmap for themselves, potentially depriving others of good opportunities to contribute. Beware of over-committing, and leave space for community contributions in project roadmaps. Be clear on what you will and will not do.

Happy Community Gardening
Community software development can be a powerful accelerator of adoption and development for your products, and can be a hugely rewarding experience. Working with existing community projects can save you time and money, allowing you to get to market faster, with a better product, than is otherwise possible. The old dilemma of “build or buy” has definitively changed, to “build, buy or share”.

Whether you’re developing for Android, MeeGo , Linaro or Qt, understanding community development is important. After embracing open development practices, investing resources wisely, and growing your reputation over time, you can cultivate healthy give-and-take relationships, where everyone ends up a winner. The key to success is considering communities as partners in your product development.

By avoiding the common pitfalls, and making the appropriate investment of time and effort, you will reap the rewards. Like the gardener tending his plants, with the right raw materials, tools and resources, a thousand flowers will bloom.

– Dave

[Dave Neary is the docmaster at maemo.org and a long-standing member of the GNOME Foundation. He has worked in the IT industry for more than 10 years, leading software projects and organising open source communities. He’s passionate about technology and free software in particular.]

The MeeGo Progress Report: A+ or D-?

[Eight months after the announcement of the MeeGo  project by Intel and Nokia, guest author Dave Neary analyses the progress made to date in MeeGo Handset, and the project’s prospects for the future]

VisionMobile - The MeeGo progress report

The end of October saw the release of MeeGo 1.1, the second major milestone release of the platform since it burst onto the scenes in February 2010. The MeeGo project was born under the auspices of the Linux Foundation from a merging of Nokia’s Maemo platform, targeting smart phones, and Intel’s moblin platforms, aimed at netbooks.

[poll id=6]

The merger grew from a core idea: pick the best of breed components from both stacks, collaborate on the integration and testing of shared components, and standardise a number of open source UX (User eXperience) profiles, on which vendors could build and deploy complete commercial grade stacks. The initial UX profiles announced were netbook, smartphone, IVI (In-Vehicle Interface) and media center/TV.

Nokia and Intel have both made a major commitment to the platform, but critics say that the relationship is little more than a marriage of convenience. After all, Intel is a silicon vendor, betting heavily on the Atom-based Moorestown platform, and Nokia is a handset designer, largely shipping ARM-based devices.

Growing pains

The project has had some teething problems. Troubled Nokia has changed CEO, and the founding father of the Maemo project, Ari Jaaksi, has been among a number of high level software executives to leave the company, leading some to ask whether Nokia might have a change of heart about the platform. The first MeeGo device for Nokia, originally expected at the end of 2010, will now appear in 2011, according to recent comments from new CEO Stephen Elop, as Nokia strive to ensure a good first impression for its first MeeGo device.

There are some early public signs of friction in the working relationship of the stakeholders in the project, also.

The adoption of Qt as the primary toolkit for both platform and applications has met with resistance from Intel engineers, who acquired Clutter in 2008 and integrated it heavily into the netbook user interface, plus partners like Novell who developed versions of GTK+ applications like the Evolution email client and Banshee music player specifically for the netbook form factor.

Long-awaited MeeGo compliance specifications have resulted in drawn out and sometimes acrimonious debate.  Trademark guidelines have been a sticking point for community ports of the MeeGo netbook UX to Linux when these ports do not include required core components.

Related to the technical governance of the project, there is some uncertainty around the release process, and the means and criteria which will be used when considering the inclusion of new components. And there are some signs that the “all open, all the time” message at the project launch has been tempered by the reality of building a commercial device.

The Promise of Openness

Many of these issues are to be expected when merging two projects into one and pairing two very different animals. Every open source project has its own culture, and Moblin and Maemo are no different. Relationship capital which participants built up in the contributing projects must now be rebuilt within a broader group.

MeeGo has had some early successes. MeeGo 1.0, which included the Netbook UX and an early prerelease of the smartphone UX, was delivered in July, complete with the source code of a number of components which had previously been proprietary. Novell MeeGo has been shipping on a number of netbooks since then. The MeeGo wiki lists dozens of MeeGo-compatible devices. The inaugural MeeGo Conference is set to take place in Dublin, from the 15th to the 17th of November, and has sold out with over 600 registered attendees to date.

And there is no denying that the companies involved in the project are committed to it. With the recent rumours that the Symbian Foundation may be shutting up shop, Nokia has few choices of platform left for upcoming high-end devices. Announcing their updated software strategy during their quarterly results call this month, the company confirmed that they are fully committed to MeeGo as the only platform for high end devices from now on.

Clearly, there is a future for the project. The question is, how will MeeGo Handset hold up against the competition from the platforms with the most momentum in the market – iOS and Android, or the recently released Windows Mobile 7. Will a newly reinvigorated WebOS (with Ari Jaaksi at the helm) challenge it for the mantle of the exciting new upstart? In short, is it any good? And will operators, handset manufacturers, application developers and users adopt it?

User experience

Since we do not yet have a MeeGo handset device available, it is very difficult to accurately judge the user experience at this time. It is possible to install MeeGo on the Nokia N900 and use it as a phone, using Nokia’s proprietary drivers to enable the hardware, but a lot of basic functionality is missing at present. In my tests, the camera, GPS, battery indicator, network signal strength indicator and WiFi did not work correctly. Features which do work can be slow, or have stability issues. Basic functionality like reading contact details off a SIM card, or unlocking the SIM card on boot, are still missing.

A MeeGo device getting to the market will undoubtedly have pristine hardware integration using 3rd party drivers, and a considerable amount of fit-and-finish which the basic MeeGo stack does not yet have.

The MeeGo handset user experience is still in transition. Maemo 5, the platform’s predecessor, was created using GTK+ and Clutter, while the MeeGo user interface has been built from the ground up using Qt. By all accounts, there are still a number of stability and quality issues with the stack, which we can expect to be addressed in a release shipping on a device.

At this time, the MeeGo Handset UX is not intended for anyone but developers. It is too early to be able to tell how the final product will compare to iOS or Android.

The Developer story

At the time of its announcement, one of the key advantages held up to developers was the potential to use a single toolkit, Qt, to build native applications which will be portable across Windows, Linux and Symbian. Nokia has been investing heavily in RAD tools like Qt Quick to allow developers to get up and running quickly. In addition, their as-yet unavailable Web Run Time promises to allow developers to easily integrate web applications.

The developer tools are in development, and do not yet compare favourably with the equivalent Android offering, which includes easy tools for building, testing and deploying applications using Eclipse. In addition, since the project is still in relatively early stages, there is a marked lack of entry-level documentation to help developers get started.

It is still unclear what software distribution channels or app stores will be available for application developers on a MeeGo device. Ovi Store will be available on Nokia devices for commercial applications, and there may be a community distribution channel made available for community-built applications, but what form this channel might take, and to what extent it will integrate with the MeeGo user experience is still unclear. Presumably other handset manufacturers, should MeeGo gain wider adoption, will provide their own application stores, further fragmenting the application developer story.

MeeGo certification ensures that it will be possible to build applications which work across all vendors, but at this point the jury is still out on how useful “MeeGo Compliant” will be to application developers. There is a possibility of considerable fragmentation among non-core APIs when MeeGo devices from several vendors are available.

From the point of view of tools, documentation and software distribution channels, MeeGo is undoubtedly behind its primary competitors – but for such a young project, this is to be expected. The success of the project among application developers and the free software community will depend to a large extent on the project’s ability to fill these gaps and provide developers with an excellent development experience.

For platform developers, the story is much more encouraging. The source code to the entire MeeGo stack is available, and anyone can download images built daily. Images built for ARM and Intel Atom can be installed and tested on a range of developer devices, including the Nokia N900, TI’s BeagleBoard or PandaBoard, or the Aava Mobile developer kit.

On the other hand, there has been a tendency of the platform architects to reduce the range of hardware and software supported by the basic MeeGo stack. There is limited support for non-Intel x86 chipsets, and support for only a subset of ARM chips. Kernel modules have been aggressively trimmed, sometimes arbitrarily, to disable functionality such as NFS.

Community and governance

MeeGo development is all happening in a public git repository, most discussions are on public mailing lists, and there are a large number of experienced free software developers among the community development team, which is ensuring that any communication or transparency problems are identified and addressed swiftly. In the mobile platform development world, it is fair to say that MeeGo is second to none in terms of its open development model.

This contrasts sharply with Android which is primarily developed behind closed doors by Google, and iOS which is a completely proprietary platform. If there is a key differentiator for MeeGo in the hand-held market, this is it. It remains to be seen whether the open development model will be a selling point which will tip the balance when manufacturers are choosing a platform for a device.

The MeeGo community is made up of members of the Maemo and Moblin communities, and in the case of Maemo, there have been a number of contributors who have decided not to contribute to the MeeGo project. The move to MeeGo represents the third major change in the project in two years (after the move to GTK+/Clutter in Maemo 5 and the announcement that Qt would be the only supported application toolkit) and has left some shell-shocked.

The Moblin community, on the other hand, did not develop a large platform developer community, partly since the project did not offer a distribution channel for application developers. It seems like all those who were productively contributing to moblin have followed the project move to MeeGo.

OEMs and operator support

One of the key differentiators between traditional handset manufacturers and the young guns (iOS and Android) which have taken the market by storm, is that both Android and iOS have concentrated on the user and application developer experience to the detriment of their relationship with OEMs and operators. It is widely argued that Apple’s iPhone has reduced the role of the operator to that of a bandwidth and infrastructure provider. In turn Google takes a take-it-or-leave-it approach with handset manufacturers; unless manufacturers comply with Android’s compatibility definitions (CTS and CDD), they can’t have access to the Android trademark, Android Market’s 100,000+ application, Google Maps and several other closed source applications.

Nokia has a more traditional approach of putting handset manufacturers and network operators ahead of developers. This shows through in many of the architecture decisions in MeeGo. The platform has been built with operator and OEM customisation and integration in mind from the start.

A primary concern for OEMs with MeeGo is the time required to integrate the platform into a specific device and ship to market. With the time to market for Android handsets dropping to 4-5 months from project to production, it will be very hard for MeeGo to compete, even with the MeeGo 1.2 release, due in the first half of 2011.

Still a long way to go

It does not feel fair at this point to compare MeeGo, a project which came into being 8 months ago, with iOS or Android, but this is the yardstick which will be used when the first MeeGo smartphone comes on the market. The project has come a long way since its inception, in particular in working towards an open and transparent development model. There is still some way to go but improvements have been happening daily.

However, to succeed as a platform, the application developer story and the user experience are vital. There is a lot of work to be done in these areas for MeeGo to gain serious traction outside of the small community of Finnish handset designers. Nokia still has a long way to go.

– Dave

[Dave Neary is the docmaster at maemo.org and a long-standing member of the GNOME Foundation. He has worked in the IT industry for more than 10 years, leading software projects and organising open source communities,  He’s passionate about technology, and free software in particular.]

Enter the Cloud Phone

[With the adoption of SaaS applications, augmented reality, visual recognition and other next-gen phone apps, the smartphone processing model is looking for help from the Cloud. Guest author Vish Nandlall introduces the concept of the Cloud Phone and the technology advances that can make this happen]

Are smartphones converging with laptops ? While smartphones enable a rich user experience, there exists an order of magnitude gap in memory, compute power, screen real-estate and battery life relative to the laptop or desktop environment (see table below). This disparity renders the whole question of smartphones vs laptops an apple vs oranges debate. It also begs the question: can the smartphone ever bridge the gap to the laptop?

Smatphones Laptops
Apple iPhone 4 HTC EVO 4G ASUS G73Jh-A2 Dell Precision M6500
CPU Apple A4 @ ~800MHz Qualcomm Scorpion @ 1GHz Intel Core i7-720QM
@ 2.80GHz
Intel Core i7-920XM @ 2.0GHz
GPU PowerVR SGX 535 Adreno 200 N/A N/A
RAM 512MB LPDDR1 (?) 512MB LPDDR1 4x2GB DDR3-1333 4x2GB DDR3-1600
Battery Integrated 5.254Whr Removable 5.5Whr 75Whr 90Wh

Source: vendor websites

As a matter of physics, the mobile and nomadic/tethered platform will always be separated along the silicon power curve – largely driven by physical dimensions. The laptop form factor will simply be able to cool a higher horsepower processor, host a larger screen real-estate and house a larger battery and memory system than a smartphone.

Does a smartphone need to be laptop ?
Yes it does…or, at least, it soon will. The low-power constraints of mobile devices have been the official Apple argument behind the recent Apple-Adobe feud – and Apple’s acquisition of PA Semi is a further testament to the importance of the hardware optimization in mobile devices.

The processing envelope for mobile applications is becoming stretched by the demands of next-generation mobile applications; always-on synchronization of contacts, documents, activities and relationships bound to my time and space; the adoption of Augmented Reality applications by mainstream service providers that pushes AR into a primary ‘window’ of the phone; advanced gesture systems as MIT’s “sixth sense” that combine gesture based interfaces with pattern recognition and projection technology; voice recognition and visual recognition of faces or environments that makes mobile phones an even more intuitive and indispensible remote control of our daily lives.  All these applications require the combination of a smartphone “front-end” and a laptop “back-end” to realise – not to mention having to run multiple applications in parallel.

The appearance of these next-gen applications will also create greater responsibilities for the mobile application platform: it is now important to monitor memory leaks and stray processes sucking up power, to detect, isolate and resolve malicious intrusions and private data disclosure, and to manage applications which require high-volume data.

So we come back to the question, is there a way to “leapfrog” the compute and memory divide between tethered and mobile devices? The answer, it turns out, may lie in the clouds.

Enter the Cloud Phone
The concept of a Cloud Phone has been discussed oftentimes, most recently being the topic of research papers by Intel labs and NTT DoCoMo technical review.

The concept behind the Cloud Phone is to seamlessly off-load execution from a smartphone to a “cloud” processing cluster. The trick is to avoid having to rewrite all the existing applications to provide this offload capability. This is achieved through creating a virtual instance of the smartphone in the cloud.

The following diagram shows basic concept in a nutshell (source: NTT DoCoMo technical review)

The Cloud Phone technology has been brought back in vogue is due to advancements in four key areas:

  1. Lower cost processing power; Compute resources today are abundant, and data centers have mainstreamed technologies for replicating and migrating execution between and within connected server clusters.
  2. Robust technologies for check-pointing and migrating applications; Technologies such as live virtual machine migration and incremental checkpointing have emerged from the classrooms and into production networks.
  3. Reduced over-the-air latency; the mobile radio interface presents a challenge in terms of transaction latency. Check-pointing and migration requires latencies on the order of 50-80ms – these round trip times can be achieved through current HSPA, but will become more realistic in next-generation LTE systems. Average latencies in a “flat” LTE network are approximately 50ms at the gateway, which suddenly makes the prospect of hosting the smartphone application on a carrier-operated “cloud” very much a reality. Note that past the gateway, or beyond the carrier network, latencies become much more unmanageable and will easily reach 120ms or more.
  4. Mobile Virtualization; this technology offers the ability to decouple the mobile OS and application from the processor and memory architecture, enabling applications and services to be run on “cloud” servers. This has become an area of intensive research in mobile device design, and was covered in an earlier article by OK Lab’s Steve Subar.

A cloud execution engine could provide off-loading of smartphone tasks, such as visual recognition, voice recognition, Augmented Reality and pattern recognition applications, effectively overcoming the smartphone hardware and power limitations. This model would also allow key maintenance functions requiring CPU intensive scans to be executed on a virtual smartphone “mirror image” in the cloud. This would also facilitate taint checking and data leak prevention which have been long used in the PC domain to increase system robustness.

Another consequence of the Cloud Phone model is that it provides a new “value-add point” for the carrier in the mobile application ecosystem. The low latency limitations will require optimizations at the radio-access network layer implying that the network carrier is best positioned to extract value from the Cloud Phone concept – plus operators can place data centres close to the wireless edge allowing very low latency applications to be realized. This doesn’t rule out a Google entering into the fray – indeed, their acquisition of Agnilux may well signal a strategy to build a proprietary server processor to host such Cloud Phone applications.

The raw ingredients for the Cloud Phone are falling into place; more users are driven towards SaaS based phone applications, and HTML5 is being adopted by handset OEMs. There is no shortage of applications waiting to exploit a cloud phone platform: in July alone, 54 augmented reality apps were added to the Apple App Store. Google has also broken ground in the Cloud Phone space with Cloud to Device Messaging which helps developers channel data from the cloud to their applications on Android devices.

What other Cloud Phone applications do you see on the horizon? When do you see Cloud Phones reaching the market?

– Vish

[Vish Nandlall is CTO in the North American market for Ericsson, and has been working in the telecoms  industry for the past 18 years. He was previously CTO for Nortel’s Carrier Networks division overseeing standards and architecture across mobile and wireline product lines. You can read his blog at www.theinvisibleinternet.net]

MeeGo: Two (M)onkeys don't make a (G)orilla. But they sure make a lot of noise

[What is behind the announcement of Meego operating system by Nokia and Intel? Guest blogger Thucydides Sigs deconstructs what Meego means and its importance to the mobile industry]

How much substance is behind the noise of Nokia’s and Intel’s announcement of Meego? A few points to consider.

Nokia, who feels threatened by Google’s Android and Chrome OS efforts, is putting significant  efforts in order to expand into other device categories and bring its Ovi services to more consumers in more places. So a move that brings Maemo – together with Ovi (and the underlying Web-runtime apps and Qt cross-platform) to Intel chipsets is a straightforward strategic win. It will allow OVI services – such as Maps – to get into non mobile devices, especially Automotive (which has been a strategic focus for Intel) and other connected (but wired – after all power consumption is Intel’s Achilles heel) devices such as home phones.

So is Nokia going to bet it’s future Linux devices on a group of Intel engineers? Nokia is smarter than that: Intel software engineering has never been something to write home about. And Nokia has always been careful in maintaining and winning control over strategic areas. So Nokia will either maintain a parallel internal effort or maintain tight control over the ARM port and the overall MeeGo architecture.

Is MeeGo going to really bring Ovi services & Maemo into the hands of tens of millions more consumers? Well, MeeGo open’s a door, but success will depend on the quality of Maemo and Ovi experience. Maemo v6, due late this year, will be catch-up to where Android and WebOS were half a year ago, and were Apple was a year ago. So it is still one or two years behind the rest of the industry. That said, Maemo does not need to be the best – it needs to be good *enough* for ‘mass market’ consumers, so that combined with Nokia industrial design expertise and marketing power, an “object of desire” can still be delivered.

It’s this consumer “Desire” that brings us to the Ovi Services angle – and the question of how good will Nokia Services offering will be. Studying the NexusOne, it is impressive to see how Google seamlessly connected it’s many service offering – creating a compelling integrated experience. From a photo gallery that is both local and web (Picassa), through Google Voice (low cost calls, transcribed voice messages) and an almost perfect navigation and mapping experience (including turn-by-turn voice instructions and maps). Contacts, Email, Calendaring are the basics that are a must have. And Google is quickly expanding into other services (note the recent Aardvark acquisition and Buzz launch). Yes, MeeGo gives Nokia a vehicle to bring Ovi to some other device segments, but can Ovi compete effectively with Google’s breadth of services?

What about Intel? It has been spending hundreds of millions of dollars on a software strategy which does not seem to show a clear path to recouping the investment. Moblin, has not been able to ship in any significant volumes, is inferior to either ChromeOS or Android from a software platform perspective, and lacks any kind of services offering (which is why they needed Ovi). If Intel thinks that software is another part of it’s vertically integrated stack that will differentiate the chipsets, then it does not make sense to open it up and make it an open industry initiative. If Intel truly believe that Moblin should be open and used by competing ARM chipset vendors, then what does it gain from spending those hundreds of millions of dollars on the effort?

Open Source: ChromeOS, Android and Maemo are creating a very different software ecosystem then the one Intel got used to with Microsoft in the 90s. None of the software players is going to generate significant revenues on the device side. Intel exec’s might  want to re-read Andy Grove book, step outside the box and ask themselves if their software effort still makes sense in the 2010 industry context.

And while Intel is spending time on building this software strategy, the chipset market is experiencing a disruptive change, shifting from computing power (where good enough performance is delivered by both Intel and ARM), to battery power and mobility where ARM is clearly superior.  It might be better for Intel to focus it’s efforts back on it’s chipset technology and fix its power consumption problems, because when it comes to wireless devices (either within the home or outside, anything that is not tethered to a power cord), their offering is inferior to ARM, and no amount of software will be able to cover this gaping hole.

What about the rest of the chipset industry? Would the other ARM chipset vendors, such as TI, Qualcomm, Broadcom and nVidia follow path and join MeeGo? It’s hard to imagine that any of those companies will want to entrust their software strategy in the hands of Intel: not only is Intel a direct competitor, it software skills leave a lot to be desired, and it’s long term commitment to the space (as outlined above) is not clear. Is Nokia’s involvement enough of a carrot to entice those vendors into MeeGo? Having Maemo running on top of MeeGo will make insertion into Nokia easier, but Maemo is open source and there is nothing holding the chipset vendors from porting Maemo to their chips on their own or with the help of other independent 3rd parties. So we suspect Nokia will give it a modest try, but when it comes to purchasing chips, power, performance and cost will still be the over-riding criteria for Nokia.

So, lots of noise that those two monkeys are making, but little impact. MeeGo seems to be cute (qt) and (h)armless, but not a big industry changer.

– Thucydides

[Thucydides Sigs – a pseudonym – has many years of experience juggling computing constraints, mobile software and consumers needs. With that said, imagine listening to a violin sonata not know who the artist is or who composed it. You end up having to listen more carefully in order to make a judgment. He can be reached at thucydides /dot/ sigs [at] gmail [dot] com]