I believe that I am the developer that Scoble mentions in his post about Mitch and the Creative Commons:

I know a developer working for you. Is he working for free? I don't think so. He has mouths to feed and a mortgage to pay off.

I'm not quite sure how Robert got from the Creative Commons to working for free, but that's not actually the point of this post. This is just a good excuse for me to explain my personal motivations for doing what I'm doing. What you are about to read is my personal opinion and does not represent the views of the Open Source Applications Foundation or the Apache Software Foundation.

Dave Winer's prediction that "the term open source will mean nothing" has been true for a while. If you doubt that, go over to IT Conversations and listen to r0ml. I don't subscribe to the ideology that all software must be free for all people. What I'm doing is called commons-based peer production of software, which is an economically justified set of techniques for constructing information products that happens to look at a lot like what we call "open source". There's nothing about that which says software has to cost zero dollars. What you need is a way to make the information product available so that the highly efficient resource matching that is at the heart of commons-based peer production can kick in. Today, in what we call open source, that is done via source code licensing. It doesn't mean that's the only way to do it. We're still in the infancy of all types of commons-based peer production. But the key point is this: Benkler's work says that for certain kinds of information products, commons-based peer production is the most efficient method of allocating resources in order to get the job done. No free as in beer ideology or free as in speech ideology needed. No destruction of the notion of intellectual property required. Just simple hard nosed economics. People/creators can and do get paid while doing this. In fact, that's how I'm getting paid right now.

Since 1999 I've done a bunch of this kind of work in the context of non-profit foundations, the Apache Software Foundation, and the Open Source Applications Foundation. These foundations are important to developers because they provide a legal umbrella and governance structure to ensure that developers are protected from lawsuits and to ensure that legal and ethical standards are upheld in the development of software. But it goes beyond that. If you accept the notion of a software commons in the sense of the commons as described in Lessig's various works, then these foundations serve another purpose: They hold pieces of software in trust for the public. This is part of the reason they are chartered as 501(c)(3) corporations -- they have a responsibility to the general public. There are certain pieces of software that are so important (operating system, web server, web browser, and the list is growing) that it is in the public interest for there to be version of each of these types of software in a public commons. One of the many means of protecting such a commons is via intellectual property law, including copyright and patents. If you remove the protection of intellectual property, you also remove a very powerful protection for the commons. People are also getting paid to work on these commons. When I worked at IBM I got paid to help construct part of the ASF commons related to XML.

So, the next time you hear "open source development", think "the most economically efficient method for matching resources to construct information products". The next time you see "XXX Software Foundation", think "people constructing a software commons (protected by intellectual property laws) that the rest of use can use and extend". There are more things that you should think, but that's enough for one post.

I agree with something that Dave Winer has said in the past, which is that some of the best blogs are the ones where you can watch people flesh their ideas out and learn along with them.

PJE is continuing his explorations with predicate dispatching, and you can follow the evolution of his thoughts:

On Wednesday:

Generic functions aren't always a substitute for adaptation and interfaces, however. Technically, a generic function can do anything that you can do by adapting to an interface and calling a method, but sometimes interface+adaptation is a better "metaphor" for what's going on, or a more convenient or expressive way to do things, especially for documentation. (For example, the interface I left behind in the new implementation was purely for documentation purposes.)

By Friday:

I'm beginning to think that predicate-dispatch generic functions capture something really fundamental about computation, or that at least they're much more fundamental than interfaces or adaptation. As useful as interfaces and adaptation are, they're actually pretty cumbersome compared to generic functions.

Now, this second insight is exactly the point of the predicate dispatch work, that it unifies single dispatch, multiple dispatch, ML style pattern matching, predicate classes and more. It's also important because there is a way to implement this efficiently.

I think that there's also something else going on, which is a rewiring of what it means for a thing to be an object. Much has been made of the virtues of encapsulation in object-oriented programming, and a typical reaction to Lisp style generic functions (or Python's single dispatching object system) is that there isn't any encapsulation, and that having everything work as functions is not really object-oriented. But maybe it's the case that being "object oriented" is not the primary goal. If reduction of unnecessary code and the ability to extend the system are what's most important, then generic functions (even without predicate dispatching) are a very powerful tool. Interfaces and adaptation (which becomes necessary by virtue of the existence of interfaces) are concepts from a very object-centric view of the world. If you remove that view, then the landscape looks very different.

Elizabeth Grigg has questions about calendaring stuff:

One thing just from observing this Lightning / Mozilla spec page as well as the Chandler spec page: both projects are in an extraordinary low level of detail at the moment. There is virtually no high level thinking in the specs, which is perhaps fine for the task at hand. It doesn't help us outside observers, though. I would like to know, for both these projects, whether unseating Outlook is the cause celebre or is there something new for users in there somewhere.

As far as Chandler goes, we have a UI spec for the Calendar work we are doing for our 0.5 release (sometime in March). I'm not intimately involved with the calendaring stuff, so reading the spec is the best way to judge whether there will be something new for users there.

The other thing to know about our calendar work is that it will be based on CalDAV, a standard based on iCalendar and WebDAV. CalDAV looks like it is gaining momentum amongst calendar implementors, and if it gets sufficiently adopted, then the existence of interoperable clients and servers would definitely offer something to users: choice. The CalConnect consortium (of which OSAF and Mozilla are members) is working hard on improving interoperability amongst between calendars.