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 Adrian Bunk <bunk@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 themost controversial is that, once Debian starts spending project money topay 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 decidingas a project that some people's work is valuable enough to pay for and (byomission if nothing else) other people's work is not, and for all the goodintentions that we have going in, there are so many ways for this to gopoorly.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 odddynamic. For example, it creates a perverse incentive for someone toresign from the project so that they can be paid for the work they'recurrently doing as a volunteer.I'm particularly concerned what will happen if something goes wrong: wepay someone to do additional work and that work isn't up to the qualitystandards that we need. Now what? If that person is also a DebianDeveloper, we have now introduced an aspect of job performance feedbackinto a volunteer community. While doubtless there are Debian Developerswho are also managers in their day jobs, that's not something anyone iscurrently doing *in Debian*. Managing feedback and consequences for poorperformance is a skill that we are not currently exercising and that isnot trivial to learn.These problems generally go away with externally-funded initiatives suchas LTS. In that case, even when Debian Developers are involved, it'sclear that the person with the money is making contract and hiringdecisions, is the person who can decide to fire someone from that contractif they don't like the work being done, and any decisions made there areentirely separate from one's ongoing Debian work as a volunteer. Peoplestill have to decide what they're willing to do for free and what theywant to be paid for, but it helps a lot that LTS is scoped to one specificproblem and has resources such that, if everyone else decides they're notwilling to do LTS support for free, the initiative still survives. Italso helps considerably that LTS was something we as a project had decidednot to do with pure volunteer resources, so it's a pure incremental on topof project work.Maybe we can find more things like LTS that are pure incrementals overwhat the project is currently doing, but I'm pretty worried about thesocial dynamic of paying people to do core project work that others arecurrently doing for free.I assume the above is the sort of thing that Sam is referring to when hesays that we need to have a higher-level discussion if we're going topursue this idea.-- Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
|