OSCon 2005 wrapup

by Andy Oram

Related link: http://conferences.oreillynet.com/os2005/

Nat Torkington and his team did a superb job choosing topics for the
O'Reilly Open Source Convention. Just take this as given: if something
important is happening in the open source space, it's at this
conference. There may be only one or two talks on a cutting-edge
topic, when the public hasn't caught on to it in a big way yet, but if
you're observant you'll find the topic here, and key people in its
space available to talk to. I'll show one example on the subject of

Identity: whose is it?

Substantial attention was given at OSCon to identity, a problem the
computer field has to solve if we are to make the most of what
individuals have to offer online. Dick Hardt of
gave a lightning keynote, Dave Smith spoke about
Johannes Ernst presented

Identity, in this context, means offering verifiable and
persistent information about yourself to people online so
they can make judgments ranging from the most basic ("Should I read
an email from this person?") to the most significant ("Is this person
offering advice really a lawyer?").

Clearly, in an online world where people increasingly generate their
own content and form communities relative unmediated by servers,
identity will become central, along with reputation and other aspects
of trust.

In his keynote, Dick Hardt relied on the trendy "2.0" meme, reserving
"Identity 1.0" for the traditional provision of online identity, based
on a single all-powerful authority such as a CA or a credit-card
company, and heralding "Identity 2.0" for forms of identity that decouple the
user from the authority.

I dealt extensively on this topic back in April 2004 in my two-part

From P2P to Web Services: Addressing and Coordination


From P2P to Web Services: Trust
I think the downbeat assessment of the field I presented in that
article is still accurate. None of the very eager and idealistic
players in this space have solved the real-world difficulties of
maintaining, verifying, and presenting information about people and

On the one hand are heavy-weight standards that take years to develop
and are dominated by huge companies: Liberty Alliance, WS-Security,
SAML, and so on. The size and complexity of these standards lay down a
stiff ante to any organization that wants to get involved in identity
services. Yet they barely scratch the surface of what is needed. This
is due to the perennial scourge of standards: they strive to be broad
frameworks, so they leave the details to other committees to
standardize later. And the problem with later is that it's always

The talks on identity that I heard at OSCon had similar
limitations--although I'll show later how the proponents handle my

It's fine to say, as Dick Hardt or Dave Smith do, that a person
ought to be able to obtain a valid ID from a trusted third
party and then present it as one presents a driver's license in order
to buy alcohol. (Both relied on this familiar analogy from everyday
life. Me, I get my alcohol from the spigots that flow freely at
conferences such as OSCon.) The question is: who will grant that valid
ID? It's a social question, not a technical one.

That's why, in the title of this section, I asked whose identity it
is. The designers at this conference have a different concern: they
want to make sure your identity is just yours, because you control how
much of it to reveal.

What we all want to avoid is the existing situation with SSL
authentication in browsers. Only a limited set of certificate
authorities, such as Thawte and VeriSign, have a chance of being
recognized. (I checked a version of Firefox and found 21 authorities
in its Certificates list.) A user can install another certificate
authority, but who ever does?

Worse still, how many users reject a certificate from a web site when
it's not secure--that is, who backs away when a dialog pops up saying
the site failed to be validated by the certificate authority? Most of
us forge right ahead.

So we all want a more inclusive system of third-party verification
with lower barriers to entry. For instance, Hardt possesses a driver's
license from British Columbia, which is useful even though he has no
relationship with British Columbia other than having proved his
ability to drive there. We can all have multiple forms of such
flexible identity. (He said that federation, as in the Liberty
Alliance, could be considered "Identity 1.5.")

The SAML-style frameworks try their best to set up robust frameworks
so organizations can exchange information about the characteristics
needed to trust people (for instance, who gets to look at financial
records) and whether individuals possess those characteristics.
But first the organizations have to agree on the characteristics
and their possible values.
This is where the real effort lies;
not in exchanging the information once they agree on it. I cover this
problem in the previously mentioned articles.

Another problem, that of privacy, has to be faced. Most people
understand the commercial benefits of identity management, especially
online wallets and single sign-on. But this is the unfriendly side of
online identity, the side that makes people afraid we'll go through
life with all kinds of sensitive facts tattooed to our online
selves. What Hardt and the others at this conference promote is a
friendly side of online identity, where we provide tidbits when
they're useful to us and build communities and new services on

For instance, you could share your college degree, authenticated by
your college, to a forum where you're trying to throw your knowledge
around. Similarly, you could decide whether to reply to someone's
question based on his rating as a helpful and competent member of the
forum. Many sites contain valuable rating information, such as eBay;
perhaps they could allow users to share it outside their boundaries.

The goals inevitably involve trade-offs, because while it's a big
advance to give a person a choice as to whether to share information,
sites can also require that information as a condition for logging
in. This conflict will never go away, although provision for
pseudonyms can soften the choice in some situations.

The underlying technologies are familiar and well tested
(cryptography, certificate authorities, asymmetric keys). CACert
(mentioned in an

earlier blog of mine
is becoming a no-cost, low-barrier certificate authority for the

The designers of the heavy-weight standards such as Liberty Alliance
as the WS specs are designing from the top down. They have daunting
business needs and are trying to put together a system that will
ensure these needs are met in an air-tight manner. By shoving off the
immense social changes that would be required for people to bring out
digital identities, they risk that the systems will never be used even
if they can be built.

When you build a specification you hope to be used, you can't get away
with saying, "Somebody else has to solve the social requirements,"
because it's up to you to design your system to so those requirements
can be met.

The designers of the low-bandwidth, easy-entry systems such as sxip,
Passel, and LID are proceeding, instead, bottom-up. As with the
historic development of the Internet and the Web (or cute little tools
such as
described next), they want to provide identity capabilities and just
see where these go. Still, they won't succeed unless some of those
same social requirements--giving everybody a certificate, deciding on
what parameters are important and how to represent those parameters
digitally--have to be solved.

Some unusual aspects of GreaseMonkey

Aaron Boodman described his GreaseMonkey Firefox extension to a fairly
sizeable crowd. Along with a few impressive demos and a quick lesson
in GreaseMonkey scripting, he laid out some lesser-known aspects of
this new and suddenly popular system. (It is being generalized and
ported to other browsers besides Firefox.)

First, he pointed out that GreaseMonkey scripts are ephemeral hacks by
nature and not likely to ever becoming something more. This is because
they are based on characteristics of downloaded pages that are not
under the control of the script, and therefore are fragile. (He didn't
use the term screen scraping, but that's essentially what GreaseMonkey
scripts do.)

For the same reason, Boodman has decided to put his library of scripts
into Wiki form, to encourage users to update and improve the scripts
without the formality of source control or project teams.

Other features under development include:

  • User notifications for new scripts. These don't involve users asking
    the script site for a script that applies to each page they download;
    that might be a privacy risk. Instead, news of new scripts will
    distributed regularly, perhaps once a week.

  • A centralized management area for scripts called Greaseproxy.

  • A possible rewrite in C++, mostly for security.

On the security front, Boodman admitted that GreaseMonkey had
originally ("like Windows") been written with no concern for security.
He promised that all this had changed in the latest version, numbered
0.5. He now recognizes that a Web site's content can abuse scripts,
notably by substituting functions written by the malicious Web site
developer for functions of the same names defined in the GreaseMonkey
script. To stop this, he's instituted the use of a JavaScript feature
called XPCNativeWrapper, which ensures that the function being run is
the native one rather than one defined on the page, and a new
structure placing GreaseMonkey above the document root, so that the
document cannot override the functions in the GreaseMonkey script.

Boodman pointed out that GreaseMonkey can be useful for prototyping.
It's much easier to try out a feature in JavaScript than to rewrite
one's Web pages, although ultimately the feature should be implemented
in a more traditional and robust manner. He also claimed that Web
sites benefit from being hacked up by users through GreaseMonkey: the
sites get new features for free and end up with happier users.

Miguel de Icaza on desktop advances

The OSCon organizers saved the ever-popular Mono designer Miguel for
the closing keynote, and I wager it helped to keep people around at
the conference. He demonstrated the somewhat hallucinagenic 3D
effects Novell has achieved in the X Window System by integrating the
Cairo vector graphics library and Xgl, an X server based on OpenGL so
it can use hardware. Watching Miguels' windows wriggle, fly toward us
and back, and wrap around, I was reminded of a demo
of Sun's
Looking Glass
I saw a year ago. I found Looking Glass even more pleasing
aesthetically, but I haven't heard anything about it recently.

A Java developer told me at the conference that one of the biggest
weapons Novell can wield in trying to persuade customers to migrate
from Windows to Linux is to tell them Mono will let them keep all
their ASP.NET scripts working. And that was one of Miguel's themes at
the keynote.

He also said (with his characteristic flippant bluntness) that Novell
is finding out "what is wrong with the Linux desktop" by gradually
migrating its entire staff to it (they are 50% done). They perform
extensive user testing, with three cameras on each user to capture
their behavior.

Key areas where they're working now include making hardware work, and
implementing missing applications (although I've seen other
implementations of some apps he showed). Some of the new applications
include iFolder, which keeps different systems in sync, a media player
with ipod synchronization and CD burning, and the Beagle search tool
(which I covered in an

earlier blog

Short takes

Wez Furlong introduced PHP Data Objects (PDO). The goal of PDO is
pretty much the same as its Perl counterpart, Perl DBI, of Java's
JDBC: to provide a portable interface that can let people use a
database application with a different database engine without having
to rewrite the library calls. (The SQL, in all these cases, may still
have to be rewritten because no two database engines have quite the
same SQL interfaces.) Furlong did not demonstrate any other strong
advantages to using PDO instead of PEAR DB or even a database-specific
library. PDO implemented various features such as error reporting and
streaming results (forward-only cursors) in its own way, but didn't
break new ground that I could see.

Randy Ray

had an unmatched opportunity for forty-five minutes to tell a
completely full room why they should use SOAP for some projects
instead of relying on REST. He did not succeed. Because he didn't get
through all his slides, I can't tell whether he tucked some knock-out
argument in the last ones. But I would expect a talk like that to
explain why standard object-oriented virtues--such as strong type
checking and routine error reporting--were sometimes useful in Web
Services. I didn't detect any such argument. Instead, he focused on
things I find irrelevant, such as the freedom with which REST
applications can define protocols. He did generously remind the
audience of XML-RPC and suggested it as a half-way measure between the
loose, light REST approach and the heavy-weight SOAP approach.

As you can tell, while I stated at the beginning of this blog that the
choices of topics at OSCon were outstanding, some of the presentations
did not live up to their potential. Usually I was glad I went and
learned something--there is no doubt that the presenters knew and
cared about the material--but I sometimes felt either that the
presenters focused on aspects of the subject that weren't the most
interesting to me personally, or that they didn't go into enough

On the other hand, an unexpectedly delightful


on how to adopt open source in business was delivered by Kartik
Subbarao of Hewlett Packard. I won't try to reproduce his perky
analogies, in which poor open source utilization comes out as a swamp
and effective open source utilization comes out as Venice. I'll just
mention that his insights align well with those in our recently
released book,

Open Source for the Enterprise
Subbarao ended with an invitation to work on the
HP Linux Common Operating Environment (LinuxCOE).

David Heinemeier Hansson offered another interesting


about the philosophy that made Ruby on Rails a success.
He concentrated on three reasons:

  • It places convention over configuration, meaning
    that the designers guessed what people want and try to provide the
    right defaults so there's minimal configuration. (People can override
    the defaults if they want.)

  • Change is instant: you don't have to recompile or copy something to a
    server; just refresh. (The language characteristics of Ruby make this
    possible: introspection, open classes, and code execution within class

  • The system is complete and integrated, from JavaScript on back to the
    database engine. Nothing is left for the user to do in some other
    component of the system.

In short, "constraints are liberating."

Asa Dotzler, Community Coordinator of Mozilla Foundation, delivered a

keynote on a few basic things

the Linux community can do to bring desktop use to the masses sooner,
such as slowing down library changes to ease application development,
and cutting down on the slew of configuration options in applications.
(Editorial complaint: nobody should talk about the confusion of
configuration options in open source applications until they're tried
to do something basic such as turning off color printing on Windows.)
He pointed out that Linux enthusiasts like to concentrate on porting
more and more hardware, but that a lot could be accomplished apart from
hardware through "low-hanging" fruit such as the ones he described. An
audience member mentioned that this philosophy of simplification lies
behind the popular Ubuntu distribution.

Biologist Drew Endy discussed

Open Source Biology

in his keynote. On eBay you can buy equipment that let you change an
organism's genome. There are many exciting (and perhaps scary)
applications of this, but due to the imprudent legalization of
patenting genes, many useful biological functions cannot be
manipulated without permission from some discoverer.

Endy also warned about the quality of the programmed organism (this is
the scary part), and risks of other intellectual property claims. In
several notorious cases, GE crops have turned up where they shouldn't,
because nature doesn't recognize property boundaries or license
agreements. But Endy also asked whether reverse engineering would be
possible or legal so that users could take control over their
crops. He finished by saying that the public must be brought into
these discussions, as with open source software, and announced the
founding of an organization with this goal.

This is still nearly the only conference where I expect the keynotes
to be interesting--and where they routinely exceed expectations. I
expect OSCon to continue to increase in size, and for the field of
open source to continue providing good fodder for it well into the

Earlier blog on this conference:

OSCon: Developers and testers as heroes