Open Stack

Hi everyone,

The discussion on the addition of golang focuses on estimating community 
costs vs. technical benefits, so that the TC can make the right call for 
"OpenStack". From that discussion, we established that the costs for 
cross-project teams (Infra...) seem to be workable. There is still 
significant community fragmentation effects as we add another language, 
creating language-expert silos, duplicating efforts, and losing some 
productivity as some needlessly rewrite things in golang. But we seem 
generally ready to accept that cost because we are missing a tool in our 
toolbelt: a language that lets us do such native optimization.

We have a number of projects in OpenStack that are more low-level than 
others and which require such optimization, and for those projects (or 
subprojects) our current mix of language is not satisfactory. The Swift 
team in particular has spent a lot of time trying to get the I/O 
behavior they require with hard disk access using Python, and they 
certainly did not jump on the golang bandwagon lightly.

I believe the programming languages you need in OpenStack official 
projects are a function of the scope you define for OpenStack official 
projects. We wouldn't need to have JavaScript in the mix if we 
considered that web interfaces that purely consume OpenStack APIs are 
projects that consume OpenStack, rather than part of OpenStack itself.

In the same vein, if we consider lower-level projects (which often 
require such native optimization) as part of "OpenStack", rather than as 
external open source projects that should be integrated by "OpenStack", 
then we need a language like golang in our toolbelt. There is basically 
no point in saying no to golang in OpenStack if we need lower-level 
native optimization in OpenStack: we'll have to accept the community 
cost that comes with such a community scope.

So the real question we need to answer is... where does OpenStack stop, 
and where does the wider open source community start ? If OpenStack is 
purely an "integration engine", glue code for other lower-level 
technologies like hypervisors, databases, or distributed block storage, 
then the scope is limited, Python should be plenty enough, and we don't 
need to fragment our community. If OpenStack is "whatever it takes to 
reach our mission", then yes we need to add one language to cover 
lower-level/native optimization, because we'll need that... and we need 
to accept the community cost as a consequence of that scope choice. 
Those are the only two options on the table.

I'm actually not sure what is the best answer. But I'm convinced we, as 
a community, need to have a clear answer to that. We've been avoiding 
that clear answer until now, creating tension between the advocates of 
an ASF-like collection of tools and the advocates of a 
tighter-integrated "openstack" product. We have created silos and 
specialized areas as we got into the business of developing time-series 
databases or SDNs. As a result, it's not "one community" anymore. Should 
we further encourage that, or should we focus on what the core of our 
mission is, what we have in common, this integration engine that binds 
all those other open source projects into one programmable 
infrastructure solution ?

-- 
Thierry Carrez (ttx)