The View Source option was, however, perfectly consistent with the culture of the Web as a whole. Certainly, as I've said above, this was consistent with Tim Berners-Lee's vision of the information Web in which all could participate, and in the choice of HTML as an immensely simplified version of SGML. One could argue that the View Source option simply reinforced the already "open" nature of the Web as a phenomenon, which was firmly in place before the first browser was ever made widely available.

Regardless of whether the View Source option set the tone for the culture or merely reflected it, it is fair to characterize the culture of Web development that came into being as a View Source culture. In the early years of the Web, people learned HTML by example. When you saw a site that was doing something interesting, you would view the source of that site, and (often quite directly) copy their code into your own pages and edit from there. It became quite customary for such "imitation" (which was in some cases arguably copyright infringement by modern definitions) to occur even without the polite inquiry that originally preceded it. At first people asked, "Can I borrow your Web page template? I love what you've done with tables," but over time it became so customary people didn't even ask. People did continue to ask for access to server-side features, like Perl scripts for the common gateway interface, but perhaps due to Perl's heritage (version 3.0, in 1989 had been under GPL, even before Linux's public release), such scripts were commonly shared as well.

As the Web bubble grew, people started to offer well-designed HTML/CSS templates; useful JavaScript snippets; cascading drop-down, slide-out menu frameworks; scrolling marquees; and the like. Some of these libraries and templates were offered as freeware or shareware; some were sold as commercial software. Of course, developers couldn't easily prevent end users with the necessary JavaScript, CSS, and HTML in their browser cache from "borrowing" their scripts - it was very common for such developers to find unlicensed versions of their code on Web pages from around the globe - but people had begun to realize that there was some value in the effort involved in making a useful function work as a cross-browser. In fact, one of the purported advantages of Java applets and Flash movies, when they first arrived, was the fact that they closed this loophole and were emphatically not View Source enabled.

Early efforts, however, to leverage JavaScript and CSS to provide a more compelling browser experience - what we then called DHTML - were hampered by the complexity of developing for multiple browsers, each of which had their own interpretation of the Document Object Model and implementation of Cascading Style Sheets. Two major events provided a way out of this complexity: the recognition of a community of practices now referred to as AJAX (itself enabled by the release of compelling competitors to Microsoft's Internet Explorer) and the appearance of a number of open source frameworks for developing AJAX applications.

AJAX
In what is now a seminal article, Jesse James Garrett noted, in February of 2005, a growing phenomenon of using standards-based presentation (XHTML and CSS), the Document Object Model (DOM), the XMLHttpRequest, and JavaScript to generate rich interface Web-based applications. He called this approach AJAX, and issued a call to designers and developers "to forget what we think we know about the limitations of the Web, and begin to imagine a wider, richer range of possibilities" ("AJAX: A New Approach to Web Applications" by Jesse James Garrett).

While many of the raw materials of the AJAX approach had been available for many years - Microsoft first introduced the XMLHttpRequest object in Internet Explorer 5, and it was leveraged in production by Outlook Web Access - it only took off when the approach was validated by inclusion in the Mozilla framework (and thus Firefox) and Apple's Safari browser (itself based on KHTML, the framework used for Konqueror in the K Desktop Environment for Linux). So long as what Microsoft called "remote scripting" was only available in a single browser (Internet Explorer), many developers felt it was unusable in any public application. (It might be acceptable, for some, to dictate browser usage on a corporate intranet, but most were unwilling to try to do so on the public Internet.)

As the user base of the old Netscape 4.x applications waned, and the availability of new platforms rose, developers were emboldened by the relative ease of developing cross-browser standard applications with rich interaction in JavaScript and CSS, and more and more developers started to create AJAX applications. Garrett's essay crystallized this movement and gave it a name. The AJAX meme spread like wildfire, and the essay became so influential, exactly because so much work of this kind was already being done.

Open Source Frameworks
In addition to the AJAX phenomenon, the other major change that supported the new explosion of activity around Web development was the emergence of open source frameworks for AJAX-style development. While the diminishing use of Netscape 4.x (specifically, the acceptance among developers and their clients of the decision to not include complete functionality in Netscape 4.x as a primary requirement) and the relative stability of standards for HTML, CSS, and JavaScript all combined to make developing cross-browser Web applications considerably easier, writing such applications from scratch still required too much repetitive effort. Though the Mozilla-based platforms had adopted an approach similar to Microsoft's remote scripting, there were enough differences to create a barrier to cost-effective and reproducible development.

The frameworks that evolved abstracted away the messy details (the difference between Internet Explorer's ActiveX-based XMLHttpRequest object and Mozilla's true JavaScript version, for example) and enabled developers to add snazzy AJAX functionality to their Web applications simply by leveraging APIs provided by the framework. (see Table 1)

Open Source Culture
In addition to ease of use, broad adoption of these frameworks has brought along with it an open source culture, characterized by an emphasis on community, de jure licensing, and more sophisticated planning and architecture for the presentation-tier of Web applications. (While the definition of open source typically focuses specifically on what licenses qualify, these licenses carry with them a set of cultural impacts, just as the View Source command brought with it a set of cultural impacts.)

First, and most obviously, an open source culture is characterized by explicit license rather than borderline theft or gift of use. While the View Source culture sometimes included explicit permission ("Can I copy what you've done here?"), it more often relied on a kind of borrowing that ranged from imitation to outright copyright infringement or theft. An open source culture relies not only on a kind of de facto or assumption-based sharing of information, but a formally stated, de jure grant of specific rights to all users. This explicit license also facilitates innovation, as improvements made by users of the code can be contributed back into the community and the benefits of those innovations shared with other users directly.

Additionally, an open source culture is characterized by communities that develop around the frameworks. These communities have differing levels of formality, professionalism, and "helpfulness," but all represent a great leap forward compared to the random deciphering of other people's code, which characterized the View Source culture. To revisit Tim O'Reilly's metaphor about "View Source," in an open source culture, a would-be developer cannot only look over the shoulder of other developers, but he or she can join them in a conference room and discuss the code directly. Open source culture also helps to ensure repeatability and maintenance of the leveraged code base because when newer versions or patches are released, there is a well-organized mechanism for announcing and providing access to the code, something that the View Source culture generally lacked.

Finally, an open source culture is characterized by a greater degree of attention to standards and interoperability. Because open source projects gain their strength from the breadth of their use and the size of their community, they tend to focus much more clearly on methods of sharing. Even in cases where an individual's needs are contrary to the direction of the overall project, open source licensing allows for and encourages the development of extensions and alternate versions to meet specific problem sets.

Community and Professionalism
In some ways, one could point out the essential difference between the Web development culture, which relies heavily on open source frameworks and libraries, and the first generation of Web development, which relied on View Source and imitation, in the same way that free / open source software advocates have long distinguished between them: by drawing the "free as in beer" versus "free as in speech" (or "free as in freedom") comparison.

Viewing the source of a Web page developed by someone else, including digging into the CSS and JavaScript that accompanies the HTML, has always been free, as in beer. If you have access to a Web browser and can display the page, you can get to the source. Open source frameworks like Prototype.js, Dojo, DWR, the YUI library, and the Zimbra toolkit, however, are free as in speech. Not only can you access the source code without cost, you are encouraged and explicitly granted the right to use, modify, and redistribute your modifications to others.

The early days of the World Wide Web were characterized by open experimentation and the de facto sharing of source, whereas the trend today is toward maturity, professionalism, and the de jure sharing of open source frameworks. This evolution is a sign of the growing professionalism of the Web development community.

While the current AJAX-style development community faces many ongoing challenges - working out JavaScript namespace issues, encouraging better adherence to security best practices, and dealing with accessibility issues are at the top of a substantial list - the broad, active, and transparent communities behind open source AJAX frameworks bode well for the possibilities of solving such challenges and continuing the evolution of Web development.