Open Stack

Monty, thanks for sharing this point of view. Competition is a 
double-edged sword for users, both end users
and deployers using OpenStack APIs to deliver their services.
When competition is about better implementations of a standard API, it 
is great for users.
When competition means users choosing between different APIs that fill 
the same important cloud infrastructure
purpose, it is horrible for users and fragmenting. While it would be bad 
for the OpenStack board and TC to choose
between competing projects too early, at some point I believe a choice 
must be made in order for the
project as a whole to maintain its coherency and greatness compared to 
other competitors.

  -David

On 11/8/2012 6:30 AM, Monty Taylor wrote:
> I can be on-board with #2. The most important thing to me is that there
> is a clear message for the users and they are being protected from
> insanity. I think Thierry is right, that my thoughts on requiring people
> to use everything is really a trademark question and is a board thing.
> So if we remove that, I think that Gabriel and I are actually saying the
> same thing.
>
>
> On 11/08/2012 11:55 AM, Gabriel Hurley wrote:
>> I find it interesting that I agree with all of notmyname's arguments
>> for #4 (and generally he with my arguments for #2), and yet we came
>> to opposite conclusions. I guess I just see the solution to the
>> fuzziness of "necessary" as being the arbitrary-yet-decisive
>> "recommended" rather than the alternative solution of everything else
>> being simply excluded (not implying any malice, only that they're
>> simply *not* part of OpenStack officially).
>>
>> I do wholeheartedly endorse mtaylor's assertion that taking the
>> IaaS-only route hurts users by leaving such a huge amount up to
>> individual deployments. On the flip side, demanding that every core
>> project be deployed in every case is a longshot and would probably
>> hurt adoption. I certainly appreciate the sentiment either way. ;-)
>>
>> Lastly, I still feel that option #1 provides too little guidance and
>> only worsens the problems mtaylor and I have laid out, so I stand by
>> option #2 (shocking, right?).
>>
>> The proliferation of ideas here is awesome, though! Can't wait to see
>> what other people have to say.
>>
>> - Gabriel
>>
>>> -----Original Message----- From: Thierry Carrez
>>> [mailto:thierry at openstack.org] Sent: Thursday, November 08, 2012
>>> 1:43 AM To: openstack-dev at lists.openstack.org Subject: Re:
>>> [openstack-dev] The future of Incubation and Core
>>>
>>> OK, let's try to summarize the different views so far:
>>>
>>> 1. core+supported (russellb) Let Core be anything you want
>>> (required set, necessary set...), but have a Supported category for
>>> everything that is a positive addition to OpenStack.
>>>
>>> 2. Product core (gabrielhurley) Do not have an intermediary
>>> category which could carry more duties than rights, but have an
>>> inclusive definition of Core that would include
>>> necessary/recommended projects.
>>>
>>> 3. Required core (mtaylor) Same as "product core", + make all the
>>> core stuff a required use if you are to call yourself an "OpenStack
>>> cloud"
>>>
>>> 4. IaaS core (notmyname) Do not have an intermediary category, and
>>> have Core only include pure IaaS projects.
>>>
>>> I hope I summarized each correctly...
>>>
>>> Personally I lean towards (1) or (2). I think (3) is an (important)
>>> trademark question (what do you need to use in order to call
>>> yourself "OpenStack cloud", "based on OpenStack", etc.) which would
>>> be better solved by the Board of Directors. So in my mind it's
>>> equivalent to (2).
>>>
>>> I think (4) is too restrictive. Basically I consider Keystone a key
>>> OpenStack project. If it's not in your definition of "Core" then we
>>> need another category ("Supported", personally I prefer the word
>>> "Key" which doesn't sound as much 2nd-class) that is as important
>>> to cover for it, which means solution (1).
>>>
>>> About solution (1), would the "Key" projects be under the same
>>> coordinated release system ? I personally think keystone and
>>> horizon need to be released at the same time as the others.
>>>
>>> So in the end, I think solution (1) and (2) are essentially the
>>> same thing, and just a play on the words. You both want more
>>> projects under the openstack umbrella. Whether that umbrella is
>>> divided, for trademark reasons, between "Core" and "Key", or
>>> everything is considered "Core", is more a word definition than a
>>> technical issue. We would care the same.
>>>
>>> The devil is in the details, of course: the wording around (1)
>>> encourages a lot of projects to join while (2) has a "recommended"
>>> feel to it that will make it a bit more exclusive.
>>>
>>> -- Thierry Carrez (ttx) Chair, OpenStack Technical Committee
>>>
>>> _______________________________________________ OpenStack-dev
>>> mailing list OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _______________________________________________ OpenStack-dev mailing
>> list OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev