A few years ago, as a senior editor at BYTE Magazine, I reviewed software and wrote about technologies and industry trends. Everything changed in the spring of 1995 when I became BYTE ’s executive editor for new media. My charter was to do what every high-tech magazine felt compelled to do in 1995: jump on the Web bandwagon. It was a dream assignment that I tackled with gusto. At first I focused on clever and efficient ways to transform BYTE into an electronic publication. But a funny thing happened on the way to the Web. Just weeks into the job, it dawned on me that our content online wasn’t just a publication. I began to see that it was fast becoming a suite of Internet-based groupware applications. And I began to see myself as primarily a developer of such applications.
What’s Internet groupware? I define it as four interrelated disciplines:
A way of using standard Internet (web, mail, and news) clients, servers, and protocols
A way of building web-, mail-, and news-based applications to create, transform, organize, transmit, search, and publish electronic documents
A way of managing sets of documents that contain semistructured data representing much of the intellectual capital of an enterprise
A way of deploying web, mail, and news services in support of these activities
I spent three years combining and recombining these disciplines in order to create a wide variety of groupware solutions. Some helped my own department—a team of three—collaborate more effectively. Others helped bind together the whole staff of BYTE Magazine, a distributed company that had primary offices in New Hampshire, Massachusetts, and California. Still others linked BYTE’s staff to an online population of several million and enabled these online users to collaborate among themselves.
I’d dreamed of, but never thought I’d be able to build, applications that could:
Be used by 10,000 people a day
Span multiple zones of privacy
Connect clients in any location to servers in any location
Extend HyperText Markup Language (HTML) authoring capability to naive users
Manage structured and semistructured information
Run on any client or server platform (Unix, NT)
Tap into distributed backend services
Scale across clusters of servers
Be written in any language (C, Perl, Java™, Unix shell, Visual Basic)
And I’d certainly never have guessed that these applications would turn out to be relatively easy to build. Why is this so? Not because I’m the world’s most clever guy. If that were true, this story would be far less compelling. Instead, the answer lies at the heart of the Internet itself. Its applications and data structures rely on simple ideas and protocols. That’s why the Internet flourished beyond what many savvy trendsetters—including, most notably, Microsoft—ever thought possible. You can make this simplicity work for you, too. This book explains how.
This book in its entirety best serves an eclectic toolsmith and information architect who wants to create group-oriented information-management solutions for users. It’s full of programming examples, many in Perl and a few in Java, and assumes strong knowledge of these languages and their associated environments. For example, I’ll often augment Perl using a Comprehensive Perl Archive Network (CPAN) module, and when I do I’ll assume that you know (or can readily learn) how to do that. I’ll also assume that you’re familiar with:
Windows NT and Unix/Linux
HTML (and, to a lesser degree, Extensible Markup Language (XML))
Cascading Style Sheets (CSS)
Basic web server setup and administration (both Microsoft IIS and Apache)
Common Gateway Interface (CGI) scripts and Java servlets
The HyperText Transfer Protocol (HTTP) (and, to a lesser extent, the Network News Transfer Protocol (NNTP))
That’s a steep ante, I’ll admit, but you don’t need to bring all these chips to the table. Just bring a flexible mind. Groupware is slippery stuff, and successful implementation requires a witches’ brew of social and technical strategies. The former will outlive the latter, because the technical underpinnings of this book—web document databases, NNTP newsgroups—are about to undergo yet another paradigm shift.
I’ll show you ways to get people working together more effectively, and I’ll demonstrate using specific examples based on current Internet technologies. I realize, though, that emerging technologies—including web distributed authoring and versioning (WebDAV), and Extensible Stylesheet Language (XSL)—may eclipse some of the solutions shown in this book. I wrestled with this problem and concluded that I had to focus on the here and now, the existing installed base of Internet clients and servers. I base some examples on XML, which matured sufficiently as this book was in progress and which can be used in ways compatible with current clients and servers, but I don’t demonstrate WebDAV or XSL, which don’t yet meet these requirements.
I know these solutions work, because I’ve used them successfully. They won’t hold up forever, because the infrastructure is evolving. Whatever comes down the pike, though, we’ll still need to create, adapt, and use collaborative tools, and we’ll likely need an eclectic assortment of strategies to do these things well. Some of this book deals with social engineering, and those principles will have a long shelf-life. Much of the book presents technical strategies whose specifics will change—perhaps quite soon. I’ve nevertheless grounded the book in specific examples, aiming to deliver a broad vision of how things ought to fit together in groupware systems based on Internet principles, and useful insight into ways to identify and assemble the parts.
Although I use the term Internet groupware, many of the ideas in this book arise from my intranet experiences. I remember looking, one day, for a driver update that I knew was somewhere on my LAN. After wasting half an hour trolling for the file, I searched the Web, found the driver, and downloaded what was probably a newer version than the one I couldn’t find on my own network. How, I wondered, could the Web, vast and disorganized, outperform my LAN? And why weren’t the Internet technologies we were beginning to use in-house as compellingly useful as the Internet itself ?
It’s mostly a matter of scale. Internet services such as the Usenet and the Web search engines have critical mass. With millions of contributors and billions of documents, there’s lots of action going on and plenty of value to be mined—though you do need to dig for it. Intranets arose when people saw that the Internet’s tools could also be useful at narrower scopes: a company, a department. Internet-style collaboration can work well here too, but the dynamics are very different. Far fewer people create far fewer documents; there’s not enough fuel for spontaneous combustion. Nevertheless, although there may be only tens or hundreds of us on an intranet, we’re working in tightly knit project teams toward common goals. There’s a more focused opportunity to use collaborative tools and a greater incentive to do so. This book explores ways to adapt modes of Internet-based collaboration, and the tools that support it, to the smaller and more task-oriented intranet.