@grimalkina Thanks for this. I've been an Open Source maintainer for a major project, I had my project attacked, and I did burn out doing so from community abuse, so I sadly speak with a tiny bit of experience, along with my overall experience as a software engineer and technical executive.

(1/n)

@grimalkina
A difficulty with software work is that it begins by dealing with code and it evolves into dealing with people. For professional work, that tends to happen at milestones that are more or less predictable, i.e. promotions.

For Open Source, the timing of that transition is unpredictable and uncontrollable. The worst that can happen is to have no users, because the efforts go to waste, but the worst that can happen is to have users, because now you have to deal with them.

(2/n)

@grimalkina Another very messy aspect of Open Source is related to time-frames and people's priorities. Open Source licenses are forever, but people's involvement is not, at least not automatically.

Chances are, original authors of Open Source want to do good, and they express that by releasing code. Over time, though, it's not about code, it's about people, which becomes a potentially toxic situation. However, the underlying desire to do good keeps maintainers from saying "no".

(3/n)

@grimalkina That has me wondering, should Open Source leaders set better expectations that authorship of code and stewardship of a successful Open Source project are two very different roles, that require different skills, such that people who did the first part well might not be ready for the second part?

In turn, should we work to recruit people who are good at the second part, even if the first part isn't as interesting to them?

(4/n)