Flash, Silverlight and the Open Web

By on April 3, 2008 10:13 am

Brad Neuberg, of the Gears team, took a stab at defining the “Open Web”. We at SitePen are very strongly in favor of the Open Web concept, because it’s the Open Web that has gotten us what we have today and will ultimately lead us to the best “web of the future”. I think that Brad does a good job laying out the characteristics that have made the web successful thus far.

The one thing that I disagree with is this part of “Transparency”:

An Open Web should have transparency at all levels. This includes being able to view the source of web pages;

Though I understand how useful “View Source” has been over time, and I’ve certainly used it, I don’t think the ability to view source is a requirement. For example, people can get pretty aggressive with JavaScript optimization today in an effort to make things perform well. Take a look at the JavaScript source for Gmail. Not only has not-very-readable source had zero impact on Gmail’s adoption by end users, it has also not prevented people from reverse engineering Gmail to the point where there are many add-on tools available.

I agree with every other requirement, though. People should be free to create what they want, and the tools they use should be open for interoperability and competition.

Brad set a careful boundary around his definition:

Today the above philosophy is instantiated using a particular set of technologies, including URLs, HTTP, HTML, CSS, JavaScript, etc. However, if we define the Open Web in terms of these technologies, then we risk losing sight of what makes the web special and being able to have the intellectual nimbleness to evolve the infrastructure of the web.

Not only do we expect all of these technologies to evolve, but we also expect that entirely new ones will grow up to give us new capabilities.

Which brings me to Adobe Flash, its close relative Flex, and Microsoft Silverlight. These tools are trying to reshape the landscape of the web, but are they part of the “Open Web”?

Adobe Flash

Adobe Flash grew up by filling the void for sound, animation and, later, video on the web. Flash is the de facto standard for video delivery on the web. It’s hard to argue against that, given that even MSN Video delivers videos via a Flash player.

In the context of playing video, Flash does not really change the shape of the Open Web. It’s just a mechanism for displaying a particular content type within the browser, and it even provides hooks to control the playback via standard JavaScript.

Adobe Flex

The “is it the Open Web?” question comes up with Adobe Flex. One could always build entire sites in Flash, but doing so was almost entirely filled with downsides. As people have been working to build increasingly sophisticated applications in the browser, Flex has stepped up to provide a way to build complete applications using modern practices, and then deploy those applications within the Flash plugin that people already have in their browsers.

An interesting note about Flex with respect to Brad’s Open Web definition is that it can be seen as an evolution of the web, specifically with applications in mind. Flex uses CSS for styling and the ActionScript 3 language is a JavaScript-like language with extensions (some of which appear in the current ECMAScript 4 work). Rather than using HTML, Flex uses MXML as a format for instantiating Flex components, which can also be instantiated via ActionScript. Flex is certainly heavily influenced by the way the web works.

As of Flex 3, the Flex compiler is open source. Adobe has also opened up their Action Message Format (AMF) for speedy client/server communication. Flex is about as open as can be.

But, it still deploys to Flash. Adobe provides a specification for Flash’s SWF file format, but only if you agree not to make a “player” for SWF files. With that requirement, Flash as more than a video file format cannot be considered part of the Open Web.

There is an open source Flash player called Gnash. At present Gnash is listed as supporting “SWF v7+”. Adobe has evolved SWF considerably since then and Flex 2 and above require SWF v9. It will likely take a while for the Gnash developers to get up to v9, and by then Adobe will have likely moved onto v10 or 11. Because of Adobe’s licensing terms, the only tool for forward progress at the Gnash developers’ disposal is reverse engineering.

With Adobe providing free Flash players for Windows, Mac and Linux, the tempting question to ask is “why care if SWF is open?”

Why Open Is Important

Openness matters because the ability for an independent implementation to come along and shine is a key to continuing evolution. Consider the case of web browsers, which are based on standards that anyone can implement. Netscape had the #1 browser by far in the mid-90s and was eventually crushed by Internet Explorer both because of monopolistic practices and a better browsing experience. After Microsoft won that round, however, they disbanded the IE team. Since then, the state of the art has been pushed forward by Firefox, Safari/WebKit and Opera, among others. The work of those browser teams forced Microsoft to put an IE team together and start building a better browser.

As Joe Walker mentioned a couple months back, total monopolies can be bad and the only real escape route is having multiple implementations that the open market can choose from. Many open source projects and companies operate under a form of “Benevolent Dictator”. Think Linux and Apple. It’s only natural the market leaders appear. But, as long as there is open competition you can choose the leader because it’s a good choice and not because it’s the only choice.

Here’s something else to consider regarding the Flash Player: currently, you can’t have an application that is completely driven by Flash with HTML content displayed by your browser’s engine in the middle. That’s because the Flash plugin has control over the window’s drawing area. If SWF were open, I can imagine browser makers providing SWF rendering with the ability to have full HTML rendering capabilities available from within those SWFs. As it stands now, only Adobe could provide such functionality.

In the end, it’s all about the ability to ensure that the web will evolve in a way that serves the end users well.

Adobe does deserve credit for all of their moves to open up over the past couple of years. As of today, however, the most critical part is still closed off: the SWF file.

Microsoft Silverlight

Microsoft Silverlight is a much more recent attempt to extend the fabric of the web. Silverlight targets precisely the same areas that Flash and Flex do: media (1.0) and applications (2.0), and offers similar features.

Microsoft’s earlier monopolistic practices have earned them a fair bit of distrust. However, over the past few years Microsoft has faced stiff competition for developers, and they have made big changes over earlier practices to keep developers and attract more. Much of their .NET framework has been standardized with ECMA. It’s open enough that there is an open source implementation (Mono) available.

This is relevant for Silverlight, which is built on .NET technologies. Within weeks of Silverlight’s announcement, the Mono project had a working prototype called Moonlight. Microsoft then went further and announced collaboration with Novell to help the Mono project get Moonlight up to speed.

It’s worth stressing that a key difference between Silverlight and Flash with respect to the Open Web is that it is possible to create alternative implementation of the Silverlight “player”. The open source Moonlight project is proof of that.

Silverlight offers something interesting in addition to what Flash offers: because it uses .NET’s infrastructure, Silverlight apps can be developed in the developer’s language of choice. Microsoft offers open source Python and Ruby implementations, as well as a closed-source JavaScript implementation.

At this point, in April 2008, Silverlight’s problem doesn’t seem to be its openness. Silverlight’s problem is its installed base, or lack thereof. The only statistic I was able to find was a Microsoft claim of 1.5 million downloads per day. It’s hard to compare that with the study commissioned by Adobe listing Flash 9 penetration at better than 95%, but clearly the installed base Microsoft is looking for is not yet there, given that MSN Video is still Flash-based.

Dojo and Gears

The vast majority of web applications built today and being built today are not using Flex or Silverlight. They’re using the current form of the Open Web: HTML 4, CSS and JavaScript. Over the past two years, the Open Web has evolved significantly.

Dojo and other JavaScript toolkits have progressed impressively. You can now get attractive widgets and powerful layout management all running in the standard browsers that people are used to.

Firefox, Safari and Opera have pushed the browser state of the art forward with support for newer standards, better debugging tools and vastly improved JavaScript performance. To compete with all of that development, Microsoft has been working hard on Internet Explorer 8, though we’ll have to wait a bit more to see how competitive that new browser really is.

Adobe has helped to support the current Open Web by donating the Tamarin virtual machine code to Mozilla. This should help speed up JavaScript execution in Firefox 4 and smooth the path to the JavaScript 2 implementation.

And, finally, there’s Gears. Gears is a cross-platform, cross-browser, open source plugin sponsored by Google that extends the existing infrastructure rather than providing an entirely new application environment inside the browser. It provides application developers with a bunch of new tools today, and more are in development. Since Gears requires a plugin, many applications will have to wait for it to become as ubiquitous as Flash before they’ll add Gears’ features.

HTML, CSS and JavaScript have the biggest installed base of both browsers and developers. That is a significant advantage over any entirely new technology that is out to displace the currently dominant form of the Open Web.

Free Market at Work

There is no standards body that can truly dictate what the web of tomorrow looks like. Developers will choose their tools as they build their apps, and users will pick the apps that they like the best. For those of us who are web developers, we should strive to ensure that the web of tomorrow remains open so that we have freedom in how we build our apps.

Comments

  • Pingback: Blue Sky On Mars » Blog Archive » Flash, Silverlight and the Open Web()

  • Great post, Kevin, and I think dojo has played a pivotal role in promoting the open web. I’d have to agree with Brad on the “view source” question though. While it’s less useful with minified JavaScript, as you point out, “view source” has still played a fundamental role in lowering the barriers to entry for developers throughout the history of the web.

    As you say:

    “In the end, it’s all about the ability to ensure that the web will evolve in a way that serves the end users well.”

    I couldn’t agree more. As typical users become increasingly tech savvy, though, things like view source form a crucial part of making everyone into both a producer and a consumer of the web. Custom MySpace pages come to mind, as millions of users take advantage of view source to make the web their own. I don’t think it means people shouldn’t compress their JavaScript, though, given the obvious performance reasons for doing so. It would be interesting to just have an automated link embedded in the JavaScript to link to the uncompressed version. Maybe a tweak to the Dojo build system?

    I guess I see Brad’s post as more a set of guidelines than requirements. Clearly the business interests of each company differ, but it would be interesting to have some sort of automated “openness score” companies could post on their sites. Some way to increase incentives for openness. Somewhat similar to what my buddy Matt’s WalkScore (http://www.walkscore.com) does for the sustainability of your neighborhood. I like the pressure regarding swf files along those lines.

    Anyway, great post. Thanks.

    -Adam Fisk
    http://www.littleshoot.org

  • Nobody’s Fool

    You’re making a very dangerous assumption that Silverlight and .NET is “open”. Here’s a challenge for you: Where is a clear, authoritative statement from Microsoft regarding the license terms for patents held by Microsoft? The ECMA standard for .NET only talks about “RAND”, which is “reasonable and non-discriminatory”. RAND is NOT open. Oh, the Mono FAQ has some nebulous email from a Microsoft employee — sorry, that’s not nearly good enough. http://www.gnome.org/~seth/blog/mono

    Microsoft will do anything in its power to maintain its Windows monopoly. The only reason why they go along with Novell and Mono is to get their foot in the door. Notice how Novell signed a patent agreement with Microsoft. Buy from Novell and you are “safe”. You call that open?

  • “Many open source projects and companies operate under a form of “Benevolent Dictator”. Think Linux and Apple.”

    Woah there, Kevin…

    Apple? Open? Given your language prefs, I’m gonna pretend you said “Think Linux and Python.” ;)

  • Brian

    I think an important part of the web ecosystem, as far as openness goes, is development platform. Not only should end users be able to choose how to produce/consume content delivered over the web, but developers should be able to choose what platform to use to develop a particular application. That is why I am so nervous about Silverlight. Adobe does not really have a vested interest in the development platform used, but Microsoft does. Are there Mac/Linux tools available for __developing__ in Silverlight that match the ones available in Windows?

    One of the strengths of the technologies of HTML/CSS/JS is that they can be written with any text editor. It helps to include people in the web from all walks of life, not just the ones that can afford to run the latest version of Microsoft’s (or Adobe’s, to be fair) tools. I do agree that the open web should not be defined in terms of technology (instead, defined by principle), but it is hard to imagine anything that is as flexible while being as easy to be a part of than our current set of “languages”.

    Thanks for taking a look at these technologies from an open standpoint. It needs to be done often, closely, and carefully if we want to preserve the freedom we currently enjoy on the web.

  • Pingback: Ryan Stewart - Rich Internet Application Mountaineer » The Open Web Is Slow()

  • I couldn’t disagree more about flex and flash. Don’t get me wrong, writing Flex apps is joy, and I look forward to the day when using Dojo is just as easy. However Flex is being used not simply as an RIA tool but as content delivery system through flash. This is a huge problem, major huge. Imagine Wikipedia as a flex/flash app. Suddenly when you google for “Uganda” you actaully get the Uganda website. Where is the wikipedia article you were hoping for? Well it’s hidden inside a closed technology. Now try and copy paste that information so you can read it later…. oops almost no flash developer allows you to copy and paste from a textbox.

    The problem with Flash and Silverlight is that I can’t see the source. I can’t parse it for content, I can’t have a semantic web. Well I can have a semantic web if Adobe or Microsoft allow me to.

    The success of the web is based on 2 things, and 2 things only.
    1) It’s intent is to share information.
    This resulted in open standards, community development, machine understanding, and ease of adoption.
    2) Semantics
    Google couldn’t even exist if the unsemantic web of today wasn’t semantic. The very nature of hyperlinks make them meaningful.

    So you tell me. What happens when machines can’t parse information on the web, and teenagers can’t look at source to figure out how something is done. What happens when Adobe instead of the w3c and the concencious the developer community determines how the web progresses.

    Closed formats close information, period.

    Full disclosure: I work for a major Flash design firm.

  • Vance:

    Well said! I completely agree with you, and unfortunately, disagree with my colleague on this.

    Flex is only open in the sense that it’s distributed in an open way, but it’s predicated entirely on the premise that the deployment environment is a closed, locked-down renderer over which Adobe eventually exerts control. To the extent that Flex is open, it has been so to reduce the effective competition from other areas; first Laszlo and then Silverlight and the *actual* Open Web (aka: “Ajax”).

    I don’t think it’s hyperbole to say that the major problems associated with Flash are due to its default toward closed-ness and the fact that view-source is optional. The defaults here *matter* as they have a long-term, guiding influence in the evolution of both the platform and the content it consumes. From that perspective, Silverlight *is* more open and has the potential to preserve some of the introspection advantages traditionally associated with the Open Web. That said, having a single entity in control is *clearly* against Open Web principles, and therefore Silverlight has a long way to go to actually hit that bar.

    Kevin’s right to question the place of HTML+CSS as the delivery vehicle of the Open Web, but I’m pretty sure that there are reasons which have gone un-explored in this post which would definitively dislodge both Flash and Silverlight from the running as currently qualifying Open Web technologies. Further, it seems dangerous to anoint either of them as “open enough” until either really earn their stripes in the ways which you point out.

    Regards

  • I work for Appcelerator and I mostly agree with this. I’ve been talking alot about this lately as well. I really worry about a web world where the browser is only a transport for proprietary bytecode.

  • Read the FAQ

    More FUD from the anti-Mono camp.

    Clearly someone that has not read the Mono FAQ on licensing and patents.

    Seth’s blog was debunked at the time in multiple forums.

  • Thanks for all of the comments!

    One general comment before more specific ones: when I wrote this article, I was thinking in terms of sophisticated application development, not in terms of “websites”. As a hypertext document system, the current web works remarkably well (so well, in fact, that it’s hard to get the “semantic web” off the ground). As an application platform, the web is only now starting to rival and surpass the UIs of desktop applications of a decade ago. I find it to be pretty amazing what Dijit can do, using the same basis for “websites” that we’ve had for years and even on browsers like IE6 which was first released in 2001.

    @Adam: While I think that View Source has been useful in history, I wouldn’t say that it’s necessary for the Open Web. Any successful platform will have plenty of tutorials, books, etc. to learn from. View Source is nice, but not a big enough barrier to being considered “open”, in my opinion.

    I was viewing Brad’s post more as a set of requirements from the perspective of “here’s a definition of what ‘Open Web’ actually means”. It’s kind of like when the Gang of Four wrote the Design Patterns book. They were trying to create a vocabulary that is defined enough to be useful… I do see what you mean about having a “score” so that openness is more of a continuum than a “yes/no”. However, I don’t think a continuum is so useful in this case, because failure to be “open” is putting future development at the risk of being stuck in an unpleasant monopoly with a very difficult slog to get out.

    @Nobody’s Fool: Software patents, particularly as loosely as they’ve been given out in the US, are bad. Frankly, any piece of software is at risk from a patent troll. As I said in the article, many people distrust Microsoft, and with good reason. Believe me, I’m no Microsoft apologist. I don’t regularly run any Microsoft software. But, I’d encourage you to check out the Mono FAQ about patents:

    http://www.mono-project.com/FAQ:_Licensing#Patents

    There’s prior art for a good deal of what’s in .NET, and there are alternate implementations for just about anything MS could sue over. Additionally, if Microsoft had patents they wanted to try to enforce, it would make more sense for them to go after Linux with an OS related patent than to go after Mono. Why? Going after Mono actually hurts .NET as a platform. Going after Linux hurts a competitor to Windows without hurting Windows itself.

    One last bit to consider: firing off a patent lawsuit against commonly used open source software in use at Fortune 500 companies could be damaging to some of Microsoft’s biggest customers.

    The patent risk is there. But, it’s there with just about any software you’re using today, and Mono is probably no more risky than the rest.

    @Dean: Well, sure… but I can’t use Python as an example for everything, can I? :)

    @Brian: You’ve actually got two things going in your comment. “Are there Mac/Linux tools available for __developing__ in Silverlight that match the ones available in Windows?” The answer to this is almost assuredly no. Mono has an authoring tool in the works, but I’d be surprised if it has the polish of Microsoft’s tools on Windows. If they see a market, I wouldn’t be surprised if Microsoft’s Mac BU ports the Silverlight tools to the Mac.

    Adobe gets bonus points because their Eclipse-based Flex Builder runs on Windows, Mac and is in alpha for Linux.

    The second part of your comment is this: “One of the strengths of the technologies of HTML/CSS/JS is that they can be written with any text editor.” Now *that* is true for Flex and Silverlight, at least from a rich application perspective. Obviously, video requires something other than a text editor.

    So, just like with HTML/CSS/JS, you can use entirely free-of-cost tools to build Flex and Silverlight applications, but there are better tools available if you want to buy them. Of course, there are far more tools available for HTML/CSS/JS because those technologies have been around longer and have incredibly widespread adoption.

    @Vance: I should have been clearer that I was talking about applications rather than “sites”. Even if Flex/Flash and Silverlight could be considered part of the “Open Web”, that doesn’t mean they are good technology to replace HTML as a document format. While that *could* happen, the action around those tools seems much more in apps than in sites.

    @Alex: I do agree with Vance. Locking up *information* in a SWF or a Silverlight file would devalue that information tremendously, at least with current tools that exist for working with those files. With more tool support, maybe you could stuff information in those files and somehow wind up with something more valuable… but I have a hard time envisioning something like that coming to pass.

    An increasing number of applications are being written in the style where the client JavaScript is in control of the user experience and the browser requests data from the server that it then formats rather than the server generating fully formed HTML pages. In that context, the data can still be available in different, easily accessible formats. Only the application code that drives the user experience is compiled.

    The question of “control” is a good one that is worth exploring more. With Silverlight, there are two implementations. One that is closed source and on two platforms (Microsoft) and one that is open source on a third (Moonlight). There’s no question that Microsoft is in the driver’s seat there.

    To some extent, Microsoft is in the driver’s seat of the current web, too, given their majority stake in the browser market. They dropped the ball and now other browsers are pushing the state of the art forward. There’s also a standards body that is slowly moving things forward. What seems to be pushing Microsoft to action more than anything is the competition. If Microsoft’s browser share was still at 90%+, would they care what the W3C has to say?

    So, ceding control to a standards body probably isn’t the solution. It really seems like having alternative implementations, or at the very least the ability to make them, would be the main driver for evolution.

    Now, it could be that there are facets to Brad’s “Open Web” definition that I missed, or maybe there are some elements that do not appear in Brad’s definition at all. My goal here is to try to test the definition of “Open Web”, see where the boundaries are with current technologies and see how we’d identify new technologies as they rise up.

  • There’s one important point I forgot to add: what makes the web special is that it supports creating both documents and applications, as well as the fuzzy boundries in between. For example, I can write something that is a document on the web, such as research report, all the way to something that is an application, such as Gmail. What is unique is you can have things that are in-between; for example, MySpace pages are a strange mixture of documents coupled with applications sprinkled in; Wikipedia pages are both documents and applications in the fact that editors (a wiki form) are provided to change things.

    I think this is one of the things that makes the web unique, and which is a very unexplored area in general: how can we create technologies that make it possible to author both documents and applications, as well as fusions between the two? It pretty much just happened adhoc on the web, but what would it look like if you actually took an intelligent stab at it? Right now both Silverlight and Flex are focused more on the application side, while the web itself (to the frustration of the HTML 5 working group) really is focused more on the document side. Can we have both? Looking back from the future we’ll probably see that our view of applications as container Windows with widgets inside is an archaic one.

    On a deeper level, I think that any hypermedia platform eventually subsumes and takes over the application space. If HyperCard had added networking, for example, I believe it would have followed the same path as the web. In fact HyperCard had the same interesting mixture of documents and application characteristics that the web has.

    This was one of Engelbart’s insights when he created NLS/Augment, that hypertext-oriented systems could subsume most of the tools and applications you use in general. He just made a system that was way too hard to use, but the general principles still hold I think.

    This is not to say that Silverlight and Flash couldn’t simply win at the task of creating web-based applications, causing a split to happen between documents and applications. It sure would be cool to find a better approach though. The old XML dream of mixed-namespace documents was one approach, where I could have HTML with SVG, MathML, etc. mixed in; why not a XUL-like language mixed in too? But the XML dream seems to have been left on the side of the road.

  • @Brad: Interesting point about the intersection of documents and applications.

    Regarding the XUL-like language: it seems to me that we actually have that of a sort today with Dojo’s parser, which gives you an extension to HTML that brings in rich behavior in your existing document structure. Not quite the same mechanism as XUL, but similar effect in the end.

    I’ve done more work on the server-side than on the client-side. In my recent PyCon talk, I focused on how things have been shifting so that the client-side has more power and the server side is more of a data storage API. In the kind of world, I don’t think the document + application mix makes a whole lot of sense. The server side has big bunches of structured data in SQL databases and it serves those up to the clients in some form for presentation. That presentation is also going to be structured in form, which makes systems that help structure “applications” better.

    But, we’re also entering an age now where we have more loosely structured data stores, such as CouchDB, Persevere, SimpleDB and even the just opened up BigTable in Google’s App Engine. There may indeed be some cool aspects that can be built by being a bit less-rigid in our structures and document/application hybrids will benefit here.

    Personally, I don’t think a “document orientation” is necessary to be considered “open”, but it is an interesting point and may prove to be important for future applications… in an open market, the users will ultimately decide that.

  • Good post, and I completely agree with you on the problem with the flashplayer (the platform for flex apps) not being open.

    Actually, I wrote a piece a bit like this, about flash still being closed source and proprietary technology, because I wanted to warn those, who became blinded by the openness of flex.

    What bugs me the most is, that Adobe is pushing the “we are so open” message so hard, while it really isn’t true. I mean, flex is great, I use it myself, and it is open, … right until it hits the flash boundary, where it closes down hard.

    I think flex (and Silverlight too) has its place in todays web, but mostly, if not only, as complete, rich web applications, where the web is “only” used as a kind of deployment platform and the (flash)player is the operating system of ones application.

    Where I am using flex today, is with a complete application, without html, only flex, to a well defined user group, requiring login to access. Nothing to index by search engines or anything like it. “Just” a rich ui technology, to provide something near what a real desktop application can, but with dead-easy deployment for us.

  • Pingback: Re: The Fight » Blog Archive » Let’s Get Crackin’!()

  • JOKe

    About Flex .. check this : http://doloresjoya.com/flex/animation/cloudscape/bin-release/Cloudscape.html
    right click on the flex app .. view source… :)

  • This post has some good points in it. However, I feel the need to clear up one misperception regarding Silverlight.

    @Vance Dubberly

    You wrote:
    “The problem with Flash and Silverlight is that I can’t see the source. I can’t parse it for content, I can’t have a semantic web.”

    I frequently hear this common complaint about Flash/Flex being assumed about Silverlight. That is not true for Silverlight.
    You can absolutely do a “view source”. All of the content contained in Silverlight’s XAML (mark up) files is text based and indexable by the major search engines. That is the default with any Silverlight application.

    In Silverlight 1.0, all code is written in JavaScript which can read the same as any existing AJAX code today.

    Disclaimer: I am a Microsoft employee.

  • Pingback: The Open Web: Now Sexier and Smaller | James Ward - RIA Cowboy()

  • I had heard a rumor that something might be changing there, and it looks like that rumor was true.

    The Gnash folks are already aware of this news as well: http://lists.gnu.org/archive/html/gnash/2008-05/msg00000.html

    This is a good move toward openness from Adobe. If you read that note on the Gnash list, Dâniel Fraga says that “a non-negligible portion of the Flash Player code is already open
    source”, which is something interesting that I wasn’t aware of.

    One other thing i should mention, because it came up in threads elsewhere but not on this site: current versions of Flex offer a “View Source” option that the app developer can choose to turn on or not.

    With this licensing change, it looks to me like Flash+Flex fit Brad’s original “Open Web” definition, which explicitly stated that it wasn’t tied to the current technology stack. I will be curious to see a response here: http://www.fightfortheopenweb.com/

  • Jay

    I don’t see the need for an ‘open’ web. Many people spend long hours developing their web pages/sites and it is unreasonable to expect them to give away the results of their work. I see the open web as meaning ‘end user content’ is available, but the mechanism used to deliver that end result need not be visible to everybody.

  • Pingback: SitePoint Blogs » Just What Is the Open Web?()

  • Pingback: Flash Tutorials | Flash and Silverlight Articles | Lemlinh.com()