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
