Open Stack

Simon,

While I love the tenor of your approach, I think we need at least three more:

1. Distributions (which I consider to be Red Hat, Canonical, and SUSE only) are currently shipping 100% of the integrated release, and they’ve expressed interest in a mark that represents that. So your proposed “OpenStack Software” mark would more likely fit *products* (Piston OpenStack, CloudScaling OCS, Nebula One, etc).

2. The proposed OpenStack Compute and OpenStack Storage would also need to apply to software and hardware products (as opposed to services) such as IBM’s whatever-that-thing-is-called. 

I think it’s increasingly confusing to refer to swift-related things as “Storage”, since that excludes Cinder- or Manila-related things.

An alternative approach would be to have just three marks:

 - OpenStack Distribution (100% of the integrated release)
 - Certified OpenStack (what’s currently covered by DefCore, being core capabilities and designated sections)
 - Powered by OpenStack Components (includes one or more of the core capabilities with the relevant designated sections for each capability)

The third mark would be a replacement for “OpenStack Compute”, “OpenStack Storage”, etc, and would prevent mark sprawl.

--

Joshua McKenty
Chief Technology Officer
Piston Cloud Computing, Inc.
+1 (650) 242-5683
+1 (650) 283-6846
http://www.pistoncloud.com

"Oh, Westley, we'll never survive!"
"Nonsense. You're only saying that because no one ever has."

On Sep 22, 2014, at 10:43 PM, Simon Anderson <simon at dreamhost.com> wrote:

> Hi Rob, I may have heard a different output from the Board call - which was that the Foundation staff would work on some multi-TM proposals and share them with the DefCore committee/Board. So Jonathan, Mark and Lauren may already be working on them.
> 
> Personally, I think having more than one trademark usage doesn't undermine the great work of DefCore so far. My thoughts on a simple multi-TM structure that might serve the market are:
> OpenStack Software (TM) for distributions, that would include all designated sections and core capabilities;
> OpenStack Compute (TM) for services running all designated sections and core capabilities *except for* OpenStack Storage designated sections/core capabilities;
> OpenStack Storage (TM) for services running the object storage designated sections and core capabilities (essentially SWIFT).
> 
> 
> 
> Best,
> Simon
> 
> On Mon, Sep 22, 2014 at 2:09 PM, <Rob_Hirschfeld at dell.com> wrote:
> All,
> 
>  
> 
> Last Thursday, the board did not act on any of our recommendations.  The Board is reconsidering one of the guiding principles from Hong Kong – DefCore is trying to define a minimum base definition for OpenStack.  Instead, they’ve asked us for multiple Trademark proposals.
> 
>  
> 
> ACTION ITEM: I’d be interested in hearing suggestions from the committee that we can use as the basis for a etherpad. 
> 
>  
> 
> Towards that end, I think we should schedule a meeting on Thursday 10/2.  I’m open to having a working session before that to brainstorm options (possibly with Mark or Jonathan).
> 
>  
> 
> I’d ask you to consider two items in preparation:
> 
> 1)      Sean Dague’s Layers Model: https://dague.net/2014/08/26/openstack-as-layers/
> 
> 2)      Consideration of OpenStack as a product or “big tent” which seems to be part of the OpenStackSV output: Monty http://inaugust.com/post/108 and Randy http://siliconangle.com/blog/2014/09/17/the-achilles-heel-of-openstack-is-lack-of-product-leadership-openstacksv/
> 
>  
> 
> Rob
> 
> ______________________________
> 
> Rob Hirschfeld
> 
> cell +1 512 909-7219 blog robhirschfeld.com, twitter @zehicle
> 
> Please note, I am based in the CENTRAL (-6) time zone
> 
>  
> 
> 
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
> 
> 
> 
> _______________________________________________
> 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/20140923/4c77e906/attachment.html>