Open Stack

On 16/01/19 4:30 AM, Jeremy Stanley wrote:
> On 2019-01-15 11:01:09 +0000 (+0000), Chris Dent wrote:
> [...]
>> Then I implied that the TC cannot do anything like actionable and
>> unified technical leadership because they have little to no real
>> executive power and what power they do have (for example, trying to
>> make openstack-wide goals) is in conflict (because of the limits of
>> time and space) with the goals that PTLs (and others) are trying to
>> enact.
> [...]
> 
> Maybe I'm reading between the lines too much, but are you thinking
> that PTLs have any more executive power than TC members? At least my
> experience as a former PTL and discussions I've had with other PTLs
> suggest that the position is more to do with surfacing information
> about what the team is working on and helping coordinate efforts,
> not deciding what the team will work on. PTLs (and TC members, and
> anyone in the community for that matter) can direct where they spend
> their own time, and can also suggest to others where time might be
> better spent, but other than the ability to prevent work from being
> accepted (for example, by removing core reviewers who review
> non-priority changes) there's not really much "executive power"
> wielded by a PTL to decide on a project's direction, only influence
> (usually influence gained by seeking consensus and not attempting to
> assert team direction by fiat decree).

This seems like a good lead in to the feedback I have on the current 
role-of-the-TC document (which I already touched on in the review: 
https://review.openstack.org/622400). This discussion (which we've had 
many times in many forms) always drives me bananas, and here's why:

It is *NOT* about "executive power"!

Think of it this way. If you drop a bunch of humans in a field in the 
middle of nowhere, the chances of them arriving together at some 
destination - any destination! - are approximately zero in the absence 
of some co-ordination. This is true even if you assume they all have the 
same destination in mind, which is already pretty unlikely.

The minimum requirements for success would appear to be:

1) One or more people to stand up and say "I think we should go this 
way" and explain why;
2) A reason for each person to expect that everybody else is going to go 
in the same direction; and
3) When the going gets tough, a sense within each individual that they 
were part of making the decisions, even when they don't agree with them.

In short: leadership.

But not "executive power"! In fact, executive power is to be avoided, 
because exercise of executive power is inimical to #3.

Where the action is at is #2. Generating #2 is the meatspace equivalent 
of the Byzantine Generals problem in computer science. It's a hard 
problem, but a problem to which we have instinctively known the solution 
for a long time (long before it was solved in computer science, even 
though it's essentially the same solution): you somehow bootstrap a 
positive feedback loop in which confidence begets confidence.

In OpenStack we choose to bootstrap it by using elections. People 
generally expect other people to follow the elected leaders because they 
believe that those other people voted for them, which at least in the 
aggregate is true. Other projects have chosen the BDFL model, which is 
inherently unsustainable as I believe the recent experiences of the 
Python community have shown. I think we made the right choice.

But, having elected a group of folks to the TC - the only body that is 
elected by the community as a whole, and therefore the only folks that 
can set the direction of the project as a whole - what do we then say?

"Well, we can't tell anybody what to do, so we have no choice but to 
just leave 'em in this field and hope for the best."

Friends, I have feelings about this, but propriety precludes me from 
expressing them fully here. You're welcome to ask me about it some time. 
Suffice it to say that I believe this is a false dichotomy.

Note that we don't need the TC to supply #1. But nobody else can supply 
#2. For these purposes you can think of "governance" - the stuff that 
the TC does consistently do - as being the guardian of the process that 
ensures #3.

The false dichotomy does not appear to exist at the level of individual 
projects, and IMHO the result is kind of what you'd expect: a bunch of 
projects that are individually successful but that struggle to cohere 
together.

Positive feedback loops are a funny thing: they're inherently unstable, 
so sometimes it doesn't take much to make them runaway in the wrong 
direction. Confidence begets confidence, but disappointment begets 
disappointment. (That's why e.g. I'm opposed to project-wide goals where 
we expect from the outset at least one project to fail to complete it in 
a single release cycle.) It is to this - the fact that the TC does not 
have a great track record of convincing the community to all move in one 
direction - that I would attribute the substantial group of people who 
are, as Chris says, simply tired of this sort of navel-gazing. I'm sure 
those folks would say that we should just stop trying. I think the 
actual solution is to start succeeding. It remains to be seen who is right.

cheers,
Zane.