Monthly Archives: November 2004

Parallel Play

I wanting to discuss “Culture of Asynchronous Communication” with my wife, and that lead me to opine that ‘asynchronous’ seems to lack an equivalent term in colloquial speech. The word synchronous is rare too. Synchronized swimming? Then there is that classic moment when the star of the movie instructs his commando squad to synchronize their watches.

She suggested the wonderful term: “Parallel Play.”

That’s just too much fun! Metaphor loose in the hall. Tenure as parallel play? Does the creative work demand parallel play time? See also the delightful: Blogging as Parallel Play.

Culture of Asynchronous Communication

Culture of Asynchronous Communication” was for many years a cornerstone of open source development. It’s notable how little analysis has gone into that. Most open source projects are coordinated with amazingly low bandwidth and extremely high latency. This is often one of the most difficult cultural conventions for people emigrating in from other software subcultures.

One neat, but certainly unintended, consequence of that was it created an audit trail that social scientists could pick apart.

We do not know if this is a necessary element to a high functioning open source project. Is there a sweet spot in the space of bandwidth and latency? What aspects of the task domain shift the location of that sweet spot?

I am confident there is a complement to Brook’s insight that “Assigning more programmers to a project running behind schedule, could actually make it even more late.”

Adding more bandwidth and lowering latency to collaborative work can make it less collaborative.

Working Environment

Some speaker at ApacheCon thru up a list like this. I wanted to get it into my frameworks category.

A good working environment for a programmer:

  • An office with a door
  • and no phone
  • A culture of asynchronous communication
  • A fast workstation
  • and two monitors. You wouldn’t believe how much difference a second monitor makes
  • and their operating system of choice
  • Good development tools.
  • A fast Internet connection
  • Snacks and drinks they don’t need to leave the office for
  • A good-natured working environment
  • Flexible working hours
  • Tasks appropriate to their ability
  •  and if at all possible, that they find interesting
  • Investment (emotional or financial) in the end-product

This appears to be the original source: The floggings will continue until morale improves.

This is a great list as far as it goes.

But, there are some serious things wrong with this list. From the labor point of view it is is far too selfish in nature. From the manager point of view it’s reflects the what I’ve sometimes referred to as the dwarf model of labor management – “Lock them in a room with a pile of straw and wait for the gold to appear.” Organizations are more subtle creatures than that!

I’d certainly add things like effective organization, collaboration, and leadership. The no phone thing seems a bit over the top and probably redundant with the culture of asynchronous communication. Also lacking is anything about assuring the collective work is in fact collective. In fact I suspect that all the failure modes enumerated in Implementation Games could hide out in an organization that managed to do everything the list above.

You elected them.

How do you shift yet more income from the lower ends to the upper ends of the wealth distribution.

Well you could eliminate the sales tax deduction.

The Bush administration’s plan to overhaul the federal tax code includes eliminating the state sales tax deduction…

There are the old classics:

… shield interest, dividends and capitals gains from taxation, expand tax breaks for business investment …

But how’s this for a real block buster?

…scrapping the business tax deduction for employer-provided health insurance, …

That should bump a few million people off the health insurance roles.

Nation building is so much easier if you lower your baseline.

Generous

Needlepoint bookmark, reading: Be strict in what you produce and generous in what you consume.Eve Maler does needlepoint during standards meetings!

Samplers have a long tradition of teaching moral lessons to the young while presumably guarding them from the dangers posed by idle hands.

Open source has taught me that a person with a talent is an opportunity. Done right it’s fun for everybody. I suggested what the world needed some of the design principles of the Internet rendered in cross point.

Might be a best practice if standards authors were required to execute some samplers first.

Eve made that and gave it to Lauren Wood; who hopefully can display it regularly to those in need.

Curiously, my wife just acquired some very nice antique lace. Lucky her!

end to end – bad actors

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.

Lazy

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.

Paying for Features

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.

Upgrade forcing

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.