Jonathan Schwartz discusses the two:
open standards are the most critical, because making a choice today shouldn’t preclude you from making a different choice tomorrow.
That’s what open standards are all about. They’re documents that outline agreed-upon conventions to enable different programs to work together, along with some means to ensure that they actually do a process or set of tests. With open standards, your company can pick and choose among competing vendors and not be locked in to any one of them.
Many people seem to think that open-source software offers the same advantages. Not necessarily.
Open source simply means that the underlying software code is available for inspection and modification.
Argues Kevin Werbach:
The problem with Jonathan’s argument is that it conflates two processes. Standards are critically important. As he points out, open standards are what allow for choice and prevent lock-in, regardless of whether source code is publicly available. But there are two sides to the standards process: development and implementation. If a standard solves a real problem and has a critical mass of industry support, it will promote openness. That’s what has happened with HTML and RSS, for example. What application developers do with standards is another story, and this is where open source comes into play.
Open source changes the dynamics of building software. It creates opportunities that would not otherwise exist. A successful open source project, like Linux, creates a large and diverse community that contributes to or makes use of the codebase. In effect, it creates a standard through developer adoption rather than vendor promotion. Linux leverages the Unix standard, and the standards-based GNU tools of Richard Stallman. But Linux itself has become a de facto standard. Bill Gates has often described Linux dismissively as just “the first version of Unix that works on Intel processors.” That’s true, but not the whole picture. It’s ironic to see a top executive at Sun, Microsoft enemy #1, make the same basic characterization.
Open source cannot simply be reduced to open standards. Jonathan understands this, and in the article he acknowledges that different software licenses have value in different contexts. Open source projects tend to be better at some things, while proprietary software tends to be better at others. There are no abolutes, just general trends based on the underlying incentive structures of each method. The “best” open source projects are those that facilitate a community and achieve its members’ objectives, whatever those may be. Today, when no application is an island, the same is true for proprietary software.
