Open Stack

> On May 24, 2016, at 12:09 PM, Mike Perez <thingee at gmail.com> wrote:
> 
> On 12:24 May 24, Thierry Carrez wrote:
>> Morgan Fainberg wrote:
>>> [...]  If we are accepting golang, I want it to be clearly
>>> documented that the expectation is it is used exclusively where there is
>>> a demonstrable case (such as with swift) and not a carte blanche to use
>>> it wherever-you-please.
>>> 
>>> I want this to be a social contract looked at and enforced by the
>>> community, not special permissions that are granted by the TC (I don't
>>> want the TC to need to step in an approve every single use case of
>>> golang, or javascript ...). It's bottlenecking back to the TC for
>>> special permissions or inclusion (see reasons for the dissolution of the
>>> "integrated release").
>>> 
>>> This isn't strictly an all or nothing case, this is a "how would we
>>> enforce this?" type deal. Lean on infra to enforce that only projects
>>> with the golang-is-ok-here tag are allowed to use it? I don't want
>>> people to write their APIs in javascript (and node.js) nor in golang. I
>>> would like to see most of the work continue with python as the primary
>>> language. I just think it's unreasonable to lock tools behind a gate
>>> that is stronger than the social / community contract (and outlined in
>>> the resolution including X language).
>> 
>> +1
>> 
>> I'd prefer if we didn't have to special-case anyone, and we could come up
>> with general rules that every OpenStack project follows. Any other solution
>> is an administrative nightmare and a source of tension between projects (why
>> are they special and not me).
> 
> I'm in agreement that I don't want to see the TC enforcing this. In fact as
> Thierry has said, lets not special case anyone.
> 
> As soon as a special case is accepted, as nortoriously happens people are going
> to go in a corner and rewrite things in Go. They will be upset later for not
> communicating well on their intentions upfront, and the TC or a few strongly
> opinionated folks in the community are going to be made the bad people just
> about every time.
> 
> Community enforcing or not, I predict this to get out of hand and it's going to
> create more community divide regardless.

I remember in 2010, our founding intent was to converge on two languages for OpenStack Development: Python and C. We would prefer Python for things like control plane API services, and when needed for performance or other reasons, we would use C as an alternative. To my knowledge, since then nothing was ever written in C. We have a clear trend of high performance alternative solutions showing up in Golang. So, I suggest we go back to the original intent that we build things in Python as our preference, and allow teams to select a designated alternative when they have their own reasons to do that. I see no reason why that designated alternative can not be Golang[1].

Programming syles and languages evolve over time. Otherwise we’d all still be using FORTRAN from 1954. OpenStack, as a community needs to have a deliberate plan for how to track such evolution. Digging our heels in with a Python only attitude is not progressive enough. Giving choice of any option under the sun is not practical. We will strike a balance. Recognize that evolution requires duplication. There must be overlap (wasted effort maintaining common code in multiple languages) in order to allow evolution. This overlap is healthy. We don’t need our TC to decide when a project should be allowed to use a designated alternative. Set rules that allow for innovation, and then let projects decide on their own within such guidelines.

My proposal:

"Openstack projects shall use Python as the preferred programming language. Golang may be used as an alternative if the project leadership decides it is justified."

Additional (non-regulatory) guidance can also be offered by the OpenStack community to indicate when individual projects should decide to use an alternative language. In the future as we notice evolution around us, we may add other alternatives to that list.

Thanks,

Adrian

[1] I categorically reject the previous rhetoric that casts Golang as a premature language that we can’t rely on. That’s FUD, plain and simple. Stop it.