In Perspectives on Open Source Software (2001) from Carnegie-Mellon's Software Engineering Institute the authors raise interesting points suggesting why the answer to "how open software needs to be" may come down to "it depends..." if we're thinking of "need" relative to optimizing for a set of requirements (as opposed to the relative simplicity of calling something "open" for marketing purposes or even establishing a trademarked definition.)
They describe "open source software" as
"at the most basic level [meaning] software for which the source code is open and available. Open and available is meant to convey two concepts: 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 (e.g., media and shipping charges or online connection charges)."
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 interesting points relevant to distinguishing meaningful requirements for the SW:
An example of a license (Sun's JDK 1.3) that violates OSD criteria #6 ("No discrimination against fields of endeavor") by stating the SW "... is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility." (For most folks for whom lack of an OSI cert might otherwise be a showstopping characteristic, IMO I'd guess this violation is likely to be something of a trivial one in terms of relevance to actual usage scenarios...)
And on the one hand 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 health of the OSS product's community, since the customer 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."
Versus the case of customers who, on the other hand intend to treat OSS as a "white box"--meaning changing code--of characteristics of the SW 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 whole report is worth reading: http://www.sei.cmu.edu/publications/documents/01.r eports/01tr019/01tr019title.html
Slashdot Mirror
In Perspectives on Open Source Software (2001) from Carnegie-Mellon's Software Engineering Institute the authors raise interesting points suggesting why the answer to "how open software needs to be" may come down to "it depends..." if we're thinking of "need" relative to optimizing for a set of requirements (as opposed to the relative simplicity of calling something "open" for marketing purposes or even establishing a trademarked definition.) They describe "open source software" as "at the most basic level [meaning] software for which the source code is open and available. Open and available is meant to convey two concepts: 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 (e.g., media and shipping charges or online connection charges)." 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 interesting points relevant to distinguishing meaningful requirements for the SW: An example of a license (Sun's JDK 1.3) that violates OSD criteria #6 ("No discrimination against fields of endeavor") by stating the SW "... is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility." (For most folks for whom lack of an OSI cert might otherwise be a showstopping characteristic, IMO I'd guess this violation is likely to be something of a trivial one in terms of relevance to actual usage scenarios...) And on the one hand 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 health of the OSS product's community, since the customer 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." Versus the case of customers who, on the other hand intend to treat OSS as a "white box"--meaning changing code--of characteristics of the SW 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 whole report is worth reading: http://www.sei.cmu.edu/publications/documents/01.r eports/01tr019/01tr019title.html