Open Stack

Excerpts from Melvin Hillsman's message of 2017-07-16 11:51:21 -0500:
> Observation: One typical concern voiced regarding a requirement from a
> working group/team, organization, deployer, end-user, etc is that there are
> no guarantees for requirements to even be considered let alone being
> implemented. Comments regarding this generally center around developers
> will work on what they are paid to work on. This assumes something that may
> be pushing more folks away at times and that is a) we have a paywall or
> pay-to-play model, b) we do not/have not had any folks contributing out of
> the spirit of open-source, and c) if you are a small IT shop you have no
> chance of being heard.
> 
> Question: What "safeguards" are in place to ensure SIGs are not going to go
> down this same path?
> 
> Suggestion(s): I have heard a couple of things which may help but primarily
> I wanted to get the conversation started. Here is one, require cross-SIG
> and non-cross-SIG proposals to be prioritized and at least one
> blueprint/proposal be put in a cycle, granted it has gone through
> appropriate vetting, per project?
> 

That's not really how open source works, though.

Open source contributors are expected to work on what interests
them.  Saying that if someone has an idea, other people are required
to work on it turns the user/contributor relationship from one of
collaboration to one of customer/vendor.  If we use SIGs as a way
to encourage people to make demands without also contributing they're
going to fail. We need to use this reorganization opportunity to
move away from that type of thinking.

For one thing, the economics just don't work. Calling it pay-to-play
attaches a negative connotation, but the reality is the work that
gets done is the work that people are both incentivized and allowed
to work on. Contributors may want to work on features, but not be
allowed. They may have free rein to choose their own tasks, but not
be interested in a particular problem.

The other problem with a command-and-control approach is that it
perpetuates the artificial separation of users and contributors.
"Tell them to do it" implies there is some group who knows best
what needs to be done, and that everything would be just fine if
the contributors lined up and did what they were told. The power
of open source is having all sorts of input into the process of
deciding what is important.

If we really want to solve the problem of "unanswered requirements,"
we need to look at them case by case. Because I think "unanswered"
is not always an accurate moniker. My guess is that in a lot of
cases, there was an answer that people just didn't like. We need
to actually look at the history to understand what is happening,
as I did with the logging improvements this cycle.

Some questions that come to mind:

Why are people coming with "requirements" but without contributors
to work on those things in the first place? Are they really
"requirements" in all cases? Or are they "wants"? If they are "wants"
with a niche audience, is it really appropriate for the community
to place a priority on them?

Sometimes a person will have a great idea but no resources to
implement it. Do we have cases where the community picked up those
ideas? Or didn't? Why were the cases different?

Do we have recent cases where contributors showed up to work on
something and were given a flat "no" response? What reason was
given? I'm sure we can find lots of cases where contributions were
accepted. What differences can we find?

Do we have recent cases where folks reported issues that truly went
unanswered? Was the answer "we have to finish this other task first"?
Or "we won't have time this cycle, but we can work on that for the
next cycle?" Or "that is a bad idea, for reason X"? Or something
else?

Let's look into the individual cases before we start trying to make
rules. A path that has some people telling other people what to
work on, instead of agreeing about what to work on together, isn't
going to set us up for long term success.

Doug