Ascription is an Anathema to any Enthusiasm

One scheme for addressing the problem of bad actors in open end-to-end networks is to guard the private/club spaces with gateways, firewalls, etc. If the bad actors are dumb then you can use simple puzzles to keep them our. A sort of child proof lock approach.

Over at telepocolypse Martin is wishing he could get one for his home phone.

““Hello, this is not a voicemail system. You still have a chance of speaking to the owner of the house. Firstly, please press 5 star hash 4 to indicate you are human. Thank you. Now please speak the name of the person with whom you wish to speak. Your entry will be compared with our database. I’m sorry, large pepperoni with extra mushrooms is not in our directory. Please try again later.””

Maybe Mr. Gates owns the patent that is keeping that from appearing in home answering machines.

One thing I was reminded of at ApacheCon was the design pattern where in you leave everything till the last possible moment. Lazy evaluation. It came up three times.

My favorite reminding was web sites that defer creating their content until the user requests it. The error handler then thrashes around till it finds a product manager, who then hires somebody to fill the demand. I see out sourcing.

Then there Doc Searles (”That’s URL with and S on each end.”) who got on about Magazine v.s. Vernacular architecture. I seem to have become less and less enthusiastic about ‘thick architectures’ for software. Though there is something pleasing about remembering that “The job of the architect is to bankrupt the builder.” Frank Lloyd Wright also said “Form follows Funding.”

The usual counter point to lazy evaluation is eager evaluation. Of course those aren’t the only two solutions to the universe of getting things done. Why there is planning, and managers (aka executive directors).

I also found out about Nagios, which has now replaced Big Sister at my house. Big sister kept giving false negatives.

I’m at ApacheCon.

A very attractive woman just ran up to me and told me my lap top is extremely cute!

You wish you were here!

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.

I got a threatening letter from my Voice over IP vendor the other day. It’s unusual to get a threatening letter from a vendor. He would like me to upgrade some software that I’m running; and apparently he felt the right tone to adopt was do this or we are cutting you off.

That behavior isn’t entirely unusual. For example a few vendors that I have relationships with force me to lie to them about what web browser I’m using. They aren’t willing to bear the QA cost of checking that their sites work with the browsers I use. Unlike my VOIP vendor some of those vendors would be very hard to switch away from.

My VOIP vendor doesn’t like something about the way that Asterisk is interacting with their servers. So it appears they hired somebody in that community to write a patch. They are emailing this patch, attached to their threat, to all their asterisk using customers. It appears that they didn’t wait for this patch to be accepted into the Asterisk source code repository. That’s amazingly stupid since it means they are forcing their installed base to fork from the main branch and thus helping to assure that their installed base won’t keep moving forward as asterisk improves.

I insist that only metric of a standard that counts if “transactions/second via the standard;” but one proxy for that is how large the installed base is folks that have adopted the standard. How far down the long tail the standard has actually spread is really important; so I may need to adjust my position. An installed base (or standard) that captures a huge portion of the long tail is good and bad. It’s very hard to upgrade, but it’s also very stable and durable.

This note from my VOIP vendor is kind of “upgrade or die;” or possibly it’s “switch or conform.” I know plenty of people who wouldn’t mind making some similar threats to large portions of the long tail of installed client software: operating systems, web browsers, mail servers. This is a interesting problem.

These little VOIP vendors are an unnatural. On the one hand attempting to displace “TPC” (aka The Phone Company”) which is probably the ultimate in durable, immovable, stable, standard, utility like operations. But they are really classic startups: rapid build out, turn on a dime, inconsistency is our tactical advantage.

It’s very hard to be both, but sending your early adopters threatening letters is kind of a bit too far over on the highly adaptable startup end of the spectrum.