projectDiversity.equals(productivity)

I have started reading the book described in this article

In Professor's Model, Diversity = Productivity

After reading some of his book, it seems that cognitive diversity (defined as group differences in perspective, heuristics, interpretation, and prediction) generally lead to improvement in overall productivity. There are other kinds of group differences, of course...e.g. what Page calls identity differences (e.g. racial, gender, and social group), and other sorts of differences, but Page identifies cognitive differences as key.

Increased productivity is dependent upon the problem/task at hand, of course. Group tasks/problems that hinge on questions of representation and interpretation get greater value from diverse perspectives, since such diversity allows more alternatives to be generated and considered.

My thought on reading this was that many sw design tasks are like this (i.e. hinge upon how the problem is represented) and so should be particularly good candidates to benefit from teams with high cognitive diversity...and the many perspectives that come with such groups.

Interestingly, Page also identifies a type of diversity that seems to result in lower group productivity...I'll talk about that after I've read a little more.

When Self-Interest Isn't Everything

An interesting editorial by an economist in today's NY Times

When Self-Interest Isn't Everything

Is Hirschman's analysis (described in editorial) relevant for the open source 'movement'? How much of open source is/will be about self-interest?

Discovery and Access for Remote OSGi Services

See here for some work combining the ECF discovery API with the ECF remote services API.

Interesting things about this:

1. ECF APIs have multiple providers...i.e. zeroconf/bonjour and SLP for discovery, r-OSGi, ECF generic, xmpp, javagroups, and multiple flavors of JMS for remote services. This allows middleware and UI written to these ECF APIs to run unmodified on any/all of these providers.
   
2. The ECF remote services API can be used in either 'transparent' or 'non-transparent' manner...allowing programmers to decide whether network transparency for remote procedure call (RPC) is appropriate for their application...or not.

In time for EclipseCon, I intend to expose some of the Equinox p2 APIs as remote services, so that OSGi containers can be remotely provisioned and managed. If you would like to participate in this, please contact us and offer to contribute.