It might be worth looking on how other organizations in our ballpark are doing stuff.
f.e. IETF/ISOC is in similar situation to Debian/SPI. I am not directly involved in looking into IETF financials, but they have contracts for certain functions (Ops, RFC Editor to name few, for full list see https://iaoc.ietf.org/contracts.html). I agree that crunching the numbers must be a first step, then next step might be identifying roles within the project that can have clear job descriptions, that might also include roles that we currently don’t have because it can’t be filled by volunteers work. Then this must also include balancing whether we can improve the function if the function is contracted and there are “hard” requirements. Personally, I don’t have any problem with paying people with Debian money if the competition for the function is transparent (thus done by third party in our case), time-limited and clearly specified so we can end the contract if the conditions are not fulfilled by the other party. Ondrej -- Ondřej Surý <ond...@sury.org> > On 1 Jun 2019, at 01:07, Russ Allbery <r...@debian.org> wrote: > > Adrian Bunk <b...@debian.org> writes: > >> My biggest high level concern is the income side, since this is the most >> difficult part and will likely also be the most controversial one. > > I could well be entirely wrong, but the part that I would expect to be the > most controversial is that, once Debian starts spending project money to > pay people to do work that other people in the project are doing for free, > the project is doing a form of picking winners and losers. We're deciding > as a project that some people's work is valuable enough to pay for and (by > omission if nothing else) other people's work is not, and for all the good > intentions that we have going in, there are so many ways for this to go > poorly. > > If we're only hiring people from *outside* the project, not each other, > maybe that avoids the worst of the problems, but it's still an odd > dynamic. For example, it creates a perverse incentive for someone to > resign from the project so that they can be paid for the work they're > currently doing as a volunteer. > > I'm particularly concerned what will happen if something goes wrong: we > pay someone to do additional work and that work isn't up to the quality > standards that we need. Now what? If that person is also a Debian > Developer, we have now introduced an aspect of job performance feedback > into a volunteer community. While doubtless there are Debian Developers > who are also managers in their day jobs, that's not something anyone is > currently doing *in Debian*. Managing feedback and consequences for poor > performance is a skill that we are not currently exercising and that is > not trivial to learn. > > These problems generally go away with externally-funded initiatives such > as LTS. In that case, even when Debian Developers are involved, it's > clear that the person with the money is making contract and hiring > decisions, is the person who can decide to fire someone from that contract > if they don't like the work being done, and any decisions made there are > entirely separate from one's ongoing Debian work as a volunteer. People > still have to decide what they're willing to do for free and what they > want to be paid for, but it helps a lot that LTS is scoped to one specific > problem and has resources such that, if everyone else decides they're not > willing to do LTS support for free, the initiative still survives. It > also helps considerably that LTS was something we as a project had decided > not to do with pure volunteer resources, so it's a pure incremental on top > of project work. > > Maybe we can find more things like LTS that are pure incrementals over > what the project is currently doing, but I'm pretty worried about the > social dynamic of paying people to do core project work that others are > currently doing for free. > > I assume the above is the sort of thing that Sam is referring to when he > says that we need to have a higher-level discussion if we're going to > pursue this idea. > > -- > Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> >
