[This is the text of my keynote speech at OSCON 2006 in Portland, Oregon -- Simon Phipps]

The Zen of Free

Good morning – it's a pleasure to be invited to open the second morning of OSCON. I'm Simon Phipps, and my day job is oversight of the open source and Free software activities at Sun Microsystems. I do that job because of the huge amount of open source software that Sun works on.

You'll've heard of Sun's work on OpenOffice.org, but you may not be aware that Sun is the key contributor to the accessibility code in GNOME. You may have heard of OpenSolaris, but you may not be aware that the internationalisation framework in Mozilla is down to Sun programmers. In fact, if you use a GNU/Linux distribution with GNOME, Mozilla, X and Perl, you're using a ton of code that Sun developers are actively maintaining every day. Sun's supporting Linux without supporting Linux. Which sounds like a koan. But I'm not going to talk about Sun here – I have a session this afternoon at 2:35 for that.

To get my job done, I spend time reading and trying to understand the dynamics of open source software. I've been amazed by how few people have looked beyond the buzzword-level to model what's actually happening in a way that helps people engage effectively with open source communities. The model I've developed to model open source involvement is something I call the Zen of Free. You may find it has spooky similarities with Tim's talk yesterday.

Altruism Without Sacrifice

First, let's take a look at the altruism involved in open source participation. For me, the best way to model an open source community is to think of it as a community of developers gathered around a source-code commons. The commons at the heart of each community is its treasure, made available for use by anyone by a license to the copyright. The members of the community use the contents of that commons, under the terms of the license, to create software works.

They all do this in order to fulfil a personal goal of some sort – what Paul Graham in “Hackers and Painters” calls “creating wealth”, meaning that they are making something that has value to them. The kind of value does not matter. To some it is to fulfil a social goal, such as improving the literacy of their region or to make web access available to the under-privileged. To others it is to fulfil the terms of their employment in order to be paid. Others create software as a side effect of delivering education, or of making software to sell. The motivation of others does not matter, though. They are all connected to one another at the level of the code, and they are all at liberty to create whatever constitutes wealth to them by the terms of the license.

But it doesn't stop there. Each of them is making a different software work, with different functions and intentions. As they do so, they add features, fix bugs, write documentation and innovate in other ways. Each of them realises that keeping their work to themselves, although it may apparently have a short-term benefit, in the long term reduces their wealth (however they define it) by requiring regression-testing and rework in order to stay up to date with the commons.

So, in apparent acts of altruism, they contribute back to the commons, improving the code within it to the benefit of all. This is altruism, but it is altruism without sacrifice – sharing innovations so that others benefit, yes, but also benefiting from the integration of the innovation back into the commons. It's the first koan of the Zen of Free – altruism without sacrifice. Joining an open source “virtuous cycle” is a matter of aligning one's interests with the interests of the existing community so one can share the commons. It's a matter of synchronising the interests of many to the benefit of all.

What are the things that make this “virtuous cycle” work? Mechanically, there are two.

Licensing Without Lawyers

The first is licensing. Software licenses define a set of freedoms for the use of the copyright materials contained in the commons. Before the late 1990s, pretty much all software licenses were bespoke, written to define freedoms around a particular body of code. This caused a problem for software developers because, to understand the exact nature of the freedoms a license created, it was necessary either to engage the services of a lawyer, or to trust the author of the license. To the individual developer, this was a problem because she could afford neither.

The Open Source Initiative addressed this problem by standardised licenses. By getting a community of license experts to review each license, the OSI Board used a benchmark – the Open Source Definition – the create a list of licenses believed by open source developers to create the freedoms necessary to make new software works in a way that did not damage the virtuous cycle of open source software development. This is my second koan – licensing without lawyers. OSI was very successful in this, and today it would be unthinkable for a company to propose an unapproved license for an open source community. In this regard, I disagree with Tim O'Reilly's assertion that licenses are irrelevant. Open source licenses remain a fundamental issue for the freedom of programmers to create wealth. However, because of the success of OSI, they are no longer a problem.

Community Without Control

The second thing that makes the virtuous cycle of open source software work is governance. By governance, I mean the rules of the community. No open source community of any value would allow just anyone to insert their code into the commons around which the community has gathered. They all have rules about who can do that – who can get commit access, who decides who gets that access, the scope of the access, and so on. More than that, every community has rules about how other decisions get made – who gets to vote, who gets to decide on infrastructure, how the antisocial are disciplined, and so on. It turns out that today, this is a far more important area of focus than licensing, and to this degree I agree with Tim. Licensing is largely a done deal, but governance is still a problem.

After all, having commit access to the commons is at the heart of many of the business models that members of open source communities use to make a living. You can only promise a big corporate customer that you'll fix bugs or add features if you have some way to ensure the bugs stay fixed at the next release and the features don't need re-implementing. Sure, you could always take the code and start your own community if you can't get commit access, but that is a big deal and you're not likely to succeed unless you have the resources of a big corporation or you have a genuine grievance about the existing community with which others agree. In practice, you need the governance of the existing community to work right.

The thing is, we have no benchmark for governance. It's easy enough to see when governance is diseased – when all the committers work for the same company, for example, or when commit rights are arbitrarily revoked, perhaps on a job change. There are communities where honest debate has turned into obstructive argumentativeness. And there are more signs of disease that I'm learning to spot. But there's no benchmark for governance, and we need one. We need some sort of definition that will resolve my third koan – community without control. The governance of a community like the Apache Software Foundation gives us an exemplar of good practice, but we need an Open Governance Definition against which we can compare the formal or informal rules of a community with which we're considering aligning ourselves so we can tell if it has governance likely to promote freedom.

Staying because of the freedom to leave

Beyond the community, however, there is a growing need for one more Definition to give us the confidence that software freedom is being promoted. Having source code open for use to create wealth is an important springboard to software freedom. Having governance that promotes a transparent meritocracy is another. But the data formats, protocols and interfaces that the software exposes or uses can trump all that.

A journalist asked me an interesting question recently. "Why is it," he asked, "that we are seeing so many new desktop and Web 2.0 tools?" He's right, of course. There's loads of energy around, with projects like Google Calendar, KOffice, OpenOffice.org, Chandler and plenty more, plus new innovations like Backpack, Writely, BlogBridge and others. I've tried many of these and some of them have stuck for me. What's the connection between them?

The thing is, all of these tools have worked out that lock-in is the new lock-out – my third koan. The fastest way to send early adopters packing is to make your cool new toy a roach motel. To start with, early adopters like me are not willing to put live data into applications that don't offer import and export. My calendar is in RFC2445 iCalendar format, so if you want me to try your new calendar thing you'd better accept that as the import format. If I can't add iCalendar and vCalendar appointments I'll not be using it for long because that's what other send me, and there had better be an iCalendar sharing facility for scheduling.

What's more, I have to have iCalendar export so I can migrate away from your new toy to things like Apple iCal, Sun Java System Calendar Server or any of the umpteen programs that support those standards. The same goes for everything else - I just moved my blog subscriptions from Bloglines to BlogBridge to give it a try using the OPML export in Bloglines (it's a pretty cool Java Webstart application), and I work with a group of people routinely exchanging documents between a selection of applications that support OpenDocument Format, which has recently been ratified as ISO 26300.

The availability of open, freely-usable standards for formats, protocols and interfaces creates a bigger market and promotes innovation because we are all free to give things a try. If "interoperability" meant "import only" or “play only in my space”, I'd never feel safe trying new things so market growth and innovation would be inhibited. People who implement open standards like this are smart, because although they allow customers to leave for greener pastures they also allow them to return - I am still using Bloglines despite the appeal of BlogBridge - and the confidence I feel over "owning" my data makes me a much more interesting customer.

That feeling is caused by more than interoperability - it takes full substitutability for me to have the confidence to stay as well as the freedom to leave. That's why Stewart Butterworth is spot-on with Flickr's policy and paradoxically will keep my business by allowing me to leave at any time. That's my fifth koan – staying because of the freedom to leave.

More than that, though, full support for truly open standards means that new ways to use the data can occur. For example, the feeds in Bloglines mean I can use BlogBridge to read the for:webmink tag feed using BlogBridge and have others send me interesting links to read without the overhead of e-mail. That's part innovation-by-design and part innovation-enabled, leaving the customer to work out new ways to mash-up the data and create innovative uses for their own stuff. When using the data demands only a particular vendor's software, or a licensing relationship, or some other boundary traversal, the innovation finds it harder to escape.

So what does it take to have a standard that leads to substitutability and the freedom to leave? At a minimum, freedom-promoting standards will have three characteristics.

First of all, it takes confidence over intellectual property rights. I dream of a world where "standard" implies that all parties to the creation of the specification have been compelled to issue non-assert covenants so every developer can be sure there's no strings attached.

Second, it takes multiple implementations, proving the format is actually usable in multiple places. This was the genius of IETF and it's one of the lessons of CORBA. There have to be at least two substitutable implementations, and at least one of those has to be open source.

Third, the approach must not favour any particular implementation or platform. That's the problem Microsoft's Office 12 XML format turns out to have, and no amount of rubber-stamping by the vendor-only Ecma International will fix it.

To be sure they don't have more subtle barriers to freedom, I look for two more characteristics:

Number four, the standard should have been created transparently. Just as an open source community looks with concern on a large, monolithic code contribution, so we should be wary of standards created without the opportunity for everyone to participate or, failing that, with a full explanation of every decision that was made in its construction. Without that there's a chance that it's designed to mesh with some facility or product that will be used to remove our freedom later.

Number five, the standard should be in the care of a transparent and inclusive stewarding organisation. Without that the successor format, protocol or interface will just appear from nowhere unexpectedly and we risk losing the wealth we created if it becomes the required way to work.

This is about far more than interoperability. Interoperability was a fine goal in the 90s, but in today's world it takes much more than just the minimum level of allowing others to use your secret sauce. Pragmatic interoperability is better than nothing and certainly beats the cold-war mindset of the 80s and 90s where incompatibility and isolationism were the rule. But I want more than import-only. I want more than lowest-common-denominator exchange, where I have to rework my data to make it survive the teleport. Those are the hallmarks of the monopolist's definition of interoperability - letting me play in your market at little risk to your monopoly.

The new world is being made by iCalendar, Atom/RSS, OpenDocument, OPML and the other new standards of Web 2.0 and the new desktop. Truly open formats are creating the new market, and those who attempt to subvert the trend with pseudo-openness will fail. But we need a benchmark against which to measure them. We need an Open Data Definition that can help us tell whether the formats, protocols and interfaces we encounter promote freedom. Seems maybe I agree with Tim after all.

So our software freedom is defined by these koans:

Altruism Without Sacrifice
Licensing Without Lawyers
Community Without Controlling
Lock-in is Lock-Out
Staying Because of the Freedom to Leave

I'm calling for definitions for Governance and Standards to help us know our freedoms are being protected as we move forward.

That's the Zen of Free, and I'm Simon Phipps. You can hear more from me at my session this afternoon at at the BOF this evening, or by coming over to Sun's lounge on the exhibit floor. Thank-you.

http://creativecommons.org/licenses/by-nc-sa/2.5/

This speech reflects the personal opinions of Simon Phipps and is not endorsed by any other individual or corporation.