Distributed development is a way of life anymore, especially for an open source project. But remote collaboration has been an essentially unsolved problem, most notably when it comes to specification and design. The upcoming release of NetBeans promises to tackle that problem in a very big way--and you'll benefit, even if you don't use NetBeans.
They're saying that the upcoming NetBeans 4.1 is not your father's NetBeans. So
far, that assessment looks to be dead on target. There are plenty of new
features to write about, including a better layout manager, a GUI design tool,
ANT-based builds, and great tools for testing and debugging server-side apps
as well as client apps.
The guiding principle in all this appears to be "things just work". The
tools are doing all the complicated wiring and keeping it hidden behind
the walls, so you can focus your attention on the problem you're trying
One of the major advances along those lines is the ability to collaborate
with remote developers from within the NetBeans session, from a standalone
tool that will part of the release, or eventually, from your favorite IDE
--because it will be collab-enabled using the brilliant API standard and
implementation libraries the collaboration project is providing.
The presentation on all these wonderful new tools was given by Todd Fast.
But before I get to the details of the technology, let me motivate the discussion
with a little story. That's in the next section. (You can skip if it you want
to go directly to the main course and never mind the entree, thank you very
much.) In outline, the story and the ensuing article go pretty much like
People who need to work remotely are the ones most interested in
solving the distributed-collaboration problem.
Because they're remote, it's a hard problem for them to solve.
The new offering coming from NetBeans not only provides an initial
tool set to make it possible, the APIs it delivers makes it almost
absurdly easy to collab-enable virtually any application you
have--because, once again, the wiring is kept hidden so you can
focus on the problem you're trying to solve.
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
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.
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
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
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.
Dragging files, directories, or entire projects into the file sharing
window makes them available to everyone. Each participant gets a copy of
the file, so they're editing locally instead of remotely. While they're
editing, the file is locked. It can be read, but not written.
Remote particpants can also build the system. The build occurs on the
originating system , so that system needs to be fast, and the
participants will have to talk to each other.
You can drag shared files onto the local system to do your own local
builds, but in that case you'll have to drag the modified versions back
into the system to share the changes. Also, the system it isn't integrated
with a source control system. (It's not perfect. But it's taking a
major step down the right road. More importantly, it's providing the
basic tools we need to build bigger and better systems.)
The chat window automatically recognizes Java code, HTML, and a
variety of other languuages. So it does syntax highlighting and peforms
code-completion, for example, so you can either paste existing code
or write new code in the chat window.
The system also adds line numbers so you can talk about line 46, for example,
instead of having to say "the 2nd if-statment in the hoozit method".
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.
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.)
Define a unique namespace to use in the XML messages.
Define a string constant (finalString) 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:
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.
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.
A server-based weblogging like the one provided at Artima has the advantage
that you can access it from anywhere--which turns out to be pretty
convenient when you're covering a convention like this.
On the other hand, if a session times out you lose your recent work. That's
somewhat less convenient. With this API, a simple editor could be collab-enabled,
and possbily delivered with Java Web Start. Voila! A real editor that runs
anywhere, with a simple Ctrl-S command to save work in progress to the server.
Email discussions reach their conclusions down at the bottom of
the thread, somewhere. That makes them hard to find. What you really want is
for the decisions to propogate to the top of the thread list, with a pointer
back to the discussion that got you there. (For more on that subject, see
What's Wrong with Email? at
The need to repeat parts of a message to comment on them creates redundancy.
What's really needed is a 3-dimensional hierarchy, with the original author's
outline in the 2-dimensional plane on screen, and a hierarchy of comments
extended into the 3rd dimension.
Weblogs provide a communication channel that solves some of email's problems,
but it's essentially one-way. People can comment, but it's hard to have a real
The collaboration APIs raise the interesting possibility of using a discussion
management tool that helps a facilitor keep track of a discussion (such as the
tool developed by Jeff Conklin at the CogNexus Institute, http://www.cognexus.org/).
By collab-enabling such a tool, peoiple involved in a remote conversation can
carry on their discussion within the context of a tool that tracks the results.