Open Stack

Excerpts from Geoff O'Callaghan's message of 2016-05-24 14:34:46 +1000:
> 
> > On 24 May 2016, at 2:04 PM, Clint Byrum <clint at fewbar.com> wrote:
> > 
> > Excerpts from Geoff O'Callaghan's message of 2016-05-24 10:59:13 +1000:
> >> Surely openstack is defined by it’s capabilities and interfaces rather than it’s internals.  Given the simplistic view that openstack is a collection of micro services connected by well defined api’s does it really matter what code is used inside that micro service (or macro service )?   If there is a community willing to bring and support code in language ‘x’,  isn’t that better than worrying about the off chance of existing developers wishing to move projects and not knowing the target language?    Is there a fear that we’ll end up with a fork of nova (or others) written in rust ?
> >> If we’re not open to evolving then we’ll die.
> >> 
> >> Just throwing in a different perspective.
> > 
> > Thanks Geoff. Your perspective is one that has been considered many
> > times. That is an engineering perspective though, and ignores the people
> > and businesses that are the users of OpenStack. We don't just shove the
> > code out the door and say "good luck!”.
> 
> Hey Clint,  That is exactly what I wasn’t saying.   Businesses and people out there want the platform to have the features they want and work.  They could care less about what it’s written in.   You tend to care when it doesn’t work and / or it doesn’t have the features you want.   So I can understand for operators now they have a vested interest in making sure they can debug what is given to them as we don’t meet Geoff’s rule # 1 - the code must work and it must do what I want.
> 

I completely respect that you may be in a situation where you can
actually define all of the things you want for your IT department today.

My experience is that those things change constantly, and there is no
product that will ever add all of the features that everyone needs. But
if one can hit 80%, and 100% of the startup features, then being open
source, there's no worry that some vendor will simply refuse to respect
those other needs. Grab a python developer, land some code, and your
feature is there.

> I also never said, ship the source code and say ‘good luck’.   What I did imply  was, due to a relaxing of coding platform requirements we might be able to deliver a function at this performance point that  we may not have been able to do otherwise.   We should always provide support and the code,  but as to what language it’s written it i’m personally not fussed and I have to deal with a variety of languages already so maybe that’s why I don’t see it as a big problem.

This again assumes that one only buys software and does not ever
participate in its development in an ongoing basis. There's nothing
wrong with that, but this particular community is highly focused on
people who do want to participate and think that the ability to
adapt this cloud they've invested in to their changing business needs is
more important than any one feature.

> 
> I understand there will be integration challenges and I agree with cohesiveness being a good thing, but I also believe we must deliver value more than cohesiveness.   The value is what operators want,  the cohesiveness is what the developers may or may not want.
> 

We agree that delivering value to end users and operators is the #1
priority. I think we just disagree on the value of an open development
model and cohesion in the _community_.