Building a healthy community doesn't just happen by accident.
Too many open source devs put almost no thought into the cultural aspects of building a community that is (1) not full of jerks, and (2) able to attract meaningful support from the businesses that use the code.
Those things can be done, if you try, especially if you start early in the life of the project.
Devs aren't supermen. A lot of people get into open source because that's the way they feel they can best do something good for the world, to put their software development talents at work.
Asking them to now go and develop a new set of skills, political savvy, that aren't just not in the same ballpark as dev, but not even in the same sport, they're going to just throw up their hands and walk away from OSS.
When firms have talented but politically-averse individual contributors, they give them managers so as to best direct those talents. OSS needs to stop expecting themselves to do everything and get some bosses to shoulder some of the burden.
What I think you're hinting at is that OSS shouldn't just be for the developers. People who are good at curating a community but don't write a line of code are super valuable. They should be seeking out OSS projects (and OSS project owners should be seeking them out).
I have to disagree with that. If you don't write a line of code, how are you supposed to actually understand what's going on? OSS projects are not simple Hello World applications here.
> how are you supposed to actually understand what's going on?
By talking with developers of the project! All it takes is a few conversations to get an idea about the why/what/when/ about a project and understand enough of its internals to be able to articulate those same things to others.
Numerous other things can be done by people who don't write the actual code:
* Writing a great "Getting Started" guide
* Writing great conceptual documentation
* Acting as a community moderator and squashing vitriol
* Acting as a contact for companies needing work done on the project
* Keeping things like Github Issues fully tagged, organized, and traced back to from Pull Requests
That's just off the top of my head. There are likely many more things that an OSS project would value which someone who isn't writing code can do.
You can just hang out on an IRC channel for a project for weeks and get a lot of ideas about how things work. Also, if we pitch documentation bounties the same way we do bug bounties, we'd probably have a lot better documentation for software projects. And if your project moves so fast documentation falls behind often, perhaps your project needs to redefine its core features enough or at least mark what is experimental and shouldn't be relied upon too much for production code. None of this stuff really needs someone to be anything more than familiar with general coding concepts. Heck, just hire some random person out of a coding academy and they can document as a way to learn the internals of a project for a while - not a lot of harm can be done to a codebase by documenting it, right?
I would look at it sort of like a CTO/CEO relationship, but with a somewhat inverted power dynamic (if there is one at all). You have someone reliable who you can ask when a technical question comes up (so that you can determine whether someone else in the community is trying to tech-bullshit you), but you have a better grasp on how to deal with the human aspects of the community.
That said, I'm not sure where you're going to find these people. Good managers are probably getting good manager jobs, and likely don't have the time to hand-hold another community. Combine that with the fact that their power mandate will be less clear in a community, and I doubt you'll get many people that want to get involved in this way.
There's a lot that people can do without knowing how to code. QA and support are two tasks that are often horribly understaffed in OSS, and in larger projects, you don't want developers doing these tasks because other people can do them equally effective and developer time is better spent fixing things.
In general I agree, but my own experiences (mostly with FreeRADIUS) show that sometimes a very "direct" maintainer can scare away most of the nagging riff-raff that this article describes. An inclusive community is great, but it seems like some companies might see that as an opportunity to take advantage of the project.
Just to give you some perspective, requests is one of the most used packages in the python ecosystem and it has an amazing community. If you're having trouble finding funding for a project that is as good as requests, then there's most definitely something wrong.
Too many open source devs put almost no thought into the cultural aspects of building a community that is (1) not full of jerks, and (2) able to attract meaningful support from the businesses that use the code.
Those things can be done, if you try, especially if you start early in the life of the project.