I would like to clarify that I was not claiming TAC pays for the development of code
the way I read Ross’s email is that “don’t pay for code” is actually in service of a higher-level principal, being: “don’t choose winners”. and I also understood from his email that we perceive resource allocation to be the primary way in which we might “choose a winner” therefore, my argument is this: we already allocate resources in ways that benefit individual projects. one example is TAC assisting a person who contributes to Apache Foo that’s not to say that this is the only way TAC assists people. instead, I am pointing out that TAC is capable of assisting people in a way that can be argued benefits specific projects the same is true for budget/resource requests that PMCs are free to make which leads me to my overall point: there is clear precedent for us assisting individual PMCs, and individual people in a way that benefits individual PMCs. we already trust ourselves to be able to adjudicate such things fairly and inline with our principals and goals so my suggestion is this: instead of focusing on “we don’t pay for code”, how about we focus on what problem that rule was designed to solve and then consider whether it necessarily applies to the proposal that the ASF is involved with the funding of an Outreachy internship for all this talk of principals, it seems to me as if we’re focusing on what our principals say rather than what we want them to do On Thu 20. Jun 2019 at 18:58, Ross Gardler <[email protected]> wrote: > I was answering a specific question about policy without applying it to > any specific situation. Yes, the question was asked in the context of > Outreachy, but I believe it was worded in such a way to understand the core > principle in order to then think, sensibly, about how it applies to a > specific situation - such as Outreachy. We (the ASF broadly) need to spend > more time understanding why we have strong opinions on some things before > we start saying they don't apply to new situations. Understanding the > history helps us design solutions for the new situation that respect the > original reason for the position. > > For this reason I have changed the subject of this reply. In this reply I > am not talking about why the policy exists but rather exploring how we > might apply the policy to this new situation. > > The goals of Outreachy have no bearing on our policy to not pay for > software development. That's not to say we can't seek to support the goals, > it's only to say we need to do it in a way that works for the foundation as > a whole rather than the goals of a single committee. We should not be using > the good work of another org to give permission for us to change a long > held policy that is a core part of what makes the ASF successful. We need > to find a way to do it such that it is compliant with the policy AND meets > the goals of this committee. > > FIrst, we need to be clear about what other committees have done in the > past. For example, the ASF does not allocate funds for *code development* > through TAC, as is claimed below. That was something we very carefully > designed when setting up the policies for TAC. For example, we do not > require that people write code for ASF projects in order to be eligible, > neither do we prioritize one project over another (ASF or otherwise), bor > do we require that participants are or become committers or even > contributors. What TAC aims to do is bring down some of the barriers to > entry to our community for people unable to attend F2F events. The hope is > that some of these people will go on to contribute to a project of their > choosing - not the ASFs. Some of them do, some of them do not. All benefit > from the experience and go on to use their experiences in many ways. > > TAC is an example of how we can break down barriers without impacting the > policy of not paying for code. This year we figured out how to use the > existing TAC process to benefit a specific minority group since we received > some directed funding for that group. The fact that we could do that with > no change to the selection process means that we got the process mostly > right when we set it up all those years ago. That's what we should we > should be aiming for here. Some policy that allows us to leverage new > opportunities in the future without long and protracted discussion as to > the unintended impact of doing so. There is no "slippery slope" if the > initial approach covers all perceived risks. The "slippery slope" is not as > dangerous if we have very clear guide-rails to hold on to and barriers on > the slope itself. > > I believe that paying for operational level projects is OK. We do already > do that. This is a barrier people are proposing on the slope. I think it is > a good one. > > An argument has been made that such projects are not representative of a > "normal" ASF project. This is true, to an extent. I argue this is > irrelevant since they are ASF projects with some of the same people, shared > code, contribution guidelines and decision making processes etc. I think > they are good introductions to the ASF and can lead to further engagement > in other projects. But that isn't really the goal here. The goal is to > lower barriers to engagement (as Naomi notes below). It doesn't bother me > if none of these people go on to contribute to ASF projects. I see it as > part of our educational mission to help educate people who want to learn > about how the ASF works. They will take this learning into other parts of > their life and we will all have done our jobs. Therefore, I believe this > argument is not a blocker. > > Ross > > > Get Outlook for Android<https://aka.ms/ghei36> > > ________________________________ > From: Naomi S <[email protected]> > Sent: Thursday, June 20, 2019 8:50:56 AM > To: [email protected] > Subject: Re: Why does the ASF not pay for development? > > On Thu, 20 Jun 2019 at 09:42, Ross Gardler > <[email protected]> wrote: > > > We don't pay for software development in our projects because our > > "software project communities consist of individuals who choose to > > participate in ASF activities." Paying people to produce the software is > > not creating communities of people who choose, but rather (in part) > > people paid by us to be present. > > > > I want to point out here that the purpose of Outreachy is to remove the > socio-economic barriers that exist that prevent people from choosing to > contribute to something like an Apache project > > this isn't semantic hair-splitting > > as it stands, with open source in general, contributing requires that you > have the resources (computer, knowledge/skills, free time) to do so. and > the temperament to do so (i.e., the ability to deal with the > culture/environment that goes along with contributing). which probably > doesn't seem like a big deal to a lot of people here. but that's > survivorship bias for you (i.e., necessarily, we all have those things, so > we're less aware of how much they contribute to our ability to contribute) > > these barriers to contribution lock out a substantial number of people. and > I would argue that THIS also makes it difficult to "provide software for > the public good". because we only have a thin sliver of "the public" > represented here > > if this was just about paying people salaries to contribute to Apache > projects, yes, I could see the argument that we were choosing which > projects win. I could see that argument that those people were not > "choosing to be here" (in the sense that the choice is being made by the > market--because a lot of people contribute on their employer's dime, as you > point out) > > but that's not what Outreachy is doing. Outreachy is about removing > barriers. about enabling people to make that choice in the first place. > something that likely isn't even consciously present for a lot of us > because it's not something that we have to consider > > > By putting ourselves in a position of influence we can no longer be > independent of market forces > > we already put ourselves in a position of influence when we allocate funds > via TAC, or when allocate funds/resources to projects that request them for > other reasons. and we trust ourselves to do that in a way that is fair and > vendor/market/project-neutral > > this is the same rebuttal I have to the "slippery slope" argument. it > presumes that we are unable to exercise good judgment when required to do > so >
