Replying to myself here, to avoid singling anyone in particular out. I
want to rephrase the question, because people are overwhelmingly either
failing to understand or refusing to answer it in the way I intended it.
Most of the candidates are essentially saying that the answer is 'everyone'.
I'm glad that we have such a bunch of next-level geniuses running for
the TC that they are able to analyse the needs of all 7 billion people
and evaluate every decision they make against all of them in real time.
Me, I'm just an ordinary guy who can only hold a few things in his head
at once, so I just try to focus on those and collaborate with people who
have different perspectives to make sure that a range of needs are
covered. This is kind of the founding principle of the Open Source
(note: not Free Software) movement, actually. None of us is as smart as
all of us (present company excepted, apparently). So it's good, but
somewhat surprising that y'all are still here, given that you would be
guaranteed insta-billionaires if you went out and started a proprietary
All sarcasm aside though, 'everyone' is a BS non-answer. It's the
Not only because engineering trade-offs are a real thing, and some use
cases will definitely be excluded in order to better serve others, but
because the average user doesn't exist. If you design for the 'average'
user then you are designing for nobody, because nobody is the average
user. We shouldn't be designing for 'everybody' (aka nobody in
particular), but for a large variety of somebodies.
As an example, look at the Keystone discussion that I linked below.
- If you were designing Keystone for an individual user, you'd might
just have one account per tenant.
- If you were designing Keystone for a team deploying semi-autonomous
apps, you might design a way for multiple agents to authenticate to each
- If you were designing Keystone for 'everyone', you might have a matrix
of users, tenants and roles - the most generic solution, right? - and
spend half a decade polishing it without ever realising that individual
users don't need it and teams can't use it.
One of these solutions works for both individuals and teams. The other
two only work for individuals. As an added bonus, one of those is also
expensive to develop and hard to operate. That's why we should design
for someones, not for 'everyone'. This is not a problem limited to
Keystone - throughout OpenStack we often fail to develop solutions that
can actually be used by the people whom we say we're building them for,
I'm not asking y'all to say that some group of end-users is unimportant
even though the question is trying to keep the bar extremely low by
asking about only one group. Nor am I asking y'all to say that operators
are unimportant, even though the question is explicitly NOT about
I'm asking if you can describe, to a modest level of detail, even one
end user persona for OpenStack that you're familiar enough with to be
comfortable advocating for on the TC.
So far the answer I'm hearing mostly translates as 'no'. (Props to the
folks who did actually answer though!) Does anybody want to try again?
On 12/10/17 12:51, Zane Bitter wrote:
In my head, I have a mental picture of who I'm building OpenStack for.
When I'm making design decisions I try to think about how it will affect
these hypothetical near-future users. By 'users' here I mean end-users,
the actual consumers of OpenStack APIs. What will it enable them to do?
What will they have to work around? I think we probably all do this, at
least subconsciously. (Free tip: try doing it consciously.)
So my question to the TC candidates (and incumbent TC members, or anyone
else, if they want to answer) is: what does the hypothetical OpenStack
user that is top-of-mind in your head look like? Who are you building
There's a description of mine in this email, as an example:
To be clear, for me at least there's only one wrong answer ("person who
needs somewhere to run their IRC bouncer"). What's important in my
opinion is that we have a bunch of people with different answers on
the TC, because I think that will lead to better discussion and
hopefully better decisions.
OpenStack Development Mailing List (not for usage questions)