Open Stack

This might come across a little trolly/devils advocate, but I mulled
on it for a few days, and I think I need to send it, so... fingers
crossed you can extract some value from my questions.

On 15 June 2016 at 01:57, Thierry Carrez <thierry at openstack.org> wrote:
> 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.

Would it change your meaning if I added 'by OpenStack community /
infrastructure' there? If not, then it seems to me that e.g.
Rackspace, Dreamhost, and the other organisations that have deployed
scaled clouds have a pretty big advantage. If it does change your
meaning, then what really do you mean?

>  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.

We already have a mechanism - the undiverse tag - for calling out
projects that don't have diversity in their core. That seems to
overlap a lot here?

> 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.

So I read this paragraph as Its ok if many organisations have unfair
advantages, but its not ok if there is only one organisation with an
unfair advantage?

Consider a project with one open implementation and one organisation
funded proprietary driver. This would be a problem. But I don't
understand why it would be.

I *think* what you're trying to say is that 'if there is no open
implementation then there is a problem', but that seems self evident
(and the CDN orchestration question doesn't apply here, because the
/implementation/ was to be entirely open, and *noone* involved had any
more advantage - the folk proposing the team did not work for the CDN,
so everyone was on equal, if terrible, footing).

> 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'm a huge +1 on not setting up such an open-core strategy in
OpenStack, but I'm really having trouble mapping the proposed ruleset
to the goal.

> 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 ?

I worry that this sets up a pathological situation where vendors are
encouraged *not* to engage, because they would be perceived to have an
unfair advantage...

I think the heart of the problem is a confounding effect: you're
measuring 'ability to develop on project X', not 'ability to compete
with proprietary backend Y'.

The existing diversity tag should provide clear signal about projects
with poor diversity in the core team, and when the core team has
diversity, multiple organisations - both purely open and those with a
proprietary solution they wish to glue in - should be on equal
footing; and *that* is what matters to me. We've had many occasions
where poorly thought out ideas are rejected from projects, and I am
confident those mechanisms can prevent tailored-to-one-backend
anti-patterns getting into a healthy, diverse project.

HTH,
-Rob