Jason Pontin, Editor in Chief and Publisher.
Mark Ostow
What freedom attracts.
Openness is a virtue. When we like a person, we say, "She has an open face." About a friendly gesture, we remark, "That was openhanded." About ourselves when young, we might sigh, "I was open to new experiences." Openness is attractive.
Most technologists find openness attractive too. A technical term originally derived from thermodynamics (where it referred to any system that interacted continuously with its environment), openness came to be applied to systems theory, and thence to software, where it initially had a very specific meaning: open computer programs and languages are those that have some combination of portability (that is, they can run within a variety of environments) and interoperability (which means they can exchange data with other software). They must also adhere to open standards, a term that is generally understood to refer to two related ideas: that the software should be free for use, and its source, or underlying, code should in some manner be defined by its community of developers and users. The operating system Linux is the best-known open software.
The Windows operating system, by contrast, is closed, or "proprietary," in the jargon of information technology: it is not portable and possesses limited interoperability. Although elements of Windows adhere to open standards, the program must be licensed, usually for a fee, and its source code has been compiled and hidden from users and developers outside Microsoft. Developers write to application programming interfaces, or APIs, which until last year were mostly closed, and which still Microsoft jealously guards.
Ever since the emergence of the Web, whose multitudinous pages are themselves created with open standards, information technology has tended to become more and more open. Increasingly, software companies stress their openness. Often, this is mere marketing. Sun Microsystems' Java platform, widely used to create software for devices as different as embedded systems and supercomputers, has been portable and interoperable since it was launched, in 1995, but the heart of its source code was released only in 2007. Some perfectionist companies forswear openness because closed software can be more beautiful, particularly if it is married to hardware, like the Apple Macintosh operating system. But most technologists want their software to be open, because openness attracts innovation.
In this issue, Technology Review's chief correspondent, David Talbot, describes the effort to make online video open (see "OurTube"). He writes, "A growing number of technologists and video artists want to see Web video adopt the same openness that fueled the growth of the Web at large. ... A similar transformation of video would not just allow trouble-free playback of any video you might encounter. It would also mean that any innovation, such as a new way to search, would apply to all videos, allowing new technologies to spread more rapidly. And it would make it far easier to mix videos together and create Web links to specific moments in disparate videos, just as if they were words and sentences plucked from disparate online text sources."
Creative Commons was founded on principles based on openness - authors can choose to "open" license their work so that others can use it, as long as they cite the author -- in other words, openness through license rather than restriction through license.
The Miro player (http://getmiro.com/) is an open source project that has not only built an awesome video player, but also a community of content around it, including all of the videos from TED conferences, large numbers of PBS videos, National Geographic videos, etc.
open source video editing, 3D rendering
http://www.blender.org/
A non-profit organization and open source suite of software that is arguably more powerful than the Adobe suite (Photoshop, Illustrator, etc.). With some training, users can edit any video, render 3D scenes and animations.
The landscape is ripe for the "openness" that you write about. And the tools are mature and ready.
1. It is considered a distortion to define or conflate open standards as requiring open source and free software. The open standard must be free to use and developed openly, without conditions on implementations. There should be no IP encumbrances in the employment of an open standard. But implementations of an open standard might be open or closed. The OpenOffice.org implementation of ODF is within an open-source product. The Microsoft Office 2007 implementation of ODF is within a closed-source product.
2. Microsoft has had massive API libraries that are openly available to use and have been for years. They are documented on-line. The regulator-compelled documentation and release applies to interfaces and protocols used among and within Microsoft products, but application development using APIs provided for use of Microsoft products by higher-level applications was not restricted. The publication of additional interfaces and protocol documentation and affordable licenses were important to enable interoperable competitive products, and that is why they were required. API is unfortunate code for that specialized material, obscuring the significant APIs that were and continue to be open to developers and users on the Windows platforms.
Having said all of that, I must also say that I admire your introductory theme about the appeal of openness. Spot on, in my world.
1. What constitutes "openness" and "open standards" can be endless debated - and has been. I certainly accept that *one* definition of open standards emphasizes open definitions but accepts that implimentation can be closed and licensed. That definition has always been very popular with software companies that wish to present themselves as open, whilst still controlling and profiting from their code (consider Sun). But the definition I gave of open standards is very common, perhaps the most common: there is an assumption of open source and also of free-for-use and free in the sense of without charge. See, among many other instances: http://perens.com/OpenStandards/Definition.html
2. Concerning the openness of MSFT's WinAPIs, I was scrupulous to say they had been "mostly" closed (by my definition) until last year. They've been *partly* open for years.
Your more narrow definition of open standards would only exclude truly, absolutely closed-box software that neither sought or required the involvement of a developer base: military systems and embedded controllers and the like.
On point 1, I looked at the Bruce Perens document and nowhere do I see anything about open-source implementations as a requirement for qualification as an open standard. I do see that open-source implementations should not be prevented in any way, nor should commercial closed-source ones as well as I can tell, but I see nothing about an open-source implementation requirement.
Where specifically are you seeing any coupling with open-source implementations in that document?
On point 2, I would have said mostly open (in terms of being able to use platform APIs available to applications) and more open since the additional interfaces and protocols have been documented and made widely available and easily licensed. The additional interoperability that is made available is very important, although the audience for it is far more limited and specialized. Also, the release of the new materials occured over several years, and have been continuously updated. That there was objection on completeness and also expansion of the scope in that period does not mean nothing was available until just last year. They finally made the documentation publicly available without license, which I recall Microsoft had not been required to do. It has since been further updated and expanded and there is no indication that will not continue.
I agree that comparative significance of what was available and what was made available since is subject to debate. But that the last is the biggest best part is not so clear-cut. The purpose of availability, as far as courts are concerned, is as a remedy by encouraging competition and substitutions for Microsoft products. At this point, I don't think we can tell whether the aims of the regulatory authorities will be achieved by this action.
[Replying in parts because the original comment is not in view while I am using the entry form.]
With regard to my "narrower definition," I fully accept and am aligned with the definition that Bruce Perens has offered. You and I seem to be reading it differently.
I also don't see where I have said anything that has the constricting consequences you are seeing. As far as I know, all of the standards I am working on (such as the OpenDocument Format at OASIS) are poster children for open standards. They neither require nor prohibit open-source implementations. I wouldn't be working on them were it otherwise.
1. The very common definition of open standards by Bruce Perens (who, for readers who don't know, is the author of the Open Source Definition) certainly supports Free Software. It supports free-for-use here: "Open Standards are available for all to read and implement." And it supports free-of-charge here: "Open Standards are free for all to implement, with no royalty or fee."
2. And the Perens definition implicitly supports community development here, although it calls this a "best practice": "The best practice is for software reference platforms to be licensed in a way that is compatible with all forms of software licensing, both Free Software (Open Source) and proprietary... [Free Software] is a paradigm in which the creators of computer software or other media convey rights to others to freely use, redistribute, and modify their work. This results in a broad public collaboration on such works."
Perhaps I am missing a logical step, but while I see your point that the implimentation of an open standard may be open or closed, a truly open implimentation of software is by definition...well, open.
But I think my larger point is that is that while definitions of openness are endlessly fought about by Perens, Richard Stallman, et al., it's non-negotiable elements seems to be: portability, interoperability, freeness (in both senses of the word), and *some* kind of community development. In my column, I was careful not to be too restrictive about the exact nature of that community development. I wrote: "...the underlying, code should be defined by its community of developers and users."
1. I believe that Bruce is always talking about the specification of the standard in those passages, not implementations of the standard (beyond the standard being free to implement).
My assertion is that it is a mistake to read these items to be imposing anything on implementations. Based on Bruce Perens having also provide the inspiration for the Open Source Definition, I think it is reasonable to presume that he is very careful in his choice of terms and what he means to distinguish. See the latest derivative of his early contribution. I think the contrast between open-source and open standards should be quite apparent.
Is this the basis for our different readings of his Open Standards thesis? I think we have narrowed in on our area of disagreement. I suppose the next thing would be to ask Bruce what he says about the connection between Open Standards (his definition) and Open Source (his definition). I have nothing more to contribute on this point.
2. Oh, and I am in full agreement that community development of specifications is part of Open Standards.
I concur that community development is also desirable for "reference platforms" whatever those are exactly, especially if needed for promoting interoperable implementations. The same would go for test suites and conformance verification materials and software-development kits (SDKs) and, oh, libraries and APIs, it seems to me.
I note that this part is conditional on whether or not there are reference platforms, something that might or might not be done or even always needed, it seems.
I'm also unclear whether reference platforms are necessarily the same as production implementations; I don't think an open-source implementation necessarily qualifies as a reference platform. There is considerable situational context to consider.
Finally, I agree with you that community development is a very useful approach in a wide variety of settings. It is to be prized. It also connects to the ways in which techologists (or at least this one) value openness. Again, thanks for pointing to that.
Well, I see what you mean: since the 3rd and final part of my definition of open software (the implementation) was about open *standards* perhaps I should have written something tautological like: "open software that is written to an open standard must be free in both senses of the word, and it must, in some sense, be defined by its community of developers and users." Or something like that!
Manufacturing in the United States is in trouble. That's bad news not just for the country's economy but for the future of innovation.
Our list of the 50 most innovative companies, including the following:
On Twitter
Become a Fan on Facebook
Subscribe to the Feed
acfou
3 Comments
openness: next step in the evolution of social networks
great article. And it points to a necessary next step in the evolution of social networks - openness. Right now, there is no way for me to export all of my content (personal conversations, photos, friends lists, etc.) out of Facebook; or even make a backup. After one or more incidents like the DDoS attack on social networks in early August, users may get spooked and demand greater control over their own information and social content.
Reply