[openstack-dev] [all][tc] Require a level playing field for OpenStack projects
sgordon at redhat.com
Thu Jun 16 20:04:28 UTC 2016
----- Original Message -----
> From: "Amrith Kumar" <amrith at tesora.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Thanks for writing this up and for the interesting discussion that has come
> up in this ML thread.
> While I think I get the general idea of the motivation, I think the verbiage
> doesn't quite do justice to your intent.
> One area which I would like to highlight is the situation with the underlying
> operating system on which the software is to run. What if that is
> proprietary software? Consider support for (for example) running on Red Hat
> or the Windows operating systems. That would not be something that could be
> easily abstracted into a 'driver'.
This is definitely a point worth clarifying in the general case, but tangentially for the specific case of the RHEL operating system please note that RHEL is available to developers for free:
This is a *relatively* recent advancement so I though I would mention it as folks may not be aware.
> Another is the case of proprietary software; consider support in Trove for
> (for example) using the DB2 Express or the Vertica database. Clearly these
> are things where some have an advantage when compared to others.
> I therefore suggest the following amendment in
> * The project provides a level playing field for interested developers to
> collaborate. Where proprietary software, hardware, or other resources
> (including testing) are required, these should be reasonably accessible to
> interested contributors.
> > -----Original Message-----
> > From: Thierry Carrez [mailto:thierry at openstack.org]
> > Sent: Tuesday, June 14, 2016 9:57 AM
> > To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org>
> > Subject: [openstack-dev] [all][tc] Require a level playing field for
> > OpenStack projects
> > 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)
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
Principal Product Manager,
Red Hat OpenStack Platform
More information about the OpenStack-dev