“To understand our position in more detail, it helps to start with the assertion that open systems win. [...] They are competitive and far more dynamic. In an open system, a competitive advantage doesn’t derive from locking in customers, but rather from understanding the fast-moving system better than anyone else and using that knowledge to generate better, more innovative products.”

This sounds great, doesn’t it? But the premise, that competitive, dynamic markets generate more profit, is inherently untrue. Competition and rapid change sap profitability. It costs a lot more money to win when lock-in is impossible. When all you’ve got to beat your competitors is brains and hard work, you have to continuously invest big money just in staying ahead.

Gartner’s Brian Prentice offers a pointed analysis of Rosenberg’s article, in which he sums up the revenue picture quite well:

“The truth is that closed systems still win. Open systems, practically speaking, are basically good for making others lose.”

True, but also misses the key point. Google is not trying to crush their competition in search advertising: they already have.  Their biggest problem isn’t competition, it is market saturation. The market for search advertising can only grow as fast as the demand for searching, which in turn grows along with the use of the Internet, and Google’s ability to index ever more of the Net. Another way to put this, is that Google’s addressable market is driven by adoption of the Internet itself.

“Open” is an incredibly important strategy for Google, because it drives greater adoption of the Internet. The money quote from Rosenberg:

“Our commitment to open systems is not altruistic. Rather it’s good business, since an open Internet creates a steady stream of innovations that attracts users and usage and grows the entire industry.”

Bingo. Google understands the adoption-led business strategy better than any other enterprise today. With their enormous scale and technological might, they relentlessly develop new, seminal Internet infrastructure that digitizes and shares more and more of the world’s information. And then they open that infrastructure. Remember: they don’t sell maps, books, document storage, music, collaboration, or mobile phones (yet). They sell search advertising. The more adoption of the Internet for accessing all of these newly digitized artifacts, the more and better targeted search advertising they can sell. They don’t sell the things they open, they sell something else that scales with adoption of the open stuff. That is the genius of Google’s business model.

Google doesn’t do “open” to compete. They do “open” to drive adoption. But if you sell something that Google offers for free, tough luck! It sure feels like competition! Google Docs feels like competition to Microsoft. Android feels like competition to Symbian and Palm. Chrome feels like competition to Mozilla, and Google is Mozilla’s biggest benefactor!

Rosenberg says that “An open Internet transforms lives globally. It has the potential to deliver the world’s information  to the palm of every person and to give everyone the power of freedom of expression.” He is absolutely right. But Google doesn’t do “open” because it is some benevolent force for the good of humanity. But if closed and bare-knuckled competitive warfare would drive more adoption of the Internet and thus more search advertising, Google would be doing that instead.

Another quote from Google’s article:

“We can do these things because they are information problems and we have the computer scientists, technology, and computational power to solve them. When we do, we make numerous platforms – video, maps, mobile, PCs, voice, enterprise – better, more competitive, and more innovative.”

Why won’t Google, in the spirit of transparency, tell the truth, which would read something like this (my words, not theirs):

We do these things because we need more and more of the world using the Internet in new and different ways, so we can sell more ads and continue to grow. We’re genuinely gratified that doing so makes numerous platforms – video, maps, mobile, PCs, voice, enterprise – better and more innovative. We’re not trying to compete in these areas but the effect of our adoption-led strategy is to make it very hard for others to make money doing these things. Still, it is fortunate for both end-users and for us that Google’s search ad prosperity is driven by Internet adoption. We reap great rewards for delivering awesome technology and information to the world, for free!

Those are my words, not Jonathan Rosenberg’s. But really, wouldn’t a transparent explanation of their business model be a better message?

“We have to get over this idea that open-source software will produce companies that look just like their proprietary counterparts. I owe much of my career to venture capitalists, but if they are expecting the same returns from the proprietary software portfolio’s that they had in the 1990s they are crazy.”

Exactly true I think. Chris Anderson’s “Free – The Future of a Radical Price“, posits that you can make plenty of dough pricing your digital assets at zero. Much of the pointed criticism of his book point out the brutal truth: there aren’t many examples of this working, outside of a few well-known famous examples that are very hard to copy.

The software industry is fast consolidating, commoditizing, and morphing into a mature industry with low margins and competition based on partnerships, product line extensions, and marketing, rather than technology and innovation. Software is no different than any other industry in that regard. It is an inexorable fact of life, driven by the structure of the world economy and the nature of technology diffusion. But FOSS accelerates and institutionalizes this rapid maturation. Free, the price, is a direct consequence of Free, the licensing  paradigm. This fact should change our expectations, shouldn’t it? Has it changed yours? Or do you think there is plenty of room left to monetize innovation and technology in the wide world of software?

“I do think that with great power comes great responsibility, and Google could truly be a much better community participant than it currently is.”

Here’s a few of his issues that I’ve spun into recommendations, generalized and refactored:

• Be stable: Establish a release “heartbeat” for your code base, with declared, numbered snapshots that are feature complete for a given version, tested and supported for a reasonable time with patches and bugfixes fixing big bugs or plugging security holes.
• Divide and conquer: Engineer your large project as a bunch of independently developed, valuable piece parts each of which has stable releases (see above bullet). Why is it good for the whole to be built from smaller independent projects? Because those independent chunks might be useful in and of themselves in other FOSS projects, and because the independent project approach ends up being more maintainable, and thus supports more participation by a more dynamic community.
• Participate: If you’re going to use someone else’s code, join their community, participate in their process, and contribute to the overall FOSS ecosystem you’re relying on. Do not take code from other projects, makes custom changes, and include the hacked upstream code without giving back to the upstream project through participation. Bad karma! And doing that also obligates you to maintain your custom hacks – so give back those changes!

There are a ton of reasons you might not want to do all this stuff. It can slow you down. It can cost you $ and resources. It can make your binaries run slower, be bigger, come out later, and be less competitive. Good karma is hard work, and entails compromise. It isn’t a slam-dunk that you should always maximize your community participation at the expense of other objectives. Its a hard decision, with real trade-offs. As Evan, one of the Chromium developers says in a comment to Tom’s blog post:

“I think the shorter answer is: you demand a huge amount of work for minimal benefit for “upstream” (Chrome), so while various bits of the work are underway it’s not going to happen quickly. Each of your bullet points is of the form “X ought to be Y” but none mention why that is useful (or if it is useful, why it merits the amount of work involved). *shrug*”

Ok, so following all the rules to be packaged with Linux distros can be hard to justify, even for a company as culturally committed to open source, and as resource-rich as Google. Why do it then?

• Your business model scales revenue with platform adoption.
• You’re in a market with network effects that make it so only a few competitors at most can survive, and only one really wins.
• Adoption of your platform depends on it “just being there” when sophisticated, influential developers need its features. In other words, when you need to be distributed with Linux distros.

If you don’t have an adoption-led model, if your market values “best” more than “easy” or “standard”, or if your platform is for a niche, a vertical market, or targets a proprietary foundation, then the costs of being a good citizen may outweigh the benefits. Or if you are one of the very few companies like Google with so much market power that rules don’t apply to you, and the community will swallow hard and adopt your platform anyway, you can cut corners on community participation.

Do the analysis, but understand that having good karma is often pretty much a binary thing. Either you are doing the community dance and you’re trusted by developers to be transparent and participatory, or you’re not. Factor in all the costs, consider the opportunity that monetizing your platform offers, and make a decision. Either pursue an adoption led strategy, or don’t. If you decide that you can’t afford community, then make that choice clear to everyone. Developers might regret that you aren’t adopting an open model, but they can respect that decision. What they can’t abide is you trying to fool them that you’re serious about open development -  inviting them to participate in your community, but not giving back to theirs. That is the epitome of bad karma.

How does Google get away with it? They’re a very sophisticated community participant and understand all of this in great detail, and make considered choices on just how they’re going to participate, and they invest a lot in community. They get cut some slack because they mostly do the right things, and they listen. Oh, and because, well… because they’re Google.

When is community part of your DNA? No magic here – it is like everything else: when you plan and budget for it, and goal and measure your staff by their participation. There aren’t any shortcuts, and you can’t have it both ways. But once you’ve really thought through your adoption-led strategy and made the decision to see it through, you will wholeheartedly execute that strategy knowing that the rewards justify the costs.

Want to know how to send your karma quotient into the cellar? Turns out it is startlingly easy to blow your foot off.

Case in point: the Symbian Foundation, established by Nokia as an independent entity to manage the open source Symbian mobile OS code base. Back in June 2008, Nokia bought Symbian, Ltd. and the OS, and simultaneously, they, along with several other OEMs and carriers, started the Symbian Foundation, announcing a project to open source the whole platform under the Eclipse Public License. Fast-forward to October 26, 2009, when the foundation announced the microkernel source code’s release as open source:

The kernel release is nine months ahead of schedule and reflects the positive momentum behind Symbian’s ambitious platform migration plan, which began with the release of security code under EPL.

16 out of a total 134 platform packages have now been released into open source since the code was first made available on the Symbian Foundation servers in April 2009.

Wow. 16 months after announcing they’re going to open source the platform, they’re up to almost 12% of the modules and ahead of schedule! Sure, it is hard to open source previously closed source code. Sifting through all that code, figuring out who owns the copyright, and cutting licensing deals for these encumbered bits of source or writing clean-room replacements is a thankless and difficult task. But have the stewards of Symbian noticed that they’re in a white-hot competitive market for pride of pocket in smartphones vs. the likes of Apple, Google, RIM, Palm, Microsoft, and a host of other competitors? The Symbian OS has the market-leading position today thanks to Nokia’s market share outside of North America – 48% worldwide. But Android and iPhone are growing by leaps and bounds, largely at the expense of Symbian and Microsoft’s Windows Mobile. Actually, this fact is not lost on Symbian’s backers. Sony Ericsson is launching the Xperia X10 Android-based multimedia smartphone in early 2010. Samsung, according to Korean investment house HTC Investment Securities, is going to ditch Symbian completely, focusing on Android and their own Bada platform, announced today. Even Nokia is hedging their bets, with their new, hotly anticipated N900 tablet running the Maemo mobile Linux platform, and not Symbian OS.

Not pretty. What to do? Savage your competition – another open source project (and a very popular one at that!) … well, perhaps thats not the best strategy but it is what Lee Williams, Symbian’s executive director chose to do on October 23, in this interview with Om Malik of GigaOM. You know you’re in rough water when your interviewer interjects “you know you are on camera?” to throw you a life ring.

The funny thing is – Williams is right. Google is so hands-off with how Android is being deployed, that the parochial interests of handset vendors are trumping the need for consistency, creating fragmentation that could derail Android’s platform adoption momentum just as it is gathering speed. But for Williams to poke at Android’s multiple UI skins when Symbian has S60, UIQ, and MOAP interfaces requiring developers to port across these interfaces and also across carrier and handset differences is a case of throwing stones in a glass house. A few lessons:

1. Don’t diss other open source communities. Developers are looking for signs of cooperation and community, not corporate style competitive trash talk. Even if you’re right, you don’t win respect with such tactics, you just look desperate.
2. Don’t blast others for issues on which you are as bad, or worse. You just look silly, and developers lose respect for you, because they know you’re trying to pull the wool over their eyes.
3. Don’t announce a grand gesture aimed at securing developer interest, and then drag your feet, or even worse, renege on your promise. Developers don’t care about your excuses. They know things are hard – so what? As Yoda said, “Do, or do not. There is no ‘try’.”

Is Symbian a lost cause? Not at all! They have the largest market share of any smartphone platform, and outside of North America the OS is a strong player. Here are some headlines that the Symbian Foundation could deliver that would create good karma:

“Symbian revamps tooling, SDK, simplifies development model, based on community input and contributions.”

“Symbian Foundation funds accelerated open source project to build automated Android to Java ME porting framework, adopts Android API as alternative programming model.”

“Low-cost embedded device manufacturers standardize on Symbian on a chip design; create ultra-high volume ‘brain’ to add intelligence and style to everyday products.”

“Symbian Foundation eliminates ‘Symbian Signed’ program, creates industry leading free application QA process with guaranteed 7-day approvals, transparency.”

“Symbian Foundation completes open sourcing of the Symbian platform through unprecedented community contributions of unencumbered APIs; surprising shift to cooperation praised by enthusiastic developer community.“

All of these possible headlines have one thing in common: achieving them would require real commitment, investment, and hard work. It isn’t just what you do, its how you do it that generates good karma. Including developers in decision making, valuing their contributions, and leveraging their goodwill are vital. Solving real-world problems facing developers and helping them innovate and succeed are essential. If you do not do these things, your competition will.

How obvious! And yet how hard to put into action. Why? Because trust is earned over time, with consistent, principled behavior that values long-term success over short-term profit. And trust is so easily trashed – one shortsighted decision, a few ill-conceived words, and you’re in the doghouse. Wreck your karma and you’ll be rebuilding that trust you so swiftly demolished, and maybe never getting it back.

I hear you saying “Yeah yeah of course! Developers trust us! We’re the good guys!” But are you? Turns out that the very things that developers look for as markers for mistrust are often the things you do to make money. And actions speak louder than words.

Remember Movable Type, the once popular blogging platform from Six Apart, Ltd.? Back in the day, MT was the bee’s knees. Six Apart had always offered a free version, allowed users to modify the code, hosted a public repository, encouraged contributions, patches, and plugins. They built a community of passionate developers and users who enthusiastically recommended MT to their friends, and helped create a groundswell of adoption. That is how it is supposed to work! Six Apart was the leader in blogging tools, launching TypePad (hosted blogging) and with leading market share in both self-hosted and hosted service blogs, because they were the good guys. Because they painstakingly had built their good karma.

Then on May 13, 2004, developers and users woke up to discover they’d been fooled. MT 3.0 was still free for one author and up to 3 blogs. More than that, and you had to pay. Whats wrong with asking for money for something valuable like blogging software? Nothing, unless you have built your large, enthusiastic developer and user base on a promise to make MT free, with source code, and then once they’ve adopted your platform you renege on that promise. MT 3.0’s passionate community felt duped. Their passion turned to scathing anger and disgust. They had trusted Six Apart, and that trust was destroyed with one ill-conceived decision, born of the need for Six Apart to monetize their hard work.

That’s bad karma.

With the 3.2 release, Six Apart restored an unlimited number of blogs for all licenses. With 3.3, MT was once again free for unlimited non-commercial use. Still not enough…. on December 12, 2007 Six Apart relicensed MT as Free Software under the GPL. But the damage was done.

Where did MT’s community go? Mostly to WordPress, which was far behind MT but rapidly caught up in features and sophistication. WordPress has been under the GPL license from day one. There are over 7000 plugins that extend it in almost any way imaginable. All plugins in their repository are GPL or compatible with GPL and open source. The WordPress community is enormous. Customizable themes can make WordPress sites look like almost anything you want (disclosure – I use WordPress for this site). WordPress is Free Software but the leading hosted WordPress service – wordpress.com – is run by Automattic, Inc., who’ve established a fast growing business built on making WordPress effortless for the non-technical blogging world. Automattic is a key contributor to the WordPress project itself which, with three releases/year is accelerating its innovative pace and developing an aura of cool as it is used by marquee Web 2.0 commentary sites like GigaOm and TechCrunch.

How is Six Apart doing now with their karma? A blog back in March 2008 by their chief evangelist, titled “A WordPress 2.5 Upgrade Guide” opens with the line:

As you might know, WordPress 2.5 is about to be released, and we wanted to encourage WordPress users to upgrade. To Movable Type.

More bait and switch. This time, baiting WordPress users trying to upgrade with an article bound to pop up in search results. That kind of bare knuckle competition may seem like business as usual but in the developer world, where cooperation and community are valued above all else, it generates more bad karma. Many comments to the post had this flavor:

Comparing your product to a competitors by putting them down is not going to hold you in good stead (as I’m sure you’ve seen by now by the posts on TechCrunch and Twitter conversations), even though you might feel the need to make direct comparisons to pull people.

Another example, this time about Six Apart’s hosted service, TypePad in a comment to Mashable’s October 2009 “Blogging Faceoff: WordPress vs. TypePad” article (in which WordPress got an overwhelming 87%, TypePad 9%, and 4% called it a tie):

My big beef with TypePad is that, when I switched to WordPress, TypePad held my graphics hostage. They would not allow me to transfer them with the other content in my blog.

More bad karma.

But what does all this have to do with adoption? Does it really make a difference? See for yourself:

TypePad vs. WordPress.com (hosted blogging)

Movable Type vs. WordPress.org (blogging platform)

Ok, visitors doesn’t equate to platform adoption. But even the most jaded metrics maven would likely conclude from these statistics that WordPress in both cloud and platform versions is trouncing Movable Type.

If you think that platform adoption is critical to your ability to make money, you ignore your karma at your peril.

Thanks to Dalibor Topić for the example idea used in this post. Now there’s a dude who really has good developer karma!

Bill walked the audience through an economic argument as to why the most successful app developers will target multiple platforms, not just the iPhone. He’s right – if you’ve got the money, the scale, the know-how and sophistication to manage a big porting and test matrix, a lot of partner programs and distribution negotiations. His point is that the more handsets and end users you can target, the more money you can make. But there comes a point of diminishing returns, even with automated porting and testing tools. The question is not how much revenue you can pull in, it is how much profitable revenue.

Jason Jacobs, founder of RunKeeper and a successful iPhone app developer was also on the panel. When asked about his plans to port RunKeeper to other smartphones, he said he’s thought about it but right now is quite happy with his success on the iPhone. Jacobs says that the fastest route to greater profit for RunKeeper has been to expand his existing market through community building features, global reach, and product extensions to new sports and training methods. For RunKeeper, the point of diminishing returns has already been reached with just one target platform. Jacobs did not rule out porting to other platforms in the future, but he’s focused on profitability, not just maximizing revenue.

The iPhone is different from BREW in some very important ways. BREW has always been perceived as tied to Qualcomm’s CDMA-centric focus and to Verizon Wireless in particular. The iPhone is on the most broadly deployed network technology – GSM. The BREW certification process is perceived as complex and costly, designed to facilitate operators’ “walled garden” models. Verizon Wireless’s announcement today of a Google/Android partnership points to the end of that sorry era. While the App Store approval process gets dinged for being arbitrary and opaque, for most iPhone apps it is fairly smooth sailing by comparison. And lets face it – BREW never has had sex appeal – targeted at more low-brow feature phones. The iPhone fairly reeks of it. In an earlier post, I’ve talked about some of the ways the iPhone is disrupting the mobile ecosystem. You can see that disruption in action, watching Apple and AT&T’s competitors scramble.

The iPhone adopted the best elements of BREW: nearly zero fragmentation and integrated distribution, and ditched the bad bits – narrow network, small subscriber footprint, weak marketing and branding. Android has adopted both the best and worst elements of Java ME – broad footprint, open platform, fragmentation and a “wild west” competitive landscape.

Bill Scott said that fragmentation is an inevitable cost of the mobile marketplace, and that successful developers must just learn to live with it. With over 2 billion apps downloaded, Apple is disproving this bit of conventional wisdom. Google needs to manage their platform’s “diversity” if they hope to catch Apple in this very new world.

Several great blog posts from Simon Phipps (I commented), Stephen Walli (I also commented), and Matt Aslett debate the question of whether there is such as thing as an open source business model. Everyone agrees – vehemently – that there is no such thing. But this whole debate on what you call business models involving giving away software for free misses the point.

Open source has accelerated the commoditization of software. If you’re competing with an open source code base, it won’t be easy for you to charge a license fee. You can offer commercial service and support, training, professional services, blah blah but Red Hat, the poster child for this model, reported $650M in revenue this past fiscal year. Oracle, at $23.3B revenue, is nearly 36 times larger. You can make a tidy sum with this approach but you probably aren’t going to be the next Google ($21.8B and they give their software away). Realistic expectations are in order.

It doesn’t matter what you call it. Making money giving away software isn’t easy. If it was, there would be a lot more Googles and Red Hats out there.

This is causing some consternation among open source and free software advocates, who are concerned mostly about MySQL falling into Oracle’s clutches and being summarily dispatched. I’m not savvy on open source DBs so I’ll leave commentary on that one to those who know something. What might happen to Java though?

Ars Technica’s Ryan Paul thinks Oracle will be good for open source Java:

Sun’s dictatorial control over the evolution of Java has been widely criticized by other stakeholders and is generally viewed as detrimental to the language’s growth and adoption potential. The Java Community Process (JCP) has been a particularly thorny source of controversy and friction.

Oracle could finally democratize the JCP by making it more transparent and inclusive. Sun’s overt hostility towards the Apache Software Foundation’s Harmony project, which seeks to build an Apache-licensed Java SE implementation, could also finally be brought to an end.

Bad, bad Sun! Now the community can rejoice! But wait… Here’s Glyn Moody of ComputerWorld who thinks overall it will be good but perhaps not so great for open source:

The downside is that Oracle’s feelings about open source – and hence its advocacy – are probably more ambiguous than Sun’s. In particular, it seems to have very little truck with the more idealistic leanings of the free software side of things. Pragmatists might rejoice at that, but it does mean that Oracle will be aiming to use open source as a tool rather than see itself as an evangelist with a mission to convert.

Canonical’s Mark Shuttleworth, in a report on a press conference after the Ubuntu 9.04 launch, is sanguine:

“I’m sure Oracle has carefully thought through everything it committed [itself] to [and] there will be no reversal of the idea that Java should be widely available and available as open source,” Shuttleworth said during a press conference today to launch ubuntu 9.04 upgrade.

“It’s a one-way trip,” Canonical chief said about the process of making software open source. “What is interesting [about the Oracle-Sun deal] is that it really cements the idea that free and open source software is the profound driving force in software today. ”

Shuttleworth is correct. Once a code base has been open sourced, the community has the power to take the code and run, if they don’t like the direction a project is headed. Having had first-hand experience with the power of community thought leaders to influence even Java, the largest and most corporate of code bases, this is a lesson Oracle will learn. Either they’ll learn it the hard way, or they’ll learn it from people at Sun who understand this stuff deeply, and whose expertise could save Oracle a lot of trouble.

Redmonk’s Stephen O’Grady sums up the most likely scenario of all:

However the politics resolve themselves or not, though, the Java landscape is characterized as much by its inertia as anything else. Ergo any potential shifts in the landscape here are likely to be glacial in pace. I’d expect something very akin to the status quo for the foreseeable future.

Time – lots of it – will tell.

There is a heckuva big investment in Java software across the IT industry, and so it is interesting to think about where this platform might go if Sun, the inventor and “steward” of Java, gets swallowed by IBM, the company that has made the most money on Java over the years.

IBM has bet a big piece of its software strategy on Java. A long-term licensee, IBM has been a leader in the JCP, built and then contributed to open source the most popular Java IDE (Eclipse), has long marketed one of the leading Java-based middleware product lines (WebSphere), and builds lots of well-regarded Java plumbing, including virtual machines, Java EE implementations, tools and embedded versions – the works. Even as IBM and Sun have cooperated in promoting and advancing the Java platform, they’ve competed on implementations and have at times not seen eye to eye on where the Java standard should go, and how the platform should be governed.

Sun’s software strategy over the past few years has been to intensively open source its marquee software platforms, including Solaris, and Java, in order to drive platform adoption by developers. Sun’s FOSS platforms are free as in – zero cost to acquire, and Free – as in, built by a community of developers and licensed to eliminate proprietary lock-in. The hope is that developers, and the enterprises they work for, will adopt Sun technology as the plumbing on which they build their critical business applications and processes if acquisition cost is zero, and their investment in time and effort are protected. Once ready to deploy, some fraction of these customers may choose to buy support. Oh… and gear to run it on – software DOES still require a computer to run it, even in the cloud.

All of this is spelled out in Jonathan Schwartz’s blog, and is party line and marketing message. But there’s a bit of subtlety that isn’t apparent until you actually try to use the FOSS Java code, especially in embedded applications. Sun has done well over the years licensing its Java ME software to those building devices. The company has a legitimate business interest in maintaining these significant licensing revenues (pdf – see pg. 6). The GPLv2 license without the Classpath exception, chosen for Java ME can be impractical for an embedded device maker to use, as it includes a “copyleft” provision requiring that modifications to the code, or other code linked to the GPL code must also be published as source code, under the GPL license. So, the recipe to any “secret sauce” must be freely available under the GPL. Hardly something that excites a handset maker, for example. Why not use Java SE then – since smartphones and other advanced devices have the power to handle it? Not so fast! There are some even more mind-bendingly complicated licensing issues for Java SE that riled up the Apache Software Foundation, related to this embedded device revenue. Ever wonder why Google’s open source Android platform – which looks startlingly similar to Java SE in many respects, is nonetheless not based on Sun’s open source code, but rather on Apache’s Harmony project? One can speculate…

IBM approaches open source platforms differently. Rather than monetizing open source only by selling support for deployers, or by choosing licenses that drive commercial licensees to keep paying, IBM distributes FOSS code that comes from elsewhere – often non-profit foundations such as the Apache Software Foundation – but licensed in such a way that IBM can bundle proprietary extensions with the FOSS code. This lets IBM add value, create something unique, and yet leverage the open source development model and the momentum of FOSS adoption for the bulk of the code they ship. Good idea! Get the benefits, and still sell stuff and make money. This approach doesn’t annoy licensees, and keeps communities happy and burnishes IBM’s FOSS credibility by contributing to independent FOSS projects. Seems to work for them too.

What would Java look like, if it was ideally suited for IBM to profit from it, using the same approach? Maybe IBM would donate Java to ASF, making it an Apache project. Or donate it to Eclipse? Perhaps they might spin it off as part of a “Java Foundation” or something equivalent, licensed under the ASL, or perhaps the EPL – the Eclipse Public License. It is interesting to think about the role of the JCP if Java were to become a code base built within a non-profit foundation, rather than controlled by a corporation as it has been with Sun. Would the JCP even be needed anymore, and if so, who would pay for platform JSRs? How much code, and staff, would IBM contribute to help the platform evolve? What commercial extensions could IBM sell? What would embedded Java look like as an IBM product? Would Google still need Android as a separate code base? Or could they adopt “real” Java under such conditions? Could IBM unify the fractured Java ME ecosystem?

IBM is much less of a charity than Sun. Perhaps that is why they’re making money and Sun is shopping for a suitor. But under IBM, it seems to me that Java is likely to remain FOSS, under a very liberal license – arguably even more liberal than GPLv2. Of course the existing code will always be available under GPLv2 as well.

Would IBM be a good steward of Java? What do you think?