How Open? Open How? It Depends…

by admin on June 20, 2006 05:51pm

Not long after I blogged about “disambiguating open” as a research issue, a debate erupted on Slashdot about “How Open Does Open Source Need to Be?”   Three different criteria for deciding whether something could legitimately call itself “open source” seemed to me to dominate the discussion: the level and terms of source code availability; whether or not there was a community organized around the code; and compliance (or not) with the Open Source Initiative (OSI) definition.

What struck me about this debate was, first, the fact that it  was happening because “open source,” in this case, was regarded as a favorable characterization (and thus in the interest of a software producer to apply to their bits) and that favorability was rooted outside of any producer’s application of the term (in contrast, it’s unlikely such a debate would occur if one of the parties had chosen to label their product “cromulent” for example.)   Put another way, the operative assumption is that calling your product “open source”  piggy backs on a store of perceived value among potential customers built up by others, which  may be in a technical or moral sense be “undeserved” and (at worst) might actually result in dilution of that store of value.

What I thought was missing, however, was  some empirical perspective on the ways in which states of the three criteria above  might in fact add to or erode that perceived store of value when the so-called (or not-so-called)  “open source” product was actually consumed by customers.  This reminded me of Perspectives on Open Source Software (2001) from Carnegie-Mellon’s Software Engineering Institute, where the authors do a great job of describing why the answer to  “how open” software needs to be will almost always come down to “it depends...”—if we’re thinking of “need” relative to optimizing for the resulting customer experience  (as opposed to the relative ease of calling something “open” for marketing purposes or conforming to a check-the-box definition.)

The report describes “open source software” as

“at the most basic level simply[meaning] software for which the source code is open and available.”

Which they define as:

“open--The source code for the software can be read (seen) and written (modified). Further, this term is meant to promote the creation and distribution of derivative works of the software…available--the source code can be acquired either free of charge or for a nominal fee”

And they contrast this with the Open Source Definition (OSD) from the Open Source Initiative (OSI) noting:

“Under OSI (strictly speaking) a software product is in fact open source if and only if it conforms to the OSD…Upon reviewing the complete text of the OSD, it is interesting to point out that the definition does not pertain specifically to the source code itself, but rather to the license under which the source code is distributed. Therefore, in strict conformance to the OSD written by the OSI, a software product that conforms to only eight of the nine criteria is not OSS.”

They raise a few points relevant to distinguishing meaningful customer requirements for the software :

• • An example of a license (Sun’s JDK 1.3) that violates OSD criteria #6 (“No discrimination against fields of endeavor”) by stating the software  “… is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility."   (For most folks for whom an OSI cert might be a desirable characteristic, IMO this violation is probably likely to be something of a trivial one in terms of relevance to actual usage scenarios…)
  • The importance for customers who intend to treat OSS as a “black box”—meaning not themselves making any modification or even reviewing code—of the OSS product’s community, since the customer will in this case plans to  be dependent on the community:  “If the community is small and stagnant, it is less likely that the software will evolve, that it will be well tested, or that there will be available support."
  • Conversely, they note the importance for customers who intend to treat OSS as a “white box”—meaning changing code and managing the derivative work themselves—of  characteristics of the code itself rather than the community: “sometimes the source is the only documentation that is provided. Some consider this to be enough. Linus Torvalds, the creator of Linux, has said, "Show me the source." Yet if this were the case, there would be no need for Unified Modeling Language (UML), use cases, sequence diagrams, and other sorts of design documentation. Gaining competency in the OSS component without these additional aids can be difficult.”

The authors of the report conclude that:

OSS [is] a viable source of components from which to build systems. However, we are not saying that OSS should be chosen over other systems simply because the software is open source. Rather, like COTS [commercial off-the shelf software] and CSS [closed-source software], OSS should be selected and evaluated on its merits…Caveat emptor (let the buyer beware): the [software] product should be chosen based on the mission needs of the system and the needs of the users who will be the ultimate recipients.

To me, reading the discussion thread and then mulling over the SEI’s examples bring me right back to what gets me out of bed every (work) day:  there is rich field of inquiry about what makes software successful for its developers and  users.   Neither any one commercial vendor nor organization has it all figured out and trademarked yet—if caveat emptor is good advice to keep in mind, salus populi suprema lex esto  (“the welfare of the people shall be the supreme law “) is a good motto to live by.

(Incidentally, SEI authors Chuck Weinstock and Scott  Hissam revisit some of the findings and analysis in the SEI report in a chapter in a great new book Perspectives on Free and Open Source Software (MIT Press) –I’ll blog more about the book soon.)