Semi-open Android getting more closed by the minute

From day one, I’ve remarked that Android is not really an open open source project. It promised openness but didn’t deliver, instead pursuing a strategy of semi-openness to gain market share against its proprietary rival. That Google tightly controlled the Android community shouldn’t be surprising since — for any firm — the point of funding (and controlling) a sponsored community is to gain benefits not available to other firms.

This wasn’t just my opinion, but was supported by a detailed study by Liz Laffan of Vision Mobile, a European consulting firm. (I thought the study was a clever idea — not just because it leveraged my typology of firm-controlled open source communities — and the press did as well). In comparing the governance of mobile open source communities, Laffan found Android was by far the least open of eight mobile-related communities. She concluded:

Android’s success has little to do with the open source licensing of the public codebase. Android would not have risen to its current ubiquity were it not for Google’s financial muscle and famed engineering team. Development of the Android platform has occurred without the need for external developers or the involvement of a commercial community.

Google has provided Android at “less than zero” cost, since its core business is not software or search, but driving ads to eyeballs. As is now well understood, Google’s strategy has been to subsidize 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.

More 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, CEO of Nokia, said at the Open Mobile Summit in June, 2011, “Apple created the conditions necessary for Android”.

As Laffan notes, the one way that Android was open was the provision of source code. But that's changed too, as Ron Amadeo documented Sunday on the Ars Technica website:

Google has always given itself some protection against alternative versions of Android. What many people think of as "Android" actually falls into two categories: the open parts from the Android Open Source Project (AOSP), which are the foundation of Android, and the closed source parts, which are all the Google-branded apps. While Google will never go the entire way and completely close Android, the company seems to be doing everything it can to give itself leverage over the existing open source project. And the company's main method here is to bring more and more apps under the closed source "Google" umbrella.

There have always been closed source Google apps. Originally, the group consisted mostly of clients for Google's online services, like Gmail, Maps, Talk, and YouTube. When Android had no market share, Google was comfortable keeping just these apps and building the rest of Android as an open source project. Since Android has become a mobile powerhouse though, Google has decided it needs more control over the public source code.

For some of these apps, there might still be an AOSP equivalent, but as soon as the proprietary version was launched, all work on the AOSP version was stopped. Less open source code means more work for Google's competitors. While you can't kill an open source app, you can turn it into abandon ware by moving all continuing development to a closed source model. Just about any time Google rebrands an app or releases a new piece of Android onto the Play Store, it's a sign that the source has been closed and the AOSP version is dead.

In some ways, this is looking like IBM’s WebSphere. IBM has a proprietary software package layered on top of an open source Apache HTML server engine: yes, the engine is useful, but it’s not complete for the commercially important applications. (BEA’s — now Oracle’s — WebLogic plays a somewhat similar role). However, IBM was open about what it wanted: in our 2006 paper, Scott Gallagher and I noted how IBM was quite open about its partly-open strategy.

What’s different here is the suggestion by Amadeo (this week) and others (previously) of an intentional bait and switch strategy:

Vic Gundotra, recalling Andy Rubin's initial pitch for Android, stated:

He argued that if Google did not act, we faced a Draconian future, a future where one man, one company, one device, one carrier would be our only choice.

Google was terrified that Apple would end up ruling the mobile space. So, to help in the fight against the iPhone at a time when Google had no mobile foothold whatsoever, Android was launched as an open source project.

In that era, Google had nothing, so any adoption—any shred of market share—was welcome. Google decided to give Android away for free and use it as a trojan horse for Google services.
…
Today, things are a little different. Android went from zero percent of the smartphone market to owning nearly 80 percent of it. Android has arguably won the smartphone wars, but "Android winning" and "Google winning" are not necessarily the same thing. Since Android is open source, it doesn't really "belong" to Google. Anyone is free to take it, clone the source, and create their own fork or alternate version.

The article documents how Google uses its APIs and app store to punish any attempt to fork the code. (Yes, the Kindle is a successful fork, but without the Google APIs it will only have a fraction of the 850,000+ Android apps.)

Amadeo concludes:

While Android is open, it's more of a "look but don't touch" kind of open. You're allowed to contribute to Android and allowed to use it for little hobbies, but in nearly every area, the deck is stacked against anyone trying to use Android without Google's blessing. The second you try to take Android and do something that Google doesn't approve of, it will bring the world crashing down upon you.

Free is not open, and open is not free

When talking to computer users and buyers over more than a decade, I was struck by how much a desire for things “open” was less about freedom and more about free. Sorry, Richard, but the reality is that people want free beer more than free speech. I saw this at SJSU, when IT buyers wanted “open” standards without knowing what open meant. I’ve remarked on this repeatedly in my research, including a 2007 chapter on open standards and a 2008 chapter on open source ideology.

Next month, I’ll be talking about the principles of open source software with a new type of audience, KGI graduate students trained in molecular biology who are preparing to work at leading biotech companies. So I thought I’d find examples of both “open source biology” (which is hard to do) and open source software being used for biology.

The best known public domain package for molecular biology is BLAST, which as Wikipedia helpfully notes, dates to a 1990 article in the Journal of Molecular Biology. The “Basic Local Alignment Search Tool” can be used to match a DNA sequence to a library of known sequences to find similar patterns. This is a very computationally intensive process — I recall that Apple made a special effort to support BLAST in its servers after Art Levinson (then Genentech CEO) joined the Apple board of directors. (Levinson succeeded Steve Jobs as Apple board chair after the latter’s untimely death.)

There seem to be two variants of BLAST out there: NCBI BLAST and mpiBLAST. The latter proclaims itself as “a freely available, open-source, parallel implementation of NCBI BLAST.” It seems to be supported by contributors from Virginia Tech, several national labs, IBM and a research group in Taiwan. However, the developer and user mailing lists have no postings since August 2011.

The gold standard is the original BLAST from the National Center for Biotechnology Information. The NCBI BLAST is delivered as a hosted service (what we now call SaaS), altthough the code and database of BLAST+ can be downloaded from a NIH website. However, it appears as the flow of technology is one way — from the government out to users — reminding me a lot of the VistA healthcare IT system that prompted my original interest in open source communities.

In other words, BLAST is free, but it isn’t really open. The government is fine with releasing technology in the public domain — which often is required under basic principles — but not in sharing control or authority.

Sure enough, I found an August 2011 posting by Peter Cock, a UK blogger (and software developer) blasting at BLAST and its lack of transparency:

Now as a USA government funded project, NCBI BLAST is released to the public domain … That's great, it's free and open source, and means BLAST can be modified and re-distributed. This is perfect for inclusion in Linux distributions like Debian which take licence freedom issues very seriously (see packages blast2 for NCBI "legacy" BLAST, and ncbi-blast+ for NCBI BLAST+, the re-write in C++).

However, in other terms the NCBI BLAST project is far from open. Looking at the BLAST Developer Information there is nothing about participating in BLAST development, and no sign of a developers mailing list.

NCBI BLAST doesn't have a public source code repository. … Update (21 October 2011) Not sure how long its been there, but there is (now) a read only public SVN for BLAST+ etc,
…
NCBI BLAST doesn't have a public bug tracker. Instead individuals must contact the NCBI by email, at blast-help (at) ncbi.nlm.nih.gov, which gets you in touch with the front line support team that then pass proper bug reports on to the actual developer team. The only way to track an issue is by follow up email, referencing the original report by date and email subject -- if there is an internal bug tracking number I've never been told it, and I have asked about this specifically.

Actually Peter has set his sights somewhat low. As Sibohan O’Mahony and I found in our research, transparency is the de minimis level of openness that can be provided to outsiders by an open source community. The truly open projects offer permeability, or the ability of outsiders to influence the direction of a project to make it suitable for a broader range of needs than is conceived by the original authors.

This permeability consists not just of the code, but also the direction and governance of the effort. If you can add changes but not influence the priorities or direction, then a project isn’t really open.

Alas, only a handful of projects meet this standard: Apache and Eclipse are the gold standard. Instead, fishbowl type single-firm communities use open source as a distribution mechanism rather than as a way of harnessing distributed innovation; MySQL was once an exemplar, but nowadays it’s Android. But then for any corporate sponsor, letting go is hard to do.

In the truly open communities, the ability to participate attracts participation and builds a real sense of community and shared governance. When I started researching open source 12 years ago, we assumed we would see more example of such communities forming, but they still seem few and far between.

Of course, for many of these tightly-controlled open source projects, the “free” beer isn’t really free but instead is more like a free puppy (cheap up front, not in the long run). In this case, you have neither open nor free.

Sponsored Communities: Letting Go is Hard to Do

While preparing to teach my Thursday night technology strategy class, I saw a tweet by Santa Clara University professor Terri Griffith (and then by others) reporting that Business Week had posted my column on the difficulty firms have in managing sponsored open source communities.

Entitled “Open Innovation's Challenge: Letting Go Is Hard To Do,” the column was requested by Michael Arndt of Business Week as part of a special report on open source, open innovation and related topics. I used the column to link the research on open source and open innovation to the specific issues that big companies are having in surrendering control in sponsored open source communities.

In my open innovation blog, I enumerated the academic research behind these observations. Here I want to look at the second half of the story: the difficulty firms have in letting go, specifically Google, Intel and Nokia.

I thought it was interesting that there are at least five (now four) firm-sponsored open source communities in mobile platforms: Nokia’s Maemo, Intel’s Moblin, Google’s Android, Nokia’s Symbian and the LiMo Foundation; all except Symbian are variations of embeded Linux. In four cases, there is clearly a single firm driving the process to meet its respective strategic goals.

In this blog, I’ve often commented on this topic, such as Nokia’s tight control over the Maemo community and Google’s over Android. That this keeps coming up over and over again suggests that it’s an inherent problem.

As Siobhán O’Mahony and I found in our research, firms that don’t let go will have trouble convincing outsiders to participate, because they don’t know whether or not they will be able to benefit from their contributions.

Of course, maybe this is just a temporary expedient, of holding the reins tight until the community is up and running, but eventually intending to share governance. An encouraging sign is the decision of Nokia and Intel to pool their efforts (forming Meego), and turning over community management to the Linux Foundation, which is much better situated to build a cooperative open source community.

Still, the inescapable truth is that we really have only one example of a big firm creating a sponsored open source community and then really letting go. In the Business Week column I wrote:

But the best role model is Eclipse, formed through IBM's 2001 donation of its Java development software. IBM executives decided to share control when they realized "they needed Eclipse to become independent to achieve their strategic goal to have the broader Java ecosystem adopt Eclipse," says Mike Milinkovich, executive director of the Eclipse Foundation. Since then, the foundation has been able to attract outside participation not only through its formal processes, but also through new bottom-up initiatives created and led by outsiders.

Due to length limits, other insights from my interview with Milinkovich that ended up on the cutting room floor. Here is a missing paragraph:

Concerned about potential for IBM domination, “a lot of companies watched the operations of the Eclipse Foundation with eye towards “is this organization truly independent?’” said Milinkovich. The foundation was able to attract outside participation not only through its formal processes, but by encouraging new bottom-up initiatives that could be created and led by outside members, independent of IBM.

Another factor that was encouraging was that Milinkovich said that other firms and sponsored communities have come to it for advice. As a consultant to Symbian Ltd. during its final two years, I know that the Symbian (and Nokia) folks spent many months studying and talking to Eclipse in setting up the Symbian Foundation, which earlier this year released 40 million lines of source code as open source. Symbian has done a good job of getting the process right, but still the bulk of the resources are being supplied by Nokia — which then, as now, ships the overwhelming majority of Symbian phones.

Milinkovich said that LiMo also came to Eclipse for advice. However, he did not hear from Google (or Intel) in setting up their communities — whether because they consulted someone else or because they thought they knew everything, neither of us can say.

The fact that Eclipse stands alone is an existence proof that letting go is hard to do. But perhaps two or three years from now, we’ll have other examples of firms dispersing control to build a truly open sponsored community.

Maybe Google is serious about OSS

With its open source release today of its Closure JavaScript tools, Google is starting to suggest that it may eventually become a good open source citizen.

The newly released tools include a JavaScript compiler, a very broad JavaScript class library, and Java/JavaScript-friendly templates. All are released under the Apache 2.0 license, a very permissive license that essentially lets outsiders do whatever they want (rather than a viral or semi-viral license like EPL or LGPL).

Sure, Google has released other code before. Some of it has been experimental (beta quality) examples. Much consists of libraries (or example code) to get at Google’s APIs and thus provide complementary products that increase the value of Google’s services. Even Android would fit in the latter category — albeit at a larger scale — since it helps make handsets that access Google services.

However, the Closure Compiler, Closure Library and Closure Template are production level code that’s been used for years. These are the same tools that Google uses to implement gmail, Google Docs and Google Maps. Theoretically, a competitor could use these tools to make web-based services that compete with Google: Microsoft and Yahoo are unlikely to do so, but I would be surprised if some of the foreign portals (without large internal R&D staffs) don’t quickly adopt the technology.

Of course, Google’s not doing this out of the goodness of their hearts, and the ultra-secretive company has not said why this release now of this code. Perhaps it doesn’t think rivals will use it, perhaps it has a huge head start, or perhaps it’s just non-strategic commodity code. Conversely, perhaps it’s trying to shape de facto industry standards for JavaScript (now that Netscape and AOL are gone), either to influence complementors or assure a supply of well-trained newby programmers.

Still, this is only one step of openness from a semi-open company leading the race for Total World Domination. Even if — as blogger Matt Asay and Google spokesperson argue — Google is a leading (if not the leading) contributor of open source code, that doesn’t mean that they have become good open source citizens.

Revealing code is only one part of sponsored open source openness, which also includes shared authority over the future of the code and governance of the community, providing both transparency and permeability to outsiders. This has proven impossible for many companies — both big, powerful, autocratic ones used to throwing their weight around, and smaller so-called “open source” startups that use OSS as teaseware for their real (commercially licensed) product.

IBM was the first and one of the few companies to prove it was serious about open source — but then it could sell hardware and services if the OSS commoditized its software offerings. Its Eclipse Foundation remains the largest and most successful multi-vendor sponsored open source community.

Five years ago, HP had a similar business model and comparable principles (if not level of investment) in Linux and other open source efforts. However, under its new penny-pinching CEO it seems to have cut back on many R&D and community oriented efforts, and the former Linux Systems Division (later Open Source Business Office) now seems to be just a web page.

Apple isn’t normally considered an open (or open source), but its WebKit library is perhaps one of the most successful and most cooperative firm-sponsored efforts after Eclipse. Google, Nokia and now even RIM are working to make the library suitable for the industry’s wide range of mobile devices.

Meanwhile, Nokia got off to a bad start last year — following the model that Sun used for so long — of a nominally open project that’s completely controlled by the sponsoring company. Maybe both will get better someday (and to be honest I haven’t checked Sun recently), but letting go is clearly hard for big companies to do.

So will Google ever let go on strategically important code on projects? Or will it always require that it retain control of such efforts? My crystal ball can’t see through all the walls of secrecy erected by the Monster of Mountain View, so I refuse to hazard a guess. But I suppose anything’s possible.

Hat tip: Matt Asay’s Twitter® feed.

Perhaps someday Android will be open

I really like Matt Asay — the founder of the OSBC is one of the most thoughtful people in the open source industry. (Brian Behlendorf, Chris DiBona and Cliff Schmidt are others who come to mind.)

But (and you knew there was a but) he’s really taking a lot on faith right now with Google, Android, the gPhone and the Open Vaporware Alliance.

The OVA is a Linux-based consortium copying the LiMo playbook, but about a 6-12 months behind. To use the term coined by researcher Sonali Shah, both LiMo and OVA are an example of a “gated source” community, not an open source one. Some people and companies are invited within the walls of the gated community and are allowed to participate, but others are not. That’s not open source.

The problem is that we don't know the real intentions of Google and Android: promises of openness are not openness. This also applies to LiMo and (given Nokia’s track record) to the proposed Symbian Foundation too.

In fact, that’s the whole point of open source — we don't have to rely on promises, because an approved open source license is a credible commitment that the code will be available in perpetuity.

However, even if Google releases the code someday under an open source license, that really doesn’t mean they’ve created a vibrant open source community. The IP license is only one of three dimensions of openness for sponsored open source communities, and there are plenty of examples of sponsored communities that do not provide openness on the other two dimensions, i.e. accessibility for outsiders to participate in development decisions and formal governance.

Thus far, Google’s open source projects seem to be limited to sharing code but not sharing power. I am not aware of an example (I could be wrong) of one with outside committers, although it appears that at least some less strategic projects allow outside patch suggestions (which the Google committers can accept or reject).

Even if Google’s consortium allows other firms to participate in formal governance, that doesn’t mean that it will be fully open or democratic. As with various totalitarian regimes, franchise or candidates may be limited to those who will vote the right way or those nominated for office may be vetted to vote the party line. Packing the board is quite common for consortia, trade associations, standards committees etc. — big boys like IBM, Intel, Microsoft and NTT do it, so there’s no reason to think Google and Nokia will resist the temptation.

So if Google’s promising to be open someday, maybe they will be. But Symbian Foundation or LiMo could get there first — or, for that matter, so could Microsoft, Apple or RIM if they wanted to. Lining up to endorse or promote Android because it’s “open” is like planning to take your vacation next summer at a hotel that has not yet been built.

Managing sponsored open source communities

Sponsoring open source projects is a tricky matter. On the one hand, if people don’t feel like their participation matters, they won’t get involved. On the other hand, the firm paying to do the sponsorship wants to make a buck from its investment.

Four years ago, Siobhán O’Mahony and I sat down to try to explain how sponsored open source projects are different from their independent (or community-managed) counterparts. The result was a conference paper we submitted in June 2004 (published in a conference proceedings January 2005) that was one of the first (if not the first) to draw attention to how sponsored projects were different from the independent variety.

That 2005 paper was the subject of a blog posting earlier this month by Roberto Galoppini. (I must admit, I can’t keep up with all the open source blogs, but for the economics of open source Roberto’s blog seems to be right up there with the one by Matt Asay).

Like anyone, I appreciate the mention and the kind words about our work. However, it’s a little embarrassing, because that 2005 paper is an early draft of thinking that progressed a lot over the next three and a half years. A newer (and much better) version of the paper was published in April 2008 in a special issue of Industry and Innovation on the topic of online communities and open innovation.

The final title makes concrete the idea articulated by Tim O’Reilly of the importance of “The Architecture of Participation”:

• Joel West and Siobhán O’Mahony, “The Role of Participation Architecture in Growing Sponsored Open Source Communities,” Industry & Innovation, 15, 2 (April 2008): 145-168. DOI: 10.1080/13662710801970142

I won’t pretend to summarize 11,000 words and four years of research in a one-screen blog posting. However, the meat of the paper can be found in two places.

First, we talk about two types of openness: transparency (letting others watch) and accessibility (letting others have a say). (In an earlier draft of the paper, we used “permeability” instead of “accessibility,” and the former term was also used by Dahlander et al in their introduction to the special issue).

Here is a quote from the introduction:

In designing a community, sponsors were more likely to offer transparency than they were to offer accessibility to external community members. We found that sponsors faced a control vs. growth tension. To leverage the ability of communities to contribute to their firm’s bottom line, sponsors sought to maintain control over the community’s strategic direction. However, sponsors soon discovered that by restricting access to community processes, they limited their community’s ability to attract new members and grow.

Secondly, we mapped these two types of openness onto three forms of control: control of production, governance of decision making, and ownership of the IP. These ideas are summarized in Table 2 below:

		Form of Openness		Proprietary Model
		Transparency	Accessibility
Dimension of Participation Architecture	Production – the way that the community conducts production processes	Ability to read code and observe or follow production processes	Ability to change code directly	Production remains within a single corporation
	Governance – the processes by which decisions are made within the community	Publicly visible governance, observers can understand how decisions are made	Ability to participate in governance	The corporation makes all decisions at its own discretion
	Intellectual Property – The allocation of rights to use the community’s output	Rights to use code and access source code	Ability to reuse and recombine code in the creation of derivative code	Limited use rights are granted by the corporation for a licensing fee

Personally, I think the meat of the paper is in Table 3, which talks about the specific trade-offs made across the various independent and sponsored projects. But I’m hoping that others will find value throughout the 38 pages.

People who find this paper interesting may also want to read two other papers:

• Siobhán O’Mahony, “What Does it Mean to be Community Managed?” Journal of Management and Governance, 11, 2 (May 2007): 139-150. DOI: 10.1007/s10997-007-9024-7.
• Joel West, “Value Capture and Value Networks in Open Source Vendor Strategies,” Proceedings of the 40th Annual Hawai‘i International Conference on System Sciences, Waikoloa, Hawai‘i (Jan. 2007): 176. DOI: 10.1109/HICSS.2007.600.

Update July 17: I thought I’d posted about this article earlier, but didn’t find the earlier mention until after I’d written this blog entry. Apologies for the duplication.

Open source without open governance

(This is a posting that was stuck in my outbasket over the weekend. For obvious reasons I'm pushing it out of the out basket).

Last week I saw an intriguing headline in an InfoWorld e-mail blast:

Nokia: Open Source Developers Should Play By Our Rules

It's becoming clear that the phone maker thinks open source developers need to adapt to the ways of commercial software vendors, not vice versa. Read on:
http://cwflyris.computerworld.com/t/3299928/121450395/121092/0/

The article was intriguing but I had to get some work done, so I didn’t have a chance to investigate right away. The link pointed to a blog entry by Tom Sullivan which pointed to an InformationWeek article by Serdar Yegulalp which pointed to a Business Week article by David Meyer.

When it comes to open source mobile devices, I’ve been writing about Nokia’s Maemo efforts (and Intel’s derivative Moblin) almost since the blog started. I first heard about Maemo at HICSS-40 from friends of mine at ETH Zürich who have written a paper on Mameo. (I can only find the slides online).

Now not knowing anything else, one would expect that Intel would have a better hope of getting OSS, for two reasons. First, software is complementary to its main hardware business, while Nokia’s systems busines (like Apple’s or IBM’s) is based on software system integration.

Second, Intel has a long experience with open source as a founder (and the main funder) of OSDL — the late, great Linux promotion entity born back in 2000. It has also done other work in house to work with Linux (as part of its successful strategy to supplant RISC Unix boxes with x86 Linux boxes).

As part of my own research on open source, one of the things that I looked at was how firms interacted with open source communities. I chose as a co-author Siobhán O’Mahony, because no academic knows more about the dynamics open source communities than she does.

In April, we finally got our paper published, which we called “The Role of Participation Architecture in Growing Sponsored Open Source Communities.” It was in a special issue of Industry & Innovation (a European innovation journal), based on a track at last year’s EURAM conference on open source, user innovation and open innovation.

I could write a whole paper about Maemo and how it fits into other open source communities, but alas I’ve promised to write other papers in the next 60 days. So let me just quote from our conclusions:

However, our study showed that sponsored open source software communities are fundamentally different from autonomous communities in the potential for goal conflict between sponsor and community members. Although both sponsors and members seek widespread adoption, the primary goal of a corporate sponsor is profiting from its investment, while the goal of an open source community would be improving the capabilities of the shared technology.

To gain interest from a community of contributors, sponsors needed to at least provide transparency. The openness of sponsored communities differed most in terms of accessibility, with most sponsors retaining privileged (monolithic) rights for some portion of the community’s decisions. In a few open cases, the sponsor shared some control with the community—and when sponsors relinquished more control to the community, those sponsored communities were transformed into autonomous ones.

As a consequence, we also found a dramatic difference between most sponsored and autonomous communities in terms of design decision related to accessibility, particularly in terms of governance. Governance of autonomous projects was largely pluralistic, shared widely among community members, whereas the ultimate decisions of sponsored communities were (with rare exceptions) controlled by the sponsor.

So, to put it bluntly: companies want to have their cake and eat it too, but if they exert too much control, people will figure this out and individuals (or other companies) won’t bother to participate.

The problem for Nokia is, the cases where tight control is where you’re the only game in town (cf. MySQL, SugarCRM). There are many other initiatives building code based on Linux, so if Nokia tries to hold things too tight with Maemo, people will just join LiMo (if it ever opens its gate), Android (if it ever opens, and if it ever ships), or OpenMoko or (fill in the blank).

SDK from the Open Google Alliance

I made a mistake in reporting last week on something called the Open Handset Alliance. Despite my reporting (and the press releases and news stories) and what it claims on the Google Code pages, today there is no Open Handset Alliance. There is a Google-owned project called "Android."

A friend asked (quite reasonably) "Just curious if you have downloaded [the] Android SDK ... I don't want to commit my company to whatever the license says so I'll hold off on doing my own analysis."

I did a little snooping and what I found:

• Looking at the download site and the license terms made clear: the download greement is with Google, Inc., a Delaware corporation, not the so-called "Open Handset Alliance". (Thus putting the lie to the idea of the OHA being "co-sponsored" by four other companies.)
• There's no source code on the site, under an Open Source Initiative-approved license or any other license.
• According to the architecture diagram, as much Android code as possible is based on a BSD (or comparable) permissive license. No viral GPLv3 here, so presumably DRM and music players will be available on gPhones.
• Android is a platform for Java applets, not native C/C++ apps. Symbian, of course, has native apps, and it sounds like even Apple will have a native app SDK before the gPhone ships.

Alas, the SDK requires an Intel-based Mac (or Windoze) to run, and my first Intel Mac is about 2 months away. So unless I can borrow someone else's machine, I won't be doing any development any time soon.

Moblins run loose

For its Mobile Internet Device initiative, Intel has decided to brand its sponsored open source project “Moblin.” [YALBNdtCS]†

Most of the code is GPLv2 or LGPLv2.1. Intel admits its complete debt to Nokia’s maemo project: “Porting applications from maemo.org to mobile Internet devices and vice versa will be straightforward.”

In my own research with Siobhán O’Mahony, we have found, however, that there’s more to open source openness than just a license, i.e. control over development and governance. Intel has historically had tight control of standards consortia that it sponsored (such as USB 2), so that pattern seems likely to continue here. As with other tightly-controlled sponsored projects, this means hackers can use the code but rivals will have little or no influence over its direction, let alone ability to use it for their own strategic goals. (Yes, the case of controlling GPL licensed Linux code is a little more complex than say MySQL or Sleepycat).

Intel’s goal is to sell more chips and crush ARM. Open source is a means to that end, not a goal in itself. Commodity software is bad for a company that sells software but good for a company that sells chips.

Just an aside: does “moblin” rhyme with “goblin”? I know bugs are often “gremlins,” but are they also “goblins”? What does this say about code quality?

† This is coming up so often that from now on I’ll just use the YALBNdtCS acronym for “Yet Another Lousy Brand Name due to CyberSquatters”

Technorati Tags: Intel, Linux, mobile phones, Nokia

Cause and Effect: Shared Governance Brings Community

In his blog today, Matt Asay makes an impassioned plea for the open source world to draw a sharp distinction between companies that are sincere about open source, and those who are not. He argues the firms that fully embrace open source will succeed — while those that are half-hearted or “treat open source as a ball-and-chain” will fail.

Based on my research on firm open source strategies over the past 7 years, I am sympathetic to the argument. My hunch is that in most cases there is a structural reason for insincerity: Microsoft (or another big proprietary software vendor) is insincere at open source and fails, but the root cause is that a full embrace of open source would cannibalize its business. Clay Christensen calls this The Innovator’s Dilemma.

However, I take violent exception to the throwaway line at the end:

Open source without community is a sham.

IMHO this is confusing the cause with the effect. There are 100,000+ SourceForge projects without community. Are they a sham, too? Or are they just otherwise sincere people that failed to attract an audience?

For the past 4 years I’ve been researching how firms work with to open source communities, working with Siobhán O’Mahony who did her Stanford Ph.D. on the subject and was the first academic sociologist to study the phenemonon. We’ve concluded that open source communities have three dimensions:

1. intellectual property
2. development practices and
3. governance.

IP (i.e., OSI licenses) and development practices (e.g. CVS, Bugzilla etc.) fall into a fairly narrow range. However, the governance decisions (both transparency and accessibility) that firms make for sponsored open source projects strongly influence whether outsiders decide to join a community.

The obligation of a real open source company is to create governance structures which allow external participants to feel that they have the full right to participate and influence the outcome of the open source project; the best example of this is what IBM did with Eclipse. If no one shows up, then it might be because the sponsor failed to share control — or it might be because the technology has a small potential user base or because another project has already attracted the largest pool of potential contributors.

Matt is a friend, and one of the most insightful people I know on open source strategies, but I think he’s plain wrong here. It may have just been a minor slip of the fingers.