Open Source Needs Leadership?

		Print
		Email weblog link
		Blog this

Tim O'Reilly
Aug. 06, 2001 05:05 PM
Permalink

The most recent Microsoft initiatives (.NET and Hailstorm) will change the way applications are delivered over the Internet. If the open source community does not directly respond to Microsoft's plans, it is likely that open source software, which has been such an integral part of the Internet's infrastructure, will have a diminished role in this next phase of the Net.

But how can a group as large, diverse, and happily anarchic as open source muster a coherent reply to something as focused as .NET? Open source can't seem to finish a browser, upgrade a Web server, or manage the development of a database server, so how can it concentrate on something as far-reaching as .NET? The answer, I believe, is with leadership. The right kind of leadership.

When it comes to implementing a specific strategy, Microsoft has the advantage of a top-down structure. Senior management establishes a vision for the company, then the various divisions of worker bees try their damnedest to implement that vision. Whatever its crimes or problems, there can be little question that Microsoft has a highly effective management team--as millions of shareholders will attest.

...only a unified plan of attack will be strong enough to weather the difficult situation ahead. Then they'll have to convince a legion of coders to pursue this path. And that isn't going to be easy.

There is a history of battles between Microsoft and other companies, from Novell to Netscape, where each competitor's "top-down strategy" has foundered on the rocks of Microsoft's entrenched monopoly position and superior execution of a winner-takes-all strategy. The technologies that have done best are those that avoid that game entirely, and counter Microsoft's "embrace and extend" strategy with one of "open up and connect." Netscape abandoned the open protocols of the early Web with an embrace-and-extend strategy of their own, which failed, despite a staggering early lead in the browser market. By contrast, Apache, which hewed strictly to interoperability and open protocols has maintained and even extended its lead over Microsoft's competitive offerings.

Perhaps I seem to be mixing two issues here: top down versus bottom up, and open versus proprietary. However, I'm convinced that the two are inextricably linked, because open architectures, like those of Unix/Linux and the Internet, are what make bottom-up technology development possible. As I've tried to point out on other occasions, well-designed open source projects define what you might call an architecture of participation, one in which the protocols between participating programs are well defined, so that the individual programs can work together despite being developed independently. Contrast this with the code "commingling" that judges have found so troubling in the Microsoft antitrust case.

The Internet as it now exists has laid down the fundamental rules of such an interoperable system. One key element of the Internet approach was first articulated in 1980 by Jon Postel in RFC 761, TCP, and repeated and expanded in RFC 1122, Requirements of Internet Hosts. It is known as the "robustness principle": "be conservative in what you do, be liberal in what you accept from others."

Overtones of the golden rule aside, this is a cornerstone of interoperability, and the opposite of the games we've watched for the last few years, as vendors have built competing implementations that are reckless in extending standards, but parsimonious in recognizing competing variations.

In short, the strategy already exists: it is to follow the credo of interoperability, and eschew the credo of competitive advantage based on proprietary and exclusive data protocols and data formats.

And because open source is, well, open, it's tough for its protocols and data formats to be anything but open as well. Even if someone produces a new one, it can, if widely adopted, be copied by anyone else. And for the most part, open source does embrace and even "enforce" interoperability. So, for example, it is sendmail that has enforced the continued use of RFC 822 as the standard for email messages, and Apache that has kept HTTP from going the way of HTML.

Many open source projects have worked to create interoperability where it was not planned. Jabber has been at the forefront of efforts to bring interoperability to Instant Messaging systems. So far, AOL, the market leader, has tried to stop Jabber and similar efforts to open up IM, but I believe that they are coming to realize that interoperability may be their only successful weapon in the coming battle with the next generation of Microsoft Instant Messaging software.

It is in this same context that we need to understand Mono, Miguel de Icaza's effort to reimplement parts of the .NET Framework. Some critics have complained that Mono is bad because it aids Microsoft's plan to make the .NET Framework ubiquitous. But that's precisely the point. The framework will become ubiquitous to the extent that independent implementations can be interoperable.

Once you accept the idea of interoperability as the cornerstone of the Internet architecture, and measure projects by the degree to which they work well with others, you see that the diversity of open source is a strength, not a weakness. Where a top-down approach limits you to one evolutionary track, a bottom-up approach allows for rapid, parallel evolution.

And there are many fascinating open source projects (as well as projects from independent developers who are either contemplating open-sourcing their work outright, or have incorporated elements of open source into their strategy.) As has been the case from the beginning, these projects are driving the industry, including Microsoft, forward. After all, it was Dave Winer's XML-RPC that gave rise to SOAP, now a cornerstone of Microsoft's .NET services strategy. (Incidentally, both XML-RPC and SOAP are well-supported by open source programming languages like Perl and Python.)

The one thing that the open source community and its media boosters could do better is to recognize and embrace its innovative new projects, rather than keeping so much of the focus on the established projects. One of the things I've tried to do in conferences such as the Open Source Convention and the upcoming Peer-to-Peer and Web Services Conference in Washington D.C., is to highlight some of this new and exciting work. Freenet, some of the Gnutella projects, Jabber, JXTA, BEEP, Alpiri, and others, should be as familiar to open source developers (and to proprietary software developers) as Linux, Perl, and Apache.

The one thing that's important to remember is that in an interoperable world, it's not necessary for a program to "win", to achieve dominant market share, to have an impact. In fact, the essence of interoperability is choice. If developers honor the robustness principle, and make software that works well with the software of others, it's ultimately the users who win.

In the end, then, the leadership we need is one that continues to embrace and exalt the values that have been so central to the evolution of the internet thus far, and not to jump ship in hopes of gaining some temporary advantage over rivals.

Tim O'Reilly is the founder and CEO of O'Reilly Media, Inc., thought by many to be the best computer book publisher in the world. In addition to Foo Camps ("Friends of O'Reilly" Camps, which gave rise to the "un-conference" movement), O'Reilly Media also hosts conferences on technology topics, including the Web 2.0 Summit, the Web 2.0 Expo, the O'Reilly Open Source Convention, the Gov 2.0 Summit, and the Gov 2.0 Expo. Tim's blog, the O'Reilly Radar, "watches the alpha geeks" to determine emerging technology trends, and serves as a platform for advocacy about issues of importance to the technical community. Tim's long-term vision for his company is to change the world by spreading the knowledge of innovators. In addition to O'Reilly Media, Tim is a founder of Safari Books Online, a pioneering subscription service for accessing books online, and O'Reilly AlphaTech Ventures, an early-stage venture firm.

Comments on this weblog

Showing messages 1 through 2 of 2.

• XML-RPC & SOAP history error.
  2001-08-09 12:38:04  bparsia1 [View]
  
  
  You wrote:
  
  > And there are many fascinating open source projects (as well as projects
  > from independent developers who are either contemplating open-sourcing
  > their work outright, or have incorporated elements of open source into
  > their strategy.) As has been the case from the beginning, these projects
  > are driving the industry, including Microsoft, forward. After all, it was
  > Dave Winer's XML-RPC that gave rise to SOAP, now a cornerstone of
  > Microsoft's .NET services strategy. (Incidentally, both XML-RPC and SOAP
  > are well-supported by open source programming languages like Perl and
  > Python.)
  
  This factually incorrect. As I understand the history, XML-RPC is a *fork* of a version of SOAP. Some evidence:
  
  From http://www.xml.com/pub/a/2001/04/04/soap.html (Don Box):
  
  > When SOAP started in early 1998, there was no schema language or type
  > system for XML (in fact, XML 1.0 had just become a full Recommendation
  > that quarter). If you look at earlier versions of the SOAP spec
  > (including XML-RPC, which was subsetted from the 1998 SOAP spec), most of
  > the focus was on defining a type system.
  
  From http://www.linuxdoc.org/HOWTO/XML-RPC-HOWTO/xmlrpc-howto-intro.html#xmlrpc-
  howto-history (Eric Kidd):
  
  > XML-RPC was inspired by two earlier protocols. The first is an anonymous
  > RPC protocol designed by Dave Winer and announced in an old DaveNet
  > essay. (This is why XML-RPC servers are often installed under /RPC2.) The
  > other, more important inspiration was an early draft of the SOAP protocol.
  
  And even from the Winer account (http://www.xmlrpc.com/stories/storyReader$555):
  
  > That's not exactly true. Before folklore becomes reality, XML-RPC was
  > originally, privately, called SOAP, when Don Box and I were working with
  > Bob Atkinson and Mohsen Al-Ghosein at Microsoft, in early 1998.
  
  I take it that this just means that XML-RPC is a fork of SOAP (i.e., there was one thing, originally called SOAP, that forked, one branch becoming XML-RPC, one branch retaining the name "SOAP").
  
  From http://www.xmlrpc.com/stories/storyReader$1726):
  
  
  > XML-RPC is the work of many people. There were four designers working on
  > the initial April 1998 specification, Bob Atkinson and Mohsen Al-Ghosein
  > of Microsoft, Don Box of Developmentor, and myself.
  
  Again, clearly, XML-RPC didn't *become* SOAP, nor was it a Winer project that MS picked up.
  
  From the same document:
  
  > So we decided to use two standards of the Internet, XML and HTTP, to form
  > the communication protocol for our software. By February 1998 we had a
  > deployed protocol for Frontier-to-Frontier communication simply called
  > RPC, and it worked pretty well.
  >
  > As I often do, I wrote a public essay about this and offered to work with
  > others. Usually I make those offers and no one responds. This time, I got
  > a call from Bob Atkinson, who I knew from work we did with Microsoft on
  > COM in the early 90s, and he asked if we would like work with them on
  > XML-over-HTTP. I remembered that it had been a lot of fun working with
  > Bob in the past, so without hesitation, I said yes.
  
  And:
  
  > A few weeks into the process I wanted to release the software to our
  > users. It was already much more powerful than what we were shipping. Wire
  > protocols are a delicate area, and serious breakage would surely happen
  > if we waited much longer. So we forked a release, called it XML-RPC, and
  > continued working with Microsoft on what would become SOAP 1.1.
  
  This affects the point you made: SOAP *didn't* come from an open source project. Even if it *did* come from XML-RPC...XML-RPC isn't open (and, qua spec, it's not even open in many senses), and Frontier isn't Open Source. There are a lot of Open Source implementations of XML-RPC, but it's hard to see it as *stemming* from an Open Source project. In any case, it looks like MS was developing such a spec all on it's lonesome and was deeply involved with the project from the beginning.
  
  I think XML-RPC and SOAP are rather *unlike* many internet protocols...it's striking that they never made the rounds as an RFC; XML-RPC isn't in the hands of the W3C or *any* neutral party (or, for that matter, a standardization body), and SOAP only came under the W3C auspicies recently(not that that's necessarily a *good* thing, but clearly SOAP wasn't an "open" project *before* that move).
  
  SOAP's open-ness is a post-facto move, I take it, in order to shine some sort of legitimacy on the MS domination plans. Perhaps SOAP *really will* make .NET or whatever more livable for outsiders, but that doesn't change its actual history.
  
  (Note I'm using "Open Source" in a rather narrow sense, something like "with an Open Source style licence, e.g., BSD, MIT, GPL, etc." and "open process" to mean something fuzzily more than "the developers in control are or claim to be "open to input".)
  
  And, just to be clear, I don't see than any of the principles are claim much otherwise. Indeed, I take their words to prove my point. The history of SOAP may be encouraging to some, but I don't think it should be *on the grounds* that it's "more of the Open Source Internet process at work".
• XML-RPC & SOAP history error.
  2001-08-10 16:00:36  Tim O'Reilly | [View]
  
  
  Your point that xml-rpc was subsetted from SOAP is really interesting; it's definitely different from the widespread perception. I'll leave arguing the point to those who were there. But even if "openness" was added post-facto to SOAP, and xml-rpc is not itself entirely open (though Dave is flirting with open source), the fact is that SOAP and xml-rpc do enable bottom up provisioning of decentralized web services. I believe that one key to open source (considered most broadly) is an architecture that allows any developer to come to the table as an equal participant. I do see people starting to build web services in the same way they built utilities for UNIX/Linux or built web sites. And that's really important! If anyone can easily add services that work together, we really can build a bottom-up internet operating system.

---

Showing messages 1 through 2 of 2.

Return to weblogs.oreilly.com.