“I promised to draft this last summer: I did, but did not see a good
opportunity to send it when people were listening (the battles of
last summer had died down by the time I drafted this), and then was out for
surgery. So here are some thoughts, I hope we can have a useful discussion.”
Subject:
Communications in Projects…
Date:
Tue, 4 Dec 2001 09:10:24 -0800 (PST)
From:
jg@pa.dec.com (Jim Gettys)
To:
gnome-hackers@gnome.org, foundation-list@gnome.org
Communications in Projects
As the size of projects increases, the need for discussion and communication
increases.
This is a direct consequence of scaling and interdependencies of projects.
Gnome itself has become a very large "umbrella" project, and itself depends
on other projects: e.g. GTK+, Linux, XFree86, various libraries, etc.
Similarly, different parts of the Gnome project itself are more or less
dependent on each other. So we have certain core libraries, that effectively
everyone depends on, Bonobo, which we'd like more applications to use
(and therefore depend on), and so on.
For example, we all depend on stability/progress in GTK+ (and the underlying
X Window System).
There are some inferences we can draw:
1) some interfaces become involate with time. For example, the X Window
System has provided absolute upward compatibility since 1988
(approaching 14 years now).
I think people all agree that we'd be shooting ourselves in the
feet to make incompatible changes here (to use an example that does not
pick on any Gnome technology).
Technologies in this catagory can only move upward in compatible ways:
recent X examples of compatible change are the Render and RandR extensions.
Network protocols are hardest to change, as you have no control
over the other endpoints, and the value is precisely the ability
to interoperate. And this can be frustrating, as you really get
to live with and appreciate your mistakes :-(. And down-revision
network services provide a challenge to interoperability.
2) some interfaces can be versioned (and things successfully coexist
simultaneously. For example, there are multiple versions of Xt, and GTK
in the world, and things can/do work. But among a single major version,
version, similar compatibility constraints to 1) exist.
3) some technologies allow for multiple co-existing environments,
for example, language environments. Programmers vote with their feet,
and it is healthy for there to be competing projects. Inside such
a technological island, 1, and 2, still apply.
Ok, what does this say about components of the Gnome project?
o The consequence of successful components (libraries, embeddable
applications) is that more and more people use them.
o The consequences of this success is that incompatibilities/changes
affect many more people, so change is much harder.
o As things succeed, there is a natural progression to 2), and sometimes
to the 1) endstate (if competing technologies are not possible: as ESR
has pointed out, some technological winners are "winners take all".
This has implications on our own behaviors:
o if you work on a part of the gnome project (e.g. many applications)
that no one else depends on, you can be your own little "god".
If people don't like your behavior, they'll build a replacement. Little
communications of your plans are needed or required (though I'd still
strongly recommend such behavior if you want anyone else to help you!).
The project as a whole does not suffer if you are as secretive as you
like (though end users may not like you!).
Note, however, that many projects need to grow beyond what a very
small project with such autonomy can handle. Natural selection
effects are very strong in open source projects, and your prima
donna project is likely to be supplanted by others if you behave
this way. Selection is as often on personalities and behavior as
on technical merit!
o if you work on a library or component others depend on, you have
a responsibility that increases with your success to gather input,
get feedback, communicate plans, etc. This is particularly critical whenever
incompatible changes are needed/planned, as this generates work for others,
and their buy in is essentially required for your (and the project's)
success. Projects can live or die on their ability to handle change.
o if development of key technology is mostly done in a small
teams, particularly when commercially supported, much paranoia can
be avoided by good communications of plans, enhancements
and changes (particularly incompatible ones that affect other
projects). Recommendation: do all your development on open
mailing lists, reserving a infrequently used list for proprietary,
commercial discussions. If you already have heavily used internal
only mailing lists, habits die hard, so turn them off and reestablish
public lists to force this separation, or your developers won't
bother to switch.
This is not only true for commercial companies: for what
seemed like good reasons years ago, XFree86 behaved much as a closed
group for years, and I think most people in Gnome appreciate
the fact that they've opened up. Arrange your lives to minimize
the "secret" communications necessary. The needs are real, but we
should avoid as much as we can such secrecy: when unnecessary,
it is poisonous to open source projects.
o make incompatible changes as early as possible in major versions,
to give time for down stream changes to percolate through: human
communication takes time! And taking responsibility to identify
who is likely to be impacted, and how much, is in order. This
homework should reduce the anguish of releases.
o if you are working on a "winner take all" part of gnome, your
responsibilities for stability and careful compatible evolution
is paramount, and good communications becomes absolutely vital.
If you don't like that responsibility (and the constraints and work
it imposes), working elsewhere in the project is probably wise.
o and being civil to each other really helps the communications,
along with an attitude of "do not attribute to malice what can be
attributed to incompetance". Lets all treat ourselves well,
and avoid "ad hominem" attacks. Don't presume bad motives of people:
more commonly they have good reasons, or just blew it entirely!
I hope this sparks serious discussion.
- Jim
--
Jim Gettys
Technology and Corporate Development
Compaq Computer Corporation
jg@pa.dec.com
