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.

Flash! Some OSS business models don't work

For more than a decade, b-school professors have been teaching about business models. However, I suspect sometimes we spend too much time emphasizing how important it is to have or understand a business model, and perhaps not enough about the importance of a good business model. (Regular readers know that I often write about bad business models, broken business models and even the decades-long search for a viable business model).

One important area of business model experimentation has been open source business models. This morning, my friend Matt Asay posted about Monty Widenius, who five years ago sold MySQL to Sun Microsystems for $1 billion, and then bailed out of Sun when the acquisition helped drag Sun down (or failed to lift it up) — leading to Sun’s eventual dismemberment by its new owner.

His opening paragraph sets the stage:

Monty Widenius, co-founder of MySQL and founder of MariaDB, just came to a surprise revelation: most people use open source for free. What's so surprising, however, is not this fact, but the idea that Widenius wouldn't have learned this 13 years ago when he first released MySQL under the GNU General Public License (GPL) and his company's revenues dropped 80%. The lesson here, however, isn't that there's no money in open-source software, but rather that some strategies for monetizing open source are effective, while others are not.

As Matt notes, it’s inherent in offering real open source (i.e. something that conforms to the Open Source Definition) that people can and will use it for free. Widenius' current suggestion is to have semi-open source (called “Business Source”) which might generate revenue but can’t be called “open source.”

I spent almost a decade researching how firms make money off of open source, including one of my favorite (and most-cited) unpublished papers. During that study, it was obvious pretty quickly that you had to give away something useful — so people would adopt your software — and hold back something valuable (e.g. support, add-on modules) so that people would pay you something. The balance was made tricky by the one-way nature of open disclosure of source code: once something was free (as in beer or speech) it was technically and legally hard to make it un-free.

Matt barely contains his snark as he cites all the people who’ve long since figured this out:

Jim Jagielski, president and co-founder of the Apache Software Foundation, suggests that "if your open source project isn't successful with FOSS licensing, it's not the license's fault." Rather, it's a matter of trying to charge for the wrong things:

what's "destroying" open source isn't people not paying for it, but wrong ideas on WHAT they should be paying for

— Jim Jagielski (@jimjag) May 30, 2013

To wit, Facebook, Google, Amazon and others make billions of dollars selling services around open-source infrastructure, while Red Hat mints over a billion dollars annually selling a certified, binary distribution of community-developed Linux. There is plenty of money in and around open-source software. The open-source license doesn't prevent this. It enables this.

Widenius is a smart person. He'll figure it out. It's only surprising that his experience at MySQL didn't already teach him this lesson.

I’m guessing that Widenius has already figured that out, but he can’t see how to get there from here because he’s painted himself into a corner.

(BTW, there’s always been a difference of OSS business models between firms that are givers and takers. A low cost, low risk strategy has been to be a taker — or net taker — by leveraging OSS created by others. It’s the givers that incur the cost of R&D for their free stuff, and thus bear a sizable risk of not being able to monetize well enough to cover that cost.)

One thing I haven’t seen mentioned is the inherent scale requirement for OSS and other freemium business models. As my research continued, it became clear that a revenue model with 1% (or 10% or 0.1%) conversion rate might work with millions of users, but the identical strategy would fail if you only had thousands of users. So copying Red Hat (or MySQL or Sleepycat) was going to fail miserably unless you had a smash hit that would support a 1% conversion rate. This is something that has recently become painfully obvious to all the iPhone game makers who used free games to win adoption and hoped to sell upgrades.

So yes, market leading companies with billions of customers can afford to give away software and monetize off of some small fraction of their customer base. But for new companies trying to launch now — even those run by smart experienced OSS veterans — an OSS (i.e., freemium) business model is at best a risky gambit. At worse, it’s a fools’ errand, because it’s no more feasible to create the next Red Hat or MySQL than it is to create the next IBM, Cisco or Google.

Open source doesn't repeal laws of economics

After failing in its webOS strategy, HP has announced plans to use it to create an open source project. This is an example of what (in our 2006 paper) Scott Gallagher and I called a “spin-out” strategy by firms to find a home for a technology they no longer wish to control.

Some might hope this would be as successful as IBM was with Eclipse. Others compare it to Fedora, the Red Hat desktop variant of its core Linux server product. However, with more than a decade of open source research and consulting, I don’t think it will be successful.

I take HP at their word that they will work with the open source community to set up appropriate licensing and governance. Unlike other firm-sponsored communities, letting go is not likely to be a problem.

However, open source only works when you have enough contributors. WebOS is not desktop Linux. Before a project launches, the best proxies are developer interest and user demand (“scratching your own itch”), and it’s no secret that webOS — although technically sophisticated — was already an also-ran when HP bought it in spring 2010.

The fact that when software has failed as a proprietary technology, it nearly always fails as an open source technology. From my research, I’d say a major reason is timing: firms don’t let go until the technology has clearly failed on the market.

The other problem that the world really only wants (or needs) a single open source product in each category. Eclipse was the first open source tools platform, so that Sun’s subsequent efforts to let go were too late (see #1 above). The BSD variants of Unix predated Linux but were swamped and the Netscape server never caught on against Apache. It doesn’t have to be all that open, as the success of MySQL (and Android) has shown.

(Some would argue that Chrome and Mozilla are an exception to this rule. Perhaps — but the competition is not over yet.)

In fact, with webOS HP seems doomed to repeat history — in this case, Nokia’s failed efforts with open source Symbian. In addition to being late and competing against Android, Symbian began open source life with a raft of problems that caused it to lose its once-dominant market share in the category it created. The prospects for webOS seem similar — except that webOS never had 60% of the global smartphone market.

Does webOS have a chance? Over a decade ago, Shane Greenstein and Tim Bresnahan showed that the only way a new platform succeeded was by identifying an unserved niche (that hopefully became a big market). So if webOS is going to succeed, the answer is the same as a year or two ago: not by competing head-to-head with Android and the iPhone, but serving a market that they’ve ignored. Since HP hasn’t found this market in the past 18 months, I can’t see how open source will change things.

Eclipse mobility

Ian Skerrett, marketing director for the Eclipse Foundation, stopped by SJSU for coffee this morning to catch up. Ian is in Silicon Valley for tomorrow’s “Eclipse Day at the Googleplex.” (registration closed July 26)

I’ve known Ian since 2004, but haven’t seen him face to face since our honors students studied key success factors for projects in the Eclipse community.

While Ian has stayed in the same job the entire time, Eclipse remains on the move. We talked about how mobile (along with cloud) is the current big thing in software development, and so far Eclipse is doing pretty well.

Eclipse has three of the big four smartphone platforms (five if you count Microsoft): Symbian, BlackBerry and Android. Apple (like Microsoft) has its own tools that for strategic reasons parallel its PC-centric tools.

It also also is used by all five of the traditional Big Five handset developers — Nokia with Symbian and Samsung, LG, Motorola and Sony Ericsson with Android. Motorola distributes its own MotoDev Studio, which includes both a custom package of Android tools and an Eclipse-based IDE for writing Java apps. Even Samsung's proprietary bada smartphone platform uses Eclipse tools.

In response to the increasing focus on mobile, Eclipse has created yet another TLA for yet another project: TMW (Tools for Mobile Web).

All is not sweetness and light. Since Nokia has decided to create its own tools to emphasize QT APIs on top of all its mobile platforms, this means that Nokia is moving away from a shared Eclipse platform towards its own proprietary one (like Apple and Microsoft).

Also, Eclipse is not a silver bullet (or life preserver) for companies with a failed business model or struggling to survive in a commoditized market segment. (Exhibit A: Borland). So there will be a certain amount of turnover inherent in both the composition of the Eclipse community and the sponsor-members who pay the bills to keep the Foundation running.

Still, Eclipse remains the exemplar for a fully open open source community — still comparatively rate, as companies find letting go is hard to do.

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.

MeeGo: Nokia and Intel learn to let go

For years, I was trying to figure out why the world needed two Linux-based tablet operating systems: Nokia’s Maemo and Intel’s Moblin. Almost three years ago, Intel created Moblin as a fork of Maemo and its Hildon UI (inherited from Symbian).

The reality was that the world didn’t need a forked niche mobile platform, but of course forking is the reality of open source. The changes may be available, but when not invented here and an unwillingness to share control get involved, corporate egos trump the nominal openness of an open source license.

The two factions have been flirting with cooperation but had been unwilling to consummate the deal. On Monday, they finally did.

In an announcement at the European cellphone industry’s global big tradeshow — Mobile World Congress — the two factions announced plans to merge the two code bases. As Nokia’s open source guru reported in his blog:

We’ve been busy with our friends @ Intel.

We decided to expand the relationship we started already last spring. We merge Maemo and Moblin projects into one single project called MeeGo. MeeGo is an open software platform – an operating system – for a wide range of devices. It’ll run on X86 and on Arm based hardware. It will be developed as an open project hosted by the Linux Foundation.

So what does it mean? Many things.

Joint development
We will merge Maemo and Moblin projects. Their architecture is already very similar. They share many components but sometimes use different versions. But they build and integrate releases independently. And while Maemo is for ARM, Moblin is for X86. Now we merge them to get the best of both. A good Moblin build and integration, Maemo’s mobile optimizations and ARM support, Qt etc. We can also now make the bright engineers of Intel and Nokia to work close together.

Of course, the announcement is less about saving R&D engineers and more about combining installed bases, APIs, ecosystems, and third party developers. Neither platform was very interesting on its own, but together the hope is Meego will be the future for both ARM and x86 devices. Both will use Nokia’s QT and Nokia will peddle applications via its (struggling) Ovi store.

More importantly, both Nokia and Intel let go, and turned control over to a neutral broker — the Linux Foundation. LF (like its predecessors OSDL and FSG) has plenty of experience contending with giant corporate egos.

The one thing that seems ambiguous is the positioning vs. the world’s most famous (quasi) Linux mobile platform, i.e. Android. Are sponsors being coy about avoiding comparisons to Android, or is this really an up-market alternative, between handsets and PCs? In an era of iPads and netbooks, will such distinctions remain a year or two from now?

Hat tip: tweeter David Wood, live from Mobile World Congress.

Google's half-full glass of openness

A number of experts have been remarking that the NexusOne brings Google into more direct competition with Apple and the iPhone, ending a once cozy and complementary relationship between the two firms.

Google’s mobile strategy continues to get closer to Apple’s. Both are peddling mobile platforms, seeking users, operators and third party software providers. While Google’s OS is open source — and available via multiple handset manufacturers — it still is a hybrid open/proprietary strategy that competes with Apple’s own hybrid strategy.

Some analysts understand this better than others. Dan Moren of Macworld portrayed it thusly:

By putting its name on the Nexus One, Google has given the Nexus One a sort of primacy on the Android front, unifying the disparate elements of the Android movement: now it’s Google going head to head with Apple, not a strange amalgam of Google, Motorola, and Verizon. It’s as if Google has promoted itself to head of the Rebel Alliance opposing Apple’s Galactic Empire.

Ooo, there's a value laden metaphor if there ever was one! (NB: In Star Wars III, Lucas is much more sympathetic to the Empire’s control problems than he was in 1977 with Star Wars IV.)

A much more accurate characterization came from John Gapper of the FT

Yet Apple is not as closed as Google portrays it, and nor is Google as open. Instead, like the proverbial half-empty glass, Google is best regarded as half-open and Apple as half-closed. That is significant because it shows how such companies need to compete in a networked industry.

Google is fighting for its own interests as hard as Apple does. That is, at one level, obvious since they are both public companies that try to maximise revenues. Yet its insistence on not doing “evil” and its dismissive view of Apple and Microsoft obscures this.

Gapper’s point is that even if Google’s OS is open, it plans to make money off these phones through its control of search. Gapper had earlier observed that mobile phone value capture had shifted from European telecom manufacturers towards US Internet companies (e.g. Google), as well as Apple.

I agree with Gapper’s overall point this week that mixed proprietary/open strategies are both normal and reasonable. I also share his aversion to exaggerated claims of openness.

However, in thinking about some of my earliest research on openness — ironically a 2003 paper about Apple’s early open source strategy — I think Gapper has only half the story.

Gapper focuses on how (to use my 2003 term) Google is “opening parts”. Its mobile phone OS is open source, but other parts of the value proposition (e.g. search, maps, mail, etc.) are proprietary. Google shares its code, but not is advertising revenues.

However, to use the 2003 terminology, I think it’s clear that Android is also “partly open.” Truly open sponsored open source communities do more than just provide source code, but also share in the governance and technical direction. Someday Android may be open, but it’s not there yet.

While Gapper talks about the openness glass being half full, I think an equally important point is that for many companies it changes over time, and differs between markets and products.

The two most proprietary companies in the PC industry, Apple and Microsoft, had various degrees of openness over time and across product lines. Among mainframe companies, IBM was once the captain of proprietary IT strategies, but in the past 20 years has moved to embrace open source and make lots of money off of services. Sun claimed to be open — and in relative terms it was — but still did everything it could to create switching costs and proprietary rents. (NB: Google CEO Eric Schmidt spent 14 years at Sun as a manager and eventually CTO.)

So I think that the only realistic way to view Google is as a self-interested, profit-maximizing, semi-proprietary company that embraces openness when it suits its purposes. Consumers should (and do) welcome that many of its ad-supported services are free, but continue to remember that Google wants to keep its repeat customers every bit as much as Apple, IBM and Microsoft do.

Truly open systems

Yesterday, the WSJ had a glowing article on the role that the public domain software VistA might play in the administration’s efforts to promote electronic health records.

The article highlighted a deployment of VistA by Medsphere of Orange County at Midland Memorial Hospital in Texas. The founders of Medsphere were working to land the Midland deal at the time I was a consultant to the company on its open source strategy. Promoting VistA was also the focus of the trade association I co-founded.

For hospitals that install VistA, they are not bound to any one company: as the WSJ article notes, there are multiple firms that can install and configure the VA software. Medsphere has also released some of its extensions as open source on SourceForge.
The Oracle purchase of Sun notwithstanding, I think open source has a particularly bright future in enterprise software for one reason: data portability. So much of what we do — whether memos in Word or elaborate customer databases — is reduced to information on a hard disk.

If the program that created it is open source, IT managers know they will always be able to get at the data, if by no other means than maintaining the open source code that reads it. If the format is proprietary and the software to read it is proprietary, then there is the strong likelihood that at some point the data will no longer be available — and the firm must hope that it can export or upgrade the data to some other format.

This issue also comes up at the personal level: I have PowerPoint 3.0 slides I can no longer read (which is why I save all notes in RTF format). But the availability of open source solutions is far less useful for a one-man individual or consultant as opposed to an IT department supporting a 1,000- or 10,000-person organization.

Sun bureaucracy rejects alien beings

My friend Matt Asay is reporting that MySQL CEO Maren Mickos is bailing from Sun Microsystems, a year after Sun paid $1 billion for the open source database company. This follows by four months the exit by one of the MySQL founders, and a goodwill writedown of sizable fraction of the purchase price. The other cofounder left last week.

Asay blames the departure on Sun bureaucracy

What Mickos doesn't say in the staff letter, but which I sensed in my conversation with him, is frustration at Sun's bureaucracy. As one of the most foundational personalities in open-source business, Mickos should have been given free rein to change Sun's fortunes. I don't think that he was given that freedom, based on other conversations I've had with Sun executives, and this clearly led to his desire to leave Sun.

There is no doubt that the Sun bureaucracy has been strangling the company since the end of the dot-com bubble, when it was perhaps hidden by Sun’s wild ride. While Asay refers to Mickos (who I met a few times) “the face of MySQL, but also of the rising open-source industry,” it’s clear that Mickos was never going to pull off a reverse takeover the way Steve Jobs did in 1997.

But I’d argue with Asay’s basic premise: Sun’s “open-source rebirth was just given a massive blow.” There was no rebirth and never would be. Exhibit A is Matt himself, who I met when he was the open source strategist for Novell. Novell did an exemplary job of acquiring Ximian and one of the open source industry’s superstars, founder Miguel de Icaza, and he still appears to be a Novell VP.

Linux revenues (from its SuSE acquisition) have grown to 16% of the company’s total in 2008. However, Novell hasn’t had a decent year since 2004, losing money in 2008, 2007, and 2005 (if you exclude the Microsoft settlement), and eking out a 2% profit in 2006 that was lost again in 2007.

If this is the best job of any incumbent in making the switch to open source, what hope did Sun have? (IBM is the exception that proved the rule: they had a senior exec who led a cultural shift nearly a decade ago).

So Sun may find its way out of the wilderness — even if the odds seem long. But MySQL isn’t going to do it, and I don’t think open source will either. Perhaps Sun’s future lies not in showing everyone it does commodity systems better than Dell, IBM or HP, but instead giving CIOs a reason again to pay a premium for its products. Apple’s done it in the consumer space, so perhaps Sun can pull it off for mission-critical enterprise IT.

Nokia's new subsidiary

Largely lost in the announcements at Nokia World is this press release

Nokia acquires Symbian Limited
December 02, 2008

Espoo, Finland - Nokia today announced that it has completed its offer to acquire Symbian Limited. All conditions to Nokia's offer to acquire Symbian Limited have been satisfied and it has received valid acceptance of greater than 99.9% of the total Symbian shares that Nokia did not already own. Symbian is the software company that develops and licenses Symbian OS, the market-leading open operating system for mobile devices.

The closing of the offer is a fundamental step in the establishment of the Symbian Foundation, announced on June 24, 2008 by Nokia, together with AT&T, LG Electronics, Motorola, NTT DOCOMO, Samsung, Sony Ericsson, ST-NXP Wireless, Texas Instruments and Vodafone. More information about the planned foundation can be found at www.symbianfoundation.org.

All Symbian employees are planned to become Nokia employees on February 1, 2009.

After 10 years, Symbian is gone as an independent company. Although the acquisition marks an important milestone to the plan announced June 24, the more important milestone will be (as noted) when the employees get all shuffled around and dispersed to Nokia divisions after Feb. 1. The bulk of today’s Symbian Ltd. — software engineers and associated QA and management — will presumably end up somewhere within handset R&D.

One major unknown (and for now unknowable) is how loyal Symbian handset makers (beyond Nokia) remain. Nokia’s always had a difficult time balancing its internal goals against attracting competitors to share an ecosystem. There have also been a series of one-off problems that seemed to jinx the other participants: Motorola’s ongoing saga, Sony Ericsson’s withdrawal from much of the world, and the emphasis of the Korean vendors on cool hardware rather than usable software.

Something that will be resolved sooner is the nature of the Symbian Foundation. The most successful multi-firm open source consortium is the Eclipse Foundation, which lists 17 names on its staff page. By my guess, this is a small fraction of those portion of Symbian employees that today work with the Symbian ecosystem — the “few hundreds” mentioned in a June interview.

Presumably the goal of the foundation (as with any consortium) is to be supported by a broad base of members rather than getting most of its money from one or two highly motivated members. Nokia will pay for a thousand employees (in R&D) but will its partners (with their smaller smartphone sales) pay for hundreds of foundation employees?

At Nokia World, Symbian Foundation executive director (designate) Lee Williams gave one of the keynotes. Williams was the obvious candidate, as a member of the (former) Symbian board and the outgoing head of Nokia’s S60 software development (a distinction that will go away once S60 and Symbian are merged). He also had experience as a manager at Be Inc. (the Apple spinoff) before and after it was acquired by Palm.

Alas, the first 15 minutes of the talk is exceedingly platitudinous, as executives seem wont to do with a large captive audience.

The useful part of the talk is the last eight minutes, beginning with the phrase "In terms of the goals of the foundation at a very concrete and practical level …” The basic message (in R&D speak rather then MBA speak) is that Symbian OS will leverage its economies of scale and scope to maintain its lead over all rivals. He emphasized three major goals

• A complete platform in 2009, and with it a more compete platform — in terms of devices, third party applications and platform maturity — than any rival.
• Hardware agnostic. 7 chipsets, 5 baseband modems, plus other chipsets and components
• “A real ecosystem” of a wide range of firms, small and large, with no one party advantaged

Obviously paying the Symbian engineers to keep updating the OS will work as long as Nokia pays the bills, and there should be some great improvements of efficiency and effectiveness after Nokia removes the Symbian/S60 schism.

The long term question is outside participation and financial support for the Foundation outside Espoo. In theory, open source should attract third party participation but in practice it rarely works that way: when a single firm sponsors an open source community, usually other firms choose not to participate due to a lack of accessibility. The IP may be open but the production and/or governance are not.

IBM gained outside supporters when it created Eclipse it created the open source Eclipse Project, but today that remains unique. Symbian was already fairly open — certainly as open as many standard consortia — and for now it’s not clear whether Nokia owned (with a smaller open source foundation) will be more open (in governance) than the previous arrangement.

How much did Sun lose on MySQL?

Sun Microsystems announced today that in its most recent quarter, it lost $1.67b on revenues of $2.99b. That’s a -56% net margin (if there were such a concept as negative margin), but only -5.6% without special charges. Compared to analyst expectations, the revenues were $150m low, as was the net income. Its gross margin also fell dramatically.

The NYT notes a consistent pattern of bad news

With falling revenue, problematic acquisitions, product slip-ups and a stock that has lost three-quarters of its value in the past year, the investment community is getting impatient with Sun’s management, including chief executive Jonathan Schwartz.

“Sun is a problem child, and the problem child has to change,” said Brent Bracelin, a hardware analyst for Pacific Crest Securities.

The Times estimates 40% of Sun’s total revenues come from financial services and telecommunications companies, two sectors that are now cutting back. Longtime CEO Scott McNealy was forced out 30 months ago because he never adjusted to the fact that the dot-com era was a one-time lucky break. So far, Jonathan Schwartz isn’t doing any better.

In today’s announcement, there is the minor problem of that $1.44 billion charge for “goodwill impairment” on unspecified business lines. There is no excuse for Sun’s obfuscation: the size of the charge is clearly material, while being truthful would not provide advantage to any competitor. Instead, it’s just management seeking to avoid accountability for its recent mistakes.

In particular, the presumption is that most (if not all) can be attributed to overpaying for two recent acquisitions, the $4.1b purchase of StorageTek in 2005 and the $1b purchase of MySQL (for 20x revenues) earlier this year.

On InfoWorld, MBA-touting blogger Savio Rodrigues estimated $2.48 billion in goodwill booked between the two sales. By his calculations, MySQL is 29% of the total, which (if pro rata is a fair allocation) would be a $420m charge on the purchase. Rodrigues reminds us that eBay took a $1.4b writeoff for its purchase of Skype.

The MySQL purchase was intended to give Sun a lynchpin role in the open source world. But the shift to get open source religion was too late. The acquisition isn’t going well for either side: Schwartz clearly overpaid by hundreds of millions of dollars while MySQL is being strangled by the Sun bureaucracy.

Maybe it’s a lack of imagination, but I don’t see where Sun can go and how they can get there — or that they would ever do it, even if they knew where and how to go. By comparison, Motorola’s problems look easy: at least they’re in a growing market.

MySQL integration going badly

Sun bought MySQL earlier this year, providing a great exit strategy for the world’s largest dual-license open source software startup.

Surprise, surprise: one of the (suddenly richer) MySQL founders, David Axmark, has jumped ship:

I have thought about my role at Sun and decided that I am better off in smaller organisations. I HATE all the rules that I need to follow, and I also HATE breaking them. It would be far better for me to “retire” from employment and work with MySQL and Sun on a less formal basis.

Official MySQL blogger remarks notes that this is a major loss for the MySQL product and division.

Of course, this problem happens with any acquisition of a little company rather than a big company. Still, the, 26-year-old Sun seems to be more hierarchical and bureaucratic than its younger and more nimble Silicon Valley rivals (like the Monster of Mountain View). And, unlike Cisco, Sun has either not mastered (or chosen not to implement) autonomy for its spinout acquisitions.

An antidote to iPhone complacency

My posting last night on Apple vs. Nokia got picked up by Seeking Alpha. It’s gratifying to get the exposure and discussion, although (as with any online discussion) the quality of the posts was variable.

Most of all, I was surprised to see the suggestion that I was too pessimistic on Apple. Readers of the Seeking Alpha site don't know me the way that my blog readers do, so let me fill in a few blanks.

I bought my first Mac in January 1984 and have never owned a DOS or Windows machine. I wrote a book on Mac programming and wrote columns or articles for 3 Mac publications. I started a Mac-only software company in 1987 and ran it for 15 years. Before the Jobs II era, we would have said "I bleed in six colors."

Today I'm a little more dispassionate as an academic strategy researcher. I did my PhD thesis on Apple losing market share in the US and Japan. I published a book chapter about why the conventional wisdom on Apple's cloning decision was wrong. Now I teach technology strategy to MBA students and consult to software companies.

My long history with Apple is EXACTLY why I think the ahisotric Apple bigots (particularly the iPhonatics) are missing the boat. In the 1990s, Apple had great products and technologies and still almost died. I know, I was there, and it’s why in 1993 I started looking for a new career to replace being a Mac ISV.

Yes Apple has had enjoyed a good run of innovation success. As I’ve noted earlier, in MP3 players Apple is crushing Microsoft and sells the vast majority of standalone MP3 players in the US. It also has dominant mindshare (again in the US) in smart phones.

However, when it comes to innovation, past performance is no guarantee of future success. Look at Apple in the 1990s. Look at Sony. Look at Ford or Chrysler or GE.

OK, some wiseass thinks because I make a blanket statement "don't stand still or (fill in the blank) will catch up," I don't know what I'm talking about. Would you prefer (say as an AAPL shareholder) that management says to the troops "We are so far ahead that no one will ever catch up?" Of course not.

Exhibit A is the old bumper sticker (and T-shirt) "Windows 95 = Macintosh '89". The problem was, Apple’s innovation (with the exception of the first PowerBooks) slowed to a crawl after System 7. Thus, Macintosh 89 = Macintosh 95 = Macintosh 2000.

Exhibit B is that 10x as many people bought Windows 95 as Mac OS 8, even though the latter provided a demonstrably better user experience. For Windows 3.1 the ease of use difference was dramatic, but for 95 it was not, and Windows 95 had other advantages: cheap hardware, more hardware variety, a larger potential installed base, more applications. Ease of use is important but it’s not everything.

A decade ago, Apple got crushed by Microsoft and nearly died. Today, there’s an even wider range of companies that could do to the iPhone what Windows 95 did to the Mac. What would it take?

First, Apple’s competitors would need to recognize what Apple has, and that it’s selling better. Nokia may be in denial, but I don’t think Microsoft or any of the major vendors in the US have missed Apple’s success.

Second, it would require the resources to apply to catching up to Apple. Samsung, LG, Microsoft and Nokia all have the resources to do so, and I think Research in Motion does too. In the short term, I’m ruling out Motorola and Sony Ericsson because their recent record on innovation is more dismal.

Third, it requires the ability to execute, in this case on software and user interface design. Obviously Microsoft could copy Windows and the iPod so there’s no reason that they can’t copy the iPhone. The other firms haven’t done well on software, but there’s no reason why they couldn’t procure that expertise. Maybe the gPhone is halfway decent. Or someone buys the PalmSource team. Or companies use the market to find some other open innovation solution.

Once LG or Samsung (or Nokia) has a decent alternative to the iPhone — particularly a CDMA phone — thanks to Apple’s foolhardy Cingular exclusive, the iPhone knockoff will have the upper hand with a majority of the market. The Koreans and Europeans will also have an advantage in their home markets where the iPhone has had a much smaller impact, in addition to the global economies of scale that Apple currently lacks.

Finally, other firms catching up to Apple will only happen if Apple is still roughly the same place when others match Apple’s existing offerings. Sure, Apple is on a roll, and as long as Steve Jobs remains savvy and healthy, their odds look good. But it’s not a lock.

Remember Netscape Navigator? The Motorola flip phone? The Sony Walkman? The Chrysler minivan? (The Boeing jumbo jet?) In many cases, a revolutionary product is all about the concept, and a concept can be copied. It’s not just about innovation activities, but also about the potential for those activities (as Geoff Moore argues) to achieve separation. If you can’t achieve separation, we call that commoditization. (NB: MCI, AT&T, the airlines, banks, or enterprise software vendors).

So I wouldn’t short Apple, but I also wouldn’t bet any sizable sum that all of its competitors will be asleep at the wheel for the next three years. And if Apple management shows signs of being as complacent as the Seeking Alpha iPhonatics, then sell! sell! sell!

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.

Built to Last

I was sorting through old newspapers in the pile to read and found a column from the Merc that struck a nerve. Normally, business columnists are either shallow and superficial, or opinionated with conclusions not supported by the evidence presented (let alone reality). This was definitely neither of those cases.

The May column by Chris O'Brien refers to a speech by utility executive Jim Rogers:

Rogers described how he has embraced something called “cathedral thinking” and he was calling on the Valley to join him. I cringed at first mention of the term, worried that he was going to digress into some awkward religious metaphor.

(I’m not sure why O’Brien automatically assumed a religious metaphor would be awkward. Has he not heard of The Cathedral and the Bazaar, a metaphor embraced by as irreligious a bunch of geeks as you’ll ever find?)

Fortunately, O’Brien listened long enough to get the full story.

Rogers talked about a recent visit he’d made to Europe where he visited a number of the great cathedrals. It struck him that the person who often envisioned these great buildings didn’t live to see them built. Instead, they articulated a powerful vision that galvanized people to work on something that took generations to realize.

Rogers is proving the timelessness of two well-understood principles of effective business (or military) strategy. One is a long-term vision of what needs to be done; the second is creating a strategy (or perhaps just a culture or a set of enabling competencies) that will bring that vision to fruition, even if it’s long after the strategist is gone. This latter point is the theme of the Jim Collins bestseller. Bill and Dave certainly had it, Tom Watson Jr. had it, and I suspect (in their own narrow self-interested way) Gene Kleiner and Tom Perkins had it too.

The American political system is seriously broken by the exact opposite thinking Solving a real problem (like homeless people, failed public housing, structural budget deficits, social security) is important for society but too hard for politicians – so they don’t try. Instead, they “kick the can down the road” on these problems and find some symbolic quick victory (like televised hearings) to get re-elected one more time. Duane Delacourt, Doonesbury’s fictional “secretary of symbolism” for President Carter and then Governor Moonbeam, is now no longer exceptional enough to be worth mentioning.

Similarly, today’s CEOs want to string together 10 or 15 quarters of increasing earnings by a penny each time, so they can be handsomely rewarded for sandbagging their objectives before they are sacked. And VCs want to flip a company onto some greater fool before anyone is the wiser.

The occasion of the column and Rogers’ visit was a party commemorating the birthday of a 20-year-old startup, Echelon Corporation. Echelon had an unusually patient management team and board of directors; today its Pyxos embedded control platform appears to be both technologically ripe, and to have found a timely business need —managing industrial, commercial and residential energy usage. The IRR is probably not impressive for the venture investors, but the vision of the CEO and late COO have been validated — and the world is a better place for it.

Symbian's new ecosystem

Today Symbian officially announced its new ecosystem program, the Symbian Partner Network. The new program is available now and the old one goes away next month. Existing partners were briefed under NDA last April but the announcement was delayed until June (and then July) to allow time for the transition.

David Wood (author of DW2-0) was quoted this morning as explaining the new program to IDG. The main differences are that the program cost $1,500/year instead of $5,000, and that the service is increasingly automated (to improve scalability and reduce costs).

Obviously things have changed with the Nokia buyout, and it's not clear what role the program will play before or after the transition to Symbian Foundation (which will have its own similar or different program).

Still, the program may live longer than the predicted 6-9 months. Due to third party licensed code, Sun required much longer than anticipate to release OpenSolaris as open source, and among the 30 million lines of Symbian OS code similar problems are certainly lurking. So even with a Symbian Foundation, the disclosure of OS code may be covered under NDA for a little while longer.

There is also the question of whether Nokia really is in any hurry to release the code. Both Google’s open vaporware alliance and LiMo are today walled gardens rather than open source projects. And I don't know how much pressure there is for openness: LiMo has just swallowed its main European competition, LiPS, which agreed last month to be folded into LiMo.

Nokia also has thus far not understood open source software, at least at the level where decisions are made. There definitely are people at Symbian who do understand, and others in a position of influence who are trying to get it.

If/when Symbian eventually does go fully open source, it will be a very different world than today for the Symbian partner network. The current network is managed through contractual restrictions on access to source code — which are more generous than most proprietary software, but obviously less flexible than an open code repository like Apache or Eclipse.

Also, combining S60 with Symbian OS under one roof (and killing the other UIs) will bring together the entire Symbian stack, to compete directly with the integrated Windows and Linux stacks. Thus the platform (and the partner relationships) will look more like any other OS platform strategy (except of course for the open source part).

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

Sun’s not so bold strategy

The headline on the front page of this morning’s Merc was about airline nickel-and-diming, but the lead headline on the business section was

Sun’s Strategy
‘bold’ and ‘risky’

I read the story — about Sun’s use of open source — and there was nothing bold about it.

Yes, Sun overpaid in blowing $1 billion on an open source database company that only generates $50 million/year in revenues. Perhaps I’d call that decision ‘bold and risky,’ but that’s old news.

What about open sourcing the rest of their code, including Solaris and Java? Sure, it would have been bold in 1998 or even 2001, but in 2007 or 2008? Not hardly.

By the time (2003) when we were doing our paper on Linux adoption, it was clear that Unix was being commoditized, and that cost-conscious buyers were increasingly unwilling to pay a premium for Sun’s products. Sun reminds me (to a lesser degree) of Digital Equipment, who came to us in March 2004 for advice on open sourcing OpenVMS (which they never did). As with DEC, Sun’s potential to capture the imagination of the industry (particularly software companies and major IT buyers) through open source has long since passed as every big company now has some sort of open source strategy.

The opportunity was when Sun led the industry. I remember back around 1996, I asked one of the IT guys at UCI whether he’d recommend FreeBSD or Linux. Ben said that FreeBSD had better technology, even if Linux got better press. While FreeBSD was good, Solaris was the industrial strength BSD variant that Unix sysadmins preferred. Even through 2000, Solaris was known to be superior to Linux by key IT buyers, so there was still a window to prmote an open source Intel Solaris using a paid support model, ala Red Hat.

Instead, Sun — like other established firms with established software revenues — worried about cannibalization more than growth of adoption, and watched open source rivals grow their share while Sun’s paid products occupied an every smaller niche. Sun worried too much and too long, given (as the Merc notes) it makes two-thirds of its revenues from hardware — and that it also makes significant revenues from services. As IBM has shown, both hardware and services revenues are helped by giving away software, and are helped even more by establishing your software as an industry standard through open source adoption

Is the headline right about Sun’s current strategy being ‘risky’? Sure it is, but not doing anything is certainly riskier. Sun once led the Unix and network computing industries, and has been unable to adjust to its post-bubble drift towards irrelevance. If it doesn’t do something to grab mindshare and marketshare, it will be like Cray and SGI and Data General (and eventually DEC), occupying a ever-smaller niche.


I still think Jonathan Schwartz has a plausible strategy. The problem is, the strategy isn’t working. After running up to $25 last fall, the stock is now near $13 — below where it was three years ago. Its shares fell 23% earlier this month the day after it announced an unexpected loss — missing expectations by 22¢/share.

A mighty Fortress...

At JavaOne last week, Sun updated the world on Fortress, its Java-based programming language for massively parallel processing. It’s consistent with Sun’s view of being an innovator, rather than a low cost commodity supplier.

The program from Sun’s Programming Language Research Group was originally developed using DARPA HPCS (nee High Performance Computing) money, and then with its own dollars.

For most of the past decade, Sun missed numerous opportunities by trying to control Solaris and Java rather than win adoption through open source. Given Sun’s origins as an “open systems” supplier, its failure to embrace openness was perplexing, in the face Linux at one extreme and Microsoft at the other. However, this time the prototype Fortress interpreter is already released under a combination of BSD and GPL licenses.

About 20 years ago, I was a programming language geek, working on compilers and programming language design, including some ideas about language design for one of the earliest massively parallel computer systems, the JPL hypercube.

At the time, the most radical programming language effort was Occam, intended for the Transputer processors. It was interesting to note that Sun Fellow Guy Steele acknowledges Occam in an interview about the Fortress efforts.

Having the smartest people in the field in house (like Steele, co-inventor of MIT’s Scheme language) is the path to differentiation through innovation, and having your own people implement the language is the surest path to make sure it works well on Sun hardware and software.

The problem is adoption. Historically, network effects have been the death of specialized languages (coming from the inventor of a specialized language). People would rather work with libraries wrapped around standard languages (like Fortran, C, C++ or Java) than learn a new language. So major breakthroughs like APL, Simula, Simscript, Smalltalk, Scheme and Occam were used to teach programming, but were rarely used to solve real program.

So the challenge will be to make Fortress the standard language for massively parallel systems — first at DoD and DoE research labs (like LLNL and Oak Ridge), then for government studies and analysis, and finally for computing-intensive industry problems like biotech and oil exploration).

To become the standard, Sun needs the cooperation of both the user and vendors of massively parallel computers. It doesn’t have any computers on the Top 10 (of the Top 500) supercomputers, which is dominated by IBM with other systems from Cray, HP and SGI. (Sun only has one machine in the top 50). So, as with any other standards-based competition in the industry, good technology is only valuable if it leads to adoption, tipping and network effects — and much of the adoption is driven by politics and alliances rather than the quality of the technology.

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.