Open Stack

This text is in my vote, but as I'm sure there are people who do not
read all of the gerrit comments for governance changes, I'm posting it
here so that my thoughts are clear.

Please know that this has actually kept me up at night. I cast my vote
on this neither glibly or superficially. I have talked to everyone I can
possibly think of on the topic, and at the end, the only thing I can do
is use my judgment and vote to the best of my ability. I apologize from
the bottom of my heart to the people I find myself in disagreement with.
I have nothing but the utmost respect for you all.

I vote against allowing Go as an official language of OpenStack.

"The needs of the many outweigh the needs of the few, or the one"

I'm super unhappy about both possible votes here.

I think go is a wonderful language. I think hummingbird is a well
considered solution to a particular problem. I think that lack of
flexibility is broadly speaking not a problem we have in OpenStack
currently. I'm more worried about community cohesion in a post-Big Tent
world than I am about specific optimization.

I do not think that adding Go as a language to OpenStack today is enough
of a win to justify the cost, so I don't like accepting it.

I do not think that this should preclude serious thought about
OpenStack's technology underpinnings, so I don't like rejecting it.

"only a great fool would reach for what he was given..."

I think that one of OpenStack's biggest and most loudly spoken about
problems is too many per-project solutions and not enough holistic
solutions. Because of that, and the six years of experience we have
seeing where that gets us, I do not think that adding Go into the mix
and "seeing what happens" is going to cause anything other than chaos.

If we want to add Go, or any other language, into the mix for server
projects, I think it should be done with the intent that we are going to
do it because it's a markedly better choice across the board, that we
are going to rewrite literally everything, and I believe that we should
consider the cost associated with retraining 2000 developers as part of
considering that. Before you think that that's me throwing the baby out
with the bathwater...

In a previous comment, Deklan says:

"If Go was accepted as an officially supported language in the OpenStack
community, I'd be the first to start to rewrite as much code as possible
in Go."

That is, in fact, EXACTLY the concern. That rather than making progress
on OpenStack, we'll spend the next 4 years bikeshedding broadly about
which bits, if any, should be rewritten in Go. It took Juju YEARS to
rewrite from Python to Go and to hit feature parity. The size of that
codebase was much smaller and they even had a BDFL (which people keep
telling us makes things go quicker)

It could be argued that we could exercise consideration about which
things get rewritten in Go so as to avoid that, but I'm pretty sure that
would just mean that the only conversation the TC would have for the
next two years would be "should X be in Go or Python" - and we'd have
strong proponents from each project on each side of the argument.

David Goetz says "you aren’t doing the community any favors by deciding
for them how they do their jobs". I get that, and can respect that point
of view. However, for the most part, the negative feedback we get as
members of the TC is actually that we're too lax, not that we're too strict.

I know that it's a popular sentiment with some folks to say "let devs
use whatever tool they want to." However, that has never been our
approach with OpenStack. It has been suggested multiple times and
aligning on limited chosen tech has always been the thing we've chosen.
I tend to align in my personal thinking more with Dan McKinley in:

http://mcfunley.com/choose-boring-technology

I have effectively been arguing his point for as long as I've been
involved in OpenStack governance - although probably not as well as he
does. I don't see any reason to reverse myself now.

I'd rather see us focus energy on Python3, asyncio and its pluggable
event loops. The work in:

http://magic.io/blog/uvloop-blazing-fast-python-networking/

is a great indication in an actual apples-to-apples comparison of what
can be accomplished in python doing IO-bound activities by using modern
Python techniques. I think that comparing python2+eventlet to a fresh
rewrite in Go isn't 100% of the story. A TON of work has gone in to
Python that we're not taking advantage of because we're still supporting
Python2. So what I've love to see in the realm of comparative
experimentation is to see if the existing Python we already have can be
leveraged as we adopt newer and more modern things.

In summary, while I think that Go is a lovely language and the people
who work on it are lovely people, while I'm sure that hummingbird is
beneficial to the Cloud Files team in real ways and while I'm sure that
if we were starting OpenStack from scratch today the conversations about
how to do it might be different, I put a large value on the code and the
community we've built and I want any decisions that we make about things
as large as this to take the code, the people, the process and the
results into account.

That said, this is a democracy. I am but one vote, and I've been both
wrong and on the losing side of an opinion before. I've already
upstreamed changes to Go to make doing code in git.openstack.org more
pleasant. I think zuul-cloner needs to learn about go source code
organization regardless of the outcome of this decision. As always, I
will both abide by and whole-heartedly support the decision of the
democratically elected governance body, whether it matches my current
opinion on this extremely hard and non-straightforward question or not.
Although I know we're all fans of hyperbole around here, I certainly
hope that everyone else who is involved and who has voluntarily agreed
to be a part of this organization of humans with this mode of governance
will do the same. Democracy is easy when we all agree, the real work
comes when we don't get our way.

Monty