Accessibility
 
Home / Developer Center /  

JD's Forum

John Dowdell

John Dowdell

John Dowdell joined Macromedia in 1993 and listens to people in the online communities. He likes to make complex things simpler, and keeps a daily weblog of related news.

View Previous Columns

 
"My Way, or the Highway!!" Technological Tolerance and Rigid Belief Systems"

The web relies on a blend of open-and closed-source code

I hear a lot of discussions online about "open" software versus "proprietary" software. Such conversations often leave me confused. Here's why....


Most times this discussion comes up, people present it as a series of binary conditions—something "is" open, or it "is" proprietary, and never the twain shall meet. But most things I see in web development are actually a blend of the two philosophies.

Take HTML. It's an actual ISO Standard, and it is used with other Standards such as ECMAScript, or Recommendations to standards bodies such as Cascading Style Sheets. Each browser has its own secret-formula engines to render markup, handle interactivity, or handle styling.

Although there's an ideal way these engines "should" act, it usually takes a given engine a couple of revisions to hit that expected behavior. For markup, the last few years people designed against HTML 3.2, and recently people have been designing against the five-year-old HTML 4.0 recommendation. Each aspect of browser behavior varies with different browser engines. Behavior usually converges over time, but there's definitely a blend of "open" aspirations and "proprietary" means in there.

The spec is designed by a committee of companies... the browsers most people use are created by a single company. You could say the spec is "open" and the implementations are "proprietary", so what is it overall...?


Or take PNG. It was the very first Recommendation of the World Wide Web Consortium, back in 1996. Most people still use the GIF or JPG formats, both of which have proprietary patents filed against them. Slashdot.org still uses GIF instead of PNG. Why? 'Cause it works, I guess.

Or writing HTML? I used to use Alpha, a customizable text editor. Now I use Dreamweaver—its core engine is closed and binary, but its configuration and extension are open and text. Most other people are in the same boat: HTML creation uses a blend of open-source and closed techniques.

So is HTML an "open" technology? Anyone can write to the file format, but you can't change the file format. You can make your own HTML viewer but you can't exceed what your audience can view. The graphics are usually "proprietary" formats instead of "open" formats. HTML creation is a blend of open and closed too. I'm pretty sure most people would call HTML "open", even though most browsing is done through proprietary code. The closer you look the harder it is to see HTML as either all-open or all-proprietary.


I hear this "open versus proprietary" discussion most often in conversations about Macromedia Flash, where someone jumps in and says SVG should be used instead, "because's it an open standard".

(That whole SWF/SVG equivalence is a little weird for me to start with, because although an XML format for vector drawings is cool, the area of theoretical overlap between SWF and SVG is small, just vector graphics... it's hard to imagine most current SWF work being replicated in SVG. People do posit such an equivalence, though....)

Is one format "open" and the other format "closed"? When you look at it more closely, the lines blur:

  • Format definition: Public input is used in both. SWF is defined by one company, SVG is defined by a few companies. When you look at the record, SWF has been more effective in efficiently bringing publicly-requested features into the file format.
  • Format documentation: Both the SWF specification and the SVG specification have been published online for years. The SVG spec describes how an engine should act; the SWF spec describes how an engine does act.
  • Creation tools: Both formats are created by a variety of tools. More tools (and more important tools) work with SWF, but both formats can be created by tools from various companies.
  • Player creation: Multiple companies have created SWF and SVG renderers. Over the years most SWF-rendering projects have adopted the Macromedia Flash Player, to take advantage of faster feature development and reliable capabilities.
  • Player source code: The source code for the Macromedia Flash Player is available to strategic partners, such as device manufacturers. There are some open-source projects for SVG renderers, but the renderers people usually design against are proprietary and undocumented.
  • Player capability: With the Macromedia Flash Player you know what you're getting... the audience has a standard capability. This difference in standard capability is the main cause of the difference in actual viewing on the web today.

Warning: Anytime I say anything about SVG someone will say I'm "bashing" it. I have no advantage in talking down SVG—if it works for you, great, go ahead and use it, more power to you, let us know about your success.

What I'm really trying to get at with this list is showing how those high-level "open" and "proprietary" labels start to break down when you look more closely at the problem. When someone knocks Flash as "proprietary", I have to question them more to learn what it is that they're really concerned about.

For Flash, the core complaint that turns up most often is "But Macromedia owns the Player and one day they might change it and break everything else and no one can stop them so I won't use Flash." Life doesn't work like that. Look, even if a flying saucer landed at 600 Townsend St one night, leaving mind-control pods which replaced us all with evil zombies the next day, we couldn't remove capabilities from the millions of Players distributed out there. Consumers control it. The current capabilities are a given. If we tried to remove features we'd get hammered. This isn't like the W3C suddenly deprecating realworld LAYER or EMBED tags, because Macromedia's financial results are dependent on satisfying people. We've got to offer people better stuff... there's no business angle in offering people worse stuff.


You can't control what's on the audience's machines, but you can control what's on your own machines. You can choose your own development tools, and you can often choose what's on the server. PHP is a great example, because you don't have to worry about which distribution or configuration other people use—set up your machine as you see fit, and you're good to go.

So, is PHP "open" and everything else "proprietary"? When you look more closely, then things start to blur again. ColdFusion's base is Java 2 Enterprise Edtion—like HTML or SVG, J2EE starts with a definition rather than an implementation. PHP is more like Flash, where a core implementation becomes a de facto standard.

Or look up a few levels, to the extensibility layer. The ColdFusion community has produced tons of custom tags, components, frameworks and other open functionality... measured by what people actually do and how they learn, PHP, .NET, ColdFusion and the rest are comparably "open".

The big difference seems to be in the core engine layer. The PHP approach lets you modify the inner functionality, while ColdFusion and most other application servers use a known and tested black box at this level. Some people can definitely benefit from tweaking their own core engine, but I'm not sure that this is sufficient to label one technology "blessed" and the rest as "evil".


So, by now I guess you see how easily I get confused at that "open versus proprietary" argument... I usually have to dig a bit to find what the person is really concerned about. Sometimes I wonder whether the core concern is a twist on H. L. Mencken's definition of Puritanism, the fear that someone, somewhere, might also be making a profit. But I also know that there are some good, valid reasons for wanting to tweak every part of code which runs on your machine. I'll be opening up a thread in my blog on the subject, and I'm interested in hearing what you have to say, thanks!