Open Stack

Hi everyone,

I just proposed a new requirement for OpenStack "official" projects, 
which I think is worth discussing beyond the governance review:

https://review.openstack.org/#/c/329448/

 From an upstream perspective, I see us as being in the business of 
providing open collaboration playing fields in order to build projects 
to reach the OpenStack Mission. We collectively provide resources 
(infra, horizontal teams, events...) in order to enable that open 
collaboration.

An important characteristic of these open collaboration grounds is that 
they need to be a level playing field, where no specific organization is 
being given an unfair advantage. I expect the teams that we bless as 
"official" project teams to operate in that fair manner. Otherwise we 
end up blessing what is essentially a trojan horse for a given 
organization, open-washing their project in the process. Such a project 
can totally exist as an unofficial project (and even be developed on 
OpenStack infrastructure) but I don't think it should be given free 
space in our Design Summits or benefit from "OpenStack community" branding.

So if, in a given project team, developers from one specific 
organization benefit from access to specific knowledge or hardware 
(think 3rd-party testing blackboxes that decide if a patch goes in, or 
access to proprietary hardware or software that the open source code 
primarily interfaces with), then this project team should probably be 
rejected under the "open community" rule. Projects with a lot of drivers 
(like Cinder) provide an interesting grey area, but as long as all 
drivers are in and there is a fully functional (and popular) open source 
implementation, I think no specific organization would be considered as 
unfairly benefiting compared to others.

A few months ago we had the discussion about what "no open core" means 
in 2016, in the context of the Poppy team candidacy. With our reading at 
the time we ended up rejecting Poppy partly because it was interfacing 
with proprietary technologies. However, I think what we originally 
wanted to ensure with this rule was that no specific organization would 
use the OpenStack open source code as crippled bait to sell their 
specific proprietary add-on.

I think taking the view that OpenStack projects need to be open, level 
collaboration playing fields encapsulates that nicely. In the Poppy 
case, nobody in the Poppy team has an unfair advantage over others, so 
we should not reject them purely on the grounds that this interfaces 
with non-open-source solutions (leaving only the infrastructure/testing 
requirement to solve). On the other hand, a Neutron plugin targeting a 
specific piece of networking hardware would likely give an unfair 
advantage to developers of the hardware's manufacturer (having access to 
that gear for testing and being able to see and make changes to its 
proprietary source code) -- that project should probably live as an 
unofficial OpenStack project.

Comments, thoughts ?

-- 
Thierry Carrez (ttx)