Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Zane Bitter]

On 20/06/16 18:50, Jeremy Stanley wrote:

On 2016-06-20 18:43:44 +0200 (+0200), Zane Bitter wrote:

The binaries are free-as-in-beer - IIUC you can't redistribute them. The
source code, of course, remains free-as-in-speech as it has always been.
(It's easy to forget the distinction when you work in Python all day and
there are no binaries, but it's the source code that counts.) And of course
there are freely-distributable binaries built from that source available in
the form of CentOS.

[...]

Not to go too far down this rabbit hole, but as a
long-time-away-from-Red-Hat user my (possibly quite outdated)
experience was that RHEL included some non-free/proprietary software
distributed alongside other free-as-in-speech software. If this is
still true, it would be a significant mischaracterization to claim
that the "source code" for RHEL as a whole is consistently free.


That isn't my understanding, but it's hard to give a definitive answer 
without knowing what kinds of non-free software you're referring to 
(since I know there have been fierce disagreements even e.g. within 
Debian on topics like firmware blobs). Certainly if anything in 
https://fedoraproject.org/wiki/Licensing:Main bothers you then you'll 
probably be unhappy.


There *is* a "Supplementary" channel that includes non-free software - 
IBM Java (ikr? apparently that's a real thing), certain CJK fonts... 
that kind of random, obscure stuff - but you have to download a separate 
DVD and/or enable a separate yum repo that is disabled by default. 
You'll never need to go near it.


But e.g. if a user wants to install the proprietary nVidia driver, RH 
tells them to go download it from nVidia.[1] It's not shipped in RHEL or 
even the Supplementary channel.


cheers,
Zane.

[1] https://access.redhat.com/solutions/5258 (paywalled, sorry):


If
_all_ software provided by RHEL is also now included under free and
open licenses, then I'm thrilled and may be more inclined to give it
a try again in the future.




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Jeremy Stanley]

On 2016-06-20 18:43:44 +0200 (+0200), Zane Bitter wrote:
> The binaries are free-as-in-beer - IIUC you can't redistribute them. The
> source code, of course, remains free-as-in-speech as it has always been.
> (It's easy to forget the distinction when you work in Python all day and
> there are no binaries, but it's the source code that counts.) And of course
> there are freely-distributable binaries built from that source available in
> the form of CentOS.
[...]

Not to go too far down this rabbit hole, but as a
long-time-away-from-Red-Hat user my (possibly quite outdated)
experience was that RHEL included some non-free/proprietary software
distributed alongside other free-as-in-speech software. If this is
still true, it would be a significant mischaracterization to claim
that the "source code" for RHEL as a whole is consistently free. If
_all_ software provided by RHEL is also now included under free and
open licenses, then I'm thrilled and may be more inclined to give it
a try again in the future.
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Zane Bitter]

On 16/06/16 23:04, Jeremy Stanley wrote:

On 2016-06-16 16:04:28 -0400 (-0400), Steve Gordon wrote:
[...]

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:

 http://developers.redhat.com/products/rhel/get-started/
 http://developers.redhat.com/articles/no-cost-rhel-faq/

This is a *relatively* recent advancement so I though I would
mention it as folks may not be aware.


Just to clarify, this is free-as-in-beer (gratis) and not
free-as-in-speech (libre)? If so, that's still proprietary so I'm
curious how that changes the situation. Would OpenStack welcome a
project built exclusively around a "free for developer use" product
into the tent?


The binaries are free-as-in-beer - IIUC you can't redistribute them. The 
source code, of course, remains free-as-in-speech as it has always been. 
(It's easy to forget the distinction when you work in Python all day and 
there are no binaries, but it's the source code that counts.) And of 
course there are freely-distributable binaries built from that source 
available in the form of CentOS.


So the question is mostly moot - we should *almost* never encounter a 
dependency on RHEL in particular (as opposed to EL builds in general - 
RHEL/CentOS/Scientific Linux/that Oracle thing/whatever). However in the 
tiny number of cases where there is one, I think it's entirely 
reasonable for the OpenStack community to require (a) that it not be a 
*hard* dependency; and (b) that a "level playing field" exists - i.e. 
the team must have no objection in principle to somebody using similar 
mechanisms to implement equivalent functionality for other operating 
systems.


(I should clarify that this is my personal opinion; I don't speak for 
Red Hat.)


I believe we follow that policy already anyway. e.g. TripleO never uses 
RHEL in the gate, only CentOS AFAIK.


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[John Garbutt]

On 16 June 2016 at 09:58, Thierry Carrez  wrote:
> Project team requirements are just guidelines, which are interpreted by
> humans. In the end, the TC members vote and use human judgment rather than
> blind 'rules'. I just want (1) to state that a level playing field is an
> essential part of what we call "open collaboration", and (2) to have TC
> members *consider* whether the project presents a fair playing field or not,
> as part of how they judge future project teams.

FWIW, I think this is what wins me over.
These are just guidelines to be considered by humans.

> There is a grey area that requires human judgment here. In your example
> above, if the open implementation was unusable open core bait to lure people
> into using the one and only proprietary driver, it would be a problem. If
> the open implementation was fully functional and nothing prevented adding
> additional proprietary drivers, there would be no problem.

This answers a lot of the questions I had after reading the idea.
Along with the fact this is only about official projects.

Thanks,
johnthetubaguy

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Amrith Kumar]

Steve, this was exactly the point I wanted to make and the reason I chose the 
verbiage of "reasonably accessible" since I believe that this would classify as 
such. However, as Thierry pointed out in his response to the review that wasn't 
his primary focus.

Rather, he didn't want a project to benefit a single contributor, vendor, 
organization and I've submitted a revision for his comments.

But, your point is well taken, and I didn't realize that the RHEL free for 
developers was a recent change.

-amrith

> -Original Message-
> From: Steve Gordon [mailto:sgor...@redhat.com]
> Sent: Thursday, June 16, 2016 11:40 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [all][tc] Require a level playing field for
> OpenStack projects
> 
> - Original Message -
> > From: "Jeremy Stanley" <fu...@yuggoth.org>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> > Sent: Thursday, June 16, 2016 5:04:43 PM
> > Subject: Re: [openstack-dev] [all][tc] Require a level playing field
>   for OpenStack projects
> >
> > On 2016-06-16 16:04:28 -0400 (-0400), Steve Gordon wrote:
> > [...]
> > > 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:
> > >
> > > http://developers.redhat.com/products/rhel/get-started/
> > > http://developers.redhat.com/articles/no-cost-rhel-faq/
> > >
> > > This is a *relatively* recent advancement so I though I would
> > > mention it as folks may not be aware.
> >
> > Just to clarify, this is free-as-in-beer (gratis) and not
> > free-as-in-speech (libre)? If so, that's still proprietary so I'm
> > curious how that changes the situation. Would OpenStack welcome a
> > project built exclusively around a "free for developer use" product
> > into the tent?
> 
> Well, in the context of evaluating this specific proposed change that
> really depends on the final language used. Under the wording that is
> currently proposed the answer would seem to be "yes" if developers of all
> organizations have access to that same software - whether that's the
> intent or not is perhaps a different question. In reality of course such a
> hypothetical project would likely fall afoul of the earlier criteria
> around dependencies anyway...
> 
> -Steve
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Steve Gordon]

- Original Message -
> From: "Jeremy Stanley" <fu...@yuggoth.org>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>
> Sent: Thursday, June 16, 2016 5:04:43 PM
> Subject: Re: [openstack-dev] [all][tc] Require a level playing field  for 
> OpenStack projects
> 
> On 2016-06-16 16:04:28 -0400 (-0400), Steve Gordon wrote:
> [...]
> > 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:
> > 
> > http://developers.redhat.com/products/rhel/get-started/
> > http://developers.redhat.com/articles/no-cost-rhel-faq/
> > 
> > This is a *relatively* recent advancement so I though I would
> > mention it as folks may not be aware.
> 
> Just to clarify, this is free-as-in-beer (gratis) and not
> free-as-in-speech (libre)? If so, that's still proprietary so I'm
> curious how that changes the situation. Would OpenStack welcome a
> project built exclusively around a "free for developer use" product
> into the tent?

Well, in the context of evaluating this specific proposed change that really 
depends on the final language used. Under the wording that is currently 
proposed the answer would seem to be "yes" if developers of all organizations 
have access to that same software - whether that's the intent or not is perhaps 
a different question. In reality of course such a hypothetical project would 
likely fall afoul of the earlier criteria around dependencies anyway...

-Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Jeremy Stanley]

On 2016-06-16 16:04:28 -0400 (-0400), Steve Gordon wrote:
[...]
> 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:
> 
> http://developers.redhat.com/products/rhel/get-started/
> http://developers.redhat.com/articles/no-cost-rhel-faq/
> 
> This is a *relatively* recent advancement so I though I would
> mention it as folks may not be aware.

Just to clarify, this is free-as-in-beer (gratis) and not
free-as-in-speech (libre)? If so, that's still proprietary so I'm
curious how that changes the situation. Would OpenStack welcome a
project built exclusively around a "free for developer use" product
into the tent?
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Mike Perez]

On 09:35 Jun 14, Ed Leafe wrote:
> On Jun 14, 2016, at 8:57 AM, Thierry Carrez  wrote:
> 
> > 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 saw the problem with Poppy was that since it depended on a proprietary
> product, there was no way to run any meaningful testing with it, since you
> can’t simply download that product into your testing environment. Had there
> been an equivalent free software implementation, I think many would have not
> had as strong an objection in including Poppy.

Yup, I spoke loud and repeated this in the discussion many times. There was no
open source reference implementation to base the API off of, just a proprietary
solution. I feel starting that direction with any new project in some open
source space where we want multiple solutions to plug in is just a disaster
waiting to happen.

-- 
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Steve Gordon]

- Original Message -
> From: "Amrith Kumar" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> 
> Thierry,
> 
> 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:

http://developers.redhat.com/products/rhel/get-started/
http://developers.redhat.com/articles/no-cost-rhel-faq/

This is a *relatively* recent advancement so I though I would mention it as 
folks may not be aware.

Thanks,

Steve

> 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
> https://review.openstack.org/#/c/329448/.
> 
> * 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.
> 
> Thanks,
> 
> -amrith
> 
> > -Original Message-
> > From: Thierry Carrez [mailto:thie...@openstack.org]
> > Sent: Tuesday, June 14, 2016 9:57 AM
> > To: OpenStack Development Mailing List 
> > 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 

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Amrith Kumar]

Thanks Thierry, I did the same (again) :)

-amrith

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Wednesday, June 15, 2016 12:22 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][tc] Require a level playing field for
> OpenStack projects
> 
> Amrith Kumar wrote:
> > 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'.
> >
> > 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
> https://review.openstack.org/#/c/329448/.
> >
> > * 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.
> 
> I replied to that on the review :)
> 
> --
> Thierry Carrez (ttx)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Thierry Carrez]

Robert Collins wrote:

[...]
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?


Where would you add that ? Also I don't think organizations which have 
deployed scaled clouds have an *unfair* advantage. Nothing in our 
governance structure actively prevents another organization from doing 
the same ?



  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?


Yes, it is likely that official project teams that present such a unfair 
playing field would stay "team:single-vendor" forever as a consequence. 
This proposal is about not recognizing such teams as official in the 
first place. The single-vendor tag is, IMHO, meant to encourage project 
teams with a fair playing field to increase their diversity. It is not 
meant to officially support projects that present unfair playing fields.



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.


Project team requirements are just guidelines, which are interpreted by 
humans. In the end, the TC members vote and use human judgment rather 
than blind 'rules'. I just want (1) to state that a level playing field 
is an essential part of what we call "open collaboration", and (2) to 
have TC members *consider* whether the project presents a fair playing 
field or not, as part of how they judge future project teams.


There is a grey area that requires human judgment here. In your example 
above, if the open implementation was unusable open core bait to lure 
people into using the one and only proprietary driver, it would be a 
problem. If the open implementation was fully functional and nothing 
prevented adding additional proprietary drivers, there would be no problem.


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Thierry Carrez]

Matt Riedemann wrote:

[...]
So is the question does Nova provide a level playing field as a project
because it has drivers that can be deployed and used and tested without
special hardware, i.e. libvirt? Then yes. Or is it Nova doesn't provide
a level playing field because zVM and powervm aren't in tree?


Nova provides a level playing field because there is no single company 
unfairly benefiting from Nova being an official project team. No 
specific group of developers in Nova ends up having specific powers that 
others can't have.



If this is really just, random project wants to be considered an
'official' OpenStack project but is totally unusable without a
proprietary stack to deploy and run it - which makes it completely
vendor specific, regardless of whether or not they open sourced the
front-end to talk to their proprietary backend, so only developers from
said vendor can work on the project, then yeah, I agree with the
proposed change in wording.


That's the gist of it, although I would extend that slightly beyond 
"totally unusable". If a project team is mainly formed around a piece of 
code that interacts with a proprietary hardware or software solution, 
then the developers which happen to have access to that solution, and 
can read or modify the code it runs, have an unfair advantage compared 
to other developers. Even if a 3rd-party testing solution is offered, 
that's still a blackbox which says "yes" or "no" for anyone outside the 
special group of people which happen to have access to it.


It is very likely that as a result of this tilted playing field, such a 
project team will stay single-vendor forever. This proposal is just 
saying such a project team should not be made an official OpenStack 
project team -- all those we bless need to be reasonably-level playing 
fields.


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Robert Collins]

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

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Matt Riedemann]

On 6/14/2016 8:57 AM, Thierry Carrez 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. 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 ?



Being someone that doesn't attend TC meetings and doesn't follow every 
thread for every project in OpenStack, I'm having a hard time with 
concrete examples and what this means. I have a feeling a lot of this 
has to do with Neutron stadium stuff, which I haven't been following 
either, except I think it's getting reigned in (at least that's what I 
remember from the mitaka midcycle discussion).


From the Nova POV I'm really just reading this as compute drivers. We 
have some in tree and some out of tree. Among the ones in tree we have a 
wide mix when it comes to feature parity, in part because a lot of the 
early Nova API was written with libvirt and xenapi in mind (e.g. 
agent-builds for xen), or specific volume drivers interacting with a 
specific compute driver (e.g. os-assisted-volume-snapshots with 
libvirt). And then we have vmcenter, hyper-v and ironic.


And we have out of tree drivers, like zvm, lxd and powervm. powervm is 
actively trying to get in tree. lxd is not, nor is zvm (at least I don't 
hear anything from the zvm developers).


But taking zVM for example, I don't have a mainframe sitting around in 
my basement, so I can't test changes for that. Or a Power8 system for 
testing powervm. But that's why we require third party CI for things 
that we don't test in community infra.


So is the question does Nova provide a level playing field as a project 
because it has drivers that can be deployed and used and tested without 
special hardware, i.e. libvirt? Then yes. Or is it Nova doesn't provide 
a level playing field because zVM and powervm aren't in tree?


If this is really just, random project wants to be considered an 
'official' OpenStack project but is totally unusable without a 
proprietary stack to deploy and run it - which makes it completely 
vendor specific, regardless of whether or not they open sourced the 
front-end to talk to their proprietary backend, so only developers from 
said vendor can work on the 

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Doug Hellmann]

Excerpts from Kyle Mestery's message of 2016-06-15 09:05:59 -0500:
> On Tue, Jun 14, 2016 at 9:15 AM, Doug Hellmann  wrote:
> > Excerpts from Thierry Carrez's message of 2016-06-14 15:57:10 +0200:
> >> 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 ?
> >>
> >
> > I think external device-specific drivers are a much clearer case than
> > Poppy or Cinder. It's a bit unfortunate that the dissolution of some
> > projects into "core" and "driver" repositories is raising this issue,
> > but we've definitely had better success with some project teams than
> > others when it comes to vendors collaborating on core components.
> >
> 
> I don't see this as the "core and driver" problem bringing this issue
> up, as it exists out side of that. But it's true that in the case of
> Neutron, something had to give when we had 40+ drivers and a handful
> of cores maintaining both the neutron code itself and those drivers.

Sure! What I meant was that it's a shame so much maintenance fell to so
few folks. I wasn't second-guessing the hard choice to clarify what the
Neutron team felt you could support. That's completely within your
purview.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Thierry Carrez]

Amrith Kumar wrote:

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

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 
https://review.openstack.org/#/c/329448/.

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


I replied to that on the review :)

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Amrith Kumar]

Thierry,

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

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 
https://review.openstack.org/#/c/329448/.

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

Thanks,

-amrith

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Tuesday, June 14, 2016 9:57 AM
> To: OpenStack Development Mailing List 
> 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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Kyle Mestery]

On Tue, Jun 14, 2016 at 9:15 AM, Doug Hellmann  wrote:
> Excerpts from Thierry Carrez's message of 2016-06-14 15:57:10 +0200:
>> 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 ?
>>
>
> I think external device-specific drivers are a much clearer case than
> Poppy or Cinder. It's a bit unfortunate that the dissolution of some
> projects into "core" and "driver" repositories is raising this issue,
> but we've definitely had better success with some project teams than
> others when it comes to vendors collaborating on core components.
>

I don't see this as the "core and driver" problem bringing this issue
up, as it exists out side of that. But it's true that in the case of
Neutron, something had to give when we had 40+ drivers and a handful
of cores maintaining both the neutron code itself and those drivers.

> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Davanum Srinivas]

Neil,

On Wed, Jun 15, 2016 at 3:17 AM, Neil Jerram  wrote:
> On Wed, Jun 15, 2016 at 9:52 AM Thierry Carrez 
> wrote:
>>
>> [...]
>> Those are good points. Note that I do not advocate for those projects to
>> be kept closed/private: I'm simply saying that those (open source)
>> projects should not be blessed as "official" and be put under the
>> Technical Committee oversight. They can still exist in the OpenStack
>> ecosystem, be developed using Gerrit and an openstack/* git repository,
>> be plugged into the gate... but as an unofficial project.
>
>
> Could you point me to where it's described how to create and operate an
> unofficial project like that?  (Or are you talking about a possible future
> arrangement that doesn't already exist?)

Please see here:
http://docs.openstack.org/infra/manual/creators.html

>
> Thanks,
> Neil
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Neil Jerram]

On Wed, Jun 15, 2016 at 9:52 AM Thierry Carrez 
wrote:

> [...]
> Those are good points. Note that I do not advocate for those projects to
> be kept closed/private: I'm simply saying that those (open source)
> projects should not be blessed as "official" and be put under the
> Technical Committee oversight. They can still exist in the OpenStack
> ecosystem, be developed using Gerrit and an openstack/* git repository,
> be plugged into the gate... but as an unofficial project.
>

Could you point me to where it's described how to create and operate an
unofficial project like that?  (Or are you talking about a possible future
arrangement that doesn't already exist?)

Thanks,
Neil
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Thierry Carrez]

Doug Hellmann wrote:

From our perspective, we (designate) currently have a few drivers from
proprietary vendors, and would like to add one in the near future.

The current drivers are marked as "release compatible" - aka someone is
nominated to test the driver throughout the release cycle, and then
during the RC fully validate the driver.

The new driver will have 3rd party CI, to test it on every commit.

These are (very) small parts of the code base, but part of it none
the less. If this is passes, should we push these plugins to separate
repos, and not include them as part of the Designate project?


No. What you're doing is perfectly acceptable. Obviously the more
testing you can do, the better, but it's up to the Designate team to
decide what code contributions it considers it can support as part of
it's official code base. Whether that is organized in one repository or
many is also up to the owners of the code.

The problem has come up because other teams have decided they cannot
manage the large number of disparate drivers. Those have been moved
out of the main source tree, and those repositories are now being
de-listed from the "official" list in the governance repo.


Right, as Doug says, I don't expect Designate to have to change anything 
if this passes. As long as you accept considering new drivers, I would 
consider that a level playing field (same as the Cinder case I mentioned 
in my original post).


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Thierry Carrez]

Fox, Kevin M wrote:

Some counter arguments for keeping them in:
  * It gives the developers of the code that's being plugged into a better view 
of how the plugin api is used and what might break if they change it.
  * Vendors don't tend to support drivers forever. Often they drop support for a driver 
once the "new" hardware comes out. Keeping it open and official gives non 
vendors a place to fix the drivers in the open after the vendor abandons it and operators 
still have the hardware they need to support.


Those are good points. Note that I do not advocate for those projects to 
be kept closed/private: I'm simply saying that those (open source) 
projects should not be blessed as "official" and be put under the 
Technical Committee oversight. They can still exist in the OpenStack 
ecosystem, be developed using Gerrit and an openstack/* git repository, 
be plugged into the gate... but as an unofficial project.


So I think we can keep the benefits of having those drivers being open 
source (including visibility and long-term maintenance), while 
guaranteeing official "OpenStack" projects present a level playing field.


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Hayes, Graham]

On 14/06/2016 17:14, Anita Kuno wrote:
> On 06/14/2016 10:44 AM, Hayes, Graham wrote:
>> On 14/06/2016 15:00, Thierry Carrez 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. 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 ?
>>>
>>
>>
>>  From our perspective, we (designate) currently have a few drivers from
>> proprietary vendors, and would like to add one in the near future.
>>
>> The current drivers are marked as "release compatible" - aka someone is
>> nominated to test the driver throughout the release cycle, and then
>> during the RC fully validate the driver.
>>
>> The new driver will have 3rd party CI, to test it on every commit.
>>
>> These are (very) small parts of the code base, but part of it none
>> the less. If this is passes, should we push these plugins to separate
>> repos, and not include them as part of the Designate project?
>>
>> As another idea - if we have to move them out of tree - could we have
>> another "type" of project?
>>
>> A lot of projects have "drivers" for vendor hardware / software -
>> could there be a way of marking projects as drivers of a deliverable -
>> as most of these drivers will be very tied to specific versions of
>> OpenStack projects.
>>
>> I fully agree with the sentiment, and overall aim of the requirement,
>> I just want to ensure we have as little negative impact on deployers
>> as possible.
>>
>>   -- Graham
>
> I highly recommend you spend some time interacting with the Neutron,
> Nova, Cinder and Ironic communities to learn how they approach this
> issue. Each community has a slightly different approach to interacting
> with vendors with different pain points in each approach. I think
> learning from these projects regarding this issue would be a great way
> to formulate your best plan for designate. Also time spent with Mike
> Perez on this issue is an investment as far as I'm concerned.
>
> Thank you,
> Anita.
>

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Doug Hellmann]

Excerpts from Hayes, Graham's message of 2016-06-14 14:44:36 +:
> On 14/06/2016 15:00, Thierry Carrez 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. 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 ?
> >
> 
> 
>  From our perspective, we (designate) currently have a few drivers from 
> proprietary vendors, and would like to add one in the near future.
> 
> The current drivers are marked as "release compatible" - aka someone is
> nominated to test the driver throughout the release cycle, and then
> during the RC fully validate the driver.
> 
> The new driver will have 3rd party CI, to test it on every commit.
> 
> These are (very) small parts of the code base, but part of it none
> the less. If this is passes, should we push these plugins to separate
> repos, and not include them as part of the Designate project?

No. What you're doing is perfectly acceptable. Obviously the more
testing you can do, the better, but it's up to the Designate team to
decide what code contributions it considers it can support as part of
it's official code base. Whether that is organized in one repository or
many is also up to the owners of the code.

The problem has come up because other teams have decided they cannot
manage the large number of disparate drivers. Those have been moved
out of the main source tree, and those repositories are now being
de-listed from the "official" list in the governance repo.

> As another idea - if we have to move them out of tree - could we have
> another "type" of project?
> 
> A lot of projects have "drivers" for vendor hardware / software -
> could there be a way of marking projects as drivers of a deliverable -
> as most of these drivers will be very tied to specific versions of
> OpenStack projects.

The location of the code is an implementation detail when it comes
to describing the thing we ship.  A "deliverable" can be made up
of more than one 

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Anita Kuno]

On 06/14/2016 10:44 AM, Hayes, Graham wrote:
> On 14/06/2016 15:00, Thierry Carrez 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. 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 ?
>>
> 
> 
>  From our perspective, we (designate) currently have a few drivers from 
> proprietary vendors, and would like to add one in the near future.
> 
> The current drivers are marked as "release compatible" - aka someone is
> nominated to test the driver throughout the release cycle, and then
> during the RC fully validate the driver.
> 
> The new driver will have 3rd party CI, to test it on every commit.
> 
> These are (very) small parts of the code base, but part of it none
> the less. If this is passes, should we push these plugins to separate
> repos, and not include them as part of the Designate project?
> 
> As another idea - if we have to move them out of tree - could we have
> another "type" of project?
> 
> A lot of projects have "drivers" for vendor hardware / software -
> could there be a way of marking projects as drivers of a deliverable -
> as most of these drivers will be very tied to specific versions of
> OpenStack projects.
> 
> I fully agree with the sentiment, and overall aim of the requirement,
> I just want to ensure we have as little negative impact on deployers
> as possible.
> 
>   -- Graham

I highly recommend you spend some time interacting with the Neutron,
Nova, Cinder and Ironic communities to learn how they approach this
issue. Each community has a slightly different approach to interacting
with vendors with different pain points in each approach. I think
learning from these projects regarding this issue would be a great way
to formulate your best plan for designate. Also time spent with Mike
Perez on this issue is an investment as far as I'm concerned.

Thank you,
Anita.

> 
> __
> OpenStack Development Mailing List (not for usage 

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Fox, Kevin M]

Some counter arguments for keeping them in:
 * It gives the developers of the code that's being plugged into a better view 
of how the plugin api is used and what might break if they change it.
 * Vendors don't tend to support drivers forever. Often they drop support for a 
driver once the "new" hardware comes out. Keeping it open and official gives 
non vendors a place to fix the drivers in the open after the vendor abandons it 
and operators still have the hardware they need to support.

Thanks,
Kevin

From: Doug Hellmann [d...@doughellmann.com]
Sent: Tuesday, June 14, 2016 7:15 AM
To: openstack-dev
Subject: Re: [openstack-dev] [all][tc] Require a level playing field for
OpenStack projects

Excerpts from Thierry Carrez's message of 2016-06-14 15:57:10 +0200:
> 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 ?
>

I think external device-specific drivers are a much clearer case than
Poppy or Cinder. It's a bit unfortunate that the dissolution of some
projects into "core" and "driver" repositories is raising this issue,
but we've definitely had better success with some project teams than
others when it comes to vendors collaborating on core components.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Hayes, Graham]

On 14/06/2016 15:00, Thierry Carrez 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. 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 ?
>


 From our perspective, we (designate) currently have a few drivers from 
proprietary vendors, and would like to add one in the near future.

The current drivers are marked as "release compatible" - aka someone is
nominated to test the driver throughout the release cycle, and then
during the RC fully validate the driver.

The new driver will have 3rd party CI, to test it on every commit.

These are (very) small parts of the code base, but part of it none
the less. If this is passes, should we push these plugins to separate
repos, and not include them as part of the Designate project?

As another idea - if we have to move them out of tree - could we have
another "type" of project?

A lot of projects have "drivers" for vendor hardware / software -
could there be a way of marking projects as drivers of a deliverable -
as most of these drivers will be very tied to specific versions of
OpenStack projects.

I fully agree with the sentiment, and overall aim of the requirement,
I just want to ensure we have as little negative impact on deployers
as possible.

  -- Graham

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Ed Leafe]

On Jun 14, 2016, at 8:57 AM, Thierry Carrez  wrote:

> 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 saw the problem with Poppy was that since it depended on a proprietary 
product, there was no way to run any meaningful testing with it, since you 
can’t simply download that product into your testing environment. Had there 
been an equivalent free software implementation, I think many would have not 
had as strong an objection in including Poppy.


-- Ed Leafe






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

[Doug Hellmann]

Excerpts from Thierry Carrez's message of 2016-06-14 15:57:10 +0200:
> 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 ?
> 

I think external device-specific drivers are a much clearer case than
Poppy or Cinder. It's a bit unfortunate that the dissolution of some
projects into "core" and "driver" repositories is raising this issue,
but we've definitely had better success with some project teams than
others when it comes to vendors collaborating on core components.

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev