Archive of UserLand's first discussion group, started October 5, 1998.

Re: "Open" vs. "Closed"

Author:Paul Snively
Posted:5/13/2000; 11:40:28 AM
Topic:"Open" vs. "Closed"
Msg #:17275 (In response to 17158)
Prev/Next:17273 / 17277

Matthew Wilson: Pike can receive pages from my CMS, and it saves pages back to my CMS. Some of UserLand's documentation is still rough around the edges (i.e. return values not specified for all of the Manila XML-RPC methods, no documentation at all that I could find on the pike.* methods [I had to write dummy HTTP servers and clients to figure out the paramaters and such]), but UserLand's staff, Dave and Andre in particular, were very quick to respond to my questions and they both seem very committed to seeing other people, not just UserLand, be able to take advantage of this technology. To me, that is open.

I think this hilights an important point that's not been made explicit in the debate, and that is that as software itself has greater and greater freedom to choose to expose its guts or not expose its guts, whether by allowing itself to be extended through DLLs, supporting one or more scripting languages or being a runtime + language, exposing itself through an RPC interface, or what have you, the notion that the question as to whether such a system is "open" or "closed" is a binary one is ridiculous, unless when you speak about "open" or "closed" you're entirely clear that what you're referring to is your right (or lack thereof) to modify and redistribute the system in its entirety without penalty.

To give some concrete examples, we don't get the source code to the Pike application and cannot alter it and redistribute it. We do, however, have access to a lot of source code within the Pike root that we can change and share with other Pike users. These thoughts obviously apply to Frontier and Manila as well. So these tools fall, in terms of access to their source, in some grey area between the polarizing notions of "open" and "closed." Of course, when you bring the politics of economics into it, they're "closed," but then, the "open source" vs. "free software" community doesn't have a problem with the profit motive for this.

Another example of a grey area instance is the ever-growing list of computer games that don't provide the source code for the "engine," but do provide source for the code that implements the game around the engine precisely so that ambitious third parties can write "mods" or even "total conversions." The obvious concrete examples here are any of the Quake family, any of the Unreal family, Half-Life and Opposing Force... anyone with a C/C++ compiler can very much develop their own game around these engines, subject to the licensing terms of the engines. Again, not "open" in the you-get-the-source-and-the-right-to-redistribute-it sense. But not "closed" in the you-have-no-rights-beyond-use sense.

Ironically, it just occurred to me that the exact same issues that are causing the lack of software security to become more and more visible are making clearer and clearer how terms applied to large software systems as if they were monolithic no longer work, either.

There are responses to this message:

This page was archived on 6/13/2001; 4:55:11 PM.

© Copyright 1998-2001 UserLand Software, Inc.