E. Standard Differences

E. Standard differences

Scholarly literature is departed for an Example from ethnography — and Another from an email discussion on standards in which Religion and Heresy appear — some Very Important Distinctions are made — between freely available standards and not — between written standards and implementations — the concept "it works" is introduced and discussed..

As the scholarly literature on standards expands, it is easy to lose sight of what might be the crucial differences between kinds of standards. The diversity of technical standards, especially those for software and networking— for information communication— can easily overwhelm the important theoretical differences. In order to maintain some specificity, without losing the generality that will connect the primitives of scale and convention to the programmed languages of the internet and society, ethnography studs the following exploration with stories that may seem more or less real, more or less explanatory, or more or less obfuscating. The spectrum of laws, regulations, contracts, standards, conventions, and customs continues to enfold a problem of location— the spectrum of boundaries: world, global, international, national, legal, commercial, mediatic, governmental, local, virtual.
At ground level, as it were, to use a metaphor of space that somehow still makes sense, there is the problem of how anyone knows what standards (techncial or otherwise) are appropriate for anything at all. Engineers and technicians from different communities will have been trained to respect different sets of standards, based on reasons that may be obscure— issues of technical 'elegance,' national or international endorsement, explicit teachings, or learning of a more implicit, customary or 'tacit' kind [1]. This is the sole point where existing national and cultural identifications have specific technical impacts. Training varies, socialization varies, and access to information varies. Engineering is not one, nor is medicine, and the differences that result translate into differences in standards that are applied or obeyed. Rightness and authority reference all standards, from the metric system to rituals of construction. Herein classical Weberian concepts still work: obeyed standards are the probablistic measure of an obcure, but identifiable given authority. [2]
The first cut divides internet-savvy programmers and engineers from telecommunications and electrical engineers. Software programmers who associate themselves with the internet as a kind of ethic ( a 'community' occassionally refereced as 'hackers') tend to be auto-didiacts who view the authoritarian attitude of "a right way to do something" as suspect, and substitute instead a demand for demonstrable, measurable quality. Telecommunications and electrical engineering is a profession with a great diversity of certification and licensing practices, that engages a much more bureaucratic and institutional version of authority, and often demands adherance over demonstrability. This cut inevitably effaces the differences within each field, in order to connect the differences between them to different sets of conventions, standards, standards making procedures, and political affiliations whose distinctions are difficult to perceive from within either one. For example, from the perspective of individual advocacy, the internet is easily identified not only a separate set of engineering ideals (I refer to the ideals of the internet as a stupid network, discussed in section G), but a different political ideal, most often— libertarianism. Telecommunications and electrical engineers might be less likely to be libertarians. In any case (assuming we could make such generalizations), to simply allow that these differences issue from different 'cultures' obscures more than it enlightens[3].
The fact remains that engineering ideals (the Bildung of the engineer, his or her tacit knowledge, and explicit professional affiliations) and political actions (the promotion or blocking of specific decisions) are inseparable. The distinction is a vulgar one, necessary to get work done, like the distinction between real work and philosophy. Political action was never confined to the voting booth, except in the justification of actions. Like the relationship between trust and truth identified by Porter, engineering decisions and political action share the same bargaining table. When people are convinced that they are right, when they insist that their way is a better way, a direct access route to obscured political beliefs is opened.
When, in the case of the internet, engineering or programming decisions are experienced as 'political' or at least, as more than simply 'technical' choices, standards are inevitably at the heart of the discussion. Standards issues, like platform wars, tend to take on the character of religious disputes, sometimes with strictly articulate rules for their arbitration (levels of specificity, arguments about users, cost, or self-evidence, testimony, especially "It works," which we will see later is one of the most powerful political assertionas of will) sometimes with all-out dogmatic insistence, unchangeable minds, ALL CAPITAL LETTERS. Often, when the specificities have been exhausted, explicit arguments about the nature of laissez-faire capitalism and its corruption by large corporations and governemnt regulation take center stage. In the end, these debates come close to engaging legitimacy at a very high level— that is to say, the cover of a distinction between technical and political issues is shorn for a direct attack on forms of political or economic action. Consider, for instance, a sample from the discussion list for XML developers, sent to me by Sean.

It seems that the word "standard" is a new modern marketing magic wand. what do this means exactly? If W3C has 320 members and claim to produce "standards." Does this means that if I get 320 friends (not from the same company) and produce a spec, could this be a "standard"? if not why? Did we forget some historical lessons when at some period of time people where claiming authority based on some "standards", even attributed themselves the right to burn people not conforming to the "standards." So, what this word really mean today? disguised power struggle? Do "standard" really mean "against Microsoft" (this does not necessarily I am for _ and that I have to say this just put more emphasis on the quest to find the real meaning of "standards") ? Do "standard" mean... What this word really means anyway? What is really behind it?

We can appreciate the difficult English of this email, if for a moment we treat it as 'non-standard' English, and listen to the bewilderment manifested at the fact that the emotional attachment to legitimate authority inevitably refers us to some version of revolution and heresy, here it is Bruno, burnt at the stake for proposing to speak truth to the prevailing authorities' standards. This email is a perspicacious example of this phenomena— common enough to be very recognizable on such newsgroups and mailing lists, and often just referred to, somewhat cynically by my informants as "religion and philosophy."
The discussions are inevitably confused by this maneuver, where the artifactual nature of standards and the purely politcal game is confused with an extra-cultural progression towards truth. The result is that standards discussions very quickly become religious disputes, disputants very quickly recognize this, and in the end, the only arbitration is a grunt insistence an a piece of technology: "it works."
These discussions came to make sense to me as a result of observing the differences between the Partners Telemedicine Center and Amicas, specifically with respect to the difference between the electrical engineer who learned information technology via night classes and Microsoft certification programs (Tim O'Neil) and the economist who learned programming and information technology on Usenet groups, from programming handbooks and O'Reilly texts, or just by asking around (Sean Doyle). Tim (as well as Dr. Kilborn) was a representative of an engineering tradition that valued consensus, certification, professional identity and treated standards as a kind of legitimate authority, whether they were the standards of a public or private entity. Sean on the other hand, preached the gospel of openness and open standards, partially as a result of his experience of learning via the internet's openness, and often referred to the Evil spread by Microsoft into the world. The mutual unintelligibility of this choice is what I insist is the central and most imortant difference for standards setting specifically, but for the internet and the technical-legal society it programs in general.
For now, two important distinctions:
1) That between a standard that is freely available (though not free) to anyone and one that is not. In the first case, it may be copyrighted or not, and there may be a nominal charge associated with it, usually justified in terms of covering the costs of its development or publishing— and usually associated with a non-profit, non-commercial organization that is made up of members of different companies in an industry. Standards organizations with the backing of governmental authority are most often of this kind, but not always. In the second case, the standard may be unavailable because important parts of it are kept secret by the company that created it— thus a proprietary standard— especially if that company is the only manufacturer (and here, monopoly and antitrust issues become relevant, as do legislation protecting "trade secrets"). A company or standards institution may also engage in some commercial activity such as licensing the standard (which depends on some protection accorded by patent and copyright law, though this will be further complicated by software licensing practices, q.v. sections K and L) or engaging in some activity with another company that necessitates sharing a standard for the production of a specific technology. Examples include the standard for Microsoft Word documents, Adobe PDF files, or the Windows Operating system.
2) That between a standard and an implementation of that standard. The published standard may be, for all intents and purposes, useless to most people (Sean Doyle: "there's open like in DICOM where people can use it but it might take them 3 months with a good C++ programmer to download the code and then understand it.") either because it is too complex or because it may set specifications that need to be tested and measured against something. Example: standards for weights and measures— whether a standard iron bar in the center of town, or the wavelength of a Krypton atom. Tolerance in Alder's work: the devices for measuring tolerance in bore size need to be available to testers, not just a number. But more than this, in the world of software engineering and management, designers need implementations to work with— to test against, and to understand how a piece of technology works, either to reproduce it, or to fix it when it breaks. If you don't have the implementation of the standard, then complying comply with the standard adds a level of complexity to the creation of software that makes producing compatibility difficult enough to discourage the most persistent designers.
In the case of this second distinction, standards are much more than simply about measurement or control: they provide examples to learn from, and challenge the distinction itself. It is possible (and indeed, required in some instances, as I explain in Chapter H) that an implementation could become the standard. That is to say: there is a working example of a protocol (or a piece of software), implemented in a working network, that is then declared a standard by a governing body. This is what the path dependency theorists theorize, but without the last step, so that, for instance Microsoft Word is the de facto standard for word processed documents, but certainly, no legitimate authority of any kind has declared it a standard. On the other hand the protocol for ftp is also a de facto standard— it was adopted in a similar manner, by use and incremental improvement— but was then declared a standard by the IETF (see chapter H). Those familiar with the internet understand this well: by making the source code of any system available, you allow not only massively parallel testing and development, but a working implementation that people can learn from, copy, comply with, compare to, and for the entrepreneur in each of them: adopt. Sean Doyle tells a version of this distinction:

S: Well, its also, very hard, because if the standards are sufficently complex— and almost all standards that are worth anything are complicated— if they don't come with a sample implementation then you know, you're toast.

Sean is thinking here about the DICOM specification, which is a hopelessly complex document, and without a system to test against, or at least to look at, he insists, you're toast. Sean, however, gives a different and more complex set of examples to illustrate the point:

S: If you look at the definition of the C language, you know, it's pretty terse, if you look at the one for Java, [the Java programming language definition is a proprietary standard wholly owned by Sun Microsystems, written James Gosling, Bill Joy, and Guy Steele, whereas ANSI C is a standard that was published by ANSI, and in 1990 included by ISO/IEC, Sean could be referring to the earlier specification by Kernighan and Ritchie, but it is unclear] it's really much longer, even though the language is much more semantically clean, and that's because they spent a lot of time trying to be really serious about having a language that is cross platform. The main thing is that they had a working implementation that other people could test against... you sort of need both the written [standard] and the implementation in order to make it go along.

What Sean is trying to get at here is more complicated than he lets on. Trying to explore the relationship between a standard and an implementation in terms of computer languages doubles the complexity of the difference between a "written" standard and its implementation and a de facto standard as an implementation and its written standard. To begin with, a "language" is never implemented, per se, but would require a compiler or an interpreter for that language, and in the case of C, it would have to be specific to the operating system and machine that it was to be run on. In the case of Java, as Sean points out, the specification for the language is more terse because they needed to include specifications that would allow it to work on several different operating systems, and potentially be expanded to others. Furthermore these technical details are not the only thing at issue, consider the difference between C and Java more carefully.
The C programming language definition is available from the Online ANSI standards store for $135, 12MB, Document Number: ANSI/ISO 9899-1990 (R1997). This means it is not a paper document (though you can get a paper one), that it is expensive, and that ANSI controls its distribution. The specification cannot be extended or transformed (which might seem obvious, since it is a standard, but it needs to be said, because this is not always true, only true in this instance). If you do change it, you are forgoing national and international standards, and would be unable to pass conformance statements that would give your implementation (of a complier, for instance) the ANSI stamp of apporval. If you wanted to get an implementation of the C programming language, you would need to find a piece of software that implemented the language for some reason, say, a compiler that turned C code into object code. There are several of these, such as gcc, the GNU C compiler from the Free software foundation (which is also free of charge). Or you could purchase whichever "software development environment" you might prefer (such as one of Microsoft's Visual Studios). However, only in the former case would you be able to look at the source code of the compiler/development environment to see how it implements the C language specification. A proprietary environment will not include the source code, usually only the binary executables. Both may conform to the ANSI C standard, if ANSI has approved them, but ANSI does not police every implementation of C, which would probably be impossible. However, in th case of gcc, the source code is available and it is also 'free' (see section K), which means that you could conceivably change it to produce a new version of the gcc (perhaps different than the ANSI standard), if you determined that was necessary for whatever reason. The relevant point for Sean's example is that if you only have a specification for C, you can't make it (perhaps your compiler) "go along" [4]. If you already have an implementation of the specification, you can at least copy its structure, or learn how it "worlks."
The Java programming language definition, on the other hand, is wholly owned by Sun Microsystems and will be given to you for free on a limited license (one copy) here. This means that Sun owns the copyright to the specification and has licensed it on a per copy basis to people who want it. It is free of charge, but it cannot be redistributed. The specification cannot be extended or transformed under threat of legal action from Sun Microsystems. Sun provides a free (though also proprietary) programming environment called the Java Development Kit (Recently changed to the Java 2 SDK, there are versions of it for Windows and Unix). Under a new license, the source code is available, but still owned by Sun. Sun allows other vendors to create development environments using the specification, but it contracts with them to implement the specification as they have designed it. Java is slightlly more complex in that it depends on the inclusion of an interpreter in the various Web browsers (for different operating systems) made by any web browser manufacturer to interpret the source code that is downloaded over the net (this is the theory behind the "write once, run anywhere" logic of Java). The inclusion of this interpreter depends on a complex licensing and contracting practice that tries to incent browser manufacturers to include an implementation of Java in their browsers. If the browser manufacture implements the language according to spec, it should run any jave program written on any platform. This was the subject of Sun's law suit against Microsoft in 1998, because Microsoft implemented a version of Java that did not correspond to Sun's specifications for Java, and thus did not always run Java programs the same way, or at all. Sun claimed a breach of contract. The point, I take it, for Sean, is that in the development of the various interpreters in various web browsers for Java, Sun had provided an implementation of Java-compatible browser to fro developers of the interpreters to test against. This made cross-platform compatibility easier than each having to write an implementation based soley on the specification of the language.
Sean offers a second example, this time of a protocol, that is also meant to prove this point:

I've heard, and this may be a bit of folklore, that TCP/IP, you know, one of the reasons that worked so well as a standard was that some of the initial implementations were part of the UNIX kernel and they were made free [such as, perhaps, an early version of BSD], and so when there were things that weren't in the spec you could look back at the implementation and say "I want to make it compatible with this one" then you could make it work that way. So it's really not enough to have the paper, you need to have an implementation, and it's really hard to have the incentives, for people to release both the implementation and release the code.

The last sentence is crucial for these distinctions with respect to the internet: having a standard is one thing, having an implementation of a standard is a second thing, having the source code for that implementation (in the case of software) is still yet a third thing. Having all three is often too much to ask. The distinction Sean points to— between the paper specification of a standard and the working implementation of a standard and its source code is recapitulated by every story of the internet, even if the conditions of possibility of this story (ARPA's hand in the development of the internet, or the NSF's, or the instiitutional conventions of university computer scientists) are effaced or troped. It is the case that this distinction is meaningful to many of the actors who write software or build networks— and it suggests that what people find compelling about the story is the suggestion of its openness, specifically that one can use it to learn how something works.
These examples should at first recall the distinction between a patent and its device, and the problematic issues of toggling between them, especially in the case of "technology transfer." But they should also give just some sense of the quadrilateral set of concerns: national and international legitimacy, availability and accessibility, corporate ownership, and workability. The corners of this shape fold to meet in a variety of conformations, and the difference between any two engineers will often depend on which corner is most dog-eared.
My use of this paralellogram of interests is in the the comparison between Partners (Tim O'Neil) and Amicas (Sean Doyle). Partners developed no software of their own, preferring to outsource most of the technical work, but this did not make them immune to standardization issues, or to the relation between standards and communities of practice, or the necessity of knowing how things work in order to make decisions about what to spend money on. For Partners, legitimacy rests outside the organization, in the structure of certification and recognition that makes up the national medical-corporate establishment. This history of standardization and certification is at least a century long, and mixes the recognition of authority in the person of the doctor with the baptism by the hand of the administrative state in the guise of the various professional societies. Goodness, skill, rightness, truth— all issues of pure validation, peer-review by the proper authorities. Authority precedes (both personal and institutional), accreditation follows, credentials bear witness. For Sean and Adrian, this history is the reason that healthcare is a frustratingly anti-competitive environment [5]. For Tim O'Neil and others at Partners, this authority is both a bureacratic hassle, and a positive external guarantee of quality— or at least the promise of quality, even if they are sometimes cynical about it.
Amicas therefore serves as the example of a company that insists on the necessity of both the standard and the implementation (though not yet necessarily the source code): it works, and the only way to know that it meets a standard is if it works. Partners Telemedicine represents a much different approach to standards, in which certification, hierarchy, and control play a large part. It doesn't need to work, in the sense that Adrian and Sean would have it work, but it does need to be tested in a clinical trial and verified through publication in a peer reviewed journal. Only in that sense will 'it work.'
Perhaps you may ask, what does it mean for something to work? Does that mean work well? Or simply work once? On the one hand the importance of the phrase "it works" will be that only a piece of software properly written and compiled and run will "work," everything else is either broken, or cannot work. A paper specification for a language such as Java does not 'run', does not produce output or cannot be used to build a compiler (at least, not without some supplemental knowledge or decisions to resolve the ambiguities of the standard). On the other hand a working implementation of something can work better or worse, it can be just good enough, or it can be reliable and robust. But if "it works" and you can look at it, and see just how "it works" you can build another one like it, or better. As we will see with the Free Software Foundation and Opensource.org, the quality of the software is implied by the token "it works," suggesting that that other piece of bloated, feature-laden, inefficient software it is compared to, doesn't work. What is meant is that it works so badly as to make users suffer. It breaks often and eats files, or it is molasses like and memory hogging. Criteria for such a comparison proliferate, as do implications for why it doesn't work— from conspiracy theories about support costs, to suggestions that "the best" developers go elsewhere.
In many ways this distinction haunts the supposedly transparent claims of people— like the FSF and opensource.org alike— who would insist that differentiating good from bad software or good from bad protocols is somehow obvious. And yet, I would insist that the crucial theoretical content of "it works" is that it refers to a kind of language that is both descriptive and performative. That the distinction between standard and implementation explained above functions as a kind of legitimation here. It repudiates a theory of representation that insists on mimesis as the mode of control of entities (make a standard that governs all possibilities and keep it separate from all implementations) in favor of a one that insists on the mutual action on and description of entities in a modifiable manner (make an implementation the standard, and allow it to be change). Modifiability is the sine qua non of this mode, not those criteria of completeness or classificatory elegance that would be identified with the hierarchical, typological, complete design of something. This mode is not new, but it is peculiar to the internet (other examples dear to path dependency theorists that involve networks of a general kind are useful for thinking about this distinction, but in each particlar case, the modifiability of the standard differs, and usually not changeable by a single user, such as VCRs, which would require buying a new deck, since changing the format is not possible).
The following two chapters attempt to follow out these threads, and specify this distinction them with greater detail in the context of specific institutions, in particular in Healthcare and in Standards organizations. First I will explore how something as deliberate, slow-moving and complex as the DICOM standard has come into conflict with the web (in particular, the HTTP, HTML and TCP/IP standards, which are themselves slower and more deliberate processes than the application level standard that Amicas is concerned with), and how Sean and Amicas have learned their way around it. A further comparison between Partners and Amicas will also be necessary. This distinction, the difference between internet protocols and the more complex standard for networking— the ISO-OSI seven-layer stack model— has specific implications regarding the specificity of medical data and the concept "Quality of Service" QoS.

1. The work of sociologists of science in the wake of Michael Polanyi's book, The Tacit Dimension, [Polanyi66] is relevant here, though it is the precise nature of the institutions that allow the transmission of such 'tacit' knowledge that ties standards to this question

2. See Weber, Economy and Society, Vol. 1, Part one, chapter one, sections 5,6,7 and Part one Chapter Three, sections i, ii, and iii [Weber68].

3. I don't know if this need be said, but it does not imply that those individuals who are 'on' the internet, or 'in cyberspace' are libertarians, any more than people who use the phone system can be said to be so. But the fact remians that those individuals most involved in the design, maintanence and redesign of the internet, are more often than not, fans of Ayn Rand

4. C was initially developed at Bell Labs, by Brian Kernighan and Dennis Ritchie and used for the initial development of the Unix operating system, no doubt there is a history of its ownership by At&T to be told somewhere, however, the basic point is that the definition of the language— the standard promoted by ANSI— is not owned by AT&T. For more on the history of these languages see http://cm.bell-labs.com/ cm/cs/who/dmr/chist.html and http://ei.cs.vt.edu/~history/ Youmans.Java.html

5. The irony in this sentiment is borne out by Donald Madison's study of early tewntieth century hospital organization, and the importance of the term "cooperation" in Progressive era hospital and AMA organization, see [Madison96]. Also see chapter P for more detail.

Last Modified 11-Sep-99 9:01 PM ckelty@mit.edu

Go Back to the Start


	E. Standard differences Scholarly literature is departed for an Example from ethnography — and Another from an email discussion on standards in which Religion and Heresy appear — some Very Important Distinctions are made — between freely available standards and not — between written standards and implementations — the concept "it works" is introduced and discussed.. As the scholarly literature on standards expands, it is easy to lose sight of what might be the crucial differences between kinds of standards. The diversity of technical standards, especially those for software and networking— for information communication— can easily overwhelm the important theoretical differences. In order to maintain some specificity, without losing the generality that will connect the primitives of scale and convention to the programmed languages of the internet and society, ethnography studs the following exploration with stories that may seem more or less real, more or less explanatory, or more or less obfuscating. The spectrum of laws, regulations, contracts, standards, conventions, and customs continues to enfold a problem of location— the spectrum of boundaries: world, global, international, national, legal, commercial, mediatic, governmental, local, virtual. At ground level, as it were, to use a metaphor of space that somehow still makes sense, there is the problem of how anyone knows what standards (techncial or otherwise) are appropriate for anything at all. Engineers and technicians from different communities will have been trained to respect different sets of standards, based on reasons that may be obscure— issues of technical 'elegance,' national or international endorsement, explicit teachings, or learning of a more implicit, customary or 'tacit' kind [1]. This is the sole point where existing national and cultural identifications have specific technical impacts. Training varies, socialization varies, and access to information varies. Engineering is not one, nor is medicine, and the differences that result translate into differences in standards that are applied or obeyed. Rightness and authority reference all standards, from the metric system to rituals of construction. Herein classical Weberian concepts still work: obeyed standards are the probablistic measure of an obcure, but identifiable given authority. [2] The first cut divides internet-savvy programmers and engineers from telecommunications and electrical engineers. Software programmers who associate themselves with the internet as a kind of ethic ( a 'community' occassionally refereced as 'hackers') tend to be auto-didiacts who view the authoritarian attitude of "a right way to do something" as suspect, and substitute instead a demand for demonstrable, measurable quality. Telecommunications and electrical engineering is a profession with a great diversity of certification and licensing practices, that engages a much more bureaucratic and institutional version of authority, and often demands adherance over demonstrability. This cut inevitably effaces the differences within each field, in order to connect the differences between them to different sets of conventions, standards, standards making procedures, and political affiliations whose distinctions are difficult to perceive from within either one. For example, from the perspective of individual advocacy, the internet is easily identified not only a separate set of engineering ideals (I refer to the ideals of the internet as a stupid network, discussed in section G), but a different political ideal, most often— libertarianism. Telecommunications and electrical engineers might be less likely to be libertarians. In any case (assuming we could make such generalizations), to simply allow that these differences issue from different 'cultures' obscures more than it enlightens[3]. The fact remains that engineering ideals (the Bildung of the engineer, his or her tacit knowledge, and explicit professional affiliations) and political actions (the promotion or blocking of specific decisions) are inseparable. The distinction is a vulgar one, necessary to get work done, like the distinction between real work and philosophy. Political action was never confined to the voting booth, except in the justification of actions. Like the relationship between trust and truth identified by Porter, engineering decisions and political action share the same bargaining table. When people are convinced that they are right, when they insist that their way is a better way, a direct access route to obscured political beliefs is opened. When, in the case of the internet, engineering or programming decisions are experienced as 'political' or at least, as more than simply 'technical' choices, standards are inevitably at the heart of the discussion. Standards issues, like platform wars, tend to take on the character of religious disputes, sometimes with strictly articulate rules for their arbitration (levels of specificity, arguments about users, cost, or self-evidence, testimony, especially "It works," which we will see later is one of the most powerful political assertionas of will) sometimes with all-out dogmatic insistence, unchangeable minds, ALL CAPITAL LETTERS. Often, when the specificities have been exhausted, explicit arguments about the nature of laissez-faire capitalism and its corruption by large corporations and governemnt regulation take center stage. In the end, these debates come close to engaging legitimacy at a very high level— that is to say, the cover of a distinction between technical and political issues is shorn for a direct attack on forms of political or economic action. Consider, for instance, a sample from the discussion list for XML developers, sent to me by Sean. It seems that the word "standard" is a new modern marketing magic wand. what do this means exactly? If W3C has 320 members and claim to produce "standards." Does this means that if I get 320 friends (not from the same company) and produce a spec, could this be a "standard"? if not why? Did we forget some historical lessons when at some period of time people where claiming authority based on some "standards", even attributed themselves the right to burn people not conforming to the "standards." So, what this word really mean today? disguised power struggle? Do "standard" really mean "against Microsoft" (this does not necessarily I am for _ and that I have to say this just put more emphasis on the quest to find the real meaning of "standards") ? Do "standard" mean... What this word really means anyway? What is really behind it? We can appreciate the difficult English of this email, if for a moment we treat it as 'non-standard' English, and listen to the bewilderment manifested at the fact that the emotional attachment to legitimate authority inevitably refers us to some version of revolution and heresy, here it is Bruno, burnt at the stake for proposing to speak truth to the prevailing authorities' standards. This email is a perspicacious example of this phenomena— common enough to be very recognizable on such newsgroups and mailing lists, and often just referred to, somewhat cynically by my informants as "religion and philosophy." The discussions are inevitably confused by this maneuver, where the artifactual nature of standards and the purely politcal game is confused with an extra-cultural progression towards truth. The result is that standards discussions very quickly become religious disputes, disputants very quickly recognize this, and in the end, the only arbitration is a grunt insistence an a piece of technology: "it works." These discussions came to make sense to me as a result of observing the differences between the Partners Telemedicine Center and Amicas, specifically with respect to the difference between the electrical engineer who learned information technology via night classes and Microsoft certification programs (Tim O'Neil) and the economist who learned programming and information technology on Usenet groups, from programming handbooks and O'Reilly texts, or just by asking around (Sean Doyle). Tim (as well as Dr. Kilborn) was a representative of an engineering tradition that valued consensus, certification, professional identity and treated standards as a kind of legitimate authority, whether they were the standards of a public or private entity. Sean on the other hand, preached the gospel of openness and open standards, partially as a result of his experience of learning via the internet's openness, and often referred to the Evil spread by Microsoft into the world. The mutual unintelligibility of this choice is what I insist is the central and most imortant difference for standards setting specifically, but for the internet and the technical-legal society it programs in general. For now, two important distinctions: 1) That between a standard that is freely available (though not free) to anyone and one that is not. In the first case, it may be copyrighted or not, and there may be a nominal charge associated with it, usually justified in terms of covering the costs of its development or publishing— and usually associated with a non-profit, non-commercial organization that is made up of members of different companies in an industry. Standards organizations with the backing of governmental authority are most often of this kind, but not always. In the second case, the standard may be unavailable because important parts of it are kept secret by the company that created it— thus a proprietary standard— especially if that company is the only manufacturer (and here, monopoly and antitrust issues become relevant, as do legislation protecting "trade secrets"). A company or standards institution may also engage in some commercial activity such as licensing the standard (which depends on some protection accorded by patent and copyright law, though this will be further complicated by software licensing practices, q.v. sections K and L) or engaging in some activity with another company that necessitates sharing a standard for the production of a specific technology. Examples include the standard for Microsoft Word documents, Adobe PDF files, or the Windows Operating system. 2) That between a standard and an implementation of that standard. The published standard may be, for all intents and purposes, useless to most people (Sean Doyle: "there's open like in DICOM where people can use it but it might take them 3 months with a good C++ programmer to download the code and then understand it.") either because it is too complex or because it may set specifications that need to be tested and measured against something. Example: standards for weights and measures— whether a standard iron bar in the center of town, or the wavelength of a Krypton atom. Tolerance in Alder's work: the devices for measuring tolerance in bore size need to be available to testers, not just a number. But more than this, in the world of software engineering and management, designers need implementations to work with— to test against, and to understand how a piece of technology works, either to reproduce it, or to fix it when it breaks. If you don't have the implementation of the standard, then complying comply with the standard adds a level of complexity to the creation of software that makes producing compatibility difficult enough to discourage the most persistent designers. In the case of this second distinction, standards are much more than simply about measurement or control: they provide examples to learn from, and challenge the distinction itself. It is possible (and indeed, required in some instances, as I explain in Chapter H) that an implementation could become the standard. That is to say: there is a working example of a protocol (or a piece of software), implemented in a working network, that is then declared a standard by a governing body. This is what the path dependency theorists theorize, but without the last step, so that, for instance Microsoft Word is the de facto standard for word processed documents, but certainly, no legitimate authority of any kind has declared it a standard. On the other hand the protocol for ftp is also a de facto standard— it was adopted in a similar manner, by use and incremental improvement— but was then declared a standard by the IETF (see chapter H). Those familiar with the internet understand this well: by making the source code of any system available, you allow not only massively parallel testing and development, but a working implementation that people can learn from, copy, comply with, compare to, and for the entrepreneur in each of them: adopt. Sean Doyle tells a version of this distinction: S: Well, its also, very hard, because if the standards are sufficently complex— and almost all standards that are worth anything are complicated— if they don't come with a sample implementation then you know, you're toast. Sean is thinking here about the DICOM specification, which is a hopelessly complex document, and without a system to test against, or at least to look at, he insists, you're toast. Sean, however, gives a different and more complex set of examples to illustrate the point: S: If you look at the definition of the C language, you know, it's pretty terse, if you look at the one for Java, [the Java programming language definition is a proprietary standard wholly owned by Sun Microsystems, written James Gosling, Bill Joy, and Guy Steele, whereas ANSI C is a standard that was published by ANSI, and in 1990 included by ISO/IEC, Sean could be referring to the earlier specification by Kernighan and Ritchie, but it is unclear] it's really much longer, even though the language is much more semantically clean, and that's because they spent a lot of time trying to be really serious about having a language that is cross platform. The main thing is that they had a working implementation that other people could test against... you sort of need both the written [standard] and the implementation in order to make it go along. What Sean is trying to get at here is more complicated than he lets on. Trying to explore the relationship between a standard and an implementation in terms of computer languages doubles the complexity of the difference between a "written" standard and its implementation and a de facto standard as an implementation and its written standard. To begin with, a "language" is never implemented, per se, but would require a compiler or an interpreter for that language, and in the case of C, it would have to be specific to the operating system and machine that it was to be run on. In the case of Java, as Sean points out, the specification for the language is more terse because they needed to include specifications that would allow it to work on several different operating systems, and potentially be expanded to others. Furthermore these technical details are not the only thing at issue, consider the difference between C and Java more carefully. The C programming language definition is available from the Online ANSI standards store for $135, 12MB, Document Number: ANSI/ISO 9899-1990 (R1997). This means it is not a paper document (though you can get a paper one), that it is expensive, and that ANSI controls its distribution. The specification cannot be extended or transformed (which might seem obvious, since it is a standard, but it needs to be said, because this is not always true, only true in this instance). If you do change it, you are forgoing national and international standards, and would be unable to pass conformance statements that would give your implementation (of a complier, for instance) the ANSI stamp of apporval. If you wanted to get an implementation of the C programming language, you would need to find a piece of software that implemented the language for some reason, say, a compiler that turned C code into object code. There are several of these, such as gcc, the GNU C compiler from the Free software foundation (which is also free of charge). Or you could purchase whichever "software development environment" you might prefer (such as one of Microsoft's Visual Studios). However, only in the former case would you be able to look at the source code of the compiler/development environment to see how it implements the C language specification. A proprietary environment will not include the source code, usually only the binary executables. Both may conform to the ANSI C standard, if ANSI has approved them, but ANSI does not police every implementation of C, which would probably be impossible. However, in th case of gcc, the source code is available and it is also 'free' (see section K), which means that you could conceivably change it to produce a new version of the gcc (perhaps different than the ANSI standard), if you determined that was necessary for whatever reason. The relevant point for Sean's example is that if you only have a specification for C, you can't make it (perhaps your compiler) "go along" [4]. If you already have an implementation of the specification, you can at least copy its structure, or learn how it "worlks." The Java programming language definition, on the other hand, is wholly owned by Sun Microsystems and will be given to you for free on a limited license (one copy) here. This means that Sun owns the copyright to the specification and has licensed it on a per copy basis to people who want it. It is free of charge, but it cannot be redistributed. The specification cannot be extended or transformed under threat of legal action from Sun Microsystems. Sun provides a free (though also proprietary) programming environment called the Java Development Kit (Recently changed to the Java 2 SDK, there are versions of it for Windows and Unix). Under a new license, the source code is available, but still owned by Sun. Sun allows other vendors to create development environments using the specification, but it contracts with them to implement the specification as they have designed it. Java is slightlly more complex in that it depends on the inclusion of an interpreter in the various Web browsers (for different operating systems) made by any web browser manufacturer to interpret the source code that is downloaded over the net (this is the theory behind the "write once, run anywhere" logic of Java). The inclusion of this interpreter depends on a complex licensing and contracting practice that tries to incent browser manufacturers to include an implementation of Java in their browsers. If the browser manufacture implements the language according to spec, it should run any jave program written on any platform. This was the subject of Sun's law suit against Microsoft in 1998, because Microsoft implemented a version of Java that did not correspond to Sun's specifications for Java, and thus did not always run Java programs the same way, or at all. Sun claimed a breach of contract. The point, I take it, for Sean, is that in the development of the various interpreters in various web browsers for Java, Sun had provided an implementation of Java-compatible browser to fro developers of the interpreters to test against. This made cross-platform compatibility easier than each having to write an implementation based soley on the specification of the language. Sean offers a second example, this time of a protocol, that is also meant to prove this point: I've heard, and this may be a bit of folklore, that TCP/IP, you know, one of the reasons that worked so well as a standard was that some of the initial implementations were part of the UNIX kernel and they were made free [such as, perhaps, an early version of BSD], and so when there were things that weren't in the spec you could look back at the implementation and say "I want to make it compatible with this one" then you could make it work that way. So it's really not enough to have the paper, you need to have an implementation, and it's really hard to have the incentives, for people to release both the implementation and release the code. The last sentence is crucial for these distinctions with respect to the internet: having a standard is one thing, having an implementation of a standard is a second thing, having the source code for that implementation (in the case of software) is still yet a third thing. Having all three is often too much to ask. The distinction Sean points to— between the paper specification of a standard and the working implementation of a standard and its source code is recapitulated by every story of the internet, even if the conditions of possibility of this story (ARPA's hand in the development of the internet, or the NSF's, or the instiitutional conventions of university computer scientists) are effaced or troped. It is the case that this distinction is meaningful to many of the actors who write software or build networks— and it suggests that what people find compelling about the story is the suggestion of its openness, specifically that one can use it to learn how something works. These examples should at first recall the distinction between a patent and its device, and the problematic issues of toggling between them, especially in the case of "technology transfer." But they should also give just some sense of the quadrilateral set of concerns: national and international legitimacy, availability and accessibility, corporate ownership, and workability. The corners of this shape fold to meet in a variety of conformations, and the difference between any two engineers will often depend on which corner is most dog-eared. My use of this paralellogram of interests is in the the comparison between Partners (Tim O'Neil) and Amicas (Sean Doyle). Partners developed no software of their own, preferring to outsource most of the technical work, but this did not make them immune to standardization issues, or to the relation between standards and communities of practice, or the necessity of knowing how things work in order to make decisions about what to spend money on. For Partners, legitimacy rests outside the organization, in the structure of certification and recognition that makes up the national medical-corporate establishment. This history of standardization and certification is at least a century long, and mixes the recognition of authority in the person of the doctor with the baptism by the hand of the administrative state in the guise of the various professional societies. Goodness, skill, rightness, truth— all issues of pure validation, peer-review by the proper authorities. Authority precedes (both personal and institutional), accreditation follows, credentials bear witness. For Sean and Adrian, this history is the reason that healthcare is a frustratingly anti-competitive environment [5]. For Tim O'Neil and others at Partners, this authority is both a bureacratic hassle, and a positive external guarantee of quality— or at least the promise of quality, even if they are sometimes cynical about it. Amicas therefore serves as the example of a company that insists on the necessity of both the standard and the implementation (though not yet necessarily the source code): it works, and the only way to know that it meets a standard is if it works. Partners Telemedicine represents a much different approach to standards, in which certification, hierarchy, and control play a large part. It doesn't need to work, in the sense that Adrian and Sean would have it work, but it does need to be tested in a clinical trial and verified through publication in a peer reviewed journal. Only in that sense will 'it work.' Perhaps you may ask, what does it mean for something to work? Does that mean work well? Or simply work once? On the one hand the importance of the phrase "it works" will be that only a piece of software properly written and compiled and run will "work," everything else is either broken, or cannot work. A paper specification for a language such as Java does not 'run', does not produce output or cannot be used to build a compiler (at least, not without some supplemental knowledge or decisions to resolve the ambiguities of the standard). On the other hand a working implementation of something can work better or worse, it can be just good enough, or it can be reliable and robust. But if "it works" and you can look at it, and see just how "it works" you can build another one like it, or better. As we will see with the Free Software Foundation and Opensource.org, the quality of the software is implied by the token "it works," suggesting that that other piece of bloated, feature-laden, inefficient software it is compared to, doesn't work. What is meant is that it works so badly as to make users suffer. It breaks often and eats files, or it is molasses like and memory hogging. Criteria for such a comparison proliferate, as do implications for why it doesn't work— from conspiracy theories about support costs, to suggestions that "the best" developers go elsewhere. In many ways this distinction haunts the supposedly transparent claims of people— like the FSF and opensource.org alike— who would insist that differentiating good from bad software or good from bad protocols is somehow obvious. And yet, I would insist that the crucial theoretical content of "it works" is that it refers to a kind of language that is both descriptive and performative. That the distinction between standard and implementation explained above functions as a kind of legitimation here. It repudiates a theory of representation that insists on mimesis as the mode of control of entities (make a standard that governs all possibilities and keep it separate from all implementations) in favor of a one that insists on the mutual action on and description of entities in a modifiable manner (make an implementation the standard, and allow it to be change). Modifiability is the sine qua non of this mode, not those criteria of completeness or classificatory elegance that would be identified with the hierarchical, typological, complete design of something. This mode is not new, but it is peculiar to the internet (other examples dear to path dependency theorists that involve networks of a general kind are useful for thinking about this distinction, but in each particlar case, the modifiability of the standard differs, and usually not changeable by a single user, such as VCRs, which would require buying a new deck, since changing the format is not possible). The following two chapters attempt to follow out these threads, and specify this distinction them with greater detail in the context of specific institutions, in particular in Healthcare and in Standards organizations. First I will explore how something as deliberate, slow-moving and complex as the DICOM standard has come into conflict with the web (in particular, the HTTP, HTML and TCP/IP standards, which are themselves slower and more deliberate processes than the application level standard that Amicas is concerned with), and how Sean and Amicas have learned their way around it. A further comparison between Partners and Amicas will also be necessary. This distinction, the difference between internet protocols and the more complex standard for networking— the ISO-OSI seven-layer stack model— has specific implications regarding the specificity of medical data and the concept "Quality of Service" QoS.
1. The work of sociologists of science in the wake of Michael Polanyi's book, The Tacit Dimension, [Polanyi66] is relevant here, though it is the precise nature of the institutions that allow the transmission of such 'tacit' knowledge that ties standards to this question 2. See Weber, Economy and Society, Vol. 1, Part one, chapter one, sections 5,6,7 and Part one Chapter Three, sections i, ii, and iii [Weber68]. 3. I don't know if this need be said, but it does not imply that those individuals who are 'on' the internet, or 'in cyberspace' are libertarians, any more than people who use the phone system can be said to be so. But the fact remians that those individuals most involved in the design, maintanence and redesign of the internet, are more often than not, fans of Ayn Rand 4. C was initially developed at Bell Labs, by Brian Kernighan and Dennis Ritchie and used for the initial development of the Unix operating system, no doubt there is a history of its ownership by At&T to be told somewhere, however, the basic point is that the definition of the language— the standard promoted by ANSI— is not owned by AT&T. For more on the history of these languages see http://cm.bell-labs.com/ cm/cs/who/dmr/chist.html and http://ei.cs.vt.edu/~history/ Youmans.Java.html 5. The irony in this sentiment is borne out by Donald Madison's study of early tewntieth century hospital organization, and the importance of the term "cooperation" in Progressive era hospital and AMA organization, see [Madison96]. Also see chapter P for more detail.
Last Modified 11-Sep-99 9:01 PM ckelty@mit.edu Go Back to the Start