Open Stack

Whether “progressively evolve” or “integrates with relevant technologies” is employed, the crux of the discussion indeed was to establish that the how and what of OpenStack isn’t a static thing… that it ought continuously evolve to attain / maintain the mantle of ubiquitous.

Also, it appears something may have been lost in the revisions. While "simple to implement" is important (and I don’t recall anyone advocating trimming that), there was also a desire to specifically target ease of use / ease of consumption.  I’d definitely advocate for a return of that… perhaps: “simple to implement & use” or something to that effect.

- Rob


From: Mark Collier <mark at openstack.org<mailto:mark at openstack.org>>
Date: Wednesday, February 3, 2016 at 3:08 PM
To: Sean Dague <sean at dague.net<mailto:sean at dague.net>>
Cc: "foundation at lists.openstack.org<mailto:foundation at lists.openstack.org>" <foundation at lists.openstack.org<mailto:foundation at lists.openstack.org>>
Subject: Re: [OpenStack Foundation] Updating the OpenStack Mission Statement


On Feb 2, 2016, at 5:06 AM, Sean Dague <sean at dague.net<mailto:sean at dague.net>> wrote:

On 02/01/2016 04:41 PM, Allison Randal wrote:
On 02/01/2016 03:50 PM, Doug Hellmann wrote:

The "and progressively evolve" seems superfluous. That's part of how we
would produce OpenStack, and so I think we can trim the statement a bit
by removing it.

My understanding of the discussion was that the main point to add was
"embracing a diversity of technologies", essentially making it clear
that the Big Tent approach is a core part of OpenStack's mission. The
"rapid evolution" part was more along the lines of expressing a desired
outcome of Big Tent.

I tried working "technical diversity" in several different ways, and all
seemed to make the statement obtuse and impenetrable. Better to be clear
and crisp.

While the Big Tent is important, I don't think it's actually part of our
mission statement. It's our current form of execution which helps cover
the needs of public / private clouds.

By my recollection of the board dicsussion, the primary intend behind adding to the language drafted by the TC was not so much to address the big tent per se (which is a means to an end as you said Sean), but to acknowledge that the cloud computing landscape is ever changing and therefore to continue to be relevant to users we have to evolve as new technologies emerge.  The typical examples cited are containers and bare metal, but I think most people agreed that calling out specific technologies would actually be counterproductive in a mission statement since the whole point is that different models come and go.

So… I think that’s the reason “progressively evolve” was suggested.

Here’s another take on an addition with similar intent:
"To produce the ubiquitous Open Source Cloud Computing platform that integrates with relevant technologies to meet the needs of users and operators of public and private clouds of all sizes by being simple to implement, massively scalable, and interoperable."
That said, I’m fine with any of the suggested versions.



I'm not sure "that meets the needs of public and private clouds"
is targeting the right object, grammatically. Clouds don't need
things. People who deploy, operate, and use clouds need things.

I prefer the "serving the cloud users' needs" phrasing rather than
"easy to use", both because it actually mentions people and because
ease of use is only one of many needs a user may have.

So, I propose:

 To produce the ubiquitous Open Source Cloud Computing platform
 that meets the needs of users and operators of public and private
 clouds of all sizes by being simple to implement, massively
 scalable, and interoperable.

+1 this is really good. I think it's important distinction that clouds
don't need anything, but users and operators do.

-Sean

--
Sean Dague
http://dague.net<http://dague.net/>

_______________________________________________
Foundation mailing list
Foundation at lists.openstack.org<mailto:Foundation at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20160205/bea1e732/attachment-0001.html>