Year: 2007

The third aspect of Web 2.0, which is often under-appre­ci­ated, is the pro­cess aspect. This has changed people’s expect­a­tions of what soft­ware can do, and how it should be delivered. This cat­egory includes open source, con­tinu­al beta and quick release cycles, and some new busi­ness models.

Pro­cess Cloud

Not all of the things that are import­ant in Web 2.0 are new, of course. Open Source soft­ware has been around for a long time, but I would argue that it has nev­er been as pop­u­lar as now, where more people have the abil­ity to con­trib­ute their time and tal­ent to pro­jects for which they’re not dir­ectly paid (unless they’re lucky enough to work for a com­pany that sup­ports such projects). 

The con­cepts of con­tinu­al beta and quick release cycles are new though. It was­n’t that long ago that you could only buy con­sumer-level soft­ware in boxes with pretty pic­tures and prin­ted manu­als, either in stores or by call­ing com­pan­ies. For expens­ive soft­ware that needed con­sult­ing ser­vices to install and con­fig­ure sales reps would vis­it if you worked for a large enough com­pany. To take part in a beta pro­gram you needed to know someone who worked in the com­pany and sign an NDA, and it was a small, tightly-con­trolled circle.

These days the Web 2.0 browser-based applic­a­tions don’t need hand-hold­ing to install and con­fig­ure, so the serv­er load is the big con­straint on how many people can take part at once. There are sev­er­al fla­vours of beta pro­grams: invite some “thought lead­ers” and ask them to invite their friends in the hope they’ll blog a lot about it (Gmail did this, you got 6 invites, then 50, then you could invite 250 of your closest friends to take part, most of whom already had gmail accounts); unlim­ited invites start­ing with a small circle; sign up on a wait­ing list; allow in any­one from cer­tain com­pan­ies (dopplr does this, with the twist that the mem­bers can then invite any­one they like).

The “con­tinu­al beta” bit comes from the fact that these applic­a­tions are updated quickly; these updates are often tried out on some of the users before being rolled out to all. Flickr appar­ently had hun­dreds of incre­ment­al releases in 18 months from Feb­ru­ary 2004 to Octo­ber 2005 (stated in O’Reilly’s Web 2.0 Prin­ciples and Best Prac­tices; I could­n’t find an online ref­er­ence oth­er than that report). The line between a beta and a non-beta applic­a­tion seems to be a fine one; the only dis­tinc­tion in many cases that the user can see is the word “beta” on the web site. Con­tinu­al releases give users a reas­on to come back often, new fea­tures can be tested and fixed quickly. Of course, this sort of sys­tem does­n’t really work for fun­da­ment­al soft­ware such as oper­at­ing sys­tems, data­bases, browsers, iden­tity pro­viders, and dir­ect­ory ser­vices, where you want full-on secur­ity and regres­sion test­ing, but it does work for the Web 2.0 applic­a­tions that run on those bits of fun­da­ment­al software.

And in keep­ing with the user-cre­ated ten­ets of Web 2.0, plat­forms such as Face­book that enable third-party developers to write applic­a­tions to run on that plat­form also ful­fill the func­tion of con­tinu­ally adding fea­tures to the applic­a­tion without the own­ers need­ing to code any­thing, or pay people to add fea­tures. The users do it all for them — use the plat­form, add fea­tures to the plat­form, mar­ket their added fea­tures. The own­ers sup­ply the hard­ware and the basic infra­struc­ture (which needs to be stable and reli­able) and the users do the rest. At least, that’s the the­ory and the hope.

Which brings us to the busi­ness mod­els. How do people pay for the hard­ware, soft­ware, pro­gram­mers, mar­ket­ing? There are a num­ber of ways in which Web 2.0 com­pan­ies try to cov­er the bills for long enough to sur­vive until they can be acquired by some big­ger com­pany. One is advert­ising. Google and its com­pet­it­ors have made it easy for even small web sites, such as blog­gers in the long tail, to make some money from ads. It’s more than enough to pay the bills for some sites, since it’s now cheap or free to build and launch a site. Some sites are free when you watch the ads, but you can pay for an ad-free ver­sion. Or free for private use, but cost some­thing for com­mer­cial use. And then there’s the vari­ant where a basic account is free, but you have to pay if you want more fea­tures, such as upload­ing files, or upload­ing more than a cer­tain num­ber of pho­tos. A vari­ant for open source soft­ware is that the soft­ware is free, but you need to pay for sup­port or real help in con­fig­ur­ing it, or to get new releases more quickly.

One of a series on Web 2.0, taken from my talk at the CSW Sum­mer School in July 2007. Here’s the series intro­duc­tion. Com­ing up next: some issues with Web 2.0

The tech­nic­al com­pon­ent of Web 2.0 includes XML, Ajax, APP, vari­ous pro­gram­ming lan­guages, plug-ins and wid­gets, and the REST archi­tec­ture. All of these have a role to play in sup­port­ing the web sites that incor­por­ate Web 2.0 fea­tures, while many pred­ate the Web 2.0 phe­nomen­on. There are far too many inter­est­ing tech­nic­al fea­tures for me to talk about all of them in one post, of course, but this post should at least intro­duce you to some of the more inter­est­ing acronyms.

Oblig­at­ory tag cloud: this one con­tains some tech­nic­al terms

Devel­op­ing Web 2.0 applic­a­tions is easi­er than devel­op­ing large enter­prise-style applic­a­tions. The developer toolkits are a lot easi­er to use, and it’s much faster to cre­ate some­thing. 37 sig­nals, who make Base­camp, amongst oth­er tools, say they put it up in four months with 2.5 developers using Rails, a devel­op­ment frame­work. For developers there’s now a range of lan­guage options, from PHP to C++ or JavaEE, with new­er plat­forms and lan­guages like Ruby and Rails grabbing mind­share as well. People can pro­gram in the sys­tem they’re com­fort­able with, and although there’s a cer­tain amount of snooty dis­par­age­ment of each lan­guage from pro­ponents of some oth­er one, what mat­ters in the end is using the right tool for the job. I’ve seen bad code writ­ten in Java and good code in PHP, and a sys­tem that does less but does it well is prefer­able to my mind to one that does a lot really badly.

Ajax (Wiki­pe­dia link) is anoth­er import­ant Web 2.0 tech­no­logy. It’s really a short­hand to describe a bunch of tech­no­lo­gies (HTML, CSS, DOM, JavaS­cript) that are tied togeth­er, using the browser to cre­ate a rich­er envir­on­ment by tying in script­ing and a way to request inform­a­tion from the serv­er without for­cing the entire page to be reloaded. It’s power­ful and inter­act­ive and can be much faster than oth­er meth­ods of adding inter­activ­ity to the web pages. There are lots of books on the sub­ject, which is a reas­on­able indic­at­or of the interest in it. 

Since it com­bines a lot of dif­fer­ent applic­a­tions, debug­ging can be a prob­lem. Some basic rules that I’ve found use­ful are: first make sure your HTML/XHTML val­id­ates, then make sure your CSS val­id­ates, then use Fire­fox with the Fire­bug exten­sion to debug the rest. Once you have that work­ing, you can make the changes for oth­er browsers as appropriate. 

Poorly writ­ten Ajax does have some prob­lems, such as not being able to book­mark res­ults, or the back but­ton not going back to the right place. The big prob­lem is the non-stand­ard­ized XML­Ht­tpRe­quest object in JavaS­cript, the object that lets your page talk to the serv­er and get the right inform­a­tion. The way it works var­ies between dif­fer­ent browsers and dif­fer­ent ver­sions of the same browser (IE 6 to IE 7, for example). Although W3C is start­ing to work on stand­ard­iz­ing it, that will take some time. Anoth­er prob­lem is the “A” in Ajax — it’s asyn­chron­ous, which means that inter­net latency can be an issue.

These prob­lems can be solved — there are Ajax toolkits avail­able which hide the XML­Ht­tpRe­quest and oth­er browser incom­pat­ib­il­it­ies, some applic­a­tions have figured out the back but­ton and the book­mark­ing URL issues, the asyn­chron­ous issues can be dealt with by break­ing the applic­a­tions up into small seg­ments which take into account the fact that the oth­er end may nev­er respond. And as a res­ult of these toolkits and tech­niques, Ajax is now a major com­pon­ent of many web­sites, even those that aren’t for Web 2.0 startups.

REST is an archi­tec­tur­al frame­work that explains a lot of why the web is so suc­cess­ful. Roy Field­ing’s PhD thes­is was the first place where it was codi­fied (and he coined the term). Basic­ally the idea is that everything that you can reach on the web should be a resource with a web address (URI) that you can reach with stand­ard HTTP verbs, and that will have oth­er URIs embed­ded in it. There’s more to REST, of course, and I’m sure the pur­ists will take issue with my over-sim­pli­fied description.

REST is widely used in what I call Ajax APIs — the APIs that vari­ous applic­a­tions have that let people get access to the data. Mash-ups, where you take data from one ser­vice and com­bine it with anoth­er ser­vice, use these APIs all the time. The clas­sic example of a mash-up was to take Craigslist rent­al data and mash it with Google map­ping data onto a third web site (hous­ingmaps) without Craig­list or Google being involved to start with. There are now vast num­bers of mash-ups and lots of toolkits to help you cre­ate them. One prob­lem with mash-ups is that the people provid­ing the data may not care to have you take it (for example, if they run ads on their sites); the Web 2.0 solu­tion to that is that if you own the data, you need to add more value to it that can­’t be mashed as eas­ily. Amazon has book reviews on top of the basic book data, for example, so people use Amazon as a ref­er­ence link.

The concept of mash-ups goes fur­ther into plat­forms that sup­port plug-ins and wid­gets. One of the appeal­ing things about Face­book is the fact that applic­a­tion developers can write wid­gets to do vari­ous things (from the trivi­al to the heavy-weight) that use the inform­a­tion that Face­book provides (this has pri­vacy implic­a­tions, but more about that in a later post). In a sense, this is about sites (usu­ally com­mer­cial sites) using the social aspect of Web 2.0 (user-cre­ated con­tent) to provide more fea­tures to their users, and is tightly tied to the pro­cess implic­a­tions of Web 2.0 (more about that in the next post).

The Atom Pub­lish­ing Pro­tocol is fairly recent. Atom is the cleaned-up ver­sion of RSS and gives you a feed of inform­a­tion, tagged with metadata such as author, pub­lished date, and title. There is now also a pro­tocol to go with it, designed for edit­ing and pub­lish­ing web resources using HTTP. It can be used as a replace­ment for the vari­ous blog-based pub­lish­ing APIs, which were used to allow people to post to their blogs from dif­fer­ent edit­ors, but it’s now obvi­ous that it can be used to carry oth­er inform­a­tion as well, and not just for blogs. Since it’s a REST-based API that uses basic HTTP, it can be used for more gen­er­al cli­ent-serv­er HTTP-based com­mu­nic­a­tion. A good over­view is on the IBM developer site.

One of a series on Web 2.0, taken from my talk at the CSW Sum­mer School in July 2007. Here’s the series intro­duc­tion. Com­ing up next: pro­cess aspects of Web 2.0