The Open Road

Mike Milinkovich

(Credit: Eclipse Foundation)

Open-source communities are founded on trust. It's therefore disappointing but not surprising, to see the Eclipse Foundation's executive director, Mike Milinkovich, rip into former Eclipse Foundation director of community Bjorn Freeman-Benson and tell him to take his "steady acid drip of negativity" and "go away."

Milinkovich, a steelie, hockey-playing executive, didn't mince words in a blog post:

Your former colleagues at the Eclipse Foundation have tolerated your public abuse quietly because we are professionals, and we honestly thought that you would tire of it. Apparently we were wrong. But the time has come to say it: You are a jerk. Please go away. You quit the Foundation, you have zero commits since April, and we tire of your sniping from afar.

Not the most diplomatic but better than a body check against the glass any day.

Given Freeman-Benson's constant carping on the foundation and his former colleagues, it's understandable that Milinkovich went on the offensive. In a variety of posts, including the one that prompted Milinkovich's post, Freeman-Benson has sought to undermine the Eclipse Foundation, which has successfully managed one of the industry's top open-source projects.

His criticism may have been fragmenting the trust that held together the Eclipse community.

Indeed, as Eclipse Foundation director of marketing Ian Skerrett told me, "There is a long history of troll-like blog post[ing] that built up to this point; yes, it is harsh, but it was hurting the community."

Call it tough love for the open-source set. Given the existence of poisonous individuals in many open-source communities, it may be "love" we see more often.

If something seems too good to be true, it probably is. That popular aphorism never seemed truer than today when reading The Wall Street Journal's analysis of Wikipedia's declining volunteer base. Despite countless articles extolling the virtues and seeming omnipotence of "community" over the past several years, the technology industry seems to be settling back into old habits:

Command and control.

It's not that the "wisdom of crowds" idea hasn't influenced the way technology is developed, or how news and information are gathered and distributed. It has.

It's just that the promised sea change has proved to be far less disruptive than we expected.

Take Wikipedia. As the Journal calls out, volunteerism has declined as the ease of contribution has waned. The easy topics are taken. Rules for upping the quality have proliferated. Wikipedia is becoming...corporate.

Nick Carr has been pointing this out for years, but it's only now becoming self-evident. Wikipedia has grown up and, in so doing, is looking more and more like the encyclopedic world it sought to displace.

Nor is it alone. Open-source business models increasingly look like proprietary software models, as the Software Freedom Law Center's Bradley Kuhn suggests.

Even uber successful open-source communities like Joomla have discovered that reliance on volunteers falls short of what a few good paid developers can do.

That's a positive discovery by Joomla. A more worrisome discovery is that Mozilla remains far too dependent on Google to fund development of Firefox. Mozilla has lots of community, right? Yes. As Mozilla CEO John Lilly has said, 40 percent of Firefox's code comes from developers not employed by the foundation.

But that still leaves 60 percent, and virtually all of the core development work, that relies on "company," not "community," which is how much of the world's best open-source software is developed: funded by IBM and other "community" members.

For those who think "community" is a euphemism for "everyone else doing my work for me," think again. It just doesn't work that way.

Of course, companies can go to the opposite extreme, too. Apple, for one, gets beat up for a heavy-handed approach to its App Store approval process. Apple, in other words, doesn't seem to care one iota what "the community" thinks.

But then, this is the same App Store with more than 100,000 applications and 2 billion downloads to date. No wonder Apple isn't apologizing: it's clearly benefiting most people most of the time, or the application developers would take their complaints to a different platform.

But they haven't, and this calls out the problem with deifying "community." It's accepted wisdom that one shouldn't "anger the community," as if it's some unknown god that demands the occasional virgin to be thrown into the volcano. But the truth is, "community" is not really much different from the "customers" and "partners" the industry has sought to satisfy for decades.

So, yes, by all means seek to work with your community of users and partners, but don't expect "the community" to do your work for you. Guess what? "The community" already has a day job, and can't afford to work full-time for you unless you pay it.

All of which leaves us largely where we started. The most successful software companies don't rely on some vague "community" to build their products. Microsoft, Oracle, IBM, Google (Android, anyone?), and even, increasingly, Red Hat (JBoss, KVM, etc.) build great software based on their own, internal plans and expertise and "the community" buys it (or resells/embeds/etc. it).

The big shift, however, has been in the transparency of the feedback loop, which has been a welcome change in the industry. So, to the extent that "community" simply implies a more open way of developing and distributing software, then, yes, it has been significant.

But it hasn't changed the world. It has only changed the way the dominant technology companies...dominate.

Vishal Sikka, SAP's CTO

(Credit: SAP)

It's a fundamental tenet of classical economics that vendors want complementary goods to be cheap and plentiful.

It's therefore not surprising that SAP Chief Technology Officer Vishal Sikka is calling for a more open Java Community Process (JCP).

What is surprising is that it is SAP, the bastion of proprietary software, that delivers this message.

Irony, thy name is SAP.

SAP, after all, is hardly the most open-source or open-process friendly company on the planet. Despite early involvement in Eclipse, some interaction with MySQL (MaxDB), and a new commitment to the Apache Software Foundation, SAP remains a firmly proprietary company.

Even Microsoft, which arguably has the most to lose from open source, has consistently and continually experimented with greater open-source involvement.

SAP? Not so much. In large part, SAP hasn't been forced to embrace open source because it hasn't been threatened by it. ERP (enterprise resource planning) is such a complex beast that it has remained largely impervious to open source (with the exception of open-source start-ups like Compiere and Openbravo, to which I'm an adviser).

A few years ago I was asked to speak at SAP's Palo Alto campus. I spent an hour talking about open source's commodity influence on the industry. During the question-and-answer period, one attendee said: "This is all fine, but open source has not touched our business. ERP is different."

Apparently, that thinking prevails, as Sikka's argument about a more open JCP process fails to apply the logic to SAP's own software. He wrote Monday in a blog, laced with italics and bolds:

The Java industry is currently going through important changes, and there are many discussions around the openness of Java and the Java Community Process (JCP). To date, the JCP is heavily dominated by Sun Microsystems which was not always to the benefit of all parties interested in Java. Java is the lifeblood of the IT industry, and IT is a fundamental underpinning of the way business is conducted in the 21st century....

To ensure the continued role of Java in driving economic growth, we believe it is essential to transition the stewardship of the language and platform into an authentically open body that is not dominated by an individual corporation. Java should be free of any encumbrances to permit fair competition between compatible implementations for the benefit of customers. By preserving the integrity of Java, the IT industry can ensure a vibrant developer community and continued innovation for enterprise software customers. This ensures the continued global economic success brought about through open innovation.

It's a good argument, but it sounds funny coming from an SAP executive. After all, Sikka starts his argument by asserting that SAP's software is indispensable to the world's IT systems: "SAP systems are at the core of large parts of global IT, and are powering more than 65 percent of the transactions that make up the world's Gross Domestic Product (GDP)."

Surely any system upon which 65 percent of the world's GDP depends should be open, right?

Apparently not. SAP NetWeaver and, well, everything the company ships remain firmly proprietary last time I checked. Complements to SAP's proprietary products should be open, however--or so the argument goes.

Sikka does suggest that "SAP software also needs to be open and adaptable in order to allow customers and partners to be nimble and benefit from the speed of innovation within the SAP ecosystem," but apparently he means that everything but SAP's software should be open and adaptable.

Complements are best when they're free and plentiful, after all.

Again, Sikka's message is not wrong. It's the messenger who has the problem.

Disclosure: I will be presenting at SAP in Walldorf, Germany, on Thursday on SAP's track record with open source and open standards. Please share your thoughts on how SAP is doing.

"Skype is going open source!" screamed the headlines over the weekend. If only.

While Skype has acknowledged an interest in making its Linux client open-source, this may not mean very much in practice.

I love Skype and use it daily for both instant messaging and voice calls. Its quality is superb and the Skype team continues to enrich Skype's functionality (now including the ability to screen-share and video chat).

We've decided to open-source this logo.

Open source won't help with this. Not in the way Skype means.

As ZDNet captures, Skype isn't planning to open-source its underlying protocols, and certainly not its back-room server technology. Instead, it's just talking about open-sourcing the Skype graphical user interface (GUI). And only for its Linux client, apparently.

Snore.

First of all, why only Linux? Open source long ago stopped being the exclusive province of Linux, if it ever was. Without Mac OS X and Windows support, Skype is actually locking itself out of the vast majority of the market for software developers.

And then there's the question of what is being open-sourced: GUI code? Really? That's it? No protocols? Does Skype think developers simply want to add fuzzy dice to the UI?

It's not really Skype's fault, as ZDNet explains, because its source code is in legal no man's land right now. You can't open what you don't own.

But maybe it doesn't matter. Steven J. Vaughan-Nichols believes an open-source Skype is unnecessary, given that there are credible open-source alternatives that are already available. Perhaps. But they lack the adoption that Skype has, and in communication the network is everything.

But, again, this is probably the biggest reason to yawn at the news of a Linux-based Skype GUI being open-sourced. The magic of Skype is not in the client. It's in the cloud/server, and that's remaining closed because, as TechCrunch posits, Skype doesn't want its competitors to free-ride on its services.

In sum, despite the euphoric greeting of the news of Skype going open-source, there's actually very little to celebrate. This isn't good for developers, and it's not good for Skype. In open source, it's generally worse to contribute too little than too much, because the community's first (negative or positive) impression tends to last a very long time.

Intuit announced on Monday that it has launched a community site for open-source developers to write open-source SaaS (software as a service) applications that enhance Intuit's own SaaS platform. Glyn Moody derides the move as "a rather feeble attempt to plug into the power of openness without really engaging with it," but this misses the point.

The point is to enhance the value around an already valuable platform (Intuit's software). This isn't just of benefit to Intuit, but also to the third-party developers who contribute. No one wants to write software to sit on a shelf, unused. Coding for Intuit ensures a ready-made audience of small businesses.

What's not to like about that?

IBM's Savio Rodrigues notes that this same effect could have been achieved with a closed-source community site, but he suggests a few reasons open source makes the community site richer:

[B]y using an open source license, Intuit reduces a potential issue for its partners that do sell open source products on top of Intuit's platform. Intuit also makes it easier for its partners to customize the code for their own purposes, something that partners are likely to do. Lastly, the open source license encourages Intuit's ecosystem to contribute their own components and, thereby, helps raise all boats, without having to open source Intuit's core products. It seems like a win-win to me.

Agreed. Intuit clearly "gets" that open source is a means to an end, not an end in and of itself. Openness helps the company accomplish community and corporate goals. It helps to enrich its partner experience. But it's not a revenue model that the company is embracing.

Some will see this move by Intuit as more about artifice than community, but they will be wrong. The Intuit community stands to benefit greatly from this move. As with Microsoft before it, these Intuit partners are looking for ways to enhance the value of their offerings while building on a winning platform.

Open source helps them to do that, as ZDNet's Sam Diaz points out, while also helping Intuit to increase the value of its platform. It's a win-win situation.

Follow me on Twitter @mjasay.

Microsoft's Internet Explorer's market share is absolutely falling. The question is, by how much?

I've reported before that Internet Explorer (IE) drops 5 percent market share points each year, while Mozilla Firefox gains 5 percentage points per year. But what is becoming increasingly clear is that IE's market share may be dropping more precipitously than previously reported, falling to 60 percent share in June 2009 instead of the 68 percent share expected.

Or is it?

The answer may depend on the source of the information, and the reliability of its data. Mozilla's Asa Dotzler uses StatCounter data to discern a 60 percent share for IE but, as ZDNet's Larry Dignan points out, this data may not hold up.

For Microsoft's sake, it had better hope not, as this chart compiled by Dotzler shows:

Internet Explorer market share falling faster than reported?

(Credit: Asa Dotzler (Data from StatCounter))

That's not the sort of chart with which Microsoft CEO Steve Ballmer likes to sweeten his coffee in the morning.

Net Applications, the other big source of browser market share data, still hasn't posted its results for June 2009, noting that it is trying to make sense of "some significant variations in browser and operating system statistics."

Given that market share data isn't a one-month phenomenon, it's not necessarily helpful to celebrate or fret over the June data, especially since much of the market share share data is going to get skewed in the summer months, anyway. For example, given Firefox's disproportionately large following in Europe, coupled with Europe's disproportionately long holiday season in the summer, I'd expect to see Firefox drop some percentage points against IE through August, only to rebound strongly in September.

Regardless of short-term variations, one thing seems clear: Firefox is gaining on IE. Microsoft spent too long enjoying its browser dominance, and not enough time innovating. It's starting to pump R&D dollars into IE again, but it's not yet clear whether its monolithic approach to browser development can compete in the long term with Mozilla's community-developed Firefox.

Microsoft needs to compete again, or risks seeing even StatCounter's data understate just how quickly it's falling.

Mozilla, for its part, faces a host of new challenges. It can't afford to waste much time with back slaps and high-fives. The browser has become the center of computing. Microsoft isn't going to give up easily, nor will Google or Apple.

Game on.

Follow me on Twitter @mjasay.

Over the past 10 years that I've been involved in open source, one thing has become strikingly clear to me: there are no real predictors of open-source success. There are, of course, general principles that contribute to the creation of successful open-source projects, but serendipitous "right project, right time" circumstances often matter most.

Apache Software License 2.0.

(Credit: Apache Software Foundation)

I was therefore intrigued to read two articles that crystallized my own thinking around critical components of successful open-source projects.

The first is from BusinessWeek and details the mechanics of Mozilla's Firefox community. Mike Beltzner, Mozilla's director of Firefox, reveals that while 40 percent of Firefox is contributed by outside developers, what and where they contribute may not be what many would expect:

There's structure in (how Firefox is developed). But at the same time you allow people to innovate and to explore and (give them) the freedom to do what they want along those edges--that's where innovation tends to happen in startling and unexpected ways (emphasis mine).

This may be easier for the Mozilla Foundation, given its nonprofit status, as you'd expect developers to more willingly build around a product if they trust the foundation (pun intended) upon which they're building.

But the general principle holds: most open-source development and, for that matter, most development around proprietary software, happens at the edges. Whether it's Microsoft Windows or Mozilla's Firefox, developers generally don't touch the core: they create add-ons, complementary products, and so forth.

So, principle No. 1: Open-source projects that create a strong, valuable, easily extensible core that developers have the ability to build upon, as well as the pecuniary or reputational interest in extending, are more likely to succeed. No one works for "free."

The second principle is related to the first, and deals with ownership of add-ons. While some people are motivated by peace, love, and open source, others (rightly, in my view) see open source as a means to an end, and not the end itself.

As such, the license used for an open-source project matters a great deal. I've long been a proponent of the GNU General Public License (GPL) because it enables vendors to bless customers (free code!) while cursing competitors (we just open-sourced your entire value proposition and you won't dare touch our code!).

But lately I've been seeing the role Apache-style licensing can play in fostering vibrant open-source communities. Daniel Jalkut, founder of Red Sweater Software, describes this well:

As the developer evaluates communities to participate in, they must evaluate the legal impact such participation will have on their own project. The closed-source communities are, by definition, uninviting to outsiders. GPL communities are open and embracing of other GPL developers, but generally off-putting to liberal-license and closed-license developers. Only the liberal-license communities are attractive to developers from all three camps.

It's your party, and you're entitled to write the guest list. But take a look around the room: not as many folks as you'd hoped for? Liberally licensed projects are booming. Speaking for myself, a developer who has been to all the parties, I'm much more likely to pass through the door that doesn't read "GPL Only."

If you want maximum participation whatever the cost, Apache/BSD is probably the right way to go. Most companies and project owners, however, have to make a living, so it's reasonable that they measure the costs of going Apache, which likely means they'll trade a liberal license to some of their code for a proprietary license of the rest of their code.

IBM is an example of this strategy on a big scale, but so are Day Software, Microsoft, SpringSource, and others.

Principle No. 2, broadly stated, is this: Your odds of encouraging adoption of your product go up if you use a liberal license like Apache, but your ability to directly monetize Apache-licensed code vaporizes.

This isn't a bad thing. It just means you have to separate community creation from customer creation, as Funambol's Fabrizio Capobianco has stated. The two aren't necessarily the same, and are sometimes inimical to each other.

As noted above, however, you don't have to license your software as open source to encourage community around it. Microsoft, with its vibrant partner ecosystem, demonstrates this, as does Apple with its amazing iPhone ecosystem.

Developers will flock to the platforms that offer them the most return, whether financial or in reputation (which eventually translates into money). Liberally licensing of your code might tip the scales in your favor if you lack the largess of Apple or Microsoft. But no guarantees.

Follow me on Twitter @mjasay.

As community becomes the currency increasingly driving cash in the technology industry, there's a lot of pressure to force communities to bend to corporate desires. This, as community evangelist John Mark Walker suggests, is perhaps the best way to kill the goose that lays the golden community.

Sting sings that "if you love somebody, set them free." Walker applies a similar principle to online community-building:

[T]he way forward is much the same as with the search for happiness: take care of the community building blocks, like your choice of web platform, community governance principles, interesting conversations, and a sense of purpose, and the rest will take care of itself.

Walker goes on to say that a lot of focus needs to be given to feeding the free-loaders, those pesky people that hang around and don't pay your company a dime. "Freeloaders help to add 'activity' and 'center of gravity' to your community," Walker writes, which might well provide the ambiance would-be paying community members need to feel comfortable sticking around.

"Community" can be a squishy concept at times, simultaneously important yet very hard to quantify and qualify. Even so, Walker's suggestions point to ways to get the most value from communities by giving the most value to those communities.

Funny how that works.

Follow me on Twitter @mjasay.

Of the formative figures in open source, Richard Stallman, Linus Torvalds, and Eric Raymond loom large. Arguably, however, few have had as much of a disruptive force as Tim O'Reilly, who has helped to create the open-source market and has spent the last six years reshaping it with his seminal "Open Source Paradigm Shift" and other articles.

In an engaging and informative recent TWiT podcast, O'Reilly revisits the theme. It doesn't break new ground (for O'Reilly), but does highlight, and render somewhat meaningless, the fissures currently running through the open-source community.

Host Randal Schwartz kicks off the podcast with a question about Twitter: Is Tim concerned that "Twitter is anything but open?"

I like to think I have a more nuanced view of open than a lot of people. Some purists will say that [I'm] a traitor....From the very beginning of my advocacy about open source, I've really just been interested in having interesting things happen in the world.

The reason I like open source and worked on this idea of renaming it from "free software" to "open source" was because I don't think it's a religious issue. It's really about how do we actually encourage and spark innovation. Because for me a more interesting world is one where there's more innovation and more freedom to innovate....

The idea is that people can build on it. You give it away because you want other people to do things with it that you can't do or don't want to do.

Open source, in other words, is not an end in itself. It is a means to an end, and that end is collaborative innovation.

While reputation is the first goal of many open-source developers, it's really a means, with the end for many being money ("There's huge currency in reputation. And that's how most open-source developers have 'monetized' giving away things for free.") But it's not really the ultimate end for, as O'Reilly rightly points out, "Money is a signifier of a more fundamental exchange."

Today, O'Reilly suggests, the real value in open source has little to do with source code; instead, it's the result of that code. Value has moved to data, with "network-effect driven databases - user-generated databases - [serving as] the heart of Web 2.0."

And yet, as O'Reilly points out, the open-source world continues to fixate on the wrong battles:

The whole context of free and open-source software is not about Linux taking over the world and replacing Windows. That might even happen, just as the PC replaced the mainframe. And it probably will happen. But it doesn't change the dynamic....

The heart of how we need to understand free and open-source software is in the context of Web 2.0. We can have as much open-source software as we want but we've now created this new layer where these databases that grow through user contributions are the real source of lock-in.

Eventually, these guys probably will make their software open source because it won't matter. The value lies in having the data. The real question is, will there be a future open-source movement that's really an open-data movement.

The market, in short, is no longer for software, open source or proprietary. Tomorrow's market is all about data. It's therefore not surprising that O'Reilly isn't too bothered by people who consume open source without contributing back. That's a short-term phenomenon:

Free riding doesn't bother me because we do get value from it.

That's not to say that there aren't real issues with the power that is accruing to Google, Facebook, et al., but open source is science, not religion. It's pragmatic. If you close things off, eventually you lose. This is why one of my slogans is 'Create more value than you capture.' As long as people are doing that, I don't care whether they're trying to capture some value.

It's a good point, and a great reminder that many persist in fixating on all the wrong issues in open source. The licensing wars should be a thing of the past. The question is how to drive participation while building businesses that improve as participation increases. Sometimes this will result from open-source licensing, but sometimes it won't.

So long as we focus on the correct end, rather than treating open source as an end in itself, we should be OK.

Follow me on Twitter @mjasay.