Open Stack

On Wed, 4 Sep 2019, Doug Hellmann wrote:

> I would take this a step further, and remind everyone in
> leadership positions that your job is not to do things *for*
> anyone, but to enable others to do things *for themselves*. Open
> source is based on collaboration, and ensuring there is a healthy
> space for that collaboration is your responsibility. You are
> neither a free workforce nor a charity. By all means, you should
> help people to achieve their goals in a reasonable way by reducing
> barriers, simplifying processes, and making tools reusable. But do
> not for a minute believe that you have to do it all for them, even
> if you think they have a great idea. Make sure you say “yes, you
> should do that” more often than “yes, I will do that."

This is very true, but I think it underestimates the many different
forces that are involved in "doing work in OpenStack". These are, of
course, very different from person to person, but I've got some
observations (of course I do, everyone should). I suspect some of
these are unique to my experience, but I suspect some of them are
not. It would be useful (to me at least) to know where some of us
have had similar experiences.

Most people work on OpenStack because it is their job or is closely
related to their job. But because it is "open source" and "a
community" and "collaborative" doing what people ask for and helping
others achieve what they need is but one small piece of the
motivation and action calculus.

Making "it" (various things: code, community, product, experiences
of various kinds) "better" (again, very subjective and
multi-dimensional) is very complicated.

And it is further complicated by the roadblocks that can come up in
the community. In the other thread that started this Sean said:

     the reason that the investment that was been made was reducing
     was not driven by the lack of hype but by how slow adding some
     feature that really mattered [1]

One aspect of burn out comes from the combination of weathering
these roadblocks and having a kind of optimism that says "I can,
somehow change this or overcome this."

Another is simply a dedication to quality, no matter the obstacles.
This is tightly coupled with Sean's comments above. Improving the
"developer experience" is rarely a priority and gets pushed on the
back burner unless you dedicate the time to being core or PTL, which
grants some license to "getting code merged". For some projects that
is a _huge_ undertaking.

My relatively good success at overcoming the obstacles but limited
(that is, constrained to a small domain) at changing the root causes
is why I'm now advocating chilling out. This is risky because the
latency between code and related work done now and any feedback is
insanely high. The improvements we've made recently to placement
won't be in common use for 6 months to 3 years, depending on how we
measure "common". Detaching or chilling out now doesn't have an
impact for some time.

That feedback latency also means figuring out what "better" or
"quality" mean for a project is a guessing game.

Making cycles longer will make that worse.

A year ago when we started extracting placement I tried to make real
the idea that full time cores should rarely write feature code and
primarily be involved in helping "people to achieve their goals in
a reasonable way by reducing  barriers, simplifying processes, and
making tools reusable". This only sort of worked. There were issues:

* There were feature goals, but few people to do the work.

* Our (OpenStack's) long term standards for what is or is not a
   barrier, good process and tooling are historically so low that
   bring them up to spec requires a vast amount of work.

To me, the Placement changes made in Train were needed so that
Placement could make a respectable claim to being "good". 75% of the
changes (counting by commit) were made by 4 people. 43% by one. [2]

The large amount of time required to be core, PTL or "get their code
merged pretty easily" (in some projects) is a big portion of any job
and given the contraction of interest in the community (but not in
the product) from plenty of companies, there is lurking fear that
the luxury of making that commitment, of being a "unicorn 100%
upstream", will go away at any time. This increases the need to do all
those "make it better" things _now_.

Which, obviously, is a trap, and people who feel like that would be
better off if they chilled out, but I would guess that people who
feel that way do so because making it better (whatever it is) is
important in and of itself. Especially when the lack of commitment
from enterprises is waning: they don't care, so I must, because I
care.

In other projects, there's simply no one there to become core or a
reluctance to get into leadership because it is perceived to be too
time consuming (because for many people in leadership, the time
consumption is very visible).

Similarly, when there's a sense of waning interest, the guessing
game described above for determining what matters is pressurized.
"If I get this wrong, the risk of our irrelevance or even demise is
increased, don't mess this up!".

Also a trap.

But both traps are compelling.

I think we need to investigate changing our governance and
leadership structures. We should have evolved away from them, but we
haven't because power always strives to maintain itself even when it
is no longer fit for purpose. TC, PTL, Core and even "projects" all
need rigorous review and reconsideration to see if they are really
supporting us ("us" in this case is "the people who make OpenStack")
the way they should.

If we are unable or unwilling to do that, then we need to enforce
"contributing" enterprises to contribute sufficient resources to prop
up the old power structures. [3]

[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009123.html

[2] That is, assuming stackalytics is correct today, it often isn't.

[3] Perversely, I think this option (companies paying up) is the
fundamentally right one from an economic standpoint, but that is
because I don't believe that OpenStack is (currently and through the
peak of its history) open source. It is collaborative
inter-enterprise development that allows large companies to have a
market in which they make a load of money. That takes money and
people. If OpenStack were simpler and more contained and tried less
hard to satisfy everyone, it could operate as an underlay (much like
Linux) to some other market but for now it is the market.

The pains we are having now may be the signs of a need for a shift
to being an underlay (k8s and others are the new keen market now).
If that's the case we can accelerate that shift by narrowing what we
do. Trimming the fat. Making OpenStack much more turnkey with far
fewer choices.

But again, the current batch of engaged enterprises have not shown
signs of wanting that narrowing. So they either need to change what
they want or cough up the resources to support what they want in a
healthy fashion.

What we should do is strive to be healthy, whatever else happens.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent