open source Archives - SlashData Blog

Hot off the Press: Developers’ needs due to COVID-19, Open Source, Languageds, DevOps and more

What do developers value in open source?
How have their needs changed due to COVID-19?

The 19th Developer Economics global survey wave ran from June to August 2020 and reached more than 17,000 developers in 159 countries. Hot off the press “State of the Developer Nation” report presents developer trends for Q3 2020 and beyond.

The report is free to access and focuses on six major topics, providing answers to questions like these:

Developers’ extra needs due to COVID-19
Programming language communities – an update
Why do developers adopt or reject cloud technologies?
Who is into DevOps?
What do developers value in open source?
Emerging technologies

Some highlights to spark your curiosity:

Developers’ extra needs due to COVID-19

Four in ten developers report that they need more flexibility in working hours/workload as a consequence of COVID-19.
Developers responsible for tooling specifications and for approving budgets and expenses are in the greatest need of increased security, performance, and cloud space.

What do developers value in open source?

Developers appreciate collaborating and interacting with the open-source community more than contributing to open-source projects.
South Asian developers highly value contributing to open-source projects, positioning this region to drive the next wave of open-source development.
Developers who are building apps and extensions for third party ecosystems, on average, value contributing and forking more than developers in other sectors.

Who is into DevOps?

DevOps has reached mainstream adoption.
The vast majority of professional developers (more than 80%) are involved in DevOps in one way or another.
Continuous integration (CI) and continuous deployment (CD) are two of the most common DevOps practices, but only one in four developers use both to fully automate their workflow.

Download the full report here.

The report is free to download for all community members including developers and industry enthusiasts.

91% of IoT developers use Open source

Did you know that 91% of IoT developers use open source technology in their projects? Our latest Premium report in the IoT series –Open source in the Internet of Things -not only confirms the figure but also sheds light to a number of tools and strategies that developers employ for open source, open hardware and open data.

The Open Source in IoT report provides developer program managers with objective data-backed insights on the use of open source technology by IoT developers and helps them to manage the use of open source in their projects. Some of the key questions that this report answers include:

How mainstream is open source in the Internet of Things? Is it just for hobbyists and idealists, or is there more to it than that?
Which developer demographics use open source and why?
How can I make sense of the hundreds of open source, open hardware, and open data licenses that are out there?
Should your project be open or closed? How can you use open source to achieve commercial success?

The data in this report comes from our 10th edition Developer Economics survey (Q4 2015). 3,700 Internet of Things developers answered questions about their use of and attitude towards open source technology.

To give you an idea of the findings of the IoT report we have prepared an infographic depicting some of the key findings. Have a look at some of the most interesting trends that have been extracted from the report and give a very representative outline of the the mindset of IoT developers and their contribution to the open source community :

HTML5 performance is fine, what we are missing is tools

HTML5 is perceived as a lower quality platform, mainly because of performance. This comes both as a result of survey data, as well as developer interviews. Yet, industry experts claim the problem is lack of tools. So what is the HTML5 really missing, performance or tools? VisionMobile’s Web Technology Lead, and author of our acclaimed “Can HTML5 compete with native?” research report, debates the performance vs. tools issue.

In April 2013 VisionMobile asked mobile app developers what stops them from using HTML5. 46% answered “Performance issues”, followed by 37% who said “Lack of APIs” (sample size: 1,518 developers).

We spoke to developers about their views on HTML5 performance. Apostolos Papadopoulos, author of 4sqwifi, a highly acclaimed public WiFi password app, noted “Quality and user experience is top priority for us. Therefore, we prefer going with a Native API”. It’s a common practice for developers to go native for better performance and user experience. But user experience, meaning following the behavioural conventions of the native platform, is a different story and HTML5 can’t help much. Developers can try to imitate but for a truly native UX they have to use Native SDKs; unless we are talking of Firefox OS or the long-awaited Tizen. Continue reading HTML5 performance is fine, what we are missing is tools

Mozilla Boot2Gecko: can the new HTML5 champion succeed where webOS failed?

[A new mobile operating system is born. Telefonica and Mozilla have teamed up to deliver Open Web Devices. The ambition is high: displace the Apple/Google duopoly and commoditize app ecosystems. But can they do better than earlier attempts like WebOS? VisionMobile business analyst Stijn Schuermans sheds light on the challenging road ahead for this new platform candidate.]

“People say that I’m a dreamer, but I am not the only one.”
John Lennon

Mozilla, the company behind Firefox (until recently the number two desktop browser) and top-5 mobile operator Telefonica are co-developing a new mobile operating system. The project is codenamed Boot2Gecko by Mozilla and devices running the OS are dubbed “Open Web Devices” by Telefonica. The goal is a phone that relies entirely on web technology and where all applications, from the dialler to games, are developed with HTML5.

At the MWC 2012 conference in Barcelona, Mozilla ran a demo of Boot2Gecko on a Samsung Galaxy II, a high-end smartphone. At the same conference, Telefonica showed the new operating system on a low-end reference design from Qualcomm, which will become available on low-cost smartphones at a sub-Android price point. Mozilla also announced the Mozilla Marketplace, an app store for web apps.

On the surface, this joint move by a major telco and a major Internet player makes a lot of sense. Mozilla and Telefonica are trying to disrupt the Apple/Google duopoly, starting from the low-end. By focusing on providing a good user experience on very low-end devices, Telefonica hopes to capture the emerging markets first. The telco plans to introduce direct-to-bill payments for mobile app purchases, as credit cards are not common in the emerging markets that the initiative targets.

As explained in Christensen’s Innovator’s Dilemma, starting at the low end of the market is smart: the easiest way for Android device makers to protect their profitability is to leave the low margin devices to Open Web Devices and focus Android on higher-end devices, targeted at people who do have credit cards. This is the best way to disrupt Android. Google’s reaction will likely be lukewarm, as their interest is only in driving eyeballs to Google ads, which can be done perfectly from either platform.

A disruptive strategy like this provides Telefonica with the opportunity to give Google a taste of its own medicine. Telcos are under big pressure from the application ecosystems of Apple and Google, which now own the customer relationship and are pushing down the value of the carriers to dumb bit pipes. If telcos are not full participants in the application ecosystem, then why not commoditize apps entirely? For Telefonica, Open Web Devices are an attempt to reduce the power of the major platforms and their vertical application silos by moving app development and distribution to a more “neutral” web-based environment. If applications are primarily developed in a cross-platform way, the platform’s power weakens. Mozilla is an ideal partner for telcos to achieve this, being a fundamentally not-for-profit organization with a mission to keep the Internet open and free.

Mozilla and Telefonica are a good match in general for realising B2G as a competitor to Apple/Google; Mozilla can add the software foundations (APIs) and the developerecosystem around it, while Telefonica adds the OEM deals, monetisation and app store.

On paper, Boot2Gecko could be the new web-based platform that succeeds where webOS failed; it is open source (unlike what webOS used to be), it has multiple OEM partners interested, it is backed by a top-5 telco and it comes at a time when HTML5 has technically evolved and enjoys widespread industry support. Indeed, B2G could be the champion that leads HTML5 from being an enabling technology to achieving full platform status. The reality is that a lot needs to be done for that to happen.

In essence, the elements behind Telefonica’s Open Web Devices are not enough to win the hearts and wallets of consumers and developers:
– Openness is a way to reduce developer marketing costs, but adds little value for end users.
– Web is not a synonym for better user experience or the platform with which to appeal to games developers.
– Devices running a web-based OS is a valid way to compete with Apple/Google, but a very expensive one, given that billions of dollars will have to be invested by Telefonica and handset OEMs before the OS reaches maturity and has a sizeable addressable market. Note that Microsoft is paying Nokia circa $1 billion a year to buy its way into an addressable market.

For Boot2Gecko to succeed, it needs to compete with the other mobile platforms on all five key ingredients:
1. Software foundations, a rich set of APIs with managed fragmentation. Telefonica has already contributed a lot of the device API glue code to Boot2Gecko (based on the carrier’s earlier work within WAC). However, competing with iOS, Android and WP7 is a major long-term effort.
2. A developer ecosystem, to spur innovation and cater to diverse use cases. There are millions of web developers out there, who need to be “onboarded” onto B2G, i.e. on its specific APIs and app distribution system.
3. Devices & distribution, i.e. a large addressable market of 10s of millions of phones sold each year. As a top-5 telco, Telefonica is a major success factor here, but needs to translate OEM intentions (notably from LG who’s an early partner) into project investments and volume commitments. A positive factor here is that B2G is running on the same reference designs and based on the same kernel and core libraries – and so, quicker to bring to market than Windows Phone.
4. Monetisation. Monetisation is essential to the creation of a healthy developer ecosystem – and Telefonica intends to provide carrier billing.
5. Retailing. It is still unclear which partner will be responsible for providing the on-device storefront, retailing and merchandising of apps to end users.

To their credit, Telefonica and Mozilla are progressing fast with Boot2Gecko. The first experiments started in October 2010 and the project really kicked off in March 2011. The phone demonstrated in February 2012 wore all the key core apps (dialler, phonebook, inbox, etc.) and a UI experience that is claimed to be better than the lowest-end Android handsets. The handset demonstrated by Telefonica runs on the same hardware as the original iPhone 3G, but can be sold at 1/10th of the price according to our sources.

This said, other contenders to the HTML5 platform crown, like Facebook Platform and Google Chrome, are already far more advanced in creating a viable ecosystem. Both Facebook and Chrome (the browser, the OS, but especially the web store) have already amassed substantial traction across screens and have solved at least some of the distribution, retailing and monetization challenges. The Mozilla Marketplace is a step in the right direction, but the organization has a lot of catching up to do.

Moreover, there is an obvious and much cheaper substitute to these attempts to create web-app platforms that Telefonica and other telcos need to consider, if their goal is to disrupt the Apple/Google duopoly. Cross-platform development tools [see our full report – www.CrossPlatformTools.com] make it much easier for developers to reach multiple platforms and flatten the competitive landscape of Apple and Google’s ecosystems.

In summary, Telefonica and Mozilla are making a very serious attempt at disrupting the current iOS/Android duopoly of application platforms. They do well to focus on low-end devices and to attack the link between apps and the platforms they run on. But using HTML5 technology or being open is not enough. Mozilla, in particular, has to prove that it can draw in web developers to this new platform and create a vibrant ecosystem. Telefonica not only needs to get OEMs enthusiastic, but also committed to produce phones in volume. Finally, it is unclear how this initiative can outrun the competition, Facebook and Chrome or whether Telefonica and Mozilla should instead invest in the alternative approach of cross-platform development tools.

– Stijn

Want to know more? VisionMobile offers deep insights into the HTML5 ecosystem and how it stands to disrupt the Apple/Google duopoly. Check out the latest research note in our CEO Trendwatch service (send an email to stijn@visionmobile.com for access), or our Mobile Innovation Economics workshop.

[Infographic] The Open Governance Index â€“ A new way of measuring openness

We are proud to present our latest infographic – the Open Governance Index, measuring the relative openness of 8 major open source projects, from Android to WebKit. This infographic presents some highlights from our full report (free download here). The Open Governance Index is authored and researched by VisionMobile, and part-funded by webinos

Feel free to copy the infographic and embed it in your website (embed codes below the infographic).

Infographic- The Open Governance Index - A new way of measuring openness

150 pixels wide version

500 pixels wide version

800 pixels wide version

[sociable_code]

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

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]

[Report] A new way of measuring Openness, from Android to WebKit: The Open Governance Index [Updated]

[Much has been said about open source projects – and open source platforms are now powering an ever-increasing share of the mobile market. But what is “open” and how can you measure openness? As part of our new research report (free download), VisionMobile Research Partner Liz Laffan introduces the Open Governance Index – a new approach to measuring the “openness” of software projects, from Android to WebKit]

Update: We have been amazed by the amount of interest to our Open Governance Index (OGI) report that we published just over two weeks ago. Our report was covered in mainstream media across Wired, ZDnet, PCPro, Gizmodo, ARS Technica, BGR, Zeit Online and ReadWrite Mobile. Our intention was to start a debate around â€˜what’ openness is, â€˜how’ it can be measured and â€˜why’ it is important – and we certainly got the ball rolling!

Openness = governance

We at VisionMobile have been researching, investigating and helping to educate the industry about open source for the past five years. In this time open source software has been transformed from geekware to business as usual. Much has been written and debated regarding open source licenses – from the early days of the GPL license to the modern days of the Android platform.

Despite the widespread use of open source, from Android to WebKit, there is one very important aspect that has been neglected: openness and how to measure it.

Openness goes far beyond the open source license terms and into what is termed Governance. While licenses determine the rights to use, copy and modify, governance determines the right to gain visibility, to influence and to create derivatives of a project, whether in the form of spin-offs, applications or devices. And while licenses apply to the source code, governance applies to the project or platform. More importantly, the governance model describes the control points used in an open source project like Android, Qt or WebKit, and is a key determinant in the success or failure of a platform.

The governance model used by an open source project encapsulates all the hard questions. Who decides on the project roadmap? How transparent are the decision-making processes? Can anyone follow the discussions and meetings taking place in the community? Can anyone create derivatives based on the project? What compliance requirements are there for creating derivative spin-offs, applications or devices, and how are these requirements enforced? It is governance that determines who has influence and control over the project or platform – beyond what is legally required in the open source license.

In today’s world of commercially-led mobile open source projects, it is not enough to understand the open source license used by a project. It is the governance model that makes the difference between an “open” and a “closed” project.

Measuring openness

Our research (free copy of full report here) showcases eight mobile open source projects: Android, MeeGo, Linux, Qt, WebKit, Mozilla, Eclipse and Symbian. We selected these projects based on breadth of coverage; we picked both successful (Android) and unsuccessful projects (Symbian); both single-sponsor (Qt) and multi-sponsor projects (Eclipse); and both projects based on meritocracy (Linux) and membership status (Eclipse).

All of these are open source projects, whether platforms (Android, MeeGo, Qt, Symbian) or engines (Linux kernel, WebKit) or multi-project initiatives with a single, uniform governance. We appreciate that these projects are unique in many ways but they are all ultimately open source projects and to that extent our governance measures can be applied to them all equally. For example all of these projects have decision-making groups and processes that are directly comparable. In the Open Governance Index we attempted to document who these decision-makers are, how they operate, what processes are used to determine project decisions and how easily is to influence these project decisions.

Our research, carried out over a six-month period, included analysis of these popular open source projects, through discussions with community leaders, project representatives, academics and open source scholars. This research was partially funded by webinos, an EU-funded project under the EU FP7 programme, aiming to deliver a platform for web applications across mobile, PC, home media (TV) and in-car devices.

We quantified governance by introducing the Open Governance Index, a measure of open source project “openness”. The Index comprises thirteen metrics across the four areas of governance:

1. Access: availability of the latest source code, developer support mechanisms, public roadmap, and transparency of decision-making
2. Development: the ability of developers to influence the content and direction of the project
3. Derivatives: the ability for developers to create and distribute derivatives of the source code in the form of spin-off projects, handsets or applications.
4. Community: a community structure that does not discriminate between developers

The Open Governance Index quantifies a project’s openness, in terms of transparency, decision-making, reuse and community structure.

Does openness warrant success?

But what is it that makes an open source project successful? Why do some projects become an immediate success, while others barely get off the ground before crashing and burning? We know that just like commercial ventures, open source projects have different cultures and drivers – but we do believe that you should be able to measure the way that open source projects interact with the community of users and contributors that they build up around themselves.

Our research suggests that platforms that are most open will be most successful in the long-term. Eclipse, Linux, WebKit and Mozilla each testify to this. In terms of openness, Eclipse is by far the most open platform across access, development, derivatives and community attributes of governance. It is closely followed by Linux and WebKit, and then Mozilla, MeeGo, Symbian and Qt. Seven of the eight platforms reviewed fell within 30 percentage points of each other in the Open Governance Index.

Moreover, our research identified certain attributes that successful open source projects have. These attributes are timely access to source code, strong developer tools, process transparency, accessibility to contributing code, and accessibility to becoming a committer. Equal and fair treatment of developers – “meritocracy” – has become the norm, and is expected by developers with regard to their involvement in open source projects.

The Android Paradox

We found Android to be the most “closed” open source project. In the Open Governance Index, Android scores low with regard to timely access to source code in that the platform does not provide source code to all developers at the same time; it clearly prioritises access to specific developer groups or organisations and has acknowledged this with the delayed release of Honeycomb. Additionally Android scores low with regard to access to developer support mechanisms, publicly available roadmap, transparent decision-making processes, transparency of code contributions process, accessibility to become a committer (in that external parties cannot â€˜commit’ code to the project) and constraints regarding go-to-market channels.

Android ranks as the most closed project, with an Open Governance Index of 23%, yet at the same time is one of the most successful projects in the history of open source. Is Android proof that open governance is not needed to warrant success in an open source project?

Android’s success may have little to do with the open source licensing of its public codebase. Android would not have risen to its current ubiquity were it not for Google’s financial muscle and famed engineering team. More importantly, Google has made Android available at zero cost, since Google’s core business is not software or search, but driving eyeballs to ads. As is now well understood, Google’s strategy has been to subsidise Android such that it can deliver cheap handsets and low-cost wireless Internet access in order to drive more eyeballs to Google’s ad inventory.

Equally importantly, Android would not have risen were it not for the billions of dollars that OEMs and network operators poured into Android in order to compete with Apple’s iconic devices. As Stephen Elop, Nokia’s CEO, said in June,2011, “Apple created the conditions necessary for Android”.

Moreover, our findings suggest that Android would be successful regardless of whether it is an open source project or not, to the extent that the vast majority of developers working on the project (the platform itself) are actually Google employees.

Evolving the Open Governance Index

Having published the report, we aim to continue the discussion on governance, to refine our criteria even further and to make the OGI measure as meaningful as possible for the open source community. One of the first suggestions has been with regard to having a time dimension to the criteria i.e. does openness change over time. Mature open source projects such as Eclipse, Linux and WebKit that have stood the test of time, score quite highly with regard to openness of governance. But this has not always been the case. For example consider the following. Apple forked KHTML to create WebKit in the early 2000’s, releasing the first WebKit open source project in 2005 but with reviewer and commit rights restricted to Apple personnel only which effectively sidelined the KDE community. In 2007 however Apple reversed this decision allowing allow non-Apple developers to have full commit access to the WebKit source code version control system. This shows that openness can and does change over the project lifecycle.

Our vision for the Open Governance Index is to for it to be a robust, and as much as is possible, an objective measure of Governance for open source projects. We believe that this is necessary such that users and contributors to open source projects, including commercial entities, understand the means by which they can, or cannot, influence the direction and content of the project.

Download the full report for an in-depth analysis of the openness of Android, MeeGo, Linux, Qt, WebKit, Mozilla, Eclipse and Symbian. Drop us a line and tell us what you think.

– Liz

Addendum – Is copyleft more or less open?

We awarded a higher score to those licenses that are permissive and not copyleft licenses. Firstly it should be noted that all the licenses used by the eight mobile open source projects are Open Source Initiative (OSI) approved and meet the Open Source Initiative Definition, which provides for free redistribution of source code, access to source code and ability to create derived works amongst other requirements. We believe that the OSI is the appropriate arbiter of the appropriate Open Source License definition and all of the licenses used by the open source projects researched in this report meet this definition of being â€˜open’.

However we also believe that from a commercial viewpoint there is still some concern about using code that is under a copyleft license – our experience of working with mobile software development organisations confirms this. Our findings suggest that organisations will be more comfortable using permissive licenses which do not mandate copyleft requirements and we reflect this in our criteria and scoring. We are happy to continue debating these findings further with the community. For example it has been suggested that the problem here is not with copyleft licenses but with the business model used by those organisations. Be that as it may, our experience is that this concern is still a valid one being expressed by many organisations, especially in the mobile device domain.

Finally we had a methodology typo which unfortunately survived the proof reading: assigning a bonus to “copyright assignment”. We fully acknowledge that copyright assignment is unnecessary – indeed we state this in our analysis of Qt whereby we acknowledge copyright assignment as inappropriate and a heavy-handed requirement.

[Liz Laffan is a Research Partner at VisionMobile. Liz has been working in the telecoms and mobile industry for over 20 years, with large telco organisations, start-up technology ventures, software development and licensing firms. Liz’s interests lie in open source software governance and licensing and in particular how best can commercial organisations interact with open source projects. She can be reached at liz [at] visionmobile.com]

The Open Source trials: hanging in the legal balance of copyright and copyleft

[Open source has been in the limelight for the last few years, but its legal implications have been in the dark. Research Partner Ã…se Stiller sheds some light into the legal precedents of open source, from Cisco to Skype]

For those meddling in open source software affairs, compliance with licenses is a very hot topic. In the last 2 years we have witnessed the licensing FUD (Fear, Uncertainty & Doubt) giving way to legal clarity with more and more relevant cases proving the acceptance of open source licenses by legal systems around the world.

The secrets of Copyright
Open source software licenses are based on copyright law. The notion of copyright has a long history; some hundred years ago copying was hard to come by and a threat only to a few. In contrast, in today’s digital world copyright is much more important as communications move around the world not in 80 days but in 8 seconds; and copying is as easy as pressing a button.

The story of international copyright starts with the Bern Convention in 1880, while the most prominent copyright law is probably the US Copyright Act from 1978. The Bern Convention was initiated by the French Author Victor Hugo in order to protect the rights of European writers against the illegal copying of books which was taking place on the other side of the Atlantic at that time.

In copyright law, the original creator has the exclusive right to reproduce a work by default, subject to certain conditions; firstly the work must reach a threshold of originality, and secondly if the work is created under commission, the person with the chequebook often becomes the copyright holder. The Fair Use doctrine also sets aside some good reasons to copy a work – for example for commenting, news reporting or research – without infringing on copyright.

Only the owner of a copyright can license or sell the right to copy the work to others, under terms and conditions of their choice. Violating these terms and conditions is in principle infringing on the copyright.

Copyright is also sticky. It will survive the creator by some 50-100 years depending on the application law at a country level. Once the copyright expires, the work enters the public domain and is no longer protected by copyright laws. Whilst open source software is by definition publicly available, this does not mean that it is freely available in the public domain as it is still under a license, be that a copyleft or copyright license.

Copyleft vs Copyright
Copyleft – one of the main innovations of open source licensing – is a word play on copyright. Copyright law is used by an author to prohibit others from reproducing, adapting, or distributing copies of the author’s work. In contrast, Copyleft allows an author to give out copies of a work with permission to reproduce, adapt or distribute, but requires any resulting copies or adaptations to also be bound by the same license agreement.

Copyleft is in reality enforced by copyright. which has been clearly demonstrated by a number of interesting legal disputes, e.g. in the New York District court case of BusyBox v. Westinghouse in July 2010 and by the US Court of Appeals for the Federal Circuit.in Aug 2008 in the Artistic License case of Jacobsen v. Katzer (more on this below).

Likewise the German and French courts have provided some good examples that they do accept copyleft licenses as valid and binding for anyone who chooses to make use of the work.

Open Source and Legal precedents
In researching the legal precedents for Open Source licenses we find that most open source license disputes are with regard to the GNU GPL v2, which was written in 1991 by the Free Software Foundation. It took more 10 years before the license was actually tried by any legal system, but since then there has been a number of highly relevant cases of open source license infringement, brought to court in Europe and in USA.

By the end of 2010 a long list of court cases have surfaced which test the validity and legality of open source licensing – the table provides a (partial) list:

Case	against	Year	Place	License	about	Ruling	Importance
MySQL	Progress Software	2002	District Court Massachusetts	GPLv2	Trademarks	Settled 2002	GPL accepted by court
Harald Welte	Dlink	2001	Frankfurt AM	GPLv2	GPL Binding?	ruled to Welte	using code = accepting GLP
	Fortinet UK Ltd	2005	Munich	GPLv2	compliance	ruled to Welte	Early test of GPL
	Gigabyte Technology Co. Ltd, TomTom	2004	–	GPLv2	compliance	Settled
	Iliad	2007	Munich	GPLv2	compliance	ruled to Welte	FSF France First case outside of Germany
	Sitecom	2004	District Court of Munich,	GPLv2	compliance	ruled to Welte	Fist case in Eur
	Skype	2008	District Court of Munich	GPLv2	Compliance/source code access	ruled to Welte	GPL must be followed strictly
SCO	AutoZone, Daimler Chrysler, IBM, RedHatIncl. countersuits	2003-2004	District Courts in Utah, Delaware, Nevada, Circuit Court Oakland	GPLv2	IP infringements Trade secrets contact breach	Settled, dismissed and referred to Novell case	Ownership over UNIX code in Linux
	Novell	2004	US Court of Appeal		IP infringements Trade secrets contact breach	ruled to Novel 2010	Ownership over UNIX code in Linux
	SUSE Linux	2003	ICC International Court of Arbitration			ruled to SuSe
AFPA	Edu4	2009	Paris Court of Appeal	GPLv2	compliance	ruled to AFPA	Downstream rights
BusyBox	Astak Inc, BellMicroproducts, Best Buy, Comtrend, Dobbs-Stanford, Extreme Networks, GCI Technologies, High-Gain Antennas, Humax USA, JVC U, Monsoon, Phoebe Micro, Robert Bosch, Samsung Electronics US, Super Micro Computer, Verizon, Versa Technology, Western Digital Technologies, Xtrasys, ZyXEL Communications.	2007-2009	NY District Court	GPLv2	compliance	Settled/undisclosed still open (?)	Monsoon was the first case for GPL in US
BusyBox	Westinghouse Digital Electronics, LLC	2010	NY District Court	GPLv2	compliance	ruled to BusyBox	Damages awarded
FSF	Cisco	2008	NY District Court	GPLv2, LGPL 2 and 2.1	compliance	Settled	Compliance officer
Jacobsen	Katzer	2008	Federal US	The Artistic License	compliance	ruled to Jacobsen	Open source licenses are for real

The most typical violation of GNU GPL arises when consumer electronics vendors, or distributors of embedded devices using Linux (which is licensed under the GNU GPL v2.1), fail to supply the source code, copyright notice or to attach a copy of the license – all of which are required by the GPL license. It´s difficult to identify if this is caused by lack of knowledge, poor version control process, or disregard for compliance due to the perceived high cost for compliance procedures, paired with a low risk for detection.

Interestingly, in many cases, it’s not the copyright holder who sues, but a representative like Mr. Harald Welte in Germany or the Software Freedom Law center in USA.

The GPLviolations.org project, set-up in 2004 by Mr. Welte in Germany, is one such enforcer of the Open Source adherence. GPLviolations.org has brought more than 100 cases to court (including D-Link, Skype, TomTom, Motorola and Acer), all of which were successfully settled out of court. Additionally the GPLviolations and Harold Welte have won several victories in Europe over large companies such as Sitecom and Fortinet.

In the Sitecom case (2004) Welte identified his own source code in the binaries for Sitecom´s Network routers, which Welte had licensed under the GNU GPL v2.0 but Sitecom had not made the source code available or referenced the GNU GPL v2.0, both of which are a requirements of the License. The District Court of Munich granted Welte an injunction against Sitecom Deutschland GmbH whereby Sitecom was prohibited to distribute the products, until they were compliant with the GPL terms. Sitecom appealed but lost and posted the terms for GPL on their Web FAQ for the router.

LikewiseFortinet Ltd UK was banned from distributing their Firewall and Antivirus products by the Munich district court in 2005, until they were in compliance with GPL. GPL-violations.org had found evidence that Fortinet used Linux kernel and other GPL licensed software in its FortiOS product. The Munich court granted a temporary injunction against the company for selling the products, and Fortinet was forced to make their OS available free. Fortinet had been warned by the GPLviolations.org about the violation but attempts to reach an out-of-court settlement failed.

The case of Skype
Similarly, Skype Technologies SA (a Luxemburg company) was accused of violating GPL in 2008 in the course of selling a Linux-based VoIP phone, through the Skype website. Harald Welte took Skype to a Munich court for failing to provide the source code and the license together with the phone. Skype claimed that a URL to where both license and code could be downloaded was provided in the documentation – however the German court found this insufficient under GPL v2. The license states that offering source code for downloading, is only applicable if and when the binaries are downloadable from the same place, which was not the case here. Skype Technologies eventually settled out of court.

D-Link
The2006 case of Welte vs D-Link GermanyGmbH, started much like any other open source legal dispute; D-Link failed to provide the source code for Linux Kernel modifications that were used in a network storage device, and failed to provide a copy of the GPL license. D-Link rectified this error but refused to cover the disbursements for Mr. Welte for the trial, claiming that the GPL license was not binding for the company. The case then became more interesting as the focus thereby shifted from the usual GPL compliance to become a test of the binding mechanism for the license: Was using the software to be considered equivalent to accepting the terms in the license? The Frankfurt-am-Main’s District Court clarified that D-Link was indeed bound by the terms in GPL v2, solely by enjoying the benefits of the free software and therefore also must cover the lawsuit costs for the plaintiff, Mr. Welte.

Free Software Foundation; on the tail of license infringements
Free Software Foundation (FSF) is another non-for-profit organization that monitors GPL compliance. The FSF was founded in 1985 by Richard Stallman to promote free software, and has since set up regional entities in Europe (2001), India (2003) and Latin America (2005).

The organization is dedicated to promoting users’ rights to the four freedoms of Open Source: To Use, Study, Modify, and Redistribute software. The FSF sponsors the GNU project and maintains the GPL licenses as well as the Free Software Definition.

FSF’s is known to enforce GPL compliance through closed-door discussions rather than lawsuits, with the aim being compliance rather than monetary damages.

Aiding the FSF is the Software Freedom Law Center (SFLC), a US-based law firm founded in 2005 providing free legal services, to nonprofit open source developers. The SFLC has also published a guide on how to comply with GPL and advice on how to act if caught violating GPL.

Cisco – a case for the Supply chain manager
Assisted by The Software Freedom Law Center, the FSF initiated a case against Cisco for copyright violation under GPL and LGPL in 2008. Like many others, the case was settled out of court in 2009 resulting in a donation to the FSF, a pledge of commitment to the GPL and the appointment of a compliance director reporting to the FSF.

Cisco never disputed GPL as such but “bought themselves a lawsuit” through the acquisition of Linksys in 2003. Shortly after the acquisition, complaints started showing up on the Linux Kernel Mailing List and Slashdot on how Linksys was not providing source code for GPL licensed software used in the router firmware (Linksys had bought the chipset from Broadcom who in its turn had outsourced the driver development). FSF took action on behalf of several copyright holders against Linksys/Cisco and other companies using the same 802.11g router chipset from Broadcom, where the issue had originated.

BusyBox – when no one is too big
Among the more interesting cases for general acceptance of Open Source licenses are the BusyBox cases which involved major corporations, including Verizon, Samsung and Westinghouse.

BusyBox is a set of common Unix/Linux utilities, all packaged in a small executable and typically used in embedded systems. The software is licensed under GNU GPL v2.

The BusyBox legal saga started with 4 different cases of copyright infringements, as a result of the distributors failing to provide source code. The first action was against Monsoon Multimedia which became the first GPL copyright lawsuit in US history. The case was settled in October 2007 with Monsoon agreeing to appoint an open-source compliance officer besides publishing the source code. There was also a monetary part of the settlement but the amount was never disclosed.

The Monsoon case was followed by High-Gain Antennas and Xterasys in 2007 and Verizon in 2008. Picking up speed and size, since 2009 14 new companies (including BestBuy, Samsung, Westinghouse, JVC) were sued by SFSC for violating the GPL license of BusyBox software.

Much like Monsson, Verizon settled in 2008 while it appears that four more defendants (Samsung, Comtrend, Dobbs-Stanford, and GCI Technologies) have also settled with the plaintiffs. The only exception was Westinghouse where a District Court in NY ruled in favor of BusyBox in August 2010. The infringement was considered willful and the damages were tripled by the judge.

MySQL, a near-test for open source derivatives
One of the reasons for uncertainty around Open source licenses and especially the GPL v2 is the often-discussed question about how to define derivative work, and how to link software to GPL-code without having to license that software under GPL too, a requirement of the GPL. This is often described as the â€˜viral’ nature of the GPL and remains a core concern for many companies is the linking of proprietary software libraries to GPL licensed code. It is generally accepted that if the linking is static then the proprietary code must also be included under the GPL license whereas if the linking is dynamic the linked software is not necessarily a derivative of the GPL and as such not bound to the GPL redistribution terms.

Now given that the definition of a derivative work in GPL v2 is unclear, this issue remains a concern, albeit slightly clarified in GPL v3. For an analysis on the differences between GPL v2 and GPL v3, VisionMobile has published a free paper: The GPLv2 vs. GPLv3: The Two Seminal Licenses, Their Roots, Consequences and Repercussions.

In the context of derivative work and legal precedents, it is also worth discussing the case of NuSphere in 2002. NuSphere produced a database add-on component (called Gemini) to the MySQL engine. As NuSphere’s Gemini component was statically linked with MySQL’s GPL-licensed database, MySQL sued NuSphere for non-compliance with the license terms. The judge however refused to allow the arguments in the case to expand beyond a mere trademark dispute and urged for an out-of-court settlement between the parties, leaving the definition of derivative work still in the dark and unclarified.

The Jacobsen case and the Artistic license
The now-famous Jacobsen vs Katzer case revolves around a Java software interface for model railroads, made available under the Artistic License (an approved Open Source license) by the developer Mr. Robert Jacobsen. The software was used by Mr Katzer´s company, in a competing solution, but they failed to provide information about the origin of the software – in violation of the licensing terms. The case was first tried in a US District court and the ruling then was that the license was to be regarded as a contract – not a license.

However the case was appealed in 2008 to the US federal court, when the judgment was reversed in favor of the Artistic License and Mr Jacobsen, thereby providing a legal precedent for Open Source licenses as valid and legally binding.

The SCO Group opera isn’t over yet
This is a story about copyright of Linux code, featuring celebrities such as IBM, Novel, RedHat and SGI. In 2003, the SCO Group based in Utah, claimed that Linux infringed their copyright and trade secrets, and subsequently demanded that Linux users needed a license from them, for parts of the Linux code.

The SCO Group sued a number of companies for donating UNIX code to Linux. The software donations included code that SCO claimed ownership of and thus the accused companies had violated SCO´s copyright. SCO also argued that GPL would not be enforceable in this case because it was preempted by the copyright law, protecting SCOs rights. (see detailed story on Groklaw).

The SCO soap opera of legal precedents has no less than five acts: SCO v. IBM, Red Hat v. SCO, SCO v. Novell, SCO v. DaimlerChrysler and SCO v. AutoZone. It includes ingredients like lawsuits, countersuits, appeals and bankruptcy protection. In 2007 a US federal court ruled Novel to be the owner of UNIX, invalidating the claims from SCO but there is a new appeal from SCO, and a Novel has filed a petition for certiorari* with the US Supreme Court. Meanwhile the final episode in this saga is yet to come.

Edu4 and downstream rights
In 2009 Paris Court of Appeals set a French legal precedent in favour of GPL, in a typical case of binaries but no source. In this case the lawsuit was not filed by the copyright owner, but by the end-user, which makes it all the more noteworthy.

The story goes all the way back to 2000, when Edu4 had distributed a GPL licensed VNC remote access software, for PCs, to a French education organization (AFPA),but refused to provide the source code for its modified version of the program when AFPA, assisted by the French FSF, requested that.

Open source licensing gaining legal maturity
The number of law suits, rulings and discussions above indicate that Open Source licenses are indeed enforceable under Copyright law, and that the enforcers will not hesitate to take large corporations to court for violations. Giving software away for no monetary charge does not invalidate copyright, and damages will be awarded for infringements even though the price for the code was zero.

There is no longer a need to question the legality of Open source licenses.There are enough legal precedents demonstrating that Open source licenses are valid legal documents and binding for anyone who uses the code.

Knowing that the Open Source licenses are in fact tested, tried and fully accepted by the legal system may deal with the U (uncertainty) and the D (doubt) in FUD, but for the remaining F (fear) the best remedy is information. The only good way to mitigate the risk of infringements is to ensure that everybody involved in the development process, has a good understanding of the obligations and restrictions of Open Source licenses, and that the an organisation’s Open Source policy is appropriate – assuming of course that there is one. Many engineers already know a lot about Open Source software and the licensing models, but do their managers know?

Keeping track of Open Source software that maybe included in the next software release is crucial for any company, and the best way to start is of course with a thorough review of existing codebase, establishing a solid process and of course a comprehensive training program for developers to CxOs.

There is obviously much to discuss besides the narrow focus of this article on court cases. Do you have more examples and experiences to share on open source licensing?

– Ase

* The U.S. Supreme Court uses the Latin term Certiorari for appeals.

[Ã…se is a Research Partner at VisionMobile specializing in software sourcing, policies and training. Ã…se co-delivers VisionMobile’s Open Source Chessboard, a full-day training course on the economics and competitive landscape of mobile open source, covering business models, licenses & patents, governance models, control points, community cultures, plus 10+ case studies on the who’s who of open source.]

Mobile Megatrends 2011

[We â€˜re excited to release our fourth annual Mobile Megatrends 2011 – themed around what else? how software is fundamentally changing the telecoms value chain. In this fourth annual research presentation we take a deep dive into the many facets of change in the mobile industry; the DELL-ification of mobile, the battle for experience ecosystems, apps as web 3.0, the use of open + closed strategies to commodise + protect and how telcos can compete in the age of software.]

After many months in the making, we ‘ve released our annual Mobile Megatrends 2011. It’s our fourth and biggest Megatrends research we ‘ve published to date featuring 68 juicy slides with detailed analysis on the future of mobile.

[slideshare id=6863232&doc=mobilemegatrends2011visionmobile-110209095522-phpapp01]

(want more? Contact us to schedule an on-site Megatrends workshop)

We take a deep dive into how software economics is fundamentally changing the telecoms value chain setting new rules for innovation. We ‘ve broken down the 2011 Megatrends into 8 core themes:

[poll id=”12″]

1. The DELL-ification of mobile: The world of handset OEMs has been irreversibly changed by software and Internet players. All traditional top-5 OEMs (from Nokia to Motorola) that used to enjoy a combined 80% market share in 2008 are now reduced to below 60%, while Internet players are reaping the majority of industry profits and market growth. The OEM market now seems destined to match the shape of the PC manufacturer market, made up of price-led assemblers (Dell, Asus) and performance-led leaders (Apple). For the old guard of top-5 OEMs, the race is on to innovate or die.

2. Software: the new era for telecoms: Besides Android and iOS headline grabbers, more than 30 software platforms have risen and (mostly) fallen in the last decade; Lesson learned: big bucks and software DNA are critical success ingredients for software platforms. The 10 or so remaining software platforms are battling for mass-market smartphone reach below the $100 retail price barrier. At the same time, every major industry player – from telcos to facebook – are striving to grow their own ecosystem, spanning from UI to social networks. However, in the software era of telecoms, not everyone is born equal. Speed of innovation, addressable consumer income and access to a partner ecosystem are all home turf for Internet players, while telecoms incumbents (from Nokia to Vodafone) are taking small, naÃ¯ve steps. The new rules are: if you can’t innovate in software, you will be replaced sooner than later.

3. The battle for Experience Ecosystems. Convergence between telecoms, PC and Internet has long been talked about. But it’s not about the all-in-one all-powerful smartphone. Convergence is proving to be not about technology, but about experience convergence; how the user experience can â€˜roam’ from one screen to the next (phone, PC, TV, mp3 player, etc). Apple is the poster child of experience roaming by consistently integrating the key experience ingredients – from UI and industrial design to an apps ecosystem – across multiple screens. The next battle in mobile is to build experience ecosystems which create user lock-in and cross-sales – and therefore present a sustainable strategy for both handset vendors and telcos to survive commoditisation pressures.

4. Apps are the new web. Everyone wants to compete with their own app store these days, but only a handful of app stores are above the developer radar. Why is creating an app store so hard? Because a successful app store needs 5 unique â€˜genes’ from 5 different â€˜species’ across the value chain. And thanks to app stores, apps succeed where the web failed; in discovery, personalization and monetization. Apps are in fact a new information paradigm, which the web is adopting. Supported by web benefactors and technology commoditization, web is becoming mainstream application development platform, in what could be could termed the web 3.0.

5. Open + closed: two sides of the same coin. Android took the mobile world by surprise when it launched a free-for-all software platform. But like Qt, MeeGo, WebKit and many other open source projects, â€˜open’ is only the tip of the iceberg, since Google et al are using closed governance models to control the direction of the product. Besides open source, â€˜openness’ is used as a business strategy to commoditise product complements while closing off other products to protect core assets; in Google’s case commoditizing handset and networks while protecting its own ad network.

6. Developers, the engine behind telecoms innovation. Mobile software developers have come a long way, from back office engineers to front row success stories. However the mobile developer market is still in its infancy. We present a novel way of looking at the developer journey and reveal how most commercial products cater to just a narrow section of that journey, with opportunities abound for catering to the needs and wants of telecom’s innovation engine.

7. Communities: the new currency. Communities are the new frontier for differentiation in the mobile industry. Everyone has tried creating their own communities – from Nokia to Vodafone – but only companies with social DNA have succeeded. Why is that? while you can buy an audience (eyeballs or subscribers), you can’t buy a community (the user interactions). Building a community is a form of art where tools and techniques are being explored, from game mechanics to religion engineering. One thing is certain; that communities are now a core asset in customer attraction and are expanding into communication networks and handsets, with Facebook leading the way.

8. Telcos: stuck in the telecoms age. Telcos are in the midst of an identity crisis and losing control point after control point – location, discovery, billing and authentication – while having no innovation to show in their core voice and messaging business. Yet the real value of telcos is still untapped with micro-billing, customer insights and retailing channels gone largely unexplored. We present 8 novel strategies for telcos and argue why WAC (the telcos’ answer to competing in the software age) is repeating history mistakes and is ultimately misguided.

Want to dive deeper into how software is fundamentally changing the mobile value chain? Contact us to schedule an on-site Megatrends workshop.

Want to reuse the slides within your presentation? Feel free to remix, but please provide attribution to VisionMobile.

Comments welcome!

– Andreas
follow me on twitter: @andreascon

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

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.