This posting is about two things. I can’t or I uncomfortable with teasing them apart. One part is about how a firm blocks out the choice to add a feature versus how an open source project makes the same choice. For example if we have the bundle of software used to run a handheld computer and are are trying to decide about adding a Postscript viewer to the bundle.

The second aspect is about network effects. In our example if the viewer is added to the base system it will create a much stronger network. That results in an interesting tension in the community around our example handheld. One camp would love to see the addition of a viewer while another camp is ambivalent. Call these camp A and camp B. The tension arises because it’s a lot more fun for camp A if the entire community gets the new feature. If camp B doesn’t get the viewer then camp A won’t be able to casually exchange their Postscript files with the entire community.

Rereading Oz Shy’s wonderful little book on network effects triggered this posting. He outlines a market failure where a firm fails to reach customers with a cool feature because the firm can’t figure out how to structure their pricing so that camp A pays for the viewer while camp B doesn’t.

I’m often asked by clients if open source can help them create a network they desire. So I got to wondering about the analogy between Shy’s example and open source scenarios.

So let’s try to map his example onto an the analagous situation in an open source project.

The commerical vendor does a cost/benefit calculation. It costs so much to add the feature, and so they need to raise prices or market by a certain amount to justify the effort. The analogy in open source is that you need to find a team, call it team X, who desire the feature sufficently to cooperate to add the project.

In Shy’s example the two camps are have different willingness to pay for the feature; i.e. we have a demand curve with a step function. One camp has high willingness to pay and the other has low or zero. Team X, in the open source, case is analagous to camp A; but different.

When I read Shy’s point about how the firm has a pricing problem my first thought was: “Ok, what’s the demand curve really look like? Are there some extremely desperate folks in camp A?” Because if there are just a few desperate folks they may be willing to pay for the firm to do the whole work and then give it away to the entire installed base. For example it is possible to image a handheld firm finding a single fortune 500 company that would be willing to write them a check to do the work. That depends on the shape of the demand curve.

Folks unfamiliar with open source often assume that Team X is an extreme form of camp A. They assume team X must be really desperate since they are willing to build it! That’s not entirely true, rarely true in my experiance. In many cases Team X is unique not in their willingness to pay but rather in how easy it is for them to build it. They have extreme talent (of a very narrow kind) as a substitute for extreme desire.

That’s important. It means that your drawing the members from team X out of a population distribution that suprisingly independent from the one that was simplified into camp A and camp B.

Either high desire, or low cost increase the probablity that a member of the project community will join a collaborative attempt to add the feature.

The standard way to visualize willingness to pay is a demand curve and we can draw a similar picture for talent to implement (and other skills that increase the chance that team X succeeds). Unlike your typical economics text book these curves are not straight lines. The forture 500 company above illustrates that. I suspect these curve are typically power law in form.

You still get failures analagous to Shy’s pricing problem. First you get failures becaue getting Team X to form is hard – i.e. finding elite members of the desire population and the talent population isn’t trivial. The open source project provides a point of rendezvous but it doesn’t necessarilly engage in directed search for oportunities with the same focus that a firm is assumed to.

The second stage of the analogy comes from returning to the issue of the network effect. Members of team X desire a large network as do members of camp A. They are seeking a distribution channel that can give them a means to that end. The open source project offers the option of getting that. Gaining a chance to try and exercise that option pulls team X together. This substitutes for the commerical firm’s directed search for features that will make them money.

For the commercial firm a feature with network effect is a pricing problem; for an open source project a feature with network effect is a team builder.