Category Archives: standards

Crisis, Safety, and Standards

It is often only after the horrific event that the standards and regulatory systems necessary to create a resilient safe society finally fall into place.

So some standards emerge out of post-crisis analysis. My favorite is the standards for bricks after Boston had a fire. Another classic example was a fire in Baltimore that lead to the adoption of national standards after the neighboring communities arrived only to discover that their hoses couldn’t hook up with the fire hydrants in Baltimore. After a series of recessions showed how brittle the US car industry was the Society of Automotive Engineers was able to introduce standardized parts so the supply chain had more redundancy built into it.

This story about how the San Francisco earthquake set in motion a series of events that lead to a worldwide recession and finally the creation of the Federal Reserve can be added to my collection.

… London fire-houses insured San Francisco during this period. The payment of claims by British insurance companies following the quake and fire produced a large capital outflow in the fall of 1906, forcing the Bank of England to nearly double interest rates and discriminate against US trade bills. These actions pushed the US into a recession and made markets vulnerable to shocks that otherwise would have been transitory in nature. World financial markets crashed in October 1907 …

There is what appears to be a precursor of that paper here, outside the peer reviewed journal garden walls.

The quake triggered some significant capital flows. Money flowed into the city from insurance claims, yes. But money also flowed in because the quake destroyed capital investments and created an green field that was inherently attractive to fresh capital. Presumably there are some very attractive investment opportunities left behind by Katrina. Finally these capital flows created new connections (knowledge, relationships, etc) and additional capital flowed into the region; what the paper calls sympathy capital.

Some firms left San Francisco entirely; which was good for Los Angeles. I’ve been wonder what New Orleans institutions other cities might now be courting.

Upgrade your Open Source License, Cash back on your cell phone bill!

This is a note about how to save a few hundred dollars on your Verizon cellphone bill, and why you should seriously consider switching from a BSD or old Apache style license to the new cooler Apache 2.0 license.

Standards reduce the diversity of behavior. Reducing that diversity creates efficiencies and free up resources for other activities, other kinds of diversity. In some cases the efficiencies are huge, as in the example standard of driving on the right. In other cases the efficiencies are subtle, as in knowing somebody is in your tribe and can be trusted to share a stake in the tribe’s commons.

To get a feel for how diverse a range of behaviors appears in the real world it helps if you can get a statistical distribution. For example I’d love to know the distribution over various forms of greetings: the quaker handshakes, namaste, high-five, etc.

Generally these distributions are power-law. The chart on the right shows the distribution of various open source licenses. It’s pulled from an earlier posting.

When a new kind of behavior appears on the scene you get a lot of diversity. People experiment with assorted approaches. Different people care about different things. Some people want a very short license. Some people want credit for their work. Some folks are concerned about protecting the commons. Other people want to encourage adoption. People revise sentences to make them more readable. Lawyers practice their craft, inserting proven boiler plate or look out for whatever they happen to think is in their their clients’ best interests.

These processes generate a lot of diversity, a lot of bogosity, and some innovation. Clearly the entire idea of an open source license was a huge innovation. The discovery that the license could protect the commons was huge. That licenses effect how your code creates and taps network externalities is still not fully understood and even less fully appreciated.

There is a lot of mimicry and random mutation. For example the Apache Group mimicked the license on BSD. A lot of people mimicked the Apache license. Some of those mimics just change the name of who held the copyright, but a lot of them added, removed, or rewrote clauses for various reasons.

This early stage, the bloom of diversity, is followed by a period of consolation. At one level that’s kind of sad. Some cool innovations die out, for example some of the rewrites that made the license more readable don’t survive. Some of the innovations fall by the way because they aren’t tied to the wagon of one of the big winners.

Some of it is good, very good. Craft knowledge accumulates. Interoperablity is enabled, Resources aggregate around the winners. The good ideas are aggregated. The newer Apache license is a perfect example of this process at work. The new license maybe a lot longer, which sad, but it’s a lot more robust. It solves a number of important problems. Problems that really need to be addressing. For example it is a lot more careful about protecting the code from malicious infection by contributor IP rights. It also solves some perfectly silly problems, like how to avoiding having to put your entire license at the top of every source file.

It’s interesting how the revision of licenses is exactly like the problem of upgrading an installed base of software. All those licenses that mimic the older Apache license are like an installed base. It’s very hard to get them to upgrade. The classic metaphor for upgrading an installed base is: Build them a golden bridge, and then set a fire behind them. I doubt anybody can implement that plan in the open source licensing world. I suspect people will try. But that metaphor is an interesting example of how a seemingly minor detail in the license in one time frame can become extremely valuable in a later time frame. It’s one reason that many agreements between a firm and a consumer typically contain a clause that allows the vendor to casually change them later. I gather that Verizon recently changed their cell phone contract and one fall out is that the subscribers can bail without paying the early termination charges.

It is clear to me, that people in the Apache or BSD licensing community would be well served by upgrading their licenses to the new Apache license. Just to be clear that doesn’t imply assigning copyright to the foundation. The new license is just plain better than the old one.

The license is here and the FAQ is here.

Open Source Office

I see that Sun has set up an Open Source Office in a further attempt to bring some coherence to their strategy and tactics for relating to the open source phenomenon.

This kind of activity can be viewed from different frames. I, for example, haven’t the qualifications to view it thru the Java frame. But let me comment on it from two frames I think I understand pretty well.

Sun has done some reasonably clever standards moves over the years. As a technology/platform vendor the right way to play the standards game is to use it as a means to bring large risk adverse buyers to the table. Once you got them there you then work cooperatively with them to lower thier risks and increase your ablity to sell them solutions. Since one risk the buyers care about is vendor lock-in (and the anti-trust laws are always in the background) the standards worked out by these groups are tend to be reasonably open. Standards shape and create markets. Open enables vendor competition.

This process is used to create new markets, and from the point of view of the technology vendor that requires solving two problems. First and foremost it creates a design that meets the needs of the deep pocket risk adverse buyers. Secondly it creates a market inside of which the competition is reasonably collegial. The new market to emerges when you get the risk percieved by all parties below some threshold.

Open source created a new venue, another table, where standards could be negotiated. Who shows up at this table has tended to be different folsk with different concerns. That’s good and bad.

The open source model works if what comes out of the process is highly attractive to developers (i.e. it creates oportunities for them) and the work creates a sufficently exciting platform that a broad spectrum of users show up to work collegially in common cause to nurture it.

The goals of the two techniques are sufficently different that both approachs can use the word open while meaning very different things. It has been very difficult for Sun to get that. For example the large buyer, risk reducing, collegial market creating standards approach talks about a thing called “the reference implementation” and is entirely comfortable if that’s written in Lisp. The small innovator, option creating, collegial common cause creating standards approach talks about the code base and is only interested in how useful as feedstock for the product they are deploying yesterday.

It’s nice to see that Sun has created an Open Source Office; it’s a further step in coming to terms with this shift in how standards are written and the terms that define the market are negotiated. But, my immediate reaction was: “Where’s the C?” as in CTO, or CIO, etc.

What does the future hold. Will firms come to have a Chief level officer who’s responsible for managing the complex liason relationships that are implicit in both those models of how standards are negotiated? I think so. This seems likely to become as key a class of strategic problems as buisness development, marketing, technology, information systems, etc.

Open source changes the relationship between software buyers and sellers. It has moved some of the power from firm owners and managers down and toward the software’s makers and users. But far more interestingly it has changed the complexity of the relationship. The relationship is less at arms length, less contractual, and more social, collaborative, and tedious.

This role hasn’t found a home in most organizations. On the buyer side it tends to be situated as a minor subplot of the CTO’s job; while of course the CIO ought to be doing some as well. On the seller side it’s sometimes part of business development or marketing even. That this role doesn’t even exist in most organizations is a significant barrier to tapping into the value that comes of creating higher bandwidth relationships on the links in the supply chain.

This isn’t an arguement about what the right answer is because the answer is obvious some of both models. Some software will be sold in tight alignment with carefully crafted specifications and CIOs will labor tirelessly to supress any deviance from those specs. Some will be passed around in always moving piles of code where developers and users will both customize and refactor platforms in a continous dialog about what is effective. The argument here is about how firms are going to evolve to manage the stuff in the second catagory. That’s not about managing risk, that’s about creating, tapping, collaboratively nurturing opportunities.

Digital Fountains in the Walled Garden

Bummer.

Returning yet again to the topic of how the producer of an information good can shift the distribution load out onto a swarm of consumers. The producer can package his content in ways that make it easier and more likely that the swarm can collaborate. For example he can distributed redundent copies of the data or provide lots of checksums.

The extreme case of this is sometimes called a digital fountain, like a water fountain. The producer sprays a stream of droplets and if the consumer can catch a cup full then he can reassemble the original cup of content. And it turns out there are some very effective algorithums for enabling just that.

Here’s a short and simple survey paper on digital fountains (pdf).

…an idealized digital fountain should …

  • A source generate a potentially infinite supply of encoding packages from the original data. Ideally, encoding packets can be generated in constant time per encoding packet given the original data.
  • A reciever can reconstruct a message that would require k packets to send … once any k encoding packets have ben recieved. This reconstruction should also be extremely fast, preferably linear in k.

Amazingly there are designs that come extremely close to that goal. But.

… Most of the work that has been described above has been undertaken by employees of or consultants with the company Digital Fountain, Inc. … the company has a number of patents issued and pending that appear to cover both the fundamental theory and specific implementation designs …

So, no network effect and this stuff will get designed into only those industrial standards that are pay to play. Damn.

Nonstandard

There are numerous reasons to be nonstandard. For example when they built the world trade center in New York the thing was so huge that the vendor suggested they could have custom light bulbs that screwed in counter clockwise rather than the usual clockwise. This would keep the construction workers from stealing light bulbs. Nonstandard is often used this way, for example to make it hard to remove the screws from something you don’t want stolen. You can avoid having your customers stolen if you can get them to adopt nonstandard APIs. In these examples the nonstandard is being used because of a lack of trust. The builder of the twin tower’s doesn’t trust his labor. The platform vendor thinks his developers aren’t loyal, so he forces loyality.

One of my favorite standards stories is how after a fire in Boston in the late 17th century they legislated a standard brick size. It seems that the brick makers had all adopted differing sizes. They would compete to sell you your first bushel of bricks, but after you’d committed to a particular vendor’s brick size they would start raising prices. They were using nonstandard as a way to avoid getting forced into a commoditized market. The city fathers, acting as agents of the buyers, forced the sellers to adopt standards. Failure to conform resulted in a term in the stocks.

There is a varation of that story around lumber. The various lumber mills had no particular reason to standardize, nor did the lumber yards. The real pressure to standardize arose from the railroads; which wanted to commoditize the flow of lumber so they could ship more of it over long distances. The principle reason why a 2 by 4 isn’t 2 inches by 4 inches is because if it’s smaller then you can fit more of them into a railway car. That an entire industry can agree to standardize 2 as less than 2 is a fine example of how nonstandard is sometimes a way shape the supply chain to serve the needs of one particularly powerful player. In this case the railroad; a railroad car full of smaller two by fours is a lot more valuable than one full of the traditional ones.

You see a lot of seemingly gratuitous nonstandard behavior around batteries. Some of that is due to the pressures of the hardware design. Some of it is pure thoughtlessness by the designers. Some of it is, I suspect, carefully calculated – by creating a custom battery and assuring that your customers have to return to you to purchase a new one you can create a nice revenue stream. This is a particularly insidious form of pricing design. It’s a form of bait and switch; you shape the product’s presentation so everything the buyer sees first is cheap and reasonable but then you make up for that discounting by charging higher prices for the maintainance and service. Nonstandard components are key to making that work.

I tend to be on the look out for this kind of thing. They are fun to study because there is always this undercurrent of trust, loyality, and pricing games. Here’s one that came up recently. I just can’t stop giggling about it.

My son is about to go off to college. The school just sent us a mailing that informs us that the dorms have nonstandard beds. This is apparently fairly common They are longer than normal beds and we are advised to acquire special bedding. Not to worry a catalog is included in the mailing from a vendor they have partnered with to help resolve this problem.

I enjoy the fantasy that the univeristy is so desperate to find ways to break out of the highly standardized financial aid system that they found this clever trick for raising a bit more cash. It makes me wonder how much of a kick back the university is getting – none I suspect. I wonder if universities have figured out how to get a kick back from the text book publishers. Text books are so expensive because the market is so fragmented, the buyers completely locked-in; much worse than batteries. Where is the open text book movement?

P2P Reputation and Social Stratification

The nice thing about P2P content distribution systems is how they lower the barriers to entry for content producers. When things are working then the cost of distributing content to N consumers drops for the producer from N to 1, and the cost for the consumers rises from 1 to 2 (see here). In theory this enables content production to move much further down the long tail. It empowers the smallest players.

The design of these systems is a beautiful example of the design issues around a collaborative system. The consumers need to collaborate. If the total contributions of the consumers don’t amount to 2N then things fall apart. I’m finding it interesting to kick the tires on this problem. You can design systems to temper the freeloading by having the consumers accumulate a reputation. You can base the reputation on reports provided by other consumers. So if A provides content to B, then B can add to A’s reputation as a good actor in the system. If peer to peer exchanges happen in largely random patterns then A’s reputation will be assembled from a diffuse set of partners; making it harder to forge.

I assume it’s possible to design such a scheme. One that would allow peers in the system to know the contribution level of their partners with a reasonable degree of confidence. I haven’t looked very hard. I assume there are some papers on designing such diffuse reputation systems.

Ok, so I take it as a given that I can design a system where the participation demands a uniformity of contribution. But wait, I don’t want that! Look at the real world. Systems in the real world have multiple actors contributing to their total energy; and the distribution of their contributions is usually highly skewed. If the real world is that way, then is it a good idea to design P2P systems that effectively outlaw that distribution? What consequences would follow from that?

One thing’s clear. If you enforced uniformity you’d get class stratification. Participants of similar reputations would tend to flock together.

I’m reading a book about Common Interest Developments, i.e. the semi-walled garden highly homogenous communities created by developers. Their enthusiasts buy into a utopian fantasy. One who’s “overvalued idea” is the maintenance of property values. Other values tend to be displaced.

If we force uniformity of contribution into the architecture of P2P system, then that becomes it’s overvalued idea. Getting all fixated on the prevention of freeloading displaces other values? Why does the real world not work that way.

The delicate trick in getting the P2P reputation system may well be finding ways to encourage a diversity of participants. A means that it doesn’t lead to stratification, with that stratification and progressively tightening regulation of each group’s wall and internal norms. Very interesting tangle of problems.

Shifting Distribution and Coordination Costs

Here’s a slightly formal way to look at various ways of coordinating an activity. This grew out of my thinking about how to push content from producers to consumers without introducing a hub that coordinates the work. I was thinking about who bears the bandwidth costs.

One obvious way to solve the problem is to have the producer ship the content directly to all N consumers. He pays for N units of outbound bandwidth and each of his consumers pays for 1 unit of inbound bandwidth. The total cost to get the message out is then 2*N. Of course I’m assuming inbound and outbound bandwidth costs are identical. If we assume that point to point message passing is all we’ve got, i.e. no broadcast, then 2*N is the minimal overall cost to get the content distributed.

Two issues. All else being equal the producer would like to shift costs onto the consumers. Secondly – the hard problem here is not moving the bytes around; the hard problem is coordinating their movement. In the our first model most of the coordination cost is born by the producer. That has the benefit that coordination expertise will accumulate so that the cost of coordination can fall and the quality can rise. The producer retains substantial control over the relationships.

It’s not hard to imagine solutions where the consumers do more of the coordination, the cost is split more equitably, the producer’s cost plummet, and the whole system is substantially more fragile. For example we can just line the consumers up in a row and have them bucket brigade the content. We still have N links, and we still have a total coast of 2*N, but most of the consumers are now paying for 2 units of bandwidth; one to consume the content and one to pass it on. In this scheme the producer lucks out and has to pay for only one unit of band width, as does the last consumer in the chain. This scheme is obviously very fragile. A design like this minimizes the chance of coordination expertise condensing so it will likely remain of poor quality and high cost. Control over the relationships is very diffuse.

We can solve the distribution problem by adding a middleman. The producer hands his content to the middleman (adding one more link) and the middleman hands the content off to the consumers. This market architecture has N+1 links or a total cost of this scheme is 2*(N+1). Since the middleman can server multiple producers the chance for coordination expertise to condense is generally higher in this scenario. Everybody, except the middleman, see their costs drop to 1. Assuming the producer doesn’t mind being intermediated he has incentive to shift to this model. His bandwidth costs drop from N to 1, and he doesn’t have to become an expert on coordinating distribution. The middleman becomes a powerful force in the market. That’s a risk for the producers and the consumers.

It is possible to solve problems like these without a middleman, instead we introduce exchange standards. Replacing the middleman with a standard. Aside: Note that the second illustration, Consumers coordinate, is effectively showing a standards based solution as well. We might use a peer to peer distribution scheme, like Bit Torrent for example. To use Bit Torrent’s terminology the substitute for the middleman is called “the swarm” and the coordination is done by an entity known as the “the tracker.” I didn’t show the tracker in my illustration. When bit torrent works perfectly the producer hands one Nth of his content off to each of the N consumers. They then trade content amongst themselves. The cost is approximately 2 units of bandwidth for each of them. The tracker’s job is only to introduce them to each other. The coordination expertise is condensed into the standard. The system is robust if the average consumer contributes slightly over 2 units of bandwidth to the enterprise, it falls apart if that median falls below 2. A few consumers willing to contribute substantially more than 2N can be a huge help in avoiding market failure. The producer can fill that role.

Of course swarming is not the only way we can arrange a standards based solution to this problem. It’s notable because it is both reliable and the total bandwidth cost can be 2N, the minimum. I find it interesting that when the cost approachs that minimum the swarm becomes unreliable. The second model where consumers coordinate the distribution in a bucket brigade can be made more reliable by introducing additional redundant links; these are another way to buy reliablity in exchange for increasing the cost above the 2N minimum.

I find it fascinating to see how the coordination costs, market power, and reliability of the market’s clearing are shifted around in these various scenarios. The bandwidth costs act as a partial proxy for those. Market participants are most concerned about risk. They want to place their faith in a market structure. Once the rendezvous around a given structure then can have a meaningful discussion about the risks that structure creates. The first model has the risk of powerful producer. The second and last models have the risk of policing standards compliance. The middleman has well known agency risks.

Standards based solutions always have problems with policing and freeloading. I think it’s neat to notice that if the producers and consumers are exchanging data over many time periods they can establish a trading framework with reputation, currency, and market clearing schemes that assure that everybody contributes their 2 units of bandwidth. In effect you can make such systems self policing in much the same manner used in a competitive market. Which goes to reenforce the way that exchange standards create and shape markets.

Reciprocity and Data Licensing

The phrase “reciprocal licensing” got into my head a few months ago. If you go poke around you find that the term is mostly used to describe ways that one organization agrees to honor the licenses granted to professionals by some other organization. Licenses are, of course, set of rights and responsibilities. For example is the state of Massachusetts grants me the right to drive a car on it’s highways most of the rest of the planet will also grant me that right. Lots of professions have associated systems of reciprocal licensing: plumbers, teachers, and lawyers. When you grant respect to a person’s title, for example Vice President of Engineering, outside the context where that title was granted you would seem to be engaged in a form of reciprocity.

Reciprocity isn’t just for roles. The GNU software licenses are a form of reciprocal licensing. In exchange for the right to modify the software you relinquish your option of hoarding those modifications. The peer to peer file sharing, systems are another example, in exchange for drawing down a file from the system you are expected to reciprocate by providing bandwidth for further file sharing. The peer to peer messaging and VOIP systems are two more example. Once you start noticing you’ll see lots of these.

Reciprocity is one way of framing the coordination aspects of collaboration. It’s a way of talking more explicitly about the responsibilities that come with club membership around a club goods. The peer to peer system, the GNU code community, the professional society around plumbers or doctors, even the universe of international drivers all have rules that govern how the goods are maintained in collaboration. You can find other examples around patent pools. Some platform vendors have begun to use these ideas to assure that members of their developer networks add to the platform. For example Microsoft’s consumer electronics platform has rules that clarify the timing of various developer IP rights so innovations can flow back into the common pool around their platform – or so I’ve been told.

Peering agreements are another interesting application of reciprocal licensing used is for. IP packet routing, or phone call routing, or check clearing are all examples. The problem is you want to join a distributed network but your concerned that other members of the network will freeload or cheat in various ways that disadvantage you. You need trust at a distance. By setting up a standard contract that every participant is required to sign you can temper some of the risks.

Data pooling agreements have the same challenges. Consider an example. Imagine you are an insurance company. You have worked hard at great expense to collect data about insurance claims. This data is valuable because in aggregate it drives how you set rates. If you had more data you could set rates even more accurately. That could be very profitable. The insurance industry shares data like this by establishing master database. And, I assume, they use a contract much like a patent pool or a peering agreement to reduce the risk that some companies freeload or engage in any number of other ways of gaining an advantage.

Of course all industries have a power-law distribution of players. One way you can disadvantage the small players is to create barriers to entry that only large players can overcome. One place you can establish these barriers is with the rules around the reciprocity agreements. But, on the other hand, you can use the reciprocity agreement to frustrate that. The GNU license is a fine example of that. There is another example found in the open source VOIP community. They need to exchange call routing data. They have a peering agreement for that which tries to keep large players from locking out tiny guys – like me with my basement phone switch.

For the last year or so I’ve been puzzling about the problem of how to equitably distribute blog pings from blogs to interested parties. The tough nut in the design is that there are some very large gorillas in the blog world and they are all, presumably, tempted to horde their ping data to gain various competitive advantages. And, as usual in these two sided markets where there are lots of providers and lots of consumers there is a two sided network effect that could lead to a single winner who acts as the hub for the exchange. A middleman taking a small cut as he coordinates the interactions. The usual way to temper that risk is to introduce some standards that fragment the market while solving the coordination problem enough. With luck you can even get the standard to do a better job than a single hub would.

All that has brought me around to the question of what the reciprocity rules would be in such a market. What the world needs is creative commons like license for pings. I want to know that when I ping weblogs.com, or ping-o-matic, or technorati, or pubsub.com that they aren’t going to horde the resulting data. I want to know that they have signed onto a peering agreement that assures that my ping joins rest of the ping flux as public data. Some rights and responsibilities are granted when you ping these guys. Their responsibilities need to be made more explicit.

I don’t mind if they want to horde information that they accumulated by spidering, polling, and scraping; though I suspect we will see similar creative commons like licenses appearing on sites. Licenses that make explicit the reciprocal nature of the relationships.

Pay to Play

The Inter-American Telecommunication Commission meets three times a year in various cities across the Americas to discuss such dry but important issues as telecommunications standards and spectrum regulations. But for this week’s meeting in Guatemala City, politics has barged onto the agenda. At least four of the two dozen or so U.S. delegates selected for the meeting, sources tell TIME, have been bumped by the White House because they supported John Kerry’s 2004 campaign. The State Department has traditionally put together a list of industry representatives for these meetings, and anyone in the U.S. telecom industry who had the requisite expertise and wanted to go was generally given a slot, say past participants. Only after the start of Bush’s second term did a political litmus test emerge, industry sources say.

   — Mostly behind the garden wall at Time

Rubbing Together

If you rub two surfaces against each other they tend to smooth each other out. But, if you rub them every which way for long enough they don’t get flat. To get a flat surface you need to rub three surfaces against each other in assorted combinations. You can make optically flat surfaces this way. My father was an optics guy. He taught me that, but I forgot until recently.

Since being reminded about that I’ve been thinking about how interfaces boundaries rub against each other and how they tend to smooth out over time.

In industrial standards work we spend a lot of time proactively creating specifications whose intent is to assure smooth efficient exchange on interfaces. It’s not uncommon to fly brilliant engineers and implementors to other continents so they can do interopt testing to assure that the resulting systems are conformant to the spec and work smoothly with each other. The cost of such coordinated efforts is extremely high; often fatally high.

Rubbing isn’t a very sophisticated approach to gettting a smooth surface. It is what I was taught to call a strong method, a method that works in all cases. Rubbing, in optics, is always the last method. When you make a lens you attempt to get it right; but latter you always use rubbing to get it right.

I distill two points out of all that.

Simple standards tend to win because they have fewer rough edges that need to be worn down when you get to the rubbing stage.

Rubbing to get things smooth and interoperable is always part of the story.

Standards that are many to many smooth out better. I.e. one of the challenges in B2B standards compared to other internet standards is the way that it’s less common to find a firm that is doing B2B exchange with a huge number of partners in a way that’s similar to the huge number of sites that web browser visits.