Open Stack

(Top posting because this veers significantly and because Outlook has really sucky reply options)



It just struck me that the "OpenStack Powered" discussion is really just another version of the "Made in America" discussion.  And the solution to that eventually evolved into:



Designed and Manufactured in America

% Manufactured (sourced) in America

Assembled in America

(probably others)



Extrapolating from this and various Defcore discussions:

·         We have already defined the core parts of projects vs. non-core as:

o    Plugins are not core

o    Extensions are not core

o    Immature features are not yet core

·         Trademark definition is *not* an engineering issue, it is a business issue

·         One Trademark will not satisfy how the community wants to use the OpenStack bits



So, how about we turn this whole thing on end.

·         We keep Capabilities as defined by maturity, integration and deployment

·         We keep Interop Tests as a certification of Capabilities inclusion in products

·         We come up with a %OpenStack based on something like APIs, functionality, LOC (I don’t recommend this one) and come decide on a minimum percentage to be met to call a product “powered by OpenStack” or “Built on OpenStack” or “100% OpenStack” or etc.

This approach allows large inclusion of the mature parts of the OpenStack integrated codebase (developers are happy) but doesn’t require any specific part of the codebase be included (keeps vendors happy).  The IBM Cloud Storage product might include 100% of Swift, but maybe replaces Horizon and might be 70% OpenStack (Or even 100%) with no Nova code or APIs.  Their compute cloud might end up 65% OpenStack based on 100% Nova and some extra code for a proprietary Hypervisor.



Right now I see that the Foundation would have to rely on Vendors to self-report how much extra code that replaces existing OpenStack DefCore capabilities is in their product, but that’s not something that hasn’t been considered before as a short term option.



This approach also gets DefCore out of the politics of Trademark and Business and back to the technical evaluation of maturity (and future direction) of specific OpenStack Integrated features.



Comments? Discussion?  Flames?



--Rocky

Trying to think around the box





-----Original Message-----
From: Mark McLoughlin [mailto:markmc at redhat.com]
Sent: Wednesday, September 17, 2014 7:34 AM
To: Doug Hellmann
Cc: Defcore-committee at lists.openstack.org
Subject: Re: [OpenStack-DefCore] Results from Community Meetings > discussion/+1 about reconsidering Havana Swift as a core capability



On Wed, 2014-09-17 at 10:17 -0400, Doug Hellmann wrote:

> On Sep 17, 2014, at 4:29 AM, Mark McLoughlin <markmc at redhat.com> wrote:

>

> > On Fri, 2014-09-12 at 09:38 -0400, Doug Hellmann wrote:

> >> The point I have been trying to make is that because our community

> >> creates code and not standards, we should not simply trademark an API

> >> without including the implementation.

> >

> > To make sure the basic point isn't getting lost - we're talking about

> > the requirements for products and clouds that wish to use the "OpenStack

> > Powered" trademark. We're not "trademarking an API”.

>

> If the cloud or product does not include the OpenStack implementation,

> how is it “Powered” by OpenStack? I could see saying “Compatible with”

> or something like that. Maybe I’m reading too much into the word

> “Powered”.



Yes, a trademark license that just required API compatibility would be a

different thing.



That doesn't mean that some part of *every* capability needs to be

"OpenStack Powered".



> > We want there to be a vibrant commercial ecosystem of "OpenStack

> > Powered" products and clouds. But we also want to ensure that such

> > products offer an experience which reflects well on our brand and

> > encourages healthy engagement with our community.

> >

> > i.e. at least three things to balance - growing this commercial

> > ecosystem, making sure the brand isn't damaged and growing our

> > community.

> >

> > If the implementation of a capability offers users a good experience and

> > the vendor is engaged with our community in good faith, then I'd err on

> > the side of allowing the use of the trademark since they will grow the

> > commercial ecosystem.

>

> So if they are engaged in one area (Nova) but not in another (Swift)

> they are allowed to replace the component entirely with their own?

> That feels very strange. We don’t apply that logic to *any* other

> component.



Swift *is* different because it doesn't have "pluggable backends".



Part of my "good faith" criteria here is that (some, at least) of the

vendors who implement a Swift compatible API without using Swift code

need to be engaged with evolving Swift so they can use it.



(The only real data I have on that is that some Red Hat affiliated

developers have been contributing in this area, but this isn't a Red Hat

concern - I don't think the decision affects Red Hat's ability to

license the trademark.)



Point is that this is the kind of stuff that I'd like to hear more about

during the debate, rather than talking in the abstract about

"capabilities must also have designated code".



> > I don't like to see us making rigid rules like "required capabilities

> > must have some designated sections", because such rules are so far

> > removed from the nuanced non-technical considerations we should be

> > making about trademark usage.

>

> This is a nuanced issue, no doubt. Maybe we should be reconsidering

> the idea that we only want to have one trademark. A single mark

> doesn’t seem to support the varied ways the ecosystem wants to use

> OpenStack in their products while also making clear how those products

> differ from each other.



Agree :)



http://lists.openstack.org/pipermail/foundation/2014-July/001709.html



At the same time, there's a balance to be struck - too many trademark

programs and they all begin to lose meaning because no-one can keep

track of the differences between them.



Mark.





_______________________________________________

Defcore-committee mailing list

Defcore-committee at lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20140917/bbc7f689/attachment-0001.html>