Addressing the challenges of Commons Based Peer Production

Is online, peer-developed intellectual property of all kinds fundamentally flawed? Are the current purveyors of FUD (Fear, Uncertainty and Doubt) right about this new paradigm of collaborative and community-based information development? Let's look at these and other topics with respect to the kinds of innovative project development being done at SpikeSource.

As you probably know, SpikeSource is aggregating and validating open source software. Many of the free and open source software projects have been growing for years, with networks of up to thousands of developers. These networks do coordinated, commons-based peer production.

The term "commons based peer production" (CBPP), originated from Yochai Benkler's work “Coase’s Penguin: Linux and the Nature of the Firm” [Benkler, 2002]. Benkler explains CBPP with a simple economical analysis, showing how it exists alongside markets and firms as a productive modus operandi.

Aaron Krowne has articulated two laws of Commons Based Peer Production (CBPP) in Free Software Magazine entitled the FUD-based Encyclopedia. The article and laws were written to defend the FUD attacks to this mode of production by obert McHenry former editor and cheif of the Encyclopedia Britanica in his article The Faith-based Encyclopedia against the Wikipedia a online collaboratively edited encyclopedia.

In the article "FUD-Based Encyclopedia", Krowne defines CBPP like this:

...(chiefly) internet-based effort whereby volunteers contribute project components, and there exists some process to combine them to produce a unified intellectual work. CBPP covers many different types of intellectual output, from software to libraries of quantitative data to human-readable documents (manuals, books, encyclopedias, reviews, blogs, periodicals, and more).

Expanding on these definitions, Aaron Krowne articulates what he calls the first two laws of CBPP.

• (Law 1.) When positive contributions exceed negative contributions by a sufficient factor in a CBPP project, the project will be successful.

• (Law 2.) Cohesion quality is the quality of the presentation of the concepts in a collaborative component. Assuming the success criterion of Law 1 is met, cohesion quality of a component will overall rise. However, it may temporarily decline. The declines are by small amounts and the rises are by large amounts.

On Law 1:

"This factor probably has to be greater than two in practice, because each negative contribution needs a proportional amount of work to be un-done. In other words, the project success criterion is p > an, where a > 2, and p and n represent positive and negative contribution quantity, respectively.

My guess for an approximate, “universal” minimum value of a would be about 10. This value probably has to be much greater than the theoretical minimum (2), because people in social settings will be annoyed and demotivated by a smaller quantity of adversity than is actually insurmountable. In general, contributors don’t want to be spending a significant amount of their time treading water and backtracking. For example, if p/n = 3, then 33% of positive contributions are not going towards permanently improving the product.

However, I would bet that the positive-to-negative contribution ratio in many collaborative projects exceeds levels of 100 or 1000. In principle, the approximate value could be discovered empirically for particular projects. This would be a very interesting study to undertake."

This relates directly to SpikeSource's value proposition. As the complexity of linking multiple CBPP projects rises, the use of automated interoperability testing to augment the manual testing that 1000's of systems maintainers do day in and day out, becomes increasingly valuable. SpikeSource's contribution of automated interoperability testing benefits each individual project as it benefits the aggregate of them all.

SpikeSource will soon be inviting programmers who want to test their code to do so.

Law 2:

Assuring that new components contributed to the collaborative whole work are cohesive, meaning that they work very well together, is key to having these large complex systems thrive. Identifying when small regressions in cohesion value happen, and addressing them quickly with our partners, is of substantial value to increasing the quality and functionality of the OSS source code bases. Krowne adds to these to laws a corollary:

• (Corollary) Laws 1 and 2 explain why cohesion quality of the entire collection (or project) increases over time: the uncoordinated temporary declines in cohesion quality cancels out with small rises in other components, and the less frequent jumps in cohesion quality accumulate to nudge the bulk average upwards. This is without even taking into account coverage quality, which counts any conceptual addition as positive, regardless of the elegance of its integration.

Large CBPP projects like - Wikipedia - draw on a world wide community of literate people to improve the quality of these entries. The nature of free and open source software (FOSS) is a bit different.

Large scale aggregations of working code need to verify and test that changes made actually improve the code. Enterprise business systems depend on FOSS projects more and more. Verification is critical to maintaining high standards of reliability.

In another work, Krowne identified two authority models for CBPP - the free-form model, and the owner-centric model. Most of the free and open source projects in the SpikeSource stacks use the owner-centric model. Linus Torvald is the owner of the Linux project, and the Apache Foundation is the owner of the Apache projects. When one aggregates different projects into a stack the whole of the stack in effect exhibits charcteristics of the free-form model.

Krowne talks about these models in the context of encyclopedia writing - where quality, cohesion and coverage might vary.

It seems likely that these authority models have secondary consequences as well. A natural result of the free-form model may be that entries lack some cohesion, and perhaps may even be of lower overall quality, despite having high coverage. On the flip side of the coin, the owner-centric model can be expected to foster a high level of cohesion quality, but may actually lag in coverage due to higher barriers to individual contribution.

Variations in the quality of written text do not matter so much - because written text is not running computer code that either works or doesn't. Variations in the quality and therefore reliability of enterprise software projects, however, do matter.

SpikeSource's model and testing are specifically designed to meet this challenge - knowing how one change in one tool affects the functioning of the other tools. We are building a participatory testing model for the open source community to use - to enhance the value and functionality of all of the components of the stack.

links: digg this    del.icio.us    technorati