Contents

• How I Came to be Interested in Collaboration

• Introducing the Distributed Collaboration Project

• Demonstration of Features

  • File Sharing
  • Code-Aware Chat
  • Public (persistent) Conversations

• Collaboration-Enabling an App (Building a Collablet)

• Immediate Uses

• Future Uses

• Conclusion

• Resources

How I Came to be Interested in Collaboration

One of the great privileges of my life was to have spent time working with Doug Englebart-- father of the mouse, workstations, windows, outliners, links, and practically everything we take for granted in the computer world these days, with the possbile exception of the Internet. In 2000, I was lucky enough to find out about a colloquium Doug was running called "The Unfinished Revolution". Since I was live and work just down the road from Stanford, it didn't take much arm twisting to get me up there for the weekly sessions.

Talk about intellectual stimulation! Every week, my head was spinning with concepts and ideas. The event reawakened my original purpose in working with computers--to figure out how to use them to make a better world. Doug's purpose was nearly identical: To use them to help solve's mankind's most complex problems. (For more information on Doug's work, visit http://www.bootstrap.org/.)

When the colloquium started up a mailing list, I was all over it. After several weeks, it turns out that I was responsible for 50% of the traffic on the list. (And that was just message count. Thank goodness they weren't doing a word count...) I'm proud to say that I wound up giving a talk at that event, and that I was invited to talk at the wrap-up session, as well. It was a great way to share my concepts about we could be, and should be, doing to solve the problems mankind faces--hopefully, before they overwhem us.

When the colloquium ended, a group of us started meeting with Doug once a week to see if we could build something we could use to get started. You see, there were people all over the world listening in to Doug's sessions, who wanted to contribute. The problem was, we had no good vehicle for distributed collaboration! We needed a tool we could use to design solutions to problems, and the first thing we needed to design was the tool!

We met once a week for close to two years, but the problem seemed to metaphorize from week to week, and there were enough different agendas among the participants that we never succeeded in really defining the problem, much less specifying a solution. (In my mind, the issue was clear. But the issue was equally clear to everyone else--but different.)

One of the good things to come out of that series of meetings, however, was a non-profit organization devoted to studying the problem of distributed collaboration. The effort, dubbed BlueOxen, was started by Eugene Kim and Chris Dent, and featured no less than Douglas Engelbart on its Advisory Board. (For more, go to http://www.blueoxen.org/).

There have many good discussions on the BlueOxen list on collaboration problems, and the group has sponsored several studies of best practices and methods. The group has developed some good software as, well, including some server-side implementations that help you put Engelbart-inspired "purple numbers" on a page. (Small purple numbers at the end of a paragraph that link to the start of the paragraph, so you can easily reference any part of the page by copying it's link.)

As always, though, the chicken and egg problem of distributed collaboration remained: How can you allow remotely distributed people to collaborate well enough to design and build a distributed collaboration engine? Lacking the tool they needed to build the tool they needed, progress was necessarily limited.

The basic tool needed to solve the problem may just have been demonstrated today at JavaOne, however. In part, it's a distributed collaboration tool that has a standalone implementation and a NetBeans implementation. But more importantly, consists of both a specification that allows remote, heterogenous systems to work together seamlessly, as well as an underlying system that makes it almost simple to enable collaboration for almost any software you write.

Introducing the Distributed Collaboration Project

This section introduces the terminology and describe the demonstration, showing how the technology is currently being used. Subsequent sections describe the demonstration of implemented features and show how the technology works.

Like any good modern-day development effort, the NetBeans collaboration-tool project starts by defining the ontologoy for the domain--the collection of terms and concepts that define the problem space:

A conversation consists of multiple participants who are communicating using one or more channels, where a channel is, for example, a whiteboard, a vocal exchange, or __xx__.

That's pretty much all that a user needs to know to decipher the terms in the interface. For developers, there are a few more terms to introduce-- the ones that define the solution space:

Each channel is implemented by in a collablet --a class that implements the tiny little Collablet interface. The collablet registers itself with the application, so it is notified when things changes. It then uses a CollabBean to send messages to participants, and to receive them.

The implementation library includes CollabBeans that send and receive XML messages to participants using MOXC--the Message-Oriented XML Collaboration protocol. Other CollabBeans can be implemented as well --for example a Voice Over Internet Protocol (VOIP) bean to handle voice traffic.

Notes:

• Current implementations include NetBeans 4.1 and CodePal, a standalone tool.
• The container (NetBeans or CollabPal, at the moment) handles the work of sending messags and tracking participants. The collablet you write for an application really only cares about the content of the messages.
• Because that message protocol is XML-based, collaboration tools can interact on heterogenous systems.
• Because the design is message-based, with no code sharing, it keeps things simple. Particpants are easily added and removed.

Demonstration of Features

This section describes the implemented features that Todd Fast demonstrated. The next section goes under the hood to describe how the technology works.

This section covers:

• File Sharing
• Code-aware chat
• Public (persistent) Conversations

Collaboration-Enabling an App (Building a Collablet)

Todd Fast showed how to collab-enable an existing application with a simple little program that tracks mouse clicks with a colored spot. The program let you change the color of the spot (a large circle), and put it whereever you clicked the mouse.

The process was completed in fours steps, with no more than a few lines of code in any step. (As the number of possible messages grows, the line count will go up--but all of the additions will be related to the application. All the overhead you need will have been added with those few lines of code.)

The process looks like this.

1. Register property-change listeners and send property-change messages.

   That requires two simple methods in the application, on to register listeners, and one to notify them when something changes. (For some applications, the hardest part of the process will be "instrumenting" the app to notify listeners whenever something changes.)

2. Define a unique namespace to use in the XML messages.

   Define a string constant (final String) for that purpose. It could be anything, but generally it's defined as the project host's URL, along with the project name. So it would be something like this: http://yourOutfit.org/yourDivision/yourProject

3. Send a MOXC notification:

   Document doc = createDocument(); // create an XML document

   Element element = doc.createElementNS(NAMESPACE, "spot:colorSpot);

   element.setAttribute("color", spotPanel.getColor(color)); // an integer

   sendMOXCmessage(element);

   Note: I didn't get the code that obtained the spot's color, but it's the simple, standard spot.getColor() kind of thing.

4. Receive a MOCX notification:

   Element element = message.getMessageElement();

   if (element.getLocalName().equals("colorSpot") {

   Color color = new Color(getIntegerAttribute(element, "color");

   spotPanel.setColor(color);

   }

   else if (element.getLocalName().equals("something else") {

   ...

   etc.

There are undoubtedly some errors in my transcription. But you get the idea. It's absurdly simple to collab-enable an application. The API libraries does the work of notifying all of the participants in the conversation. The shell you're working in (NetBeans or the standalone CollabPal) keeps track of who's participating. All that wiring is kept behind the walls where it belongs. All it takes is a few lines of additional code, and you're in business.

That simplicity, coupled with the basic losely-coupled, XML message-based design, is why I called the APIs "brilliant", and why I'm waxing so enthusiastic about it.

Immediate Uses

These are the things that the NetBeans solution enables today:

• Code Sharing and Development. This is the obvious use case, and it just became reasonably possible.
• Support. The automatically-generated line numbers on code segments will make it easier to talk about things.
• Specification and Design. This where the biggest impact will be, in my opinion. The ability to work collaboratively on use-case documents and design documents may make it possible, practically for the first time ever, for remote people to design together, in addition to working on a shared code base.

Future Uses

Here are some other things that the APIs make possible:

• Better webLogging tools.
• Threaded discussions that lead somewhere.

Resources

• Doug Engelbart's Bootstrap Institute: http://www.bootstrap.org/
• BlueOxen Collaboratories: http://www.blueoxen.org/
• NetBeans http://collab.netbeans.org
• Todd's Blog at http://www.toddFast.com
• What's Wrong with Email?: http://www.treelight.com/software/collaboration/whatsWrongWithEmail.html
• Jeff Conklin's CogNexus Institute: http://www.cognexus.org/