ContentEarlier this week I posted a short piece about end user licensing questions in Silverlight. I discussed potential incompatibilities in the Beta 2 licensing terms with respect to open source software development. For most people this is a niche concern, a curiosity, but not something they would normally be thinking about. Besides, one expects that these problems will get fixed in the final Silverlight EULA. So why raise the question at all?
The short answer is that the technology behind Silverlight, and most certainly the company creating it, has the potential of changing how the web itself works.
If you’re a web developer then you’ve felt the acute pain involved in writing applications inside the browser. Even armed with the most state-of-the-art toolkits, such as jQuery, Dojo, etc., you’re still limited to the available runtime of HTML, CSS, and JS, and worse, the absolute morass of cross-browser incompatibilities and restricted access to native client-side capabilities. I remain in awe of what people have accomplished in this environment, but I’m sad that this is all we’ve been able to accomplish so far.
The web revs slowly. Very, very slowly. In 10 years we’ve seen virtually no meaningful advances in the the ubiquitous web client; just a painful slog forward as web developers learn to eek out just a little more functionality in a constrained environment. Progress is slow because revving the ubiquitous client requires the coordination of multiple parties, not all of whom have shown consistent interest in working together to move the web forward.
More recently we’ve seen some earnest attempts at breaking that cycle. Rather than wait for the entire web to catch up, projects like Gears seek to rev the client from the inside out. It may take several years for standards like HTML5 to be widely deployed, but if developers can gain a toehold inside the client and start forcing the issue immediately then we’ll quickly see what works and what doesn’t, and be that much more informed about what to standardize and adopt as part of the long-term web platform.
But there’s another approach, an approach best exemplified today by the Flash runtime, whereby one doesn’t seek to improve the web from the inside, but rather replace it entirely. Sure, technologies like Flash take advantage of the web via http-based delivery mechanisms and in that they run inside the browser, and yes, they can use network connections like anything else, but these alternate runtimes fundamentally divorce themselves from the web ecosystem, and in doing so gain a significant advantage, but at a cost.
In spite of circumventing the web — no, because they circumvent the web — these new runtimes have the potential of offering a far better developer experience, and hence, a far better user experience, then the least-common-denominator of the standard widely-deployed ubiquitous browser runtimes of today.
Which leads us to Silverlight: Silverlight is positioned to take the fork-and-forget approach to the web pioneered by Flash and bring to it an unprecedented wealth of technology and corporate might. With a better underlying runtime and VM, better tool support, far superior multi-language capabilities, and more marketing muscle, Silverlight has all the potential to make rapid and noticeable inroads over the next several months, cleaving a large section clean out of the web.
And the scary thing? That this isn’t entirely a bad idea. The browser itself is anemic, the dependency on a single language is a handicap, the security models simultaneously constricting and flawed, the development environments underpowered, and frankly, the whole ecosystem is deserving of a major disruption. We’ve lived too long thinking that what we have today is good enough.
Granted, these technologies won’t be perfect at first. On the contrary, they might be slow, cumbersome to deploy, buggy, and feature deprived. But right now that doesn’t matter. The strategy is all about getting a wedge in place, a bit of leverage that can be used to further pry open a vector for escaping the existing ecosystem. And over time, as the technology improves and adoption grows, so will the size of that tear in the fabric of the web.
But fighting the web is like holding back the ocean; it will route around you or it will wear you down, but will never go away, and it will never tire or give up. Yet in spite of the futility of fighting the web, Silverlight is being positioned in opposition to the web, not in support of it.
Why in opposition to the web? This stems from the principle that the web is axiomatically defined as an open system, where the underlying technologies are resistant to the centralization of control, where the protocols and formats are extensible and malleable, and where the power to effect change is shared and distributed. The DNA of the web is one of ceding control, and of learning to work with, rather than against, the collective wisdom and power a larger community.
Whereas a development monoculture, a centralization of control, and a tight grasp on the ability to change and adapt, all stand against these basic ideals, and give rise to the forces that, given enough time, will erode and eat away at any temporary advantage gained.
A violation of these principles does not necessarily make for a bad technology, but it does make it something other than the web. The winners here will be those that harness the power of the open web, not those who align themselves against it. Fragmentation wastes time and energy and offers little in return other than short term distractions, whereas as a collaboration offers the potential for long term solutions.
The collective forces on the web are not going to sit idly by and let the Internet operating system be fragmented and dominated like we saw in generations past. Difficult lessons were learned, and there is an inherent will about the web that resists all such attempts with striking efficacy. Success is unlikely when everyone is aligned against you.
But the call to action here is not to go and try to fight the disruptive technology. On the contrary, the ideas are sound and the improvements are very much needed. No, the call is to discover ways in which these ideas can become a part of the web, rather than working to tear it apart.
I do not want to see ambitious attempts like these fail. Just the opposite — I want to see them succeed. But success on the web requires a different kind of DNA, the type of DNA that is difficult to adopt when one’s attention is focused on fighting the web itself.
August 8th, 2008 at 2:46 pm
[...] Eventually an embedded distributed OS (codename TBD iOS thanks to DeWitt’s post) [...]
August 8th, 2008 at 4:48 pm
I’ve heard “replace the HTML page” for about ten years now, but “complement the HTML page” has always seemed the more apt description.
(And a pertinent reminder that The Net enfolds The Web: “A key concept of the Internet is that it was not designed for just one application, but as a general infrastructure on which new applications could be conceived, as illustrated later by the emergence of the World Wide Web.” http://www.isoc.org/internet/history/brief.shtml#Initial_Concepts )
jd/adobe
August 9th, 2008 at 10:57 pm
[...] is one of a few great quotes from DeWitt Clinton’s post On Fighting the Web itself. DeWitt is a colleague at Google, one that I have shared offices with, and great conversations. He [...]
August 10th, 2008 at 12:04 am
[...] can read the rest of this blog post by going to the original source, here [...]
August 10th, 2008 at 1:42 am
I thought for a long time about working with tools like silverlight, but generally I distrust any package that gives it all to me in an instant. Furthermore I don´t want to rely one companies tool – what if they decide to drop it or replace it with something else I am then forced to adopt also?
Much of what silverlight and the like offer me can be done with other smaller tools also, in which I can trust much more because I can dig through them. Local storage etc. its all out there.
Yes the web moves very slow. But I like it like this. It gives me the chance to get to the bottom of things instead of being forced to adopt technologies in a hurry just because everybody else does it also.
August 10th, 2008 at 2:55 am
Best piece I’ve read in ages, thanks.
August 10th, 2008 at 4:40 am
Cool Stuff man… Really interesting….
August 10th, 2008 at 5:50 am
[...] is one of a few great quotes from DeWitt Clinton’s post On Fighting the Web itself. DeWitt is a colleague at Google, one that I have shared offices with, and great conversations. He [...]
August 10th, 2008 at 6:49 am
So, we should support silvershit while they fuck us up sabotaging canvas and svg?
Demand canvas in IE8 first!
The open web will prevail!
August 10th, 2008 at 7:13 am
“Complement the Web” still means “fork away from the Web.”
August 10th, 2008 at 11:45 am
[...] can read the rest of this blog post by going to the original source, here [...]
August 10th, 2008 at 1:02 pm
What an interesting and fantastically written article. Thank you.
August 10th, 2008 at 3:43 pm
What is also extremely key is that while these technologies evolve, you use Ajax to bind them together. Leveraging two plugins at once gives you better reach and naturally leads to building a more abstract, more portable API that will be easy to adapt to future standards. An example would be the many Ajax-based vector drawing systems that use SVG or Canvas with VML as a fallback for IE.
However, it’s too bad that people continue to talk about the morass of cross-browser inconsistencies as though that’s really a requirement of working with Ajax. It’s not. There are systems that have solved this via a consistent, high-level, object oriented API where you never deal directly with the DOM. SmartClient is one of them.
August 10th, 2008 at 4:01 pm
I quiet agree with the tenor of Mr. Clinton’s argument. Adobe’s AIR RIA (Rich Internet Application) IDE and Flash are proprietary software that are Abode’s attempt to become the standard for critical web technologies and, thereby, monopolize the web and reap vast streams of revenue. I suspect that Microsoft’s Silverlight RIA IDE is exactly the same type of attempt to monopolize the RIA IDE for the Web. The community of the Web should resist these attempts to monopolize and control the Web.
Is Google’s Gears the answer? I don’t think so. The license for Gears provides, inter alia: “You acknowledge and agree that Google (or Google’s licensors) own all legal right, title and interest in and to the Services [i.e., inter alia, Gears], including any intellectual property rights which subsist in the Services (whether those rights happen to be registered or not, and wherever in the world those rights may exist).” Thus, Google retains all of its rights in Gears, which is its RIA IDE, and in its entire GWT, the license for which uses the same language. Thus, Eric Schmidt could at any instant decide that Google will charge a license for Gears or otherwise restrict its use. In the sense of retaining full rights in its RIA IDE, Google’s Gears is no different that Silverlight, AIR, and Flash. Retention of all rights in one’s RIA IDE so that I can alter those rights as one please ain’t open source.
However, there is at least one open-source RIA IDE, SproutCore, that the Web community can turn to to develop web applications on a true open-soure RIA IDE. SproutCore is licensed under the MIT open-source license, which provides:
“Copyright (c)
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.” This is a true open-source license. Its only downside is that it does not provide any warranties, but it does provide developers, who use any RIA IDE licensed under it, non-exclusive, perpetual, free, and unrestricted use of that RIA IDE.
SproutCore is rich RIA IDE that allows the development of powerful web applications that function fully offline as well as online. SproutCore is what Apple uses for its MobileMe applications, which, notwithstanding Apple’s troubled launch of MobileMe, give some idea of what SproutCore is capable of. If the Web community is seeking an open-source RIA IDE that will provide a powerful set of tools, allow it to fight against attempts at proprietary control, protect developers from license fees, and ensure the freedom of the Web, I strongly urge the Web community to consider SproutCore.
August 10th, 2008 at 4:09 pm
Hey Orlando,
Quick clarification. You wrote:
The binary distribution of Google Gears is indeed covered by a Terms of Service agreement. This is standard stuff — in fact Google needs to do that in order to distribute software.
But the source code for Gears is entirely open source under the BSD license, and no one, not Google, not Eric, can take that back.
You or anyone else can always continue to use and build Google Gears under the terms of the (irrevocable) BSD license.
Hope that helps clear up your confusion.
Cheers,
-DeWitt
August 10th, 2008 at 4:15 pm
Oh yes, I forgot to mention that SproutCore is not a plug-in. It uses Java Script, and, in so doing, uses capabilities that are built into every modern web browser or, at least into Firefox and Safari, so developers aren’t locked into relying on any plug-in, and neither Google, Microsoft, or Adobe can interfere with or hinder SproutCore’s functionality by either controlling a proprietary plug-in or by controlling the browser.
August 10th, 2008 at 4:21 pm
Dear Mr. Clinton: But aren’t the binaries what the developers use? Is opening the source code, but restricting the binaries, useful to anyone that wants to use either Gears or the GWT as open-source to develop web applications? Unless, the answer to the first question is no, and the answer to the second question is yes, my argument stands undiminished.
August 10th, 2008 at 4:31 pm
Hi Orlando,
I have to admit I don’t quite follow the argument you are making. Is your concern that Google has reserved the right to discontinue releasing Gears binaries in Section 4.3? If so, that’s a perfectly normal clause for binary distributions — in fact, I’m not sure how it could be any other way.
But the nice thing about Gears is that, because the source code is perpetually and irrevocably available under the BSD license, other people can always build their own version of Gears whenever they’d like, even if Google discontinues to release binaries. This is significantly superior to most comparable client-side tools.
If you can better articulate your specific concern I’d be happy to look into it for you.
Cheers,
-DeWitt
August 10th, 2008 at 4:52 pm
Dear Mr. Clinton: My problem is that unlike the MIT Open-Source license or the GPL, Google retains every right in its binaries, and that is a tremendously power set of rights that the GPL and the MIT license transfers to the developers. Giving developers the sour codes and saying go to it is as my brethren would say a right without a remedy, because most developers haven’t the resources to develop and maintain their own RIA IDE under an open-source license. So giving open-source rights to source code isn’t that useful, because source code doesn’t run anything, nor does not provide a developer with something that he/it can afford to maintain.
Apple, by adopting SproutCore under the MIT Open-Source License, Sproutfit, and the other developers of SproutCore give developers the right to use the binaries, which you download now under the MIT license, and provide a community of developer, one of which, Apple, is a very wealthy and powerful corporation, that can support, maintain, and enhance SproutCore.
Licensing the source code for Gears and GWT, as Google has done, is probably better than either Silverlight or AIR, but it is nowhere near what SproutCore provides by licensing SproutCore, source code and binaries, under the open-source MIT license, and is inadequate to ensure the freedom and openness of the Web.
August 10th, 2008 at 6:09 pm
Not to belabor the point, but you are likely mistaken in your understanding of the rights granted by the MIT license versus the New BSD License. The two licenses are generally considered equivalent. (Aside from the no-endorsement clause, which doesn’t seem to be your concern here.) Compare the two licenses for yourself.
But either way you’ve completely lost me.
August 10th, 2008 at 9:39 pm
Dear Mr. Clinton: I am not disputing whether the MIT Open-Source License (MIT License), which I quote, supra, is equivalent in its legal effect to the BSD License. My complaint is that Google licenses only the source code, which, as explained in my post, supra, isn’t that useful to developers, while Sproutfit licenses all of SproutCore, both source code and binaries. SproutCore is also supported by a diverse community, which includes at least one major player, Apple, while Gear, GWT, Silverlight, and AIR, because of their proprietary licenses, all depend on their respective companies for support, maintenance, and enhancement and can’t legally be modified, at least in their binaries, except by their respective companies.
So, even if I grant, arguendo, that the BSD and MIT licenses are legally equivalent, that point is irrelevant, because what matters is what Google has chosen to place under the BSD license, which is only the source code for Gears and GWT, while it has placed the binaries those items of software under its Terms of Service, which is no less proprietary than the license for AIR or Silverlight, thought Google may be exercising its discretion to presently offer the binaries for Gears and GWT for free. And as explained in my post, supra, it is the binaries that matter most for developers, because developers use the binaries, not the source code, and the source code wouldn’t be useful to the vast majority of developers because they wouldn’t have the resources to support, maintain and enhances it. And the other developers with sufficient resources to maintain and enhance Gears and/or the GWT, such as Apple, would be fools to build their strategic software on the proprietary RIA IDE of another company, which is why, I think, Apple uses SproutCore and not Gears, Silverlight, or AIR for its MobilMe applications.
Thus, I don’t take issue with the BSD license. I am sure that it, even more than a decade ago, was and is a good open-source license. If it wasn’t, Apple would never have used BSD Unix to build OS X. I take issue with Google not placing the binaries, as well as the source code, for Gears and GWT under the BSD license or some other open-source license, such as the GPL or MIT license, and claiming that Gears and GWT are truly, fully, and usefully open source software.
August 10th, 2008 at 9:44 pm
Ahh, okay. I think I understand the point you are making a little better now.
Why don’t you email me at dewitt at google.com and we can talk specifically about how you’d like to see the binaries licensed and what rights should be attached. Perhaps there is something that can be done here.
Thanks, Orlando. Cheers,
-DeWitt
August 10th, 2008 at 9:54 pm
I misspoke on one point in my posts. Because SproutCore uses only Java Script and other resources that already exists in modern browsers, it does not have binaries. It is simply a development framework and a set of tools. For a more complete and competent description of SproutCore go to: http://www.sproutcore.com/.
I also take to this occasion to state that I have no relationship to or interest in Sproutfit, SproutCore, and/or any enterprise or endeavor that uses, develops, maintains, or in anyway benefits from SproutCore, nor do I have any prospect of benefiting from SproutCore, except as a user of the Web and web applications.
August 11th, 2008 at 2:49 am
You assert this without giving any reason for it, which irked me, so I thought about it a little. Why is the web so inherently ocean-like that it is impossible to overcome with a closed platform? Is it really? I am now mostly but not entirely sure of that (which makes the question you are discussing all the more acute).
What I think is that the web probably really is as close to a force of nature as that – at least at this point (though not necessarily when it was young) – because of network effects. The open web provides far more opportunities for serendipity (in the Roy Fielding sense of the term) than closed platforms generally do. You can get a sense of this by reading Leonard Richardson\u2019s essay on The System of the World Wide Web (and How the Web Won): the URI allowed the web to embrace-then-asphyxiate the previously widespread protocols. Any new technology that tries to supersede the web will have to be equally capable of embracing and incorporating the existing web stack and other protocols, or else it will eventually find itself embraced and absorbed by the web instead of vice versa.
By definition, a closed platform cannot.
August 11th, 2008 at 5:31 pm
[...] DeWitt Clinton » Blog Archive » On Fighting the Web Itself brilliant post. i'd argue with bits – the assertion that richer environments = better UIs, for example – but the general point is well made and well taken. i'll need to comment on this. (tags: dewittclinton webdev web standards software silverlight programming opensource fork fight google adobe microsoft) [...]
August 11th, 2008 at 5:54 pm
“The DNA of the web is one of ceding control, and of learning to work with, rather than against, the collective wisdom and power a larger community.”
It’s been 12 or 13 years since the Javascript came to existence yet it still doesn’t have built-in multithread support, among many other staggering inadequacies. If that’s what “collective wisdom” has produced, I think we can do without it, can we? This whole HTML stuff was designed as document tags instead of an app framework. Again, no major improvement for even longer than Javascript. Now we are moving toward the SAAS era, why would I want to build rich online apps in a technically stagnant HTML/Javascript combo? The “open” platform didn’t do anything, for more than a decade, until Adobe and MS light up a fire underneath, so I’m not sure it all the sudden will be able to deliver in future. The question is therefore: Is it really Adobe/MS fighting “open” web, or developers stuck with old & inadequate web techniques (HTML/Javascript) fighting (or, frankly, FUDing) RIA innovation introduced by Adobe/MS? Before you realize it, Sun is coming up with JavaFX soon, which will bring the vast existing number of Java developers into the play. Anyone still wants to fight this RIA innovation?
Being open is fine, just make sure not to stand in the way of innovation, especially when end users prefer such innovation.
August 15th, 2008 at 8:30 am
[...] answer, in this case, comes to you via DeWitt Clinton’s excellent piece “On Fighting the Web Itself“: The short answer is that the technology behind Silverlight, and most certainly the company [...]
August 29th, 2008 at 1:38 am
If Silverlight causes some panic in the ‘open web’ this may actually be a good thing – in fact you hit the nail on the head when you criticise – “a development monoculture, a centralization of control, and a tight grasp on the ability to change and adapt, all stand against these basic ideals”.
This is essentially what the W3C standardisation process, and the Java JCP, have become. That is why organisations like WHATWG had to route HTML5 around the W3C, or the huge number of alternatives to the approved ‘standard’ Java web stack.
Of course the dominance and need to appease Microsoft has been a major factor in slowing down the W3C, but not the only one – specs have also held back on the other side (recall the debate over Ogg/Theora support and the video tag), the crying over spilt milk with the canvas tag (‘but Apple should just have used SVG’).
Another huge difference from 10 years ago is that pushing out browser / plugin updates is now pretty trivial (well, so long as they don’t induce a reboot) – we should really be looking at cycles closer to the Flash player.
As for JavaFX and the threat of bringing Java developers into play in the RIA area, dare I make the snide comment that Java developers have not exactly been noted for the richness of UI design, on the desktop or mobile phone space.
August 29th, 2008 at 1:29 pm
JulesLt: Actually the Ogg Theora issue, while it did result in a lot of e-mail, had no notable effect on the development of HTML5, because basically none of the e-mails sent said anything substantially new. We’re still waiting for a suitable codec, but the spec continue to evolve unabated in the meantime.