Follow Us on Twitter
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 :
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.)