Of all the conferences that I attend, ApacheCon is different, because I am an "insider". As with all conferences, the technical program is a piece of superstructure that facilitates the human part of the program. Since ApacheCon is one of the few times for Apache folks to gather in person, I find that the human track is much more important than the technical track. It's a time to have those high bandwidth conversations that don't happen over e-mail, to catch up with old friends, and to find some perspective on what is happening all around the Apache Software Foundation.

This year in the "official technical track", I worked with David Recordon, Paul Querna, and Justin Erenkrantz (thanks!) to get all of the Heraldry committer accounts created and Jira accounts setup. That process has been dragging out and it was one of my big goals to get that unstuck so that we can get going. That work paid off handsomely, because a bunch of code showed up in SVN on Wednesday. So now we can get on to the business of getting the community going.

I also talked about Heraldry in the Incubator Fast Track, a set of lightning talks focused on projects that are currently in the ASF Incubator. This is the first time that I've attended / participated -- I'm not sure if this was done at ApacheCon Europe this year or not. It's the kind of thing that just obviously makes sense, and you wonder afterwards why it took so long. The session took up two session lengths, and there still wasn't room for everyone who wanted to participate. I heard the best quote of the conference during this track. It was during one of the web services talks, and the presented described the WS-* stack of web services protocols as the "WS Death Star".

I attended Sally Khudairi's media training tutorial for an afternoon. I've been interested in getting some kind of media training for a while now, so I jumped at the chance to get in on this one. This was really "basic" media training, which focused on speaking to people, understanding how much information that you (as a technical person) are throwing at a journalist or analyst, and a bit about the world of a journalist or analyst. Sally kept it very interactive and experiential, which I really appreciated. She was able to get Michael Cote from the Redmonk analyst firm to come and do mock press briefings with us, which was great. I've been a follower of the Redmonk blogs for quite some time, and it was great to meet Cote. He and I had several good conversations during the course of the Con.

Brian Moseley from OSAF did a great job talking about Cosmo. When we submitted the presentation earlier in the year, it was directly applicable to Apache since we were using Jackrabbit as our storage engine for Cosmo. Unfortunately, since then we've had to replace Jackrabbit with a Hibernate based storage layer, so the relationship to Apache projects was not as obvious. Nonetheless, there was a decent turnout (especially for the first talk on the last day), and people asked engaging questions.

On the human/social track, I participated (as usual) in the PGP key signing (don't worry folks, cabot will be filling up your mailboxes soon). This was a little depressing for me. Before my laptop was stolen this year, I had one of the most highly cross-signed keys in the foundation, including signatures with/from people who only attended a single ApacheCon. Having to revoke that key and start over was one of the most bitter pills to swallow on the laptop scene.

I also spent a lot of time talking to Stefano and David Reid about RDF and mod_sparql. I hadn't seen Stefano in several years, and it was really fun just to see him and catch up on all the doings.

The photography walkabout/BOF never happened -- the biggest cause for this was that sunset was around 7pm, and this year the social scene at ApacheCon was really active. During the conference proper there was at least one event (sometimes two) every night. Wednesday night was the keysigning, which I couldn't miss, and Thursday there was the Lightning Lottery Talks, which are a must see. So we ended up with nothing. That doesn't mean that there wasn't a lot of shooting going on. I saw a good number of SLR's and lots of point and shoots. The active social scene provided lots of photo opportunities as well. In fact, this year, most of my shots are from the social activities and not the conference. There are only so many photos that you can take of people sitting in a room listening to someone talk -- same goes for the exhibit halls. In addition, I wanted to do a mini photography project showing various ASF folks in a more human setting. So as we made our way up and down Sixth Street each night, there were plenty of opportunities to shoot, and to interact with other shooters. Torsten Curdt took a bunch of really nice photos and Andrew Savory was around a lot with his Rebel XT. I met Debbie Moynihan of IONA when I noticed a camera strap with "EOS Digital" hanging out of her handbag - another Rebel XT.

Several people have asked me about my shooting at the show, so this next bit is for them. I shot a total of 733(!) frames and posted 159 of those. That includes test shots that I took to figure out the exposure for some of the club/party shots. The whole set of photos is here (Leo, I remembered to change the license this time). Thanks to Ken Coar for annotating the shots of his amazing lightning talk.

My photos from ApacheCon are up on Flickr...

"Me too"

• Get my new PGP key cross signed
• Make some good progress on Heraldry stuff
• Hook up with some Abdera folks
• Talk to David about mod_sparql
• Add my FOAF to the committers info
• Go to sk's media training tutorial
• Do a photography walkabout - the austin bat bridge is on my list

This year's ApacheCon US starts in less than a week in Austin, Texas. In addition to the regular ApacheCon activities, I'm interested in organizing a photo walkabout, similar to the ones that James Duncan Davidson has started doing at the conferences that he's attending. So if you're interested, or you know good spots to shoot in Austin, leave a comment or send me mail -- please say whether you are around for the tutorial days.

[via Kim Cameron’s Identity Weblog » Microsoft’s Open Specification Promise ]:

Today marks a major milestone for Mike Jones and myself.

Microsoft announced a new initiative that I hope goes a long way towards making life easier for all of us working together on identity cross-industry.

It’s called the Open Specification Promise (OSP). The goal was to find the simplest, clearest way of assuring that the broadest possible audience of developers could implement specifications without worrying about intellectual property issues - in other words a simplified method of sharing “technical assets”. It’s still a legal document, although a very simple one, so adjust your spectacles:

This is a big step for Microsoft, and so far the details look good. The OSP covers a raft of web services specs, including a few that are important for digital identity. The promise extends not just to spec implementors but down the distribution chain, which is essential to being open source friendly, and there's no registration or notification of Microsoft required.

In the coming days, I am sure more legally savvy folks will look the document over, but so far Larry Rosen and Mark Webbink [Deputy General Counsel at Redhat] believe (via the Microsoft OSP FAQ) that the OSP is compatible with FOSS community requirements.

People that are aware of OSAF are usually aware of Chandler, not as many are aware of Cosmo. Cosmo started its life as the sharing server for Chandler, but over time Cosmo is going to bring quite a few ideas from Chandler into a web based UI. Our goal is to have both rich desktop client and rich web client access to your Chandler data, so that you have a choice of whichever interface appeals to you the most. The Cosmo project is much younger than Chandler, so it is going to take some time to reach that goal.

Several weeks ago, we found ourselves in need of a new manager for the OSAF engineers working on the Cosmo project, and I agreed to take over those responsibilities. Lots of people who read this blog have talked to me about Chandler in the past, so I wanted you to be aware of what is happening with me and Chandler. You can keep talking to me (and any other contributor to the Chandler project) about Chandler, but you can also talk to me about Cosmo and stuff in the web space.

I also wanted to make you aware that we have two openings for people to work full time on Cosmo. The last time I posted about jobs at OSAF, we got PJE, who has helped tremendously on Chandler, so here I am again. Please use the link if you are interested.

As always, if you are looking to stay up to date on what is happening with Chandler and Cosmo, you should subscribe to one or more of our mailing lists.

I am so backlogged on posts that I am tempted to declare total blogging bankruptcy. I"m suffering a bit of insomnia, so I'm going to see if I can kick myself back into posting...

Fitz and Ben Collins-Sussman have posted the slides from their awesome OSCON 2006 presentation: How Open Source Projects Survive Poisonous people (And You Can Too). I promised to link their slides when they went up, and I'm only a month late, which just goes to show how deep the backlog goes.

It's becoming increasingly hard for me to do a decent job of blogging conferences in anything approaching real time. The face to face time is so rare and precious that it's hard to justify dropping hours of sleep to do the analysis and posting, especially when I am already dropping hours of sleep just to keep up with the face time.

Instead of going to the tutorial track, this year I once again attended a meeting for people working with the non-technical end of open source foundations. I haven't been able to get to every meeting (some are in Europe), but I've found the gatherings to be very informal. Last year, I learned an enormous amount about what is happening in the Eclipse community, and I think that it's worthwhile for open source people to be aware of the things that are happening at Eclipse, particularly if your community is going to interact with companies.

This year there were a pair of topics that stood out to me. Zak Greant of the Mozilla foundation discussed how he is using a bug/issue tracker to deal with community issues. This sounds like a no brainer kind of activity, particularly for open source projects, but I am not aware of any other community that is making use of this practice. I think that Zak is going to put up some documentation on what he has been doing, and I plan to link that when it goes up.

The second topic was kind of a side discussion on the topic of how to explain open source software to non computer people. Two of the phrases or labels that caught my attention were "green" software and "organic" software (as in organic food). I don't know whether these are the right labels for the job, but the whole notion of applying food labelling to software and technology issues is an interesting one.

The OSCON program looked much stronger to me this year. There were several slots where I had to make tough choices about which talks to attend. Also, this year there was a much larger number of talks on community building and other soft topics (not including business topics, of which there have been many over the years). While writing up this summary I realized that the only technical talk that I attended this year was the presentation that some OSAF'ers gave on Cosmo and Scooby, our web projects. This happened partly because I inserted a few "hallway track" sessions. But it happened mostly because I prioritized community/soft talks over technical ones. OSCON is a conference about open source. The whole point is that any "outsider" ought to be able to go to a project's web site and get up to speed by looking over the documentation and other materials that are available. If that can't happen, then either the "outsider" can't read, or the "insiders" can't write. So while it would be nice to sit in a session to get the scoop on a topic, I ought to be able to find that information on line somewhere. My view of open source, heavily influenced by my participation at Apache, is focused on the community aspects, not the licensing or technical aspects. The community building part is the hardest part of open source and plays a huge role in determining whether projects are successful over the long term. More than anything else, I think that these topics are the "secret sauce" of open source.

The best talk of the entire conference was Brian Fitzpatrick and Ben Collins-Sussman's talk How Open Source Projects Survive Poisonous People (And You Can Too). This was a hugely practical talk on dealing with difficult people. Part of the reason that their talk was so practical is their opinion that a strong community is the best defense when dealing with difficult people. So not only did they discuss difficult people, they also discussed what a healthy community looks like. Fitz and Ben are developers on the Subversion project -- Fitz is also an a Apache guy -- as is Karl Fogel, author of Producing Open Source Software. I think that the Subversion team's work in helping people understand community building is growing to be (at least) as significant as the work that they are doing by producing Subversion itself. I hope that Fitz and Ben will be posting their slides soon.

Other talks that I really liked: Jeff Waugh's talk on the Ubuntu community. It was a tough choice to go to this talk because it was opposite the panel "The Art of Community" which had some friends on it. For some reason that I can't explain, I had not really looked carefully at the governance and community organization of Ubuntu. The problem is now rectified, but I wish that I had paid attention sooner (kind of like Eclipse). Jeff started by talking about shared vision and shared values. I think that it is somewhat common for open source projects to have some kind of (codified, even) shared vision. It seems to be less common that they have explicitly thrashed out what the shared values of the community are. That lack of values is one of the sources of tension in communities. I am very interested in a lot of the things that the Ubuntu folks have done.

r0ml was all over the place at OSCON -- I think that he gave 3 presentations, including a keynote. Having sat through the first two parts of his "The Semasiology of Open Source", it was "inconceivable" that I would miss the final portion. As always with r0ml, the presentation skill and style is as much the draw as the content -- look for the audio when it hits IT Conversations.

Karl Fogel gave a great session on tools for facilitating open source communities. I am definitely an admirer of Karl's work, and it was great to meet him in person after the session and tell him a bit about the impact that his book is having amongst people that I know. One of the things that I have been thinking about is the need for better tools to facilitate the entire open source process, and Karl has been doing some good thinking about this, which he shared in his talk. I hope that he will be posting his slides or some other kind of write up soon.

I've already gone on record as being "not a fan" of the 15 minute keynote format. I'll make an exception for r0ml's 15 minutes of presentational virtuousity. However, the other two keynotes that got my attention were longer than 15 minutes. Damien Conway did a wonderfully entertaining keynote lampooning various product oriented keynotes. I can only assume that his keynote was inspired when something inside of him snapped. This keynote will not translate well to podcast, since you'll miss some of the accompanying video cues. I hope that somehow the full video winds up on the web. Eben Moglen delivered a speech that epitomizes what I think a keynote should be. He started by taking on Tim O'Reilly's question "Do licenses matter?" and showed why in this day of "open source triumph", licenses still do matter, why the desktop and pant's pocket are still important, and called upon the open source community to do their part in answering the question "do users have rights?".

Last year's OSCON was the first conference that I attended with a camera, and a photo that I took accidentally (I messed up the white balance setting)

accidentally (I didn't consciously enter - all you had to do was tag photo's the "right way") made the final group of the HP sponsored photo contest.

This year I actually paid attention to the directions and consciously entered some photos. I was very happy when one of my photos was selected as one of the grand prize winners:

My thanks to the gentleman that allowed me to take this picture (I asked before I took the shot). You can see the other prize winners here, and you can see all the photos that were entered here. There were lots of good photos taken for the contest, and I am happy that my skills with a camera are improving.

[via Hack the Planet Innovation Happens Elsewhere ]:

Ron Goldman & Richard P. Gabriel posted Innovation Happens Elsewhere, their book about corporate participation in open source projects.

Well, not really, but maybe I had Scoble and Podtech worried for a nanosecond.

Rich Bowen and David Reid have started up the "Feathercast", an unofficial podcast featuring interviews with people from around the Apache Software Foundation.

Guys, a request -- better filenames!

Hanna Wallach and Chris Ball convinced the GNOME Foundation Board to fund some summer project slots for women, using the money that GNOME received from Google for participating in the Google Summer of Code.

If you know young women who are still available for some cool summer hacking, pass the word along!

Mitchell Baker wrote an interesting post about The "community" and decision-making. She finishes with the important point:

Other projects may invoke the authority of the ultimate decision maker more or less often. The important point is that many open source projects incorporate clear decision-making into their processes.

There's some worthwhile perspectives on leadership in the comments.

Back in April Henri Yandell wrote an interesting post about the ASF's community mantra titled "How we lie to ourselves". In that post he contrasted "despot" driven projects and community driven projects, and he used Codehaus as an example of an organization that focuses on despot driven projects. Of course, he could have equally well used Linux, Python, or any of a number of fine open source projects as his example.

The term "despot" (or to use the Python community's label, "Benevolent Dictator For Life") inserts a lot of unhelpful color into this particular discussion. It is very rare to find a human endeavor in which no one displays that quality known as leadership. Sometimes it takes on the form of articulating a vision. Other times it takes the form of doing whatever needs to be done. In other settings it means stepping in to cool a raging discussion between project participants. There are various kinds of leadership, and all of them are necessary in a project of any size. As Henri points out, even ASF projects contain people who act like leaders - title or not.

I like to think of the two viewpoints this way: If you want to look at leadership as giving someone authority, then there are two kinds of authority. There's positional authority. That's where you give someone a title and then people follow the instructions of the person with the title. But there's another kind of authority, which is much more powerful (at least I think so). Call this relational authority, the authority that stems from the relationship that you have with another person. We all have (I hope) people that we trust enough that we let them "tell us what to do". We've given those people a place of "authority" in some sphere of our lives. In the "despotic" projects that I've observed up close, in every single one of them, the despot had gained significant relational authority, in addition to whatever their supposed title conferred.

A few more thoughts from "The Success of Open Source":

On the nature of open source leadership:

While leaders of other large projects have different personality traits, they do tend to share an attitude that underemphasizes their own individual importance in the process. And they share, more importantly, a commitment to invest meaningful effort over time in justifying decisions, documenting the reasons for design choices and code changes in the language of technical rationality that is the currency for this community

Because anyone can join and leave at any time, the leader is in a sense more dependent on followers than the other way around. The core question then becomes, How can a leader fail his followers? The simple answer, which captures the unusual power dynamic, is "lack of responsiveness to those led."

On the nature of the core freedom of open source (which is actually a freedom of community as opposed to property):

Albert Hirschman's classic argument from Exit, Voice, and Loyalty is a useful metaphor here. While the open source process certainly encourages the use of voice, open source licenses are design explicitly to empower exit rather than loyalty as the alternative when voice fails. The core freedom in free software is precisely and explicitly the right to fork.

In other words, positional authority without relational authority is moot, and the community is always free to vote with its feet.

I finished Steven Weber's "The Success of Open Source" a while ago, but it's taken me a while to make my note-taking pass, and even more time to figure out how to get a decent post out of my notes. Getting this post out has been holding me back from really digging into The Wealth of Networks, so here goes. Weber looks at the phenomenon of open source through the lens of political economy. The major questions from this view point are about motivation of individuals, coordination, and complexity.

One of the interesting conceptual handles that I took out of the book was Conway's law:

In 1968, Melvin Conway made an argument about this relationship that software developers now call Conway's Law. This is the idea that the structure of the (technical) system mirrors the structure of the organization that developed it. According to Conway, it is first and foremost a consequence of the communication needs of the people building the system. The computer scientist David Parnas takes this argument a step further by defining a software module as "a responsibility assignment" for a piece of an organization first, and only secondarily as a subprogram.

The open source process relies on a foundational consensus around technical rationality -- that is its stake driven firmly in the ground. It is actively evolving organizational structures around that stack. Thus open source developers really are forced to live by the lessons of Conway's Law. The architecture of the technical system drives the organization, rather than the other way around.

The reason Conway's Law actually works in favor of the open source process is that early architectural formulations are approximations are are always unstable. The formal hierarchical organizations that enclose proprietary software development are resistant to change and often end up driving the technical architecture (the dysfunctional flip side of Conway's Law). In the ideal case the organization should follow this organization rather than lead it.

Conway's Law definitely provides some more food for thought when look at the ASF's community is more important than code mantra.

A key notion in the "commons movement" is that of non-rival goods. Weber takes this a few steps further and gives us another term, "antirival" goods:

I believe the solution to this puzzle lies in pushing the concept of nonrivalness one step further. Software in many circumstances is more than simply nonrival. Operating systems like Linux in particular, and most software in general, actually are subject to positive network externalities. Call it a network good, or an antirival good (an awkward, but nicely descriptive term). In simpler language, it means that the value of a piece of software to any user increases as more people use the software on their machines and in their particular settings

The point is that open source software is not simply a nonrival good in the sense that it can tolerate free riding without reducing the stock of the good for contributors. It is actually antirival in the sense that the system as a whole postively benefits from free riders.

The twist is this: Under conditions of anti-rivalness, as the size of the Internet-connected group increases, and there is a heterogeneous distribution of motivations with people who have a high level of interest and some resources to invest, then the large group is more likely, all things being equal, to provide the good than is a small group

I think that the issues of governance and culture are going to become more important as familiarity with open source practices continues to increase both in software and other fields.

The Internet does not solve foundational problems of organizing complexity. It does not create working divisions of labor. Reducing or even removing the costs of geographically widespread and time-dependent collaboration is important, but that effort still leaves other collaboration costs unsettled -- decision making, human emotion, resolution of technical uncertainties, and so on. In principle, the Internet can increase these difficulties because it can be set up (and in the open source process, is set up) to be non-excludable

When I use the term "governance" in this discussion, I am using it in the way it is used in international relations. In that context "governance" is not government, it is typically not authoritative, and in fact it is not about governing in a traditional sense as much as it is about setting parameters for voluntary relationships among autonomous parties. Given that perspective, the central question becomes, How has the open source process used technology along with both new- and old-style institutions of governance to manage complexity among a geographically dispersed community not subject to hierarchical control?

Weber uses developments in modern religious communities as another example of reversing power dynamics in communities. I've observed this myself in some (but not all) religious communities.

More generally, there has been a dramatic shift in what it means to be a leader in a religious community. Change the foundations of property, and you change the network of relationships that radiate outward from that which is owned, in fundamental and unexpected ways.

I will come back to this point later when I discuss power and communities; but for the moment, recognize an interesting corollary. In nonauthoritative settings -- that is, in relationships primarily characterized as bargaining relationships -- power derives in large part from asymmetrical inter dependence. Put simply, the less dependent party to the relationship (the one who would be harmed least by a rupture) is the more powerful. In the kinds of modern religious communities I am talking about here, it is the leader who is dependent on the followers more than the other way around. This dependence changes the dynamics of power. Leaders of open source projects understand the consequences intuitively -- the primary route to failure for them is to be unresponsive to their followers. In Hirschman's terms, this is a community that empowers and positively legitimates exit while facilitating voice.

There were several interesting points around open source and innovation:

Innovation starts from the edge and migrates to the center as it proves itself -- there is a meritocracy of ideas as well, at least ideally.

End-to-end innovation goes a step beyond simply reduced transaction costs. It enables parallel processing of a complex task in a way that is not only geographically dispersed but also functionally dispersed. End-to-end architecture takes away the central decision maker in the sense that no one is telling anyone what to do or what not to do. This is the essence of distributed innovation, not just a division of labor. There are no weak links in the chain because there is, in a real sense, no chain. Innovation is incentivized and emerges at the edges; it enters the network independently; and it gets incorporated into more complex systems when and if it improves the performance of the whole.

This is of course an idealized version of the story. An end-to-end technological architecture may indeed be truly neutral, but technology does not exist on its own. The political and organizational interfaces that touch the technology and link it to human action typically are biased.

The underlying problem here is to specify general organizational principles for distributed innovation, a problem solving algorithm that works. The open source process suggests that there are four principles:

• Empower people to experiment
• Enable bits of information to find each other
• Structure information so that it can recombine with other pieces of information
• Create a governance system that sustains this process

The search problem of local vs global maxima applied to the innovator's dilemma at the level of individuals.

Distributed innovation systems like open source have a simple advantage here that helps compensate for the inherent tendency to stick to debugging an existing architecture. Any single open source developer might suffer from individual versions of the innovator's dilemma in her own decision making about where to invest her time, but the decision as a whole remains disaggregated among the community. ... Ultimately the freedom to fork code distributes much more widely the ability to make different bets on the exploration-exploitation trade-off, and that raises the probability that on aggregate some decisions will pay off. Put simply, end-to-end innovation systems depend on a market logic of disaggregated decisions rather than on a central intelligence to manage the innovator's dilemma.

The challenges facing the application of open source techniques to areas like user interface design.

But it is possible that end-to-end innovations systems will generally underperform in these specific kinds of user interface settings, for two related reasons. Some programmers believe that understanding direct user experience requires extensive physical interaction -- that is focus groups, not internet mailing lists. The more general point here is that design for components like user interfaces still rests on the transmission between individuals of a great deal of tacit information. This requirement makes it difficult to modularize and difficult to develop in parallel distributed settings. End-to-end innovation systems lack a good mechanism for getting at the underlying concepts of tasks like this in novel ways. That may change as advances in information processing move more human experiences out of the tacit realm and into communicable forms, but for now this seems a notable constraint.

Standards and open source: Open source aids standardization preventing the gaming of standards as described in Information Rules: A Strategic Guide to the Network Economy. I wish that open source was doing better at benefitting standardization as a source of unencumbered implementation experience.

In other words, releasing source code is a credible commitment against the possibility of using a standard for technological lock-in and hold up. Proprietary standards cannot make this commitment in the same way.

The success of open source is introducing many kinds of tensions between markets and communities. Weber has an interesting idea for looking at the needs of markets and communities:

In this kind of discourse, the failure of a community to take shape because of high transaction costs is just as much a market failure as is the nonevent of a contract to exchange money for widgets that would make both sides better off but does not happen because the widget owner can't find the buyer. The perfection of markets and the realization of potential communities are theoretically identical.

Weber believes that the next steps in research on open source have a lot less to do with transaction cost economics:

I do not have a full-fledged model to propose at this point, but I suspect any model will have to focus on at least two factors that transaction cost economics does not emphasize. The first is the relationship between problem solving innovation and the location of tacit information, information that is not easily translated into communicable form. ... The second is the importance of principles and values, in contrast to efficiency as an organizing concept.

A few days ago I commented on the difference between projects using open source methodologies and those which are loosely inspired by open source methodologies. I emphasized the governance end (meritocracy vs democracy). Weber also adds the property regime.

Many of these projects gain their ideological inspiration from the open source process and tap into some of the same motivations. Many are interesting experiments in using Internet technologies to organize volunteer efforts and affinity groups. But in many instances, these projects are not organized around the property regime that makes the open source process distinctive.

[via Scripting News: 5/31/2006 ]:

Jaron Lanier has written an essay on problems with the Wikipedia, presumably in response to some of the recent blog posts about the death of the Wikipedia. The paragraph below is the one that struck me the most.

And that is part of the larger pattern of the appeal of a new online collectivism that is nothing less than a resurgence of the idea that the collective is all-wise, that it is desirable to have influence concentrated in a bottleneck that can channel the collective with the most verity and force. This is different from representative democracy, or meritocracy.

Many people associate the Wikipedia with open source software, and while there are similarities, there are also important differences. I've run into plenty of people who believe that open source software is run by some kind of democracy. None of the good open source projects that I am aware of are democracies. All of them are meritocracies. I see this fundamental misunderstanding frequently when I talk to people, and I see it when people try to use "open source" as an adjective to apply to their favorite project which leads to open-source journalism, open source radio, and so on. Most of these things tend to be like Wikipedia, sharing some qualities with open source, but differing in other important respects.

Lanier makes a stop along the way to comment on some of those differences:

Here I must take a moment to comment on Linux and similar efforts. The various formulations of "open" or "free" software are different from the Wikipedia and the race to be most Meta in important ways. Linux programmers are not anonymous and in fact personal glory is part of the motivational engine that keeps such enterprises in motion. But there are similarities, and the lack of a coherent voice or design sensibility in an esthetic sense is one negative quality of both open source software and the Wikipedia.

These movements are at their most efficient while building hidden information plumbing layers, such as Web servers. They are hopeless when it comes to producing fine user interfaces or user experiences. If the code that ran the Wikipedia user interface were as open as the contents of the entries, it would churn itself into impenetrable muck almost immediately. The collective is good at solving problems which demand results that can be evaluated by uncontroversial performance parameters, but bad when taste and judgment matter.

I am not as pessimistic as Lanier about the ability of the open source process - note that I said process and not community - to produce a high quality user interface/experience, but I will readily agree that we have almost no examples of such an interface to point to as proof. But recall the some open source projects are run on a "benevolent dictator model" and that some of these projects have been able to produce products (in their domain) imbued with a strong aesthetic sense -- the Python and Ruby languages come to mind here - at least according my sense of aesthetics.

I've just posted the details of OSAF's Summer of Code projects on the OSAF blog. If you are a college student looking for something to do this summer, I encourage you to check it it - hurry, the deadline is May 8. If you don't find an OSAF project that interests you, there are plenty of other organizations sponsoring projects. They definitely didn't have anything like this when I was in college...

If you are interested in design and user experience, you might consider popping in for DCamp on May 12th and 13th. I was conveniently scheduled to be in San Francisco for the week preceeding, so I'll be extending my stay in order to attend, along with a few other folks from OSAF. We're particularly interested in talking / brainstorming around the topic of design in open source and/or distributed projects. If you are interested in this topic and have ideas or questions that you want to share, please leave a comment or send mail.

My copy of Yochai Benkler's "The Wealth of Networks : How Social Production Transforms Markets and Freedom"
is on its way from Amazon. In the meantime I'll be looking over the PDF.

Larry Lessig is strongly endorsing it.

Mitch Kapor has a new blog up. In addition to Chandler, Mitch is involved with a number of things, including Second Life and Foxmarks.

I've posted a Chandler - Quicksilver integration hack over at the OSAF group blog.