Open Stack

There have been plenty of cross project goals set forth from the TC and implemented by the various projects such as wsgi or python3. Those have been worked on by each of the projects in priority to some project specific goals by devs interested in bettering OpenStack. Why is it so hard to believe if the TC gave out a request for a grander user/ops supporting feature, that the community wouldn't step up? PTL's are supposed to be neutral to vendor specific issues and work for the betterment of the Project.

I don't buy the complexity argument either. Other non OpenStack projects are implementing similar functionality with far less complexity. I attribute a lot of that to difference in governence. Through governence we've made hard things much harder. They can't be fixed until the governence issues are fixed first I think.

Thanks,
Kevin
________________________________________
From: Jeremy Stanley [fungi at yuggoth.org]
Sent: Tuesday, August 21, 2018 4:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

On 2018-08-21 22:42:45 +0000 (+0000), Fox, Kevin M wrote:
[...]
> Yes, I realize shared storage was Cinders priority and Nova's now
> way behind in implementing it. so it is kind of a priority to get
> it done. Just using it as an example though in the bigger context.
>
> Having operators approach individual projects stating their needs,
> and then having the individual projects fight it out for
> priorities isn't a good plan. The priorities should be prioritized
> at a higher level then projects so the operators/users needs can
> be seen in a global light, not just filtered though each projects
> views of things.
>
> Yes, some folks volunteer to work on the things that they want to
> work on. Thats great. But some folks volunteer to work on
> priorities to help users/operators in general. Getting clear,
> unbiased priorities for them is really important.
[...]

I remain unconvinced that if someone (the TC, the OSF board, the now
defunct product management nee hidden influencers working group)
declared for example that secrets management was a higher priority
than shared storage, that any significant number of people who could
work on the latter would work on the former instead.

The TC has enough trouble getting developers in different projects
to cooperate on more than a couple of prioritized cross-project
goals per cycle. The OSF board has repeatedly shown its members are
rarely in the positions within member companies that they have any
influence over what upstream features/projects those companies work
on. The product management working group thought they had that
influence over the companies in which they worked, but were
similarly unable to find developers who could make progress toward
their identified goals.

OpenStack is an extremely complex (arguably too complex) combination
of software, for which there are necessarily people with very strong
understanding of very specific pieces and at best a loose
understanding of the whole. In contrast, there are few people who
have both the background and interest (much less leeway from their
employers in the case of paid contributors) to work on any random
feature of any random project and be quickly effective at it. If
you're familiar with, say, Linux kernel development, you see very
much the same sort of specialization with developers who are
familiar with specific kernel subsystems and vanishingly few who can
efficiently (that is to say without investing lots of time to come
up to speed) implement novel features in multiple unrelated
subsystems.

We'll all continue to work on get better at this, but hard things
are... well... hard.
--
Jeremy Stanley