Login or e-mail Password   

Commonspace - Chapter Eight (The Tools Matter)

Link to original publication: http://commons.ca/articles/fulltext.shtml?x=483
People make the Internet. People make community. People make commonspace. No question. This being said, the tools that people use to construct commonspace matter– a lot ....
Views: 699 Created 10/08/2006

People make the Internet. People make community. People make commonspace. No question. This being said, the tools that people use to construct commonspace matter– a lot.

 

Why? Because the tools assemble the people, and the way they assemble them has a major impact on what we can do online and on how successful we are at doing it. USENET is different from the software that manages eBay. A Web discussion forum is different from an e-mail list. For that matter, Gnutella is different from Napster, and Netscape is different from Internet Explorer. Large or small, these differences matter. The interface, the features, the protocols all have an impact on what you can do in commonspace.

 

Deep within the lines of code, all of these tools hold the potential to produce the online collective. This is precisely why they continue to thrive while others have failed.

 

Several companies have tried to create Internet tools that ignore the collective. Such attempts have always met with the massive indifference – and occasionally the wrath – of the online community. Microsoft, for one, has behaved like a hackneyed cartoon villain, launching scheme after hairbrained scheme to pacify Net users. First, they tried to replace HTML with their own proprietary programming language called Blackbird, which would have allowed people to write content solely for MSN. Bye bye Blackbird. Next, they bought WebTV, a technology which essentially lobotomized the computer, sucking the potential for interactivity out of the browser and replacing it with a remote control. [Evil baritone villain voice: ‘Yes, my zombie minions…. Don’t type. Don’t say anything. Just surf and buy. Hahahahahahaha!’]

 

In both of these cases, designers tried to do exactly what RCA did to radio in the 1930s. They tried to rip the transmitter out of the Internet. Luckily, they have failed miserably. [Evil baritone villain voice: ‘And I would have gotten away with it too, if it weren’t for you meddling kids and your dog!’]

 

 

Many-to-Many Gadgets

 

In commonspace, the ability to create many-to-many connections matters a great deal. Internet tools need some kind of many-to-many capability, end stop. It is a basic precondition of their existence. They must allow anyone to send and many people to receive, if only to ask for another Web page or to order a pizza.

 

This rule runs to the very heart of the network itself – Internet protocol (TCP/IP) and Internet culture. As it routes traffice over the network, TCP/IP makes the technical assumption that every computer on the network is equally empowered to send and receive. Furthermore, most of the people building sites and software for the Internet regard it as inherently dedicated to various forms of many-to-many communication. For the most part, they design and implement tools that take advantage of TCP/IP, tools that encourage people to be creators as well as users. No one is selling modems or writing e-mail programs that only let you download (except WebTV). Not yet, at least.

 

How a tool provides many-to-many connections is much more interesting than the connections themselves. Some tools make it easy for everyone to be a sender and limit the amount of possible response. Other tools provide an equal flow of information between all senders and receivers. The features, the core technological design, the rules of use, the social mythology – all these factors determine what types of connections are possible with a given technology.

 

The different characteristics of the available tools determine the extent to which they lend themselves to commonspace applications:

 

·         The Web provides people with a great deal of space to respond (eg. Web-based forums) despite the fact that the underlying technology (HTTP) provides very limited abilities to the person on the 'client' side.

 

·         E-mail has excellent potential for many-to-many applications but is usually used for one-on-one or small group communication.

 

·         Intranets are built on many-to-many technologies but tend to place substantial social restrictions on who can be connected to them.

 

·         Napster and other file sharing tools are the closest thing we have to a pure many-to-many environment, connecting peers to peers. The interface and all the rules of use follow suit. 

 

·         Newsgroups also fall into the pure many-to-many category. They were designed by and feed into a culture founded on the premise that 'anyone can talk, and many will listen'.

 

Internet tools tend to float between the 'anyone can send' and 'many can receive' poles. In contrast, older forms of media have long since chosen sides. The telephone is squarely in the 'anyone can send’ camp. Inversely, television works only in 'many can receive’ mode.

 

Mapped out, the many-to-many commonspace tech spectrum might look like this:

 

 

Society
Conceptual frameworks and rules.

Anyone
can send!

Technology
The wires and the material devices.

Many
can receive!

Telephone

E-mail

Television

Radio

Print

Napster

WWW

commonspace

Newsgroups

Intranets


 

One of the biggest factors determining the nature of a given technology is distributedness – the degree to which it is centralized or decentralized. Is there a single access point or are there many? Is the directory in one place, or is it spread across the Internet? Does the information reside in a single place, or is it replicated so that it exists in many places at once?

 

USENET is a good example of the impact of 'distributedness' on a tool’s role. USENET is incredibly distributed, with its feed stored on thousands of different servers around the world. Each server provides a small group of users with the means to send and receive newsgroup messages. When there are new messages on one server, it sends these messages out to the rest of the network. At a technical level, this distributed approach lends redundancy and robustness to the system. It also protects against failure and data loss at any particular node in the network.

 

More importantly, the decentralization of USENET creates a culture of independence. Each access point in the network can choose which portions of USENET to include and which not to include. Just because someone creates alt.sex.fetish.rockclimbing.butt.naked doesn't mean that any other servers have to pick it up. If an ISP doesn't like (or doesn't want) to expose its users to naked people bumping uglies on mountaintops, it can drop this newsgroup from its feed. Administrators can also establish their own local or private newsgroups. As a result of the distributed design and culture, each small subset of USENET users can have a discussion forum system that responds to their local needs.

 

USENET’s particular technological features and its approach to distributedness also define the limits of its usefulness:

 

·         It's not a great place for selling the spare stuff in your garage (most people have abandoned the .forsale newsgroups for eBay);

·         It's not a good tool for aggregating statistics about our mutual likes and dislikes (usage stats spread across thousands of servers are almost impossible to compile);

·         And it's not a good tool for the collaborative development of a document (it doesn't include version control or a proper file archive).

 

But USENET isn't supposed to do these things. What it does it does well, and it does so by design. Other tools have evolved – and will continue to evolve – to meet these other needs.

 

 

Road Warriors

 

Luckily for commonspace, people gravitate to tools that are designed for distributedness. They prefer tools that give anyone a voice and allow many to listen. This tendency became evident at the beginning of the last decade, during what we’ll call the Battle of the Information Superhighways.

 

In the early 1990s, the media heralded the dawning of a new era. Video-on-demand. Online shopping and banking. Pick-your-own-camera-angle-sports-and-porn. The five-hundred-channel universe. It was all just weeks away. And Time Warner, TCI and Microsoft were pouring hundreds of millions of dollars into creating 'set-top boxes' and proprietary networks that would make it all happen.

 

At the same time, the humble little Internet was chugging away quietly in the background. Nobody thought it would beat the proprietary info highway at its own game (not even people like Marc Andreessen[1]). It was more of a plaything and a test bed. But then the Web and Netscape happened. And then everything exploded. All of a sudden, people could create their own media, their own businesses, their own stores. More importantly, people could connect without paying homage to the corporate gatekeepers. The Internet was the little engine that could – and did – connect us to each other.

 

As people chose Netscape and the Web – and they chose it in droves – talk of video-on-demand and proprietary superhighways faded away. Time Warner shelved its much-heralded, multi-million dollar interactive TV tests in Florida. Microsoft dropped its Tiger video-on-demand server and its propriety Blackbird language for MSN content providers. Everyone, even those who had fought it tooth-and-nail, moved to the Web. It provided a platform to many who'd never had one before, and in doing so, it fed a revolution.

 

Tools matter.

 

 

Lingua Franca

 

Another factor that determines the usefulness of tools is their ability to talk to each other. This is where open standards, the lingua franca of the Internet, come in.

 

Not too long ago, all e-mail programs had their own proprietary formats for moving messages. If you had e-mail on Compuserve, or through cc:Mail at the office, your mail system wasn't compatible with your friend's mail system on AOL or with a neighbouring office’s Novell system. If you were lucky, you might have been able to send e-mail to your friend via a 'gateway' (which you had to specify and know how to use). If you were unlucky, you simply couldn't send mail to people outside of your own system.

 

In the world of proprietary protocols, e-mail looked like this:

 

 

 

Compuserve

Corporate Network A

Corporate Network B


But in the background, the Unix hackers who created the building blocks of the Internet were changing things. They wanted to talk to each other and were making it possible by using an open standard mail system that they shared amongst themselves – the Simple Mail Transport Protocol (SMTP). SMTP suddenly enabled users to send e-mail between technologically different organizations. The e-mail tsunami began.

 




By the mid-1990s, SMTP had replaced proprietary mail protocols almost everywhere. And even where proprietary tools continued to exist, they talked via SMTP to the outside world. E-mail started to look like this:

 

 

Compuserve

Corporate Network A

Corporate Network B


 

The result was the e-mail system we have today. While we may take it for granted, it's actually quite a feat that e-mail can leap organizational boundaries in a single bound. Even as recently in the early 1990s, proprietary e-mail seemed like a sensible idea. Why make your system work with other systems? It would erode market share or pollute the content of the network. But the leap happened all the same. And it has changed our preceptions of the technology to the point where proprietary e-mail now sounds like a crazy joke made at the end of a drunken evening.

 

Commonspace and collective work thrive when data becomes free of boundaries. Data needs to flow between people and between organizations. This is not possible in a world of proprietary tools. Open standards are necessary to liberate data and help us connect.

 

Luckily, there are a lot of smart people out there who understand the importance of standards and data exchange to the development of commonspace. New protocols and standards are constantly under development. From B2B process automation to information about international aid and disaster relief, someone out there is developing a standard that will make it easier for information to flow between diverse systems.

 

 

XML - Everything, Everywhere

 

On of the most exciting technical developments in commonspace in years is eXtensible Markup Language, or XML. Intended as a replacement for HTML, XML deals not only with presentation elements of a page (i.e. bold text, picture placement, columns) but also with the data elements (i.e. title, body content, contact information).

 

So what, you say? Why get so excited about a three letter acronym replacing a four letter acronym? Isn't it all just the Web?

 

With XML, Web pages will come alive. One computer will be able to talk to another, sharing information about the content that’s available on the web pages it hosts. Computers will be able to interact, exchange information, and update each other – to work together as if they were one. The entire Web will begin to work as if everything were all on the same computer and stored in the same database. The resulting fluidity will also create new opportunities for collaboration and collective work. Moreover, it will fuel the fire of commonspace phenomena such as web constellations, aggregated data pools and distributed computing.

 

XML is still in its infancy. Nonetheless, it’s already being used in some simple but powerful applications . Take the swapping of news content in the open source tech community. This swirl of collective content uses an XML protocol called Rich Site Summary (RSS). With RSS, sites like SlashDot constantly send out summary info about the content they want to share. Other sites pick up this summary information and list the stories on their own sites. Likewise, Slashdot publishes RSS summaries from other sites. Voilà: a collective news network of ‘smart’ content, all of it automated. Machines talking to machines, taking the best of what is fed to them from trustworthy humans.

 

Because XML is 'extensible,' anyone can dream up a new use for it. Doctors are working on an XML-based system that lets medical systems talk to each other. Aid workers are building tools to find and connect international development data, no matter where it exists. Whatever the application, people are using XML to break down barriers and connect things. They are running towards commonspace with open arms.

 

 

KISS

 

The essence of commonspace design philosophy is simple: choose the Laguiole Knife over the Swiss Army Knife.

 

We’ve all seen Swiss Army Knives, and many of us have one (they make great stocking stuffers). But how many people ever use anything other than the main blade? What could you possibly do with those other little tiny blades? Or the stupid saw thing?

 

In contrast, the Laguiole Knife, which has been around since 1829, is an uncomplicated, elegant tool, featuring just one large, sharp blade of high-quality steel, and (optionally) a corkscrew and a sharp metal spur for letting the gas out of the stomach and intestines of freshly killed animals. The analogy to software is clear: massive ‘all-in-one’ solutions (bloatware) are popular, but smaller specialty tools accomplish the same tasks just as well, or better, and for less capital investment. They’re also easier to debug if something goes wrong. (And let’s face it: when there are computers involved, there are always problems.)

 

But the tools you choose to build commonspace don’t require you to sacrifice other tools. Successful technologies always complement each other and allow for overlap without needless duplication or interference. It's also important that tools use open standards for communicating with other specialized tools to balances focus and versatility.

 

GameSpy is a tool with one purpose: combining access points to various online games into one elegant interface. Its simplicity allows a level of interactivity between gamers that many commercial software packages can’t match. For the most part, GameSpy does a better job of pinging the servers of many game networks than the crude interfaces bundled in with the game software itself.  GameSpy allows users to filter server lists using their own parameters (such as ping time), to create sub-lists based on game types, to perform quick refreshes of server lists, to compile sophisticated stats on particular games in play (up to and including lists of participating players and the ‘skins’ or character types they happen to be using), to locate ‘buddies’ who happen to be online, and to chat. Moreover, it consolidates the operation of a large number of games under a single interface.

 

Gnutella is an even more extreme example of simplicity in action. In the Gnutella interface, there is no provision for chat of any kind, or even for sophisticated searching or monitoring. There’s just a simple form with a search box and a results box, and a tab to a window which scrolls current search strings. The only internal clues about how to operate the program come from the watching search strings as they zip past. The reason for Gnutella’s minimal interface is that the project was killed before its interface had been developed further. Nevertheless, it does the job. Some users have cloned and modified the program to solve problems such as bugs and spamming; others have improved on the aesthetics of the original interface, and still others are working on improving the program’s scalability to alleviate traffic jams caused by apprehensive Napster users migrating to Gnutella. However, the majority of users continue to use the original release despite its Spartan design.

 

Application Service Providers (ASPs) are another result of the drive for simplicity. ASP companies provide software 'for rent' over the Internet. They do all the configuration and maintenance and tailor their product to the needs of their users. All the user needs to do is fire up a Web browser. ASPs with a focus on commonspace are growing. Take eGroups, for example. When you set up your community with eGroups, they do all the gruntwork. Other organizations, such as b2bScene.com, are taking complex and expensive intranet software and delivering it as an ASP-style service. Click a few buttons, enter your credit card, and you have a trading community or project intranet.

 

Amidst all of this, there is only one thing to remember – KISS. Keep It Simple, Stupid.

 

 

Tools People Want

 

If tools are going to be successful, people have to like using them. Simple, convenient tools put power in the hands of their users. In principle, it’s not hard to design such tools. If you can:

 

·         balance simplicity, access and power;

 

·         fit in with the normal daily routine of users;

 

·         empower users, not service providers;

 

·         make it free or cheap;

 

·         listen constantnly to what users are saying;

 

.... you’ll do fine in the ‘give people what they want’ department. Of course, 'just' doing these things isn't always easy. We all get caught up in our own rigid, obstinate ways of doing things. It takes practice to fit into the groove of giving people what they want.

 

Take mail lists, for example.  Mail lists are by far the most popular many-to-many discussion tools on the Net. eGgroups alone hosts over 18 million members who participate in thousands of mail lists[2]. As of August 2000, CataList, the catalogue of LISTSERV lists estimates that there are 30,792 public listserv mail lists out of a total of 166,665 mail lists on the Internet today[3].

 

But mail lists are a frumpy old technology – aren’t they? Why doesn't everyone just switch over to Web-based forums? Simple: Web forums are closed systems that take people out of their way and inconvenience users. In other words, they are a pain in the ass to use.

 

Look at the evidence. On most of the 'give people what they want' fronts, mail lists put the smack on Web forums:

 

 

Mail Lists

Web Based Discussions

Simplicity and power

Yes. What's more simple and direct than an e-mail message?

No. Usually the interfaces are cluttered and confusing.

Daily routine

Yes. Users check their e-mail anyway.

No. Users have to take the initiative to visit the forum site.

Empower users

Yes. Users can set up and configure mail lists with ease.

No. Space is controlled by the service provider.

Free or cheap

Yes. Mail lists are available for free from many sources. Even where you pay, they are cheap.

No. Web-based discussions usually require the purchase and configuration of expensive server software.

 

These differences have contributed to the continued success of the mailing list as a collaboration and community building tool and to the almost complete failure of Web-based discussion.

 

 

Wallowing In Complexity

 

Of course, complexity has its attractions. Grand technological dreams are often built on the field of complexity. Consider Ted Nelson and Xanadu.

 

Hypertext didn't start with the World Wide Web in 1992, or even with Apple's HyperCard in the 1980s. It started with Ted Nelson and the Xanadu project back in 1960 <www.xanadu.net>. Named after the mythical locale in Coleridge’s ‘Kubla Khan’, Nelson's Xanadu project outlined a grand dream for the world's first workable hypertext system. It was a system that would link not only one document to another, but also one section of one document to another. It was going to create parallel documents, monitor versions and provide for two-way links. In other words, it was going to create an interwoven, self-aware knowledge network.

 

Even from today's perspective, Nelson's ideas from the 60s and 70s are brilliant. He proposed a technical system based on connection and collaboration – data knowing about other data, people creating collaborative documents (easily linking individual chunks of data),  and aggregating data simply and powerfully. Both the technical and social aspects of Xanadu embodied the very essence of commonspace.

 

Unfortunately, plans went awry as Nelson tried to turn the grand dream into a reality. Working with a number of collaborators, Nelson strove to create a workable Xanadu system throughout the 70s and early 80s. Little pieces of code came together, but nothing complete ever emerged to be 'productized' (Nelson's own word)[4]. In 1988, software giant AutoDesk came along with investment money to make Xanadu real. But with little to show for its money by 1992, it abandoned the project.

 

Meanwhile, the Internet was growing in the background. The first examples of hypertext were appearing. Lotus Notes came out as an interconnected, self-replicating database environment. Millions of Mac users were futzing around with Hypercard. Then World Wide Web burst onto the scene. While all of these technologies owe a debt of gratitude to Xanadu (as their developers will freely admit), they are distinct from the Xanadu project in one crucial respect:  they are simpler.  And, as simple, powerful tools, they have fueled a revolution.

 

The sad thing in all of this is not that Xanadu's complexity got in the way of the grand dream becoming a reality. No, the sad thing is that Nelson seems bitter about the success of simpler hypertext systems. The front page of www.xanadu.net reads:

 

Since 1960, we have fought for a world of deep electronic documents-- with side-by-side intercomparison and frictionless re-use of copyrighted material.

 

We have an exact and simple structure.  Our model handles automatic version management and rights management through deep connection.

 

Today's popular software simulates paper.  The World Wide Web (another imitation of paper) trivializes our original hypertext model with one-way ever-breaking links and no management of version or contents.

 

WE FIGHT ON.

 

Nelson sees the World Wide Web as a massively nerfed version of his original dream. Maybe it is. But the Web is effective in its simplicity, because it is creating commonspace and changing the world.

 

 

Welcome to the Pleasure Dome

 

The simplicity of Internet technology is vital because the Internet and commonspace are complex to start with. But their complexity is more like that of an ecosystem than a technological masterplan. It's not a rigidly planned whole; it is an interwoven mesh of ideas and systems. Like an ecosystem, it grows organically. Simple new ideas enter the system. The good ones survive and propagate, the bad ones are reabsorbed and fuelk othyer new growth. The system evolves.

 

As with an ecosystem, online diversity is everything. The system isn't about one grand vision, but about a multiplicity of visions combining together synergistically. These visions are different, sometimes even conflicting; but in a massive conceptual pool where the simple ideas survive, this kind of diversity is good. In fact, it is to be celebrated. It feeds change. It allows for options. It creates unexpected synergies that feed into astounding watersheds.

 

All of this is what makes commonspace so exciting.It is based on a system of communication that isn't monolithic. We can all contribute a piece to the pie and see if it weaves into the overall fabric. We can all benefit from each other's contributions. And as this happens, we move slowly towards Ted Nelson’s grand dream.



[1] David Sheff, "Crank It Up," Wired, August 2000, 186.

[2] <www.egroups.com>

[3] <www.lsoft.com/lists/listref.html>

Similar articles


6
comments: 1 | views: 4550
8
comments: 4 | views: 12483
5
comments: 0 | views: 3317
7
comments: 0 | views: 1783
6
comments: 0 | views: 2004
4
comments: 6 | views: 3617
4
comments: 1 | views: 5799
4
comments: 0 | views: 1871
 
Author
Article




No messages


Add your opinion
You must be logged in to write a comment. If you're not a registered member, please register. It takes only few seconds, and you get an access to additional functions .
 


About EIOBA
Articles
Explore
Publish
Community
Statistics
Users online: 75
Registered: 58.512
Comments: 444
Articles: 66.447
© 2005-2014 EIOBA group.