[OpenStack Foundation] Updating the OpenStack Mission Statement

Tim Bell Tim.Bell at cern.ch
Sat Feb 6 19:27:35 UTC 2016

I think it shows the evolution of OpenStack that we can now look at the end users (through user committee teams such as the API working group).

For many releases, the operators have worked hard to provide a stable cloud for their users within the constraints of what can be achieved with the software.

We are now able to include the end user on the basis of a stable cloud service. We should not ignore the effort this has taken to get to this point (and calling out operators who have significantly invested is unproductive).


On 06/02/16 17:04, "Monty Taylor" <mordred at inaugust.com> wrote:

>On 02/06/2016 09:58 AM, Allison Randal wrote:
>> On 02/05/2016 08:32 AM, Sean Dague wrote:
>>> They are statements of 'How'. They are not statements of 'What'. And
>>> while they may be accurate most 'How' should not exist in a mission
>>> statement. It's the same reason we don't put 'in Python' in our mission
>>> statement. Except, they are even worse that that, because they are
>>> filler words that are so vague as to sound important but not give anyone
>>> in the project clarity as to what they are doing. Relevant technologies
>>> is what exactly? And is it the same answer yesterday as today?
>> To carry this forward a bit, the purpose of a mission statement is to
>> outline 'What' an organization is trying to achieve, the 'How' part
>> belongs in some other document. There has been some discussion recently
>> on OpenStack Values, and a document outlining those would be the right
>> place to include things like "approach development as a continuous
>> process of evolution", "integrate with established technologies as they
>> gain traction", and "avoid prejudice against ideas from other
>> development communities or traditions".
>>> """
>>> To produce a ubiquitous Open Source Cloud Computing platform. It should
>>> be easy to use, simple to implement, work well at all scales, be
>>> interoperable between instances, and meet the needs of both public and
>>> private clouds.
>>> """
>> +1 for clarity and conciseness.
>> I really liked Doug's emphasis on users and operators, so I'd work that
>> back in: "...meet the needs of users and operators of both public and
>> private clouds".
>++ - that was one of the main things that was missing before. The idea 
>that OpenStack users include the end-users of the clouds being run by 
>the operators rather than OpenStack's user's being the operators is an 
>important thing to call out. We've actually focused very strongly on the 
>Operator as the primary user so far, and it shows.
>I think it's worth calling out and is not just a 'how' - because the 
>shape of things would be very different if we only considered Cern and 
>Vexxhost as our users and not the transitive set of their users as well.
>Foundation mailing list
>Foundation at lists.openstack.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2792 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20160206/57ee9ba4/attachment.bin>

More information about the Foundation mailing list