One of the biggest dangers of closed software/standards is vendor lock-in. In Simon’s look at the value of open standards in government, she describes proprietary software as having a focus on integration with tightly coupled components bundled together. As I reflect on this description, Microsoft products like the Windows operating system and Office application suite come to mind. Thanks to Microsoft, I experienced the disadvantage of proprietary file formats in my own life. In middle school, I used the edition of Microsoft Works that came bundled with my new PC for word processing. Only later in high school when I began to use OpenOffice and started sifting through my archives did I realize that I couldn’t open the old works file format. While a converter to the Microsoft Word file format did exist, one could imagine a scenario where a company goes out of business and no such converter is ever created. For institutions like government which are responsible for archiving content, not being able to open old archives is unacceptable.

More recently, Microsoft Office and its family of file formats (doc, xls, and ppt) have become a de facto standard in the realm of office applications because of Office’s dominance. However, the fact that “many government agencies have already adopted or are currently adopting policies that require adherence to open standards” (Simon 299) has forced Microsoft to act in attempt to avoid losing market share. In September 2006, Microsoft published its Open Specification Promise, opening up these formats for compatibility with other applications. While Microsoft’s newest office suite, Office 2007, doesn’t natively support the OpenDocument format (an open standard implemented by OpenOffice), a Microsoft sponsored plug-in to read the format is available. Also, Microsoft has lobbied (successfully it appears) to pass Office 2007′s native file format Office Open XML as an ISO standard. As an interesting aside: Google Docs, a product looking to make inroads in the office application space, offers import and export for many formats including Microsoft’s .doc format and OpenDocument. Microsoft’s change in its stance on file formats demonstrates that proprietary standards aren’t sustainable in an era where consumers demand interoperability.

Another example of vendor lock-in is the Apple iTunes music store, specifically songs that are encoded with Apple’s FairPlay DRM protection. The DRM restrictions only permit these songs to only be played on iPods. While you can burn the songs to CD and then re-encode them on your computer to circumvent the copy protection this process is lengthy and cumbersome. While Apple has recently surpassed Walmart as the number one music retailer in the US, it is unlikely that iTunes will remain the only dominant player in the digital media market, especially with these restrictions. Already more open competition has sprung up like Amazon’s DRM-free MP3 store. Besides offering DRM free MP3s, Amazon’s service boasts the Linux client that iTunes lacks. Pressure from competitors to go DRM-free has also resulted in Apple beginning to open up and offer DRM-free music. But imagine investing hundreds of dollars in iTunes music, only to realize that when you replace your iPod with some other MP3 player you cannot play it on that device. (Although this might not be entirely true for the tech savvy consumer since iTunes DRM has been cracked, in addition to the loophole mentioned earlier, the example is illustrative nonetheless). Time and time again, we see copy protection schemes cracked, demonstrating consumers demand for interoperability.

Interoperability and open standards are also important on the web. While many online services are closed source, they offer a layer of compatibility. Google’s Gmail, for example, offers POP3 and IMAP for compatibility with other mail clients. Financial sites allow data to be downloaded into Quicken and other financial software. It is interesting to speculate on the future of sites that don’t embrace open standards. The current stance taken by the social networking site Facebook, for example, is against interoperability with other social networking sites. While Facebook has an API for application developers, its Terms of Service prohibit exporting user data. By doing so, Facebook keeps the switching cost to another social networking provider high and essentially locks in it’s users. It’s a matter of time to see how Facebook fairs with this decision. It seems unlikely that Facebook would face legal pressure in the same way that Microsoft did, however, competition in the form of open social network providers like Google’s OpenSocial have already sprung up. OpenSocial “defines a common API for social applications across multiple websites” thus making your social connections portable. If I were Facebook, I would be careful because as we’ve seen previously, closed standards are often unstable when consumers desire freedom with their information.

As noted earlier, the early days of mainframe computers saw proprietary hardware bundled with proprietary software before PC hardware evolved into a collection of commodity components. As history often repeats itself, a similar paradigm is re-emerging in the market of embedded systems. For the most part, devices like cell phones and PDAs have been bundled with closed, proprietary software. As the industry matures and consumers become frustrated with these limitations, open-source projects like the OpenMoko (open cell phone hardware) and Google’s Android (open cell phone software) are in development. While their future remains to be seen, I predict innovation and growth in these markets as consumers realize the restrictions of closed platforms.

Contrary to this paper’s thesis, Aggarwal et. al argue that proprietary standards are stable from an economic standpoint. They describe a pie representing the total market for a technology and use this metaphor in describing the motivational differences between proprietary and open standards. They characterize proprietary standards as being “concerned with pie sharing—trying to increase your share of the pie” while open standards are “concerned with pie expansion— trying to increase the size of the pie while leaving your share fixed.” The authors argue that trying to grab the biggest piece of pie, rather than cooperating and splitting a larger pie, is a dominant strategy in this classic prisoner’s dilemma situation. Pursuing the proprietary standard is dominant because “If one firm gets a reputation for pursuing the monopoly route, then the best response for other firms is to do the same.” I would argue, however, that there are external forces that affect the payoffs in this game. Whether it is government pressure, consumer demand, or high-quality open-source software, these forces drive the situations we’ve examined toward more open solutions.

If open standards are the future, then what do we make of closed source software? Should open-source always be preferred to its closed-source competitor? Not necessarily. Sutor argues that the decision between closed and open source software should be made “from practical business considerations, not political or ideological reasons”. As much as I like the idea of open-source software, I have to agree with this. In choosing the best software, consumers should choose the software that provides the best cost/benefit ratio. Interoperability, however, is a hidden factor that most people don’t consider. Sutor argues that in a perfect world closed and open-source software can coexist with open standards as the mediator. It’s a win for consumers if they can choose software that is simply the best tool for the job, rather than worry about compatibility with existing systems and interoperability with others.

References:
1. Aggarwal, Nitin and Qizhi Dai and Eric Walden. “Do Markets Prefer Open or Proprietary Standards for XML Standardization? An Event Study.” International Journal of Electronic Commerce, Vol. 11 Issue 1. October 2006.
2. Simon, K.D. “The value of open standards and open-source software in government environments.” IBM Systems Journal. 2005.
3. Sutor, B. “Open Standards vs. Open Source.” Striking the Right Chord, If You Can Find It. Available on the web: . May 27, 2006.
4. West, J. and J. Dedrick. “Proprietary vs. Open Standards in the Network Era: An Examination of the Linux Phenomenon.” In Proc. of the 34th Annual Hawaii International Conference on System Sciences. IEEE Computer Society, Washington, DC, 5011. January 2001.

In the early days of non-networked computing, distributed open source projects like Django were not possible. However, the rise of the network society, as described by Manual Castells in “Materials for an Exploratory Theory of the Network Society,” has enabled a plethora of them. Castells describes the new society as networked, global, and informational. The Django Project possesses each of these aspects.

Networked: People and Employment

In describing the networked aspect of the new society, Castells posits that a new form of economic organization, the network enterprise, is at the heart of the global economy. This term describes “a network made from either firms or segments of firms, and/or from internal segmentation of firms” (10). He notes, for example, that small and medium businesses are connected in networks, and that “these co-operations are based increasingly on sharing of information” (11). Theoretically, anyone can contribute code to Django, but in reality it is a small enthusiast group of core developers that does most of the work. Nonetheless, like Castells describes, Django enables a network of individuals to make collaborative contributions and decisions. Further, by leveraging the Django framework, small businesses and even individual freelancers can provide services that at one point in history could only be offered by larger businesses.

The oversight that the core Django developers provide is essential to the project’s well-being. Without the guidance of these dozen or so developers, the Django project would be an uncoordinated collection of programmers without a unified vision. The core developers “are the folks who have a long history of contributions, a solid track record of being helpful on the mailing lists, and a proven desire to dedicate serious time to Django.” In return, they have permissions to commit (make changes) to Django’s source code.

Since there are only a handful of core developers, their time spent reviewing tickets (bug reports and suggestions for improvements) and patches (modifications to the source code) is a scarce resource. In the Django IRC channel, for example, cramm (screen name) laments about other developers attaching incomplete patches to tickets:

I don’t know how to feel abot [sic] people attaching patches to tickets that simplify things but at the same time break them. Then a core dev comes in one of her/his rounds sees only the broken patch and we’ve lost a chance of getting the thing fixed.

As another example, the run-up to a release is not the time to make feature requests since the core developers are busy finishing tickets milestoned for the release. A participant in the django-developers mailing list tried to float a suggestion for a new feature a few weeks prior to the 1.1 release and received a rather blunt reply from core developer Malcolm Tredinnick:

Look at the major contributors to this list and the people who have the deepest understanding of the platform. Now look at the list of people doing the reviews and commits to get 1.1 out. Notice the large overlap.

The Django developers form a network in which “nodes increase their importance by absorbing more information and processing it more efficiently” (Castells 15). The core developers are the most important nodes in the network since they process the most information and ultimately make all changes to the framework, even if the patch is contributed by a member of the community.

Having a global team of developers is ideal for finding specialists to develop specific areas of the framework. A company that hires exclusively in the area surrounding its headquarters limits itself to the interests of those in the surrounding community. In the opening section of Wealth of Nations titled “On the Division of Labor,” Adam Smith argues the merits of the specialization of labor noting that it increases dexterity through practice, reduces transition time between tasks, and the increases the likelihood that a person will find a method to automate the task to abridge the labor. In his work “On the Division of Mental Labor”, Charles Babbage extends these ideas to the the knowledge worker. The Django development team has several specialists who work on areas of Django that interest them. When I asked a question in IRC, for example, Alex Gaynor pinged cramm who he thought would be knowledgeable about my question: “cramm: you’re the rest expert, can you take a look at what timograham pasted.” Specialization frees individuals from the need to be fluent in the entire code base and allows them to innovate in specific areas of the framework.

On the question of employment in the networked economy Castells notes that “Most jobs are in fact not global, but all economies are under the influence of the movements of their globalized core” (10). True to this statement, most of the Django developers who work with Django professionally are employed near where they live. Some do work remotely, but this remains the exception rather than the rule. The Django community also allows developers to collaborate and develop a piece of software at a scale that would be unfeasible for a small business with only a few developers. Electronic Frontier Foundation board member Esther Dyson claims that “The fundamental thing (the Net does) is to overcome the advantage of economies of scale… so the big guys don’t rule” supports this assertion (Turner 219). While the core of Django was implemented by a small team at World Online, the major refactorings of the code base that have occurred since then would not have been possible if Django were not opened to the world.

While many of the Django contributors hold a professional stake in Django, others like college students participate for different reasons. Like the nonmarket work with new media described by Ito in her Digital Youth Research, Django is a place where young people have the opportunity to practice work. Nonmarket work “provides domains where youth can put [knowledge and skills] to practice in a context of accountability and publicity” (Ito). Possible motives for young people to volunteer on the Django project include a better chance of being accepted into the prestigious (and paid) Google Summer of Code program, as well as the opportunity to claim contributions to open source software on a résumé. My time studying the Django community overlapped with the application and acceptance period for the Google Summer of Code, so I encountered several student contributors to Django. The most notable was Alex Gaynor, a freshman computer science student at RPI, who is one of the top talkers on the Django IRC channel. I suspect his involvement with Django will most definitely “help [him] in [his] longer-term career aspirations” once he graduates (Ito). This collaboration of individuals, small businesses, and volunteers around Django forms a network enterprise.

Global: Collaboration – Virtual and Face to Face

The global aspect to Castells’ argument is fairly self-explanatory: global economic activities “have the capacity to work as a unit on a planetary scale in real time or chosen time” (10). Online tools such as wikis, mailing lists, and Trac (an online bug tracker) allow asynchronous collaboration, while the django-dev IRC channel allows developers to interact in real time. Even though Django’s developers are distributed across the globe, face-to-face meet-ups at conferences are vital for building community as well as working on Django itself.

Tickets are the process by which things get changed and fixed both in the Django code base and in the online documentation. For my initial interaction with the Django developer community, I decided to get a feel for the development process by working on some documentation tickets. At first, I looked for the easiest tickets such as typos. I was able to obtain a copy of the Django source code using the instructions on the Django wiki (documentation which is publicly editable, and any changes do not need to be approved), and the online documentation had information about the process by which tickets are triaged. Ticket triage describes the process of moving tickets from “unreviewed” to “accepted” to “ready for checkin”, and ultimately “closed” once the issue is fixed. Even though there isn’t a tangible reward, it was a great feeling once the patches I contributed were checked in. I appreciate the work that people before me have done, and it feels good knowing that my improvements will help someone else who is learning Django.

After a few weeks of working on small tickets I decided to try to contribute something more significant. I found several tickets for updates to the page describing third-party distributions of Django. I posted my ideas on refactoring the page to django-developers and received positive feedback from two core developers. I then created a ticket and a patch based on their suggestions. After a few weeks, I became impatient that there wasn’t any activity on the ticket so I marked it “Ready for checkin”. Ten minutes later, Alex Gaynor noticed my change, moved the ticket to “accepted” status, and left a comment: “Please don’t mark your own tickets as ready for checkin, it skips a vital review phase.” Well, so much for that… A few weeks later (about a month after I filed the original ticket and patch), Jacob checked in the change along with a collection of other documentation tickets. This episode demonstrates the limited time of the core developers, as discussed earlier. Through this episode, I also learned an important lesson: peer review is vital to high-quality open source software. Except for trivial changes, all patches should be reviewed by at least two developers, and the more significant the patch, the more reviewers should be involved. I think Malcolm put it best with his remark regarding his frame of mind when reviewing patches: “The bozo bit is on until proved otherwise”.

Speaking to the global distribution of developers, a conversation I witnessed in IRC reveals that as one core developer in Chicago drops offline for the night, it’s the beginning of the day for another in Australia. Even though the time zone differences create some awkwardness for real time communication, tasks like the ticket triage process can be done asynchronously using tools like Trac and the mailing list.

Software conferences are an important facet of the Django community. In fact, the decision to open source Django emerged from Adrian’s demo of “the CMS” at PyCon 2005. Conferences include keynote talks, tutorials, and a chance for community members to meet-up in person. Django had its first dedicated conference, DjangoCon, in September 2008 at Mountain View, California. DjangoCon 2008 was the first time that many of the core developers met in person, which I’m sure was a nice morale booster and enabled them to have a lengthy meeting to discuss the future direction of the project.

Typically, several days of “sprinting” follow a conference. The Django wiki describes a sprint as “an excuse for people to focus their undivided attention, for a set time frame, on improving Django.” Sprinting provides an opportunity for developers to meet and work face-to-face where they can be more productive than they might be working remotely. Local sprints are also organized spontaneously through venues such as django-developers. I encountered one on the mailing list in preparation of the release of Django 1.1 organized by Jeremy Dunck in Dallas. While the networked society has freed individuals from the daily commute to work, occasional face to face meet-ups with coworkers have become the new way to refresh and recharge.

Informational: Free versus controlled

By informational, Castells means that “the capacity of generating knowledge and processing/managing information determine[s] the productivity and competitiveness of all kinds of economic units” (10). Knowledge work is at the heart of the new economy, and the internet and related technologies, like Django, play an increasingly important role. Django evolves through “itch-driven” development and demonstrates that even though proprietary software dominates some market segments, the open source software industry has a viable future.

Since its inception, open source software has been viewed as emerging from developers “scratching an itch” to get something done. Jacob claims that the team at World Online didn’t start out intending to develop a web framework. Rather, they were just trying to solve the problem of fast-paced news publishing. This culture of itch-driven development continues today. In a posting to django-developers, Russel Keith-Magee explains how new features are developed:

If you’re not willing to write the code yourself, then you either need to convince someone to engage with the community and make it happen, pay someone to engage with the community and make it happen, or wait until it becomes a big enough itch for someone that it gets scratched.

The Django project’s decision making process is mostly democratic and, at last resort, dictatorial. The development is driven by the need to “get shit done” as Jacob says, and Django’s motto is “the web framework for perfectionists with deadlines.” Adrian echoes Jacob’s sentiments by stating the pattern of posing the question “What’s the need?” to a proposed change, and he asserts that “Nothing goes into Django without an explicit use case from someone who is trying to do something and can’t.” In response to a feature request on the django-developers mailing list, core developer Russ Magee writes “we will want to see public interest [in the proposed feature] and continued support as a standalone project before we commit to integrating anything into the Django core.” While core developers have a strong say in the development of Django, Jacob confesses to a time when “pretty much all of the core developers were against the idea, and all of the community was for it” and a compromise was made. Even though Adrian and Jacob have assumed the title “Co-Benevolent Dictators for Life” of Django, Jacob remarks that “we only rule by fiat when absolutely necessary.”

In “Architectures of Innovation”, Lawrence Lessig proposes “control vs. freedom” as the intellectual property debate of the 21st century (178). This debate extends to the realm of software: commercial and proprietary versus free and open source. During the time when the notion of open source software was gaining traction, Steward Brand pointed out the economic paradox of information: “information wants to be expensive, because it’s so valuable. [...] On the other hand, information wants to be free, because the cost of getting it out is getting lower and lower” (Turner 136). Django is licensed under the terms of the BSD license, a permissive license which can be summarized as 1) You are free to redistribute the software, in binary or source form, as long as the copyright, conditions and disclaimer are present and 2) You cannot use the name of the originating organization, or contributers, to promote derivative works of the software, without written consent. While a license like the GNU Public License (GPL) requires derivative works to be released under the GPL, the BSD is a compromise between the GPL and a proprietary license in that derivates of BSD licensed software may be licensed commercially. Many businesses, including World Online with their Ellington CMS for news organizations, have used Django as a building block for commercial products which they license to cover their open source development costs.

Time will tell, but I think the BSD can be a good compromise for corporations looking to give back to the open source community. There are other tangible benefits to open sourcing software. When the idea to open source Django arose, Jacob detailed a business case for open sourcing the framework: “open source will increase our visibility and lead to easier sales and easier hiring, open source will improve the quality of our software.” Interestingly, the most effective argument with management, according to Jacob, was a “moral” one: “how Open Source had helped our business (Apache, Linux, Python, etc.)” and how it was time to “give back” to the open source community. The story of Django makes Jacob “hopeful that this ‘hacker culture’ is in fact compatible with business culture”. He believes that most business are concerned with doing the right thing but don’t know what this means when it comes to technology. He also describes the people at World Online as very forward thinking, so this may be an indication of things to come.

Perhaps most hopeful aspect in the control versus freedom debate is Sherry Turkle’s perspective on the current generation that is growing up: “As they reach adulthood, today’s children are not going to approach the issues raised by these technologies with a sensibility that depends on there being one answer that must serve all purposes” (28). Programs like Google’s Summer of Code are no doubt an attempt to evangelize the merits of open source software to the next generation. Even though information is at the center of the new economy, it does not need to be restricted intellectual property.

Since leaving World Online, Adrian Holovaty has started a local news aggregation service, EveryBlock, which must be open sourced per the terms of the project’s grant. In response to how he plans to maintain a competitive advantage after open sourcing the product, Adrian asserts, “Our competitive advantage is that we’re an incredible team, and I’m sure we’ll come up with a way to feed our families.” The “software as a service” industry (charging for value added services like support rather than the software itself) is something to keep an eye on as the debate between free and proprietary software plays out. Due to the modern capitalist belief that “the whole world is best managed when divided among private owners ,” Lessig views the future of free content as dismal (183). However, I think and hope that people will see the merits of open source software, and I suspect that the future of the industry lies in a hybrid of free and proprietary software.

In his 1995 book Out of Control, Kevin Kelly hypothesized that the ideal corporation should be: “distributed, decentralized, collaborative, and adaptive” (Turner 203). While this vision has not quite materialized, the Django project certainly possesses aspects of it. Django has impacted the web developers across the globe by creating a rallying point for collaboration and community. A small group of core developers leading a larger global community has resulted in a valuable contribution to the knowledge economy.

References

Babbage, Charles. “On the Division of Mental Labour.” On the Economy of Machinery and Manufactures. London, 1832.
Castells, Manual. “Materials for an Exploratory Theory of the Network Society.” British Journal of Sociology. 51 (1) 5-24, 2000.
Ito, Mizuko. “Work.” Digital Youth Research: Final Report. http://digitalyouth.ischool.berkeley.edu/book-work. 2008.
Lessig, Lawrence. “The Architecture of Innovation.” Duke Law Journal. 51 (6) 1783-1801, 2000.
Turner, Fred. From Counterculture to Cyberculture. University of Chicago, 2006.
Turkle, Sherry. Technological Visions. Temple University Press, 2005.

Architecture of the World Wide Web begins by outlining the fundamental paradigm of the information space we know as the web. The document describes the notion of a resource (“items of interest”), represented by a global identifier (a URI; side note: URL is sometimes used interchangeably in this discussion since many of the URIs discussed are indeed locaters as well). Upon the dereference of a URI by an agent, a server returns a representation of the resource. Unfortunately, this paradigm is lost by many people whose perception of the web is little more than a glorified file system. While the W3C recommendation states the good practice that “A URI owner SHOULD provide representations of the identified resource consistently and predictably”, anyone who has encountered a “404 Not Found” message knows the problem of dead links. In Cool URIs don’t change (1998), World-wide-web creator Tim Berners-Lee reflects that “There are no reasons at all in theory for people to change URIs [...] but millions of reasons in practice.” He deconstructs common reasons people assert for allowing URIs to die, such as website reorganization, change of technology, or the lack of proper tools for URI management. For example, noting that web technologies and file formats come and go, Berners-Lee recommends the practice of avoiding such elements in URIs in order to future proof them.

While both the architecture document and Cool URIs outline content-negotiation and HTTP response codes as ways to allow URIs to “live forever,” these techniques are relatively high cost as compared to easy content publishing (and removal!) methods like FTP. While it seems unreasonable to require every individual to maintain persistent URLs (indeed, the architecture provides no way to enforce such a lofty goal), any individual who is serious about his web presence should strive for them. Among the many benefits of persistent URIs include the ability to attract links – “links from other websites are the third-most common way people find sites” (Nielsen, 1999) – and the related avoidance of linkrot. Dead links to and on a website undermine credibility, and as Nielsen notes “Linkrot equals lost business.”

Once the importance of URI persistence is established, it makes a lot of sense to spend some time designing these identifiers which will remain indefinitely. Among the many properties of URIs, Architecture of the WWW argues for URI opacity: “Agents making use of URIs SHOULD NOT attempt to infer properties of the referenced resource.” Does this mean that URIs should be pseudo-random text or the like? Certainly not! Usability guru Jakob Nielsen notes that even though URIs are “a machine level addressing scheme[,] users often go to websites or individual pages through mechanisms that involve exposure to raw URLs.” In the area of search, for example, the value of human readable, semantic URIs is a convincing argument against opaque URIs. Such URIs can be a great asset in driving traffic to a website through search results as a URI is one of three short pieces of info (along with page title and description) displayed in the results of major search engines. Nielsen cites a Microsoft Research study that found “people spend 24% of their gaze time looking at the URLs in the search results” and says that these results reconcile with his own research which concluded that “searchers are particularly interested in the URL when they are assessing the credibility of a destination.” In fact, search engines such as Google and Yahoo! will bold a search term when it appears in a URL on a search results page, thus making it all the more helpful to include relevant terms in URIs. Semantic URIs are also important for inbound links from other websites. In the absence of a title tag from the linker, a quick glance at the outbound URI in the browser status bar may be an important factor in click-through-rate.

With the rise of the browser search box and the relative effectiveness of modern search engines, remembering URIs is becoming less important, however, their design remain an important consideration in usability. In URL as UI, Nielsen promotes URIs that allow users to visualize site structure as well as “hackable” URIs that “allow users to move to higher levels of information architecture by hacking off the end of the URL.” For instance, an URI like http://example.org/employees/john is “hackable” in the sense that by removing /john the user might expect to get a list of employees. Such URIs cater to more advanced users and support the navigation objective of the web.

After reading Fast webpage classification using URL features, one might wonder if the authors have ever read the W3C’s recommendation on URL opacity. Citing speed as the primary benefit, Kan and Thi (2005) conducted analysis on URLs by segmenting them into “meaningful tokens.” Their analysis concluded that “URL features correlate with Pagerank [...] allowing prediction of Pagerank within 1 point on average on Google’s 10-point scale.” This study is especially interesting in considering Tim Berners-Lee advice in Cool URIs on what to leave out in creating persistent URIs. He advocates omitting elements like authors name (“authorship can change with new versions”) and subject (to avoid “binding yourself to some classification”) which might be useful in an automated classification of pages by URL. While Berners-Lee’s advice might hurt the prospect of classification by URL analysis, Nielsen’s notion of “hackable” URLs would seem to suggest favorable results for URL analysis.

A nice solution that conforms to Berners-Lee’s naming suggestions is the permalink feature in content management systems like WordPress. This option allows a “permanent” semantic identifier of the form http://example.com/2008/03/07/sample-post/. The identifier includes the publication date and the title of the post, two pieces of metadata that almost certain not to change. WordPress allows posts to be placed in categories, but by omitting this from the post URI, allows the post to be recategorized over time as site structure evolves (a la Cool URIs). Bravo WordPress! On the other hand, URI analysis would likely be much easier with the category tag. Indeed, there seems to be a tension between “Cool URIs” and those that can be easily categorized by analysis like that of Kan and Thi.

On the topic of URI aliases, the Architecture of the World Wide Web states unequivocally “A URI owner SHOULD NOT associate arbitrarily different URIs with the same resource.” Interestingly, video sharing site Viddler.com seems to do exactly that. Viddler appends /[frame number]/ to a video URI to initiate playback (within a Flash player) at that particular frame, thereby associating a number of URIs for each video equal to the number of frames that the video has. According to the web architecture, the preferred way to implement such a system would be to use the fragment identifier. This optional text component following the # sign in a URI “allows indirect identification of a secondary resource”. In this case, the dilemma occurs because the fragment identifier remains client-side and is not passed to the server. The trouble with associating arbitrarily many URIs with the same resource is that it eliminates the advantage of global identifiers and the corresponding network effects as described in the W3C architecture document. Search engines which use links as a factor in ranking of search results, for example, will consider each frame URI as a separate resource. Unfortunately, the convenience of embedding a flash video comes at the expense of associated arbitrarily many URIs with a single resource.

Sometimes poor URI design can result in other users associating arbitrarily many representations to your URIs. Long, non-semantic URLs are good candidates for applications like tinyurl.com which is designed to convert a long hyperlink into a shorter link of the form [tinyurl.com/xxxxx]. While these tiny URLs are handy for passing around in applications like email or Twitter, all context (domain name, etc.) provided by the URI is lost, which may cause users to be weary to follow such a link. Thnlnk.com goes a step further by asking the user to enter a 5-7 word description of the resource and then attempts to generate a more semantic URL based on the description. In my experience, however, these URLs were sometimes as long as the original. Better to design your own URIs correctly in the first place and avoid these context killers!

The architecture of the web is a broad framework that does little to specify aspects of usability and semantics, let along enforce such aspects. Ideas such as “usable URIs” and the “semantic web” lie outside of the architecture and are left up to people to decide and act upon. Ultimately, the onus lies on website administrators and content publishers to create usable URIs and to associate documents with identifiers rather than the reverse. The significant benefits of doing so coupled with the the costs of not doing so, however, should not be ignored by anyone who takes his web presence seriously.

References:
1. Berners-Lee, Tim. Cool URIs don’t change. 1998.
2. Jacobs, Ian and Norman Walsh. Architecture of the World Wide Web, Volume One. December 15, 2004.
3. Kan, M. and Thi, H. O. 2005. Fast webpage classification using URL features. In Proceedings of the 14th ACM international Conference on information and Knowledge Management. ACM, New York, NY, 325-326.
4. Nielsen, Jakob. URL as UI. March 21, 1999.

pulseaudio -k
pulseaudio -D

A few weeks later I spotted an update to pulseaudio on update manager with the description “Add pm-utils sleep hook to suspend (and resume) users’ pulseaudio daemons”. That sounded promising so I quickly installed the update and put my computer to sleep. Sure enough, after waking it up the sound worked!

I’m using Skype for Linux 1.4.0.99 and I noticed that if I jostle my microphone, the capture volume will decrease. This is annoying because when I go to make a call, the other person won’t be able to hear me. I found a fix to avoid this auto-adjustment:

First, close Skype if it’s running.
In your home directory press Ctrl-H to show hidden folders.
Find the .Skype folder and edit the shared.xml with a text editor.
Find the subsection <lib> with a subsection <voiceeng>. In this subsection, add <agc>0</agc> to disable automatic microphone manipulation.

Here’s a screenshot of the modified shared.xml file:

• Full: this backs up everything
• Incremental: the first time the backup is run everything is backed up; subsequent backups contain only the files that have changed since the previous backup
• Differential: like incremental, the first time the backup is run everything is backed up; subsequent backups contain only the files that have changed since the last FULL backup

Obviously, incremental and differential will save backup time, however, recovery may be a bit more complex since recently modified files are scattered across several archives. Depending upon your backup size and how often you modify files, I’d recommend running a full backup once a week so you don’t have too much to piece together in the case of a recovery.

One setting I activated was to run missed backups, in case my computer is off when I scheduled to run the daily backup. Go to Tools ? Options ? Functionality and check Run Missed Backups; I also checked Run Without Asking.

Other notable features:

• Archives can be compressed as a standard zip file for easy recovery.
• Optional system shutdown after backup is complete.
• Exclude certain file types

From someone who has lost files before, if you are not backing up the data you care about, get on that now!

With Windows XP, ClearType delivers improved font display quality over traditional forms of font smoothing or anti-aliasing. ClearType improves readability on color LCD displays with a digital interface, such as those in laptops and high-quality flat panel displays. Readability on CRT screens can also be somewhat improved.

Check out the pic. It really does work!

For more media player replacements check out QuickTime Alternative. Note that if you use iTunes, however, QuickTime is bundled with the iTunes installation. I’m trying to find a standalone installer.