Haptics and Sensors: The new toolset for handset differentiation?

[Haptics, sensors, gesture tracking, intelligent texting and pico projectors; a taste of the technology soup headed our way. Guest author Peter Crocker discusses how sensor technologies offer handset differentiation, and the challenges ahead for OEMs.]

Haptics and sensors - the new toolset for handset differentiation

Innovation is the name of the game for handset manufacturers. Not just for Apple who keeps expanding the envelope of hardware and UI capabilities, but all major OEMs who are looking to differentiate beyond software. Android and Windows Phone are now providing an end-to-end device recipe for device makers, from hardware to a developer ecosystem. As such, handset OEMs (Nokia, Samsung, LG, Motorola and Sony Ericsson) are finding themselves on the same playing field as PC assemblers (Acer, Dell, plus the likes of Huawei, ZTE and Visio). In the post-Android era, not only is the playing field leveling, but it’s also becoming more crowded. More importantly, unless handset OEMs can find ways to differentiate they’ll have to default to competing on price, which is exactly what they want to avoid; the OEM cost structure is not designed to withstand razor-thin margins.

[poll id=”11″]

One way to differentiate is with phone features – not GHz figures, but the type that would have a major impact to the user experience. Many OEMs would crave to break into the market with innovations such as what the Palm Graffiti handwriting recognition was at its time.

Feature innovation comes today in many forms, as manufacturers try to evolve smartphones into smarter phones; haptics, predictive texting, gesture recognition technology, inertia sensors, digital compasses, and the emergence of pico projectors to name a few.

A taste of feature innovation
– Next Generation Haptics: Haptics, or the process of using motion or vibrations to create tactile feedback on a users hand or finger, has been around for quite a while, with solutions available from Immersion and Synaptics. As an alternative to using touch-sensitive screens, companies like eyeSight and GestureTek are using the built-in phone camera to analyse hand motions and recognize gestures.

– Inertia and direction sensors: handset makers are following Apple’s lead with the integration of accelerometers, digital compasses and gyroscopes into the phone. These sensors can be leveraged to support for example improved location through dead reckoning and gesture recognition. Gyroscopes and compasses are also providing precise data on the location of a device in the three dimensional plane opening the door to augmented reality applications. Companies such as Layar and Wikitude are helping developers walk through that door with AR software platforms.

– Predictive Text & Gesture Tracking: Predictive texting has seen limited innovation beyond plain-old T9; as such a range of vendors have emerged to provide significant improvements in prediction and correction accuracy, namely Keypoint, EXB, TouchType, Cootek, Keisense (now Nuance) and BlindType (acquired by Google). New forms of predictive texting combined with gesture recognition technology such as as Swype and ShapeWriter (acquired by Nuance) is enabling quicker text input on a touchscreen – for example tracking the movement of a finger on a touch screen, a phone moving in space with inertia sensors, or tracking hand movements with infrared technology hand gestures.

– Pico Projectors: While the integration of pico projectors, or mini video projectors, into mainstream phones is still a ways off, the technology from the likes of TI and Micorvision claims to overcome one of the biggest UI challenges of mobile device, small screens.

What’s more, combining such features can yield more than the sum of the parts. For example, gesture recognition technology combined with haptics could allow users to effectively navigate applications. Similarly, the combination of pico projectors, gesture recognition and image tracking technology could eventually enable interfaces that will resemble Sci-Fi movies.

Integration challenges
As easy as it may sound, innovative features are not just about shopping components off the shelf. Cost is an important consideration, especially for technologies that require specialized components that do not enjoy economies of scale. For example, the green laser required in a pico projector represents one third of the cost of the entire system due to the fact that the part has no use beyond a pico projector.

Integrating new technologies into handsets is a further challenge for handset designers. Digital compasses are sensitive to electronic interference and need to be carefully positioned within the phone to avoid interacting with neighboring electronics. The design of haptics mechanisms also presents many problems. In a typical haptics system design, touch screens float in their frames and are held in place by flexible materials that allow the screen to vibrate creating haptics effects. These designs can fail letting dust inside the device or the screen can separate from the frame if the device is dropped. OEM’s are still learning how to effectively incorporate such features into their designs.

A number of start-ups are working on overcoming these barriers in addition to creating new capabilities. Senseg in Helsinki is eliminating the need for moving parts in haptics systems and has created a system that it claims can pinpoint tactile feedback. InvenSense has brought to market a motions sensing MEMS chip that integrates a gyroscope and accelerometer in one chip, making it easier for OEMs to integrate and reduce cost. Light Blue Optics has developed a pico projector that creates a holographic image and infrared sensors to turn any surface into a virtual touch screen. The company also just raised $13 million to shrink the technology.

Innovation of course requires risk-taking. OEMs are finding themselves in a chicken and egg scenario; design cutting edge features first, or wait for the apps to leverage the features? Samsung and HTC seem to be comfortable taking such risks. Samsung was the first to introduce a phone with an integrated pico projector in 2009 and the Galaxy S sports a gyroscope, Swipe technology and an Augmented Reality browser. HTC is also pushing the envelope having developed and launched devices with home grown haptics.

Undoubtedly users will be the biggest winners as OEMs battle to wow new customers. A close second will be application developers who will stretch their imagination to build new applications and businesses around emerging features.  While these opportunities are compelling, progress will not happen overnight. Gyroscopes are still only available in high end smartphones and next generation haptics will only appear in niche devices next year. If you’re interested in building an app for a pico projector, you may be waiting a few more years.

The question is: is this new roster of sensor technologies going to allow OEMs for once to out innovate Apple?


[Peter Crocker is the founder and principal analyst at Smith’s Point Analytics (www.smithspointanalytics.com), a full service market research company helping innovators in the mobile and wireless market better understand emerging opportunities. Peter has been in the mobile and wireless industry since 2003 and holds an MBA from the College of William and Mary. Peter can be reached at peter@smithspointanalytics.com]

[Survey] Developer Economics 2011: The evolution of app development

[Developer Economics 2011 is here! As we launch our new survey on all things developer-related, Marketing Manager Matos Kapetanakis looks back at the 2010 report and examines the major events that have shaped mobile development in the past 6 months]

VisionMobile - Developer Economics 2011

The evolution of Developer Economics
Last July we published the definitive mobile developer research report: Developer Economics 2010, dubbed by TechCruch as “one of the most profound…to date”. Our report delved into all aspects of mobile application development, across a sample of 400+ developers segmented into eight major platforms.

We’ve just launched the follow-up to this research report: Developer Economics 2011, once again made possible thanks to BlueVia, the global developer platform from Telefonica that helps developers take apps, web services and ideas to market. Our goal is to see how the dynamics of the developer world have changed since early 2010 and to provide more insights into app marketing, monetization and many other factors.

Join the survey or help spread the word! This year we ‘ve also secured a prize for each of the first 400 developers; 10 hours free testing time on DeviceAnywhere’s 2000+ handsets. UPDATE: Thanks to overwhelming support, all 400 free testing time prizes have been awarded by DeviceAnywhere. Of course, the $1,500 Amazon voucher is still up for grabs!

Major shakeups of the mobile industry for H2 2010
So, what’s changed since our 2010 research? The mobile industry is an ever-evolving landcape. In the past 6 months we have seen the Symbian Foundation close shop, with Nokia hoping that the as-yet untested MeeGo project will carry their smartphone banner. We have also seen the stellar rise of Android, zooming past Apple’s iOS and BlackBerry and becoming the no2 smartphone platform behind Symbian.

In the handset OEM arena, we have seen more shakeups in 2010 alone than in the 10 years preceding it. Apple and RIM have overtaken some of the traditional handset OEM powers (Sony Ericsson, Motorola, LG) and claimed a spot in the top 5. According to some estimates, ZTE could join them soon.

Moving forward, Developer Economics 2011 is looking at how the key metrics of mobile development have changed in the last year.

The migration of developer mindshare
One of the major findings of our 2010 report was the migration of developer mindshare away from the ‘old guard’, i.e. Symbian, BlackBerry and Java, towards the new powers of the realm – iOS and Android. According to our research, nearly 60% of the 400+ respondents had developed apps on Android. Apple’s iOS took second place, with more than 50% of respondents having a go at it, with Java ME following third.

In our Developer Economics 2011 research, we’ll be asking participants which platforms they’re currently targeting, which ones they plan on targeting and which ones they’re abandoning.

So, what’s changed since then? Well, if anything, the gap between Android and iOS and the rest of the platforms has grown even larger. The Apple App Store carries more than 300 thousand apps, while recent estimates place the number of apps in Android Market at around 130 thousand.

While Nokia has been spending considerable effort on the Ovi Store and increased its popularity with consumers and developers alike, they still have a long way to go to catch up with the two app-dispensing behemoths.

Why do developers head towards iOS and Android? Our Developer Economics 2010 analysis showed that Apple offers a platform that is relatively easy to master and using which a developer can design great UIs. They also have the largest app store and although the certification problem is an issue for some,  porting and fragmentation are not a challenge;. Android, on the other hand, has been gaining momentum across all fields, storming its competitors’ key market – the US. Of course, Android’s many fragmentation issues are often overlooked in the face of many handset OEMs’ dependency on the platform.

The disparity between handset sales and available apps

Our Developer Economics 2010 research uncovered a disparity between the number of devices sold for each platform and the number of available apps. One would expect the platforms with the highest market penetration to dominate in terms of apps, but that couldn’t be further from the truth.

Taking 3Q10 as a reference, it’s easy to see that the two platforms with the lowest penetration, iOS and Android, have the highest number of available apps.

On the opposite side of the spectrum, while Java ME and Flash Lite have the greatest market penetration by far, they can scarcely measure up to the newer platforms when it comes to app volumes.

In Q4, the contrast is even sharper. Both Android and iOS stores have grown by almost 100 thousand apps apiece. Windows Phone has shown an admirable growth, reaching 4 thousand apps in just two months, although it still has a long way to go before becoming truly a threat to incumbents.

Monetization and revenue expectations

In Developer Economics 2010, we asked developers how they felt about the revenues they’re receiving from selling their apps. Almost one in four respondents reported poor revenues, while only 5% reported revenues exceeding their expectations.

VisionMobile - Developer Economics 2010 - revenue expectations

While there has been a boom of app stores, that’s not necessarily a blessing for developers. Most developers face a discoverability issues, having their apps buried under thousands of other apps. Like one developer said in our previous research “It’s like going to a record store with 200,000 CDs. You ‘ll only look at the top-10″.

What options are there for developers? One option is to adopt a multiple storefront strategy, as well as to tailor your monetization model to specific app stores. As the CEO of Rovio, creator of the prodigious Angry Birds app, noted: “Free is the way to go with Android. Nobody has been successful selling content on Android”.

Developing apps in 2011
Care to see how the apps world has changed in the last year? Stay tuned for Developer Economics 2011, where we delve into app development, monetization, distribution, retailing, porting and fragmentation issues among many others.

Mobile developer? Join the survey and have your say.

RIM: a leap ahead in user experience, but can it execute?

[RIM’s acquisition of UI firm TAT marked the largest mobile software M&A of 2010. Research Director Andreas Constantinou explains why the acquisition places RIM a leap ahead of the top-10 OEMs in terms of UI capabilities and asks – can RIM execute on the promise?]

RIM: a leap ahead in user experience, but can it execute?

In December, RIM surprised industry observers by buying TAT (The Astonishing Tribe), a 200-strong UI technology and design firm based out of Malmö, Sweden. At nearly $130 million, RIM’s move marked the largest mobile software M&A transaction of 2010 globally and an impressive 5.5x multiplier over TAT’s 2009 revenues of 170 million SEK. It follows a string of RIM acquisitions since 2009, namely QNX (operating system), Cellmania (content billing and distribution), Dash (two-way navigation), DataViz (document viewer), Torch Mobile (WebKit experts) and Viigo (software house).

More importantly, TAT’s acquisition places RIM a leap ahead in the league of top-10 handset manufacturers in terms of own UI capabilities. Here’s why.

A leap ahead of the competition
TAT was founded in 2002 by 6 games engineers and designers out of university (here’s their story) but has come a very long way. TAT is not just another technology company. It has seen its Kastor 2D/3D graphics framework deployed in over 500 million phones across 5 out of the top-7 OEMs. More important to the RIM story is TAT’s Cascades product, a UI framework that allows OEMs to design their phones not in terms of applications, but in terms of screens, allowing what can be termed ‘rapid variant management’ (more about that later).

TAT has also been clearly ahead of the UI technology vendor pack – vendors like Ikivo, Digital Aria, Acrodea, Bluestreak, YouILabs and Scalado – thanks to its design skills. When other vendors have banked on technology marketing, standards implementation or operator deals, TAT has used its design skills to get into the door of both OEMs and operators/carriers (check out this video on the ‘future of screens’). The marriage of design skills and technology licensing allowed TAT to build momentum and cash-flow when OEMs were cutting budgets post-2005. These same skills were what got TAT the deal to design Google’s Android 1.0 UI. TAT’s strength lies in the combination of UI framework technology and the first-class design skills – both of which are now with RIM.

So what does RIM get?

TAT’s acquisition is far more encompassing than many would have thought – it puts RIM a leap ahead of the pack in the league of top-10 handset manufacturers in six ways:

1. Match the iPhone
With the Cascades technology, RIM can now match and even exceed the sophistication of the iPhone UI (see this and this video demos). Long term this means RIM has a chance to contain the exodues of enterprise customers opting for replacing their RIM with iPhones due to the outdated UI and usability on the Blackberry OS 6. Heck, it would be even easy for RIM to offer ‘deep skins’ for BlackBerry handsets where the navigation and core apps closely resemble the iPhone apps.


2. Rapid variant management
TAT’s Cascades is a departure from how OEMs build handsets today, by allowing the UI to be designed in terms of screens and not applications.

The downside is that Cascades-enabling an existing software stack means that legacy ‘spaghetti’ applications have to be ported one by one on top of TAT’s framework, which takes 9-12 months for the complete UI (it’s 10s of millions of lines of code that have to be ported). This is what has historically limited Cascades to only tactical wins for specific applications on Motorola, Samsung and Asus handsets.

The upside is that with Cascades RIM gets rapid variant management; creating 100+ operator variants from a single vanilla UI is just a button (and an XML file) away. Designing in screens rather than apps means that RIM can keep its investment into messaging, graphics and enterprise middleware but radically change the UI look and feel. This allows RIM’s carrier customers more differentiation and exclusivity opportunities, all without delaying the time to market – and therefore securing the carrier multi-million subsidy and marketing carrier budgets.

Rapid variant management is today one of the few domains where Android suffers and Nokia’s Symbian still excels, so a very important differentiator for RIM once the integration work is out of the way.

3. Consumer and enterprise personas
We covered earlier how RIM needs to escape its dual personality disorder by designing separate consumer and enterprise product lines. However, designing a different set of apps for enterprise and consumers is complex – not to mention managing many more device models and variants in the field.  With TAT, RIM buys the ability to have enterprise AND consumer UI personas ship in the same phone – not only that, but in a way that can be easily switched by the user at the flick of a button. Switching between enterprise and consumer personas is also much cheaper to do at the UI level rather than the bare metal level with what’s called ‘mobile virtualization‘.

This implies that with TAT’s technology, RIM can allow users to switch between consumer and enterprise UI personas; a consumer UI when you want to browse on Facebook and check out Flickr and an enterprise UI when you want to check the email attachment for your next meeting. Note that Nokia and HTC Sense have also implemented basic switching between work and personal skins.

4. Enterprise UI customization
Besides the runtime technology, TAT develops Motion Lab, a tool that a designer can use to define UI screens and UI flows through a drag-n-drop environment. For RIM, this means that enterprises can customize the phone’s navigation to focus on the few key applications that are used most of the time. It also offers RIM a level of enterprise customization beyond what other OEMs can achieve out of the box.

5. UI personalities
With the erosion of the market of downloadable ringtones and wallpapers, the industry has turned to apps as the next premium content market. Yet, there are still new revenue opportunities in downloadable content. In Japan, DoCoMo has led the market of downloadable UIs in the form of “standby screens” (programmable home screens), and which Acrodea has extended to the dialer and menu apps.  This has created a small market of downloadable UIs for both DoCoMo and KDDI.

With TAT, RIM can extend that market to the world, and across more embedded applications – creating what can be called the market of downloadable UI personalities. Whether RIM can turn this capability into a new ‘market’ is questionable, but it certainly presents a unique point of differentiation and an opportunity for a new revenue stream for RIM.

6. Connected experiences
With the acquisition of Dash, a 2-way car navigation company, RIM has its sights set beyond phones and tablets into the automotive segment. To deliver a consistent UI across these varied form factors a new OS (QNX) is far from adequate. It needs a portable UI technology that allows RIM to reuse its UI assets with minimum maintenance overhead across different form factors, from phones to cars. TAT’s Cascades is exactly this technology and as TAT has shown, it can be extended to connected screens in the living room, in the street, in the car, and in the hands.

Filling in the gaps that TAT left
With TAT out of the picture, how can other OEMs catch up to the level of UI technology sophistication and design skills? There’s a variety of UI technology vendors out there (see below for an extract from our Mobile Industry Atlas), but none really combine the UI ‘screens’ framework or the design skills of TAT.

Many companies claim to have “UI frameworks”, but they all invariably mean a combination of SVG engines, 2D and 3D graphics toolkits or compositing engines – which address UI development as an application, not a screen paradigm. Historically there have only been three companies who have developed screen-based UI frameworks; TAT, Digital Airways and Next Device. Digital Airways was behind the UI of the Vodafone Simply series of five handsets launched between 2005 and 2007 and the Porsche P9522 handset introduced by Sagem in late 2008; the company has since transitioned into UI services in mobile, embedded, automotive and aerospace – however the company ceased trading sometime in 2010. Next Device was acquired by Mentor Graphics (makers of the Nucleus RTOS), who didn’t manage to leverage the technology asset as the licensing model was markedly different to Nucleus’ site-licensing. The gap that TAT left creates an opportunity for other UI middleware vendors (e.g. Ikivo, Acrodea, Digital Aria, Sasken,) to maneuver into this technology space.

Another way to deliver ‘screen-based’ phone design and variant management is via development tools; much like how OpenPlug (now Alcatel Lucent) uses the Adobe Flash IDE to create mobile apps. However this is still virgin territory and we ‘re not aware of any sufficiently advanced UI tools vendors in the mobile domain.

Can RIM execute?
All in all, TAT can deliver Apple-class user experience that offers RIM a strategic advantage compared to OEMs leveraging 3rd party Windows Phone and Android platforms.  This all sounds great on paper of course, but it’s all a question of execution.

Can RIM’s corporate monoculture adapt to the creative minds of TAT? Will the TATers get the mandate and budgets to innovate deep into RIM’s product lines? How long will RIM take to integrate the TAT technology on top of the QNX platform and where will the competition be at that point?

Ladies and gentlemen, place your bets.

– Andreas
you should following me on Twitter: @andreascon

[Andreas Constantinou is Research Director at VisionMobile, and oversees the research, strategy and industry mapping projects at VisionMobile. Andreas also served on TAT’s advisory board during 2008-9]

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.]