Wandering Thoughts archives

My thoughts on why invented standards succeed or fail

So suppose that you have a standard that, regardless of the risks, has invented things instead of just documenting existing practice. What helps it succeed or pushes it towards failure?

(By success I mean that the standard is implemented and gets used; by failure I mean that it is either not implemented or ignored.)

Implementing and using a standard has costs, and people are lazy. This implies that a standard's chances of success are going to depend a lot on its benefits relative to the current status quo. Thus, the 'best' (most likely to succeed) invented standard is in a new field (one without existing standards to 'compete' with it) and answers a clear need, solving a problem that people are wrestling with; such a standard delivers high benefits, as it is the only solution to a real problem.

Correspondingly, the 'worst' (least likely to succeed) standard is one that is in a field that already has existing standards (either formal or just de facto) and that offers only minor functional differences over what you can already do with the existing standards. Even if the cost of using this standard is extraordinarily low, its 'profit' (benefits minus costs) will always be small because its benefits are so small; with higher costs of use, you'll never see any net benefit from using it.

(I have sort of been ignoring the costs of implementing and using a standard, but obviously they matter too; an extraordinarily costly standard had better deliver extraordinary benefits, and you can probably get people to adopt a standard that has zero cost but only a small benefit because, well, why not adopt it at that point, it's not like it costs you anything. There are probably ways to reduce the cost of a standard, such as by delivering a test suite as part of it.)

This is by no means the whole story of why standards succeed or die; in real life, as opposed to theoretical musings, there is a whole pile of other things going on. (After all, the ultimate way of getting your standard to succeed is to have it adopted as a requirement by someone who is big and powerful. But as they say: with sufficient thrust even pigs can fly.)

The risk continuum for standardization success

Following on from the three stereotypes of standards approaches: so you have a standard. Now, how likely is it to succeed, or at least to be implemented (since standards more or less necessarily fail if they're never implemented)?

Well, that depends on the specific standard. But we can ask what the continuum of risks is for each stereotype of approaches to standardization.

At one end of the continuum is pure documentation, where the behavior the standard calls for already exists and so the standard is 'implemented' the moment it's written up. Vendors don't need to implement anything, they just need to not change anything that you've documented.

In the middle is coordination; vendors have to implement something, but they've already agreed to do so. And from there to the far end are the various ways you can approach invention, ranging from talking a lot to vendors about what they're happy with (but not requiring explicit agreement to implement before you go ahead with the standard) to basically having no contact with would-be implementors at all.

In addition to the 'will anyone build it' risk, there is also the 'will it actually work once implemented' risk. Documentation has no risk here; you know it works, because it already exists and you presumably wouldn't be standardizing it if it worked badly (yes, I'm an optimist). Coordination has some risk but the vendors should be convinced that it will work before they agree to it, and invention has various levels of risk depending on how you go about inventing the standard.

Well, sort of. The coordination versus invention division breaks down here because in both approaches you need to decide what to specify, and whether the standard is useful has more to do with how you go about making those decisions than what is going on around those decisions. I do think that coordination has somewhat lower risks because the vendors have more riding on the standard working (if it doesn't, they have probably wasted the effort of implementing it), but vendors can make howling mistakes too.

That the pure documentation approach has such low risks of both implementation and usefulness goes a long way to explaining why it has such a high appeal.

What I think I understand about how standards get created

To condense and stereotype a great deal, there are three general ways of creating standards:

• invention, where you come up with something that seems good from more or less scratch (ie, not feeling obliged to pay any attention to existing practice, if there is any).

  The risk of this approach is getting your standard adopted in the field; many invented standards fail dismally because no one is interested in implementing them.

  The Atom syndication feed format is, I believe, an example of this way.

• documentation, where you write down the common core of what already exists and works (more or less) in everybody's implementations.

  The risk is that your standard doesn't and can't really solve any new problems; it just helps new entrants into the field and promotes portability.

  A fair bit of the original C standard was an example of this.

• coordination, where you get all of the important implementors together in a room and find out what they will all agree to do, then write it down.

  The major risk is that your standard will probably wind up loaded with compromises in order to get everyone to agree to implement it, and they may not implement it anyways.

  (I can't think of an example, alas.)

(Since these are stereotypes, it should not be surprising that real standards are usually a mixture of all of the approaches. For example, the general mythology is that the ANSI C standard documented a lot of things that everyone could agree on, made up others like function prototypes, and got vendors to agree to implement specific semantics for a lot of things that had previously been not well defined.)

Successful standards can and have been created with all three approaches, and I don't think that any particular approach is better than the others. And to a large extent, what approach is best depends a lot on the circumstances in which the standardization is taking place, since each approach protects you against certain vulnerabilities while opening you up to others.

(It's common to laud the documentation approach as the best way to go, but I've come around to not believing this any more; there are situations where it works great, and there are situations where it's pointless, because the real issue is that the existing implementations don't provide the features that people actually need. If you pursue documentation-based standards anyways, you get lovingly written standards and beautifully compliant implementations that no one cares a whit about.)

When discussing standards, it's important to start from an understanding of what sort of standard it is. For example, criticizing a standard for not inventing solutions to new problems when its job was documenting the existing practice is much like criticizing snow for not being warm; it's true but not useful, and it's not going to change any time soon. Worse, such discussions often wind up with people talking past each other, since the sides are starting from completely different basic assumptions (often ones that they don't bother articulating because they strike each side as too obvious to need it).

Some thoughts on a 'modern' university email system

Here's a question: what would a 'modern' university email system look like, one that's in line with the 'students already have online lives' theme of last entry?

(Let's assume that our assignment is limited to designing the email system, and thus we don't get to question or change what it's used for.)

Clearly, a lot of people will already have outside email addresses and many of them will want to just forward their university email address to their real address. Not everyone will, though; we should expect a certain number of people to want to keep their university mailbox separate from their personal one. (And some people will open up a new GMail account or whatever and forward their university email to it, in order to keep the mail separate but get the interface they like.)

If the university email system is effectively a backup for your real email address, that means that we need to make it a good backup, one that avoids and works around the general problems with email forwarding (those problems often lead to such forwarding being officially discouraged). First of all, the system should do a good job of forwarding in general. At a minimum, this means segregating outgoing email into separate streams for at least official university communications, email that originated on campus, and email that came in from the outside world.

(By 'official university communications', I don't mean the weekly email bulletin; I mean critical notices about stuff that people will be held responsible for.)

In order to be a real backup, the system needs to be able to recover if something goes wrong with your forwarding. So:

• it should keep a copy of the last N days of all email, where N is a reasonably substantial figure. (Certainly it should be longer than the largest break in the school year, which argues for at least three or four weeks.)
• if the system can see that your forwarding has broken down (eg, it gets SMTP-time rejections), it should not expire the unforwarded email at all. It should also flag it, put it in a separate folder, or otherwise make it really easy to see when you finally log into the university email system.

• it should keep a copy of all official university communications, no matter how old. This should be visible in a separate (IMAP) folder that has just them, so it is easy to skim.

(This is radically different than how most current email systems handle forwarding. That's because current email systems don't do a good job of really supporting forwarding; instead they just wash their hands of the email after they've tried to dump it on someone else.)

There should be a competent webmail interface to all of this, because it's going to be popular; using webmail is less work than configuring an IMAP client if you're only a casual, occasional user, ie you're someone who forwards their email. The local power users will continue to prefer IMAP.

Something I have realized about university services

There's a lot of services that people build around the university, both large and small. The general habit is to make them self-contained services that run on your own web site or whatever, or perhaps ones that integrate with other on-campus systems.

I have come to believe that this is a mistake. These days, university services should be assuming that students (both undergraduates and especially graduate students) will show up to the university with already established online identities and habits, which means that services should be designed so that they primarily integrate with these. People aren't going to abandon the services that they're already using, and generally they aren't going to be enthused to add more things to their online life (more websites, more programs, more whatever).

Or, in short and as an example, if you're going to make a new calendaring service, the thing to do is to make it export calendaring information so that people can integrate it with their existing Google Calendars or Yahoo Calendars or whatever online calendaring system they're already using. And you should expect that most people will use it that way.

This doesn't mean that you can't have your own self-contained service (eg, a calendar section on your website). But such a thing should be viewed as a backup that most people only use when something goes wrong with the data export to their regular services, not as something that very many people will ever use regularly.

(Yes, there are some practical issues; you'll have to figure out which outside services to support, for example, and make sure that you don't require people to join any particular one. These are not insurmountable, just potentially hard.)

This implies a number of things about how you design the services and what parts of them you focus most of your efforts on, of course. If the version on your own website is effectively a minor sideline, it doesn't make sense for it to consume lots of the project's efforts; they're better spent making sure that you integrate very well with the outside services that most people will use your service through.

One thing that top-posting is good for

Like many Internet people of a certain generation, I don't like top-posting (and often have a semi-visceral reaction to it). For a long time I avoided it almost entirely but these days I'm in an environment where I'm reasonably exposed to it, and I've come to realize something about it.

Ultimately, the purpose of all quoting in email is to provide context, to remind people of the previous discussion if they don't remember it off the top of their head. Top-posting optimizes for the case when you don't actually need this context while still letting you recover if you do.

If you don't need the context, you don't want to waste time skipping over quoted text; top-posting puts the new text right at the top, so you can read it immediately. Plus, if you only need a little bit of context, the most recent context is at the top of the quoted text, right there for you to read next. (If you need a lot of context, top-posting is horrible.)

Realizing this caused top-posting to make a lot more sense to me, because at least around here, the common case is that people don't need the context very often (but it's unpredictable when they do want it). Thus, top-posting is optimizing for the common case.

(No wonder that it is so persistent and pervasive.)

This is of course yet another example of the fact that people are rational (well, generally). When people do crazy things, it's quite possible that they're actually completely logical and sensible from the right viewpoint. You just have to find it (which I think is often harder than it looks).