[openstack-dev] [tc] persistently single-vendor projects

James Bottomley James.Bottomley at HansenPartnership.com
Thu Aug 4 17:07:26 UTC 2016


On Thu, 2016-08-04 at 10:10 +0200, Thierry Carrez wrote:
> Devdatta Kulkarni wrote:
> > As current PTL of one of the projects that has the team:single
> > -vendor tag, I have following thoughts/questions on this issue.
> 
> In preamble I'd like to reiterate that the proposal is not on the 
> table at this stage -- this is just a discussion to see whether it 
> would be a good thing or a bad thing.

I think this is fair enough, plus the idea that the tagging only
triggers review not an automatic eviction is reasonable.  However, I do
have a concern about what you said below.

> > - Is the need for periodically deciding membership in the big tent
> > primarily stemming from the question of managing resources (for the
> > future design summits and cross-project work)?
> 
> No, it's not the primary reason. As I explained elsewhere in the 
> thread, it's more that (from an upstream open source project 
> perspective) OpenStack is not a useful vehicle for open source 
> projects that are and will always be driven by a single vendor. The 
> value we provide (through our governance, principles and infra 
> systems) is in enabling open collaboration between organizations. A 
> project that will clearly always stay single-vendor (for one reason 
> or another) does not get or bring extra technical value by being 
> developed within "OpenStack" (i.e. under the Technical Committee
> oversight).

I don't believe this to be consistent with the OpenStack mission
statement:

    to produce the ubiquitous Open Source Cloud Computing platform that 
    will meet the needs of public and private clouds regardless of size,
    by 
    being simple to implement and massively scalable.

OpenStack chooses to implement this mission statement by insisting on
Openness via the four opens and by facilitating a collaborative
environment for every project. I interpret the above to mean any
OpenStack project must be open and must bring technical benefit to
public and private clouds of any size; so I don't think a statement
that even if a project satisfies your openness requirements, the fact
that it must also derive technical benefit from the infrastructure
you've put in place can be supported by any construction of the above
mission statement.

The other thing that really bothers me is that it changes the
assessment of value to OpenStack from being extrinsic (brings technical
benefit to public and private cloud) to being intrinsic (must derive
technical benefit from our infrastructure) and I find non-extrinsic
measures suspect because they can lead to self-perpetuation.

James




More information about the OpenStack-dev mailing list