Open Stack

Ed Leafe wrote:
> On Nov 9, 2016, at 5:14 AM, Chris Dent<cdent+os at anticdent.org>  wrote:
>
>> Something that feels like it gets under-emphasised in this conversation
>> is that change is coming whatever we do. As a community we can either
>> move quickly and stay ahead of the change and see it as a productive
>> development that we can surf or we can dilly dally and get drowned by a
>> wave that collapses over us.
>>
>> Ecosystems must evolve and change because the world evolves and changes.
>> If we try to control this stuff too much what we will be doing is taking
>> the oxygen out of the system and snuffing the flame of excitement and
>> innovation.
>
> That is, of course, a series of obvious statements. We need to change or die.
>
> What I think is missing from this conversation is that there are a lot of people who are used to the way things happen in the startup world, where you get an idea, work like crazy to get an MVP out the door, and then iterate from there. The problem is that OpenStack is the exact opposite of a startup; it’s a giant legacy application.
>

That's only because some (? I'm not sure who they are ?) believe this is 
the way that it *must* be. There are also folks that don't believe this 
is the way it needs to be (including myself), though I get what u are 
saying.

> Don’t like the word “legacy”? Well, what would you call something that has to support users who haven’t upgraded in several years? What would you call something that can never have a greatly-improved but backwards-incompatible change? Sure, that might be possible in some of the add-ons for the OpenStack ecosystem, but for any of the core projects (yes, I said that word), that is simply not an option.
>
 > So yes, of course we’re going to drive off those who want to work 
with the coolest and latest stuff. This isn’t “exciting” work in that 
sense of the word.

I understand what u are saying with the above, but I don't necessarily 
feel it is something we as a community can not resolve (fate is what we 
make).

Why aren't we asking the question of why can't we figure out a way to do 
breaking changes, why can't we move quicker... Instead of assuming there 
is no way that can happen, what happens if we ask ourselves 'what are 
the ways we can make such a thing happen, what are the reasons people 
are stuck on releases of several years behind...' and work through 
fixing those.

Perhaps that involves some very tough questions and perhaps some 
potentially 'radical' answers, but so what... I'd rather have those 
kinds of questions than just assume we are all stuck doing not exciting 
work on some legacy application(s) that never change because existing 
users are stuck.

I mean if we get stuck in the support X users of things for all of time, 
we sort of miss out on the Y users that we can gain by fixing it (even 
if such changes are radical) and making it better; perhaps at the end u 
get X + Y users total (which is even better) or perhaps u don't and u 
move on and learn from the attempt.

-Josh