Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!newstop!jaytee!witzend!db
From: db@witzend.East.Sun.COM (David Brownell)
Newsgroups: comp.groupware
Subject: why so little groupware?
Message-ID: <2997@jaytee.East.Sun.COM>
Date: 20 Oct 90 20:55:30 GMT
Sender: news@East.Sun.COM
Reply-To: db@witzend.east.sun.com (David Brownell, Network Dude)
Organization: Sun Microsystems, Billerica MA
Lines: 82

I'm curious why, with the good platform technology we have today, there's
so little software that could comfortably be called "groupware".  Let me
define my terms a little, and give what seems to me to be a partial
answer ... I'll really like to know if my impressions are shared, and
what I'm missing!


First, what's groupware?

(I meant to post this one a long time ago.  Ever since this group began
everone just _assumed_ there was a common definition!  So here's one version
of a definition; I expect there are changes to come, I have my asbestos on!)

I pretty much agree with Esther Dyson's comments at CSCW'90 that the word
reflects more of an underlying commonality of approaches than specific tools.
In my mind, those approaches include:

    -	Directly supporting groups _as well as_ individuals within them.

    -	Being an environmental feature, not a primary application.  (That
	relates to the above point:  individuals can use it to advantage,
	then there's benefit when more of them use it.)

    -	Supporting a variety of group work styles and policies, rather than
	being restricted to particular styles such as strong central control.

    -	Taking advantage of networked, or at least multi-user, environments
	to provide knowledge of the other group members.

    -	Letting groups define themselves through shared history, storage,
	messaging, and task definitions external to computer systems.

By this definition a lot of computer applications (as in, the problem the
software solves) are groupware:  multiuser tools built with a database like
Sybase or Ingres, system and network administration done with a variety of
operating systems, USENET and EMAIL, the mission-critical apps built by many
businesses, and so on.  These are rarely "neat" problems, or static ones.

The focus of "groupware" is applications, and on the sociological aspects of
people sharing computer usage.  Groupware is systems that include many people
as well as at least one computer; it's not just whizzy GUI tools.


Second, why so little groupware?

On one hand, there's a lot of it ... mainframes run multiuser applications,
some of the provided by third parties that need to support a variety of
customer usage policies.  That extends to departmental computers and so
on; what most of those don't have in common is running on the UNIX hosts
or networks that so many of us work with.  MIS groups traditionally had to
find out a lot about how their organizations worked, and improve them by
using computer technology that only recently could have all those "open
systems" benefits.

So why doesn't the current technical community (no longer trained exclusively
in IBM shops) produce such applications?  The best reason I have been able
to come up with is that building groupware requires collaboration between
(at least) two technical communities with very different goals:

    *	Software implementers understand the computer technology, and want
	to push technological systems.

    *	Social scientists understand the dynamics of a variety of groups,
	and want to study them further.

One disconnect here is that I rarely hear of applied social sciences (can
someone educate me?) that might use computer technology as a tool to affect
the operation of groups ... while I often hear studies about how technology
is used by groups, experiments on any scale are uncommon (or not presented
as such -- they're called "managerial mistakes" :-).

Another problem, with which I'm a little more familiar, is that implementors
of software don't want to deal with messy issues of group dynamics.  There
are tendancies both to oversimplify (claiming all user groups will work like
the development/testing group does, so only one control policy is needed) and
to add complexity because it's technically simple.

Maybe the simplest explanation is that it just takes time for lots of group
applications to be made available, and it won't happen just because there
are all these likely looking platforms around.

- Dave