Open Stack

I wish it was so simple. Its not.

There is a good coding practice:
"The code is done, not when there is nothing more to add, but nothing more to remove"

Some of the more mature projects are in this mode of thinking now. (which is mostly good, really). They don't want to add features unless they see it as a benefit to their users. This is the problem, there is a disconnect between the view of Project X's users, and greater view of OpenStack Users.

Even accepting the smallest of patches to work towards the goal is unacceptable to projects if they believe it is not a helpful feature to their perceived user base, or helpful enough to them to justify adding more code to their project. Or the feeling that "just push it to a new project or a different one is better". This fractured view of OpenStack users at the project level is preventing progress on OpenStack as a whole.

Only an overarching Architectural group with some power to define what a user is, or the TC can address those sorts of issues.

Thanks,
Kevin
________________________________________
From: James Bottomley [James.Bottomley at HansenPartnership.com]
Sent: Wednesday, July 20, 2016 9:57 AM
To: OpenStack Development Mailing List (not for usage questions); Clint Byrum
Subject: Re: [openstack-dev] [tc][all] Big tent? (Related to Plugins for all)

On Wed, 2016-07-20 at 16:08 +0000, Fox, Kevin M wrote:
> +1 to the finding of a middle ground.

Thanks ... I have actually been an enterprise architect (I just keep
very quiet about it when talking Open Source).

> The problem I've seen with your suggested OpenSource solution is the
> current social monetary system of OpenStack makes it extremely
> difficult.
>
> Each project currently prints its own currency. Reviews. It takes
> quite a few Reviews (time/effort) on a project to gain enough
> currency that you get payed attention to. And, one project doesn't
> honor another projects currency.

OK, I accept your analogy, even though I would view currency as the
will to create and push patches.

The problem you describe: getting the recipients to listen and accept
your patches, is also a common one.  The first essential is simple
minimal patches because they're hard to reject.

Once you've overcome the reject barrier, there's the indifference one
(no-one says no, but no-one says yes).

Overcoming indifference involves partly knowing who to bother and when
(In openstack, it's quite easy since you know who the core reviewers
are) and also building a consensus for the patch; usually this involves
finding other people who need the feature and getting them to pipe up
(if you can't find other projects, then you can get potential users to
do this) even better if they help you write the patches.  Ideally, you
build your consensus before you actually push the patch set.  Sometimes
building consensus involves looking beyond your particular need to a
bigger one that would satisfy you but also pulls other people in.

> When these sorts of major cross project things need to be done
> though, you need to have folks with capital in many different
> projects and its very difficult to amass that much.
>
> There is no OpenStack level currency (other then being elected as a
> TC member) that gets one project to stop and take the time to
> carefully consider what someone is saying when bringing up cross
> project issues.
>
> Without some shared currency, then the problem becomes, the person
> invested in getting a solution, can propose and prototype and
> implement the feature all they want (often several times), but it
> never actually is accepted into the projects because a project:
>  a) doesn't take the time to really understand the problem, feeling
> its trivial and just not accepting any reviews
>  b) doesn't take the time to really understand the problem, so
> minimize it in their mind to a 'you should just use existing thing
> X...' or a heavy handily propose alternate solutions that really
> aren't solutions.
>  c) they decide its better handled by another project and stall/block
> reviews, trying to push the implementation to go elsewhere. When
> multiple projects decide this, the ball just keeps getting bounced
> around without any solution for years.
>
> The status quo is not working here. The current governance structure
> doesn't support progress.

What you'll find you've described above is a process that doesn't
support drive by coders at all and, by extension therefore, doesn't
welcome newcomers, which is a big problem, but one I thought OpenStack
was tackling?

The bounce problem is annoying but not insuperable.  It mostly occurs
where there's overlap.  Often the best method for coping is to field
the bounce: produce the patch for the other project.  If it's smaller
and neater, perhaps the bounce was correct.  If it's bigger and uglier,
get the other project to say so and you now have a solid reason to go
back and say "we tried what you suggested and here's why it didn't
work".  Morally, you're now on higher ground because incorrect
technical advice is a personal failure for whoever bounced you (make
sure to capitalise on it if they try another bounce).

James


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev