[Gdbheads] Trust

[Stan Shebs]

I've been pondering a while just what it is that people are really
unhappy about, and I think the deepest underlying problem is a lack of
trust. You see it in the desire to have private meetings, in the
accusations about cabals, attempts at public censure, and so forth.

Why wouldn't we all trust each other? Aren't we all on the same side?
I think we are, but sometimes a person might not see it that way.  For
instance, a free software ideologue might see dark designs in the work
that Apple or IBM or Red Hat supports. Indeed, company management
tends to view GNU work in terms of "what is the minimum we have to do
to get stuff for free", and will pressure employees accordingly.
Similarly, an adherent of one platform, say BSD, might suspect that
GNU/Linux folks will try to twist GDB into only being a debugger for
one platform.

However, I think it's a safe assumption that all GDB maintainers are
fundamentally honest; that despite pressures from employers, users,
etc, to do wrong things, that we're able to resist those pressures and
deal straightforwardly with each other. As far as I know, no one has
ever deliberately lied about the purpose or consequences of a change
to the code, so there's no empirical evidence that any suspicions are
justified. (Right? :-) )

So where does all this lack of trust come from? Well, I suspect there
is some internal politics at Red Hat, so that while the engineers are
honest, their management *is* telling lies about projects or
priorities whatever, and that puts the engineers in a tough spot.
Some of it I know is history; some of the suspicions I've heard
expressed recently have their origins in Cygnus days, when as mgmt I
got to witness some of the lying firsthand, and saw the corrosive
effect it had on engineers. Especially for persons prone to feelings
of insecurity or self-doubt, the scars last a long time. Some lack of
trust comes from personality; some people just naturally tend to be
suspicious and distrustful of others.

Another thing that diminishes trust is not doing what one has promised
to do. This happens a lot because of the nature of our project; we're
sincere in our desire to help to make it a success, and see that it
won't move forward without our direct participation, so we commit
ourselves to more work than we can realistically accomplish. While
some people will feel that overpromising is as bad as a deliberate
lie, I hope we generally agree that the zeal is a good thing, that the
intentions are honorable, and that we want to temper the enthusiasm
rather than to attack the overpromiser.

There's more to say about levels of trust at a technical level and how
it drives our process, but I'll save that for another message.  For
now, I'd like everybody to ask themselves one question:

   Do you trust the other GDB maintainers?

For myself, I'll answer "yes, completely" for the global
maintainers. I think any one of them could take over all of the GDB
work tomorrow and make a success of it. My trust in the write after
approval folks is variable, since some of them I know well and trust a
lot, while others are unfamiliar to me.

So everybody should think about who they really trust. If you're
perennially suspicious of other GDB maintainers, no amount of process
tinkering is going to help; you're always going to be worrying about
how this patch or that idea is going to sabotage the whole project, or
about what might be going on behind your back. That in turn will make
all of your interactions difficult, since you're not going to want to
be helpful, and will instead be thinking about ways to get the person
to go away from working on GDB.

GDB maintenance will become impossible if the maintainers don't trust
each other.

Stan