Wondering what can be done to stop this from happening? Or, companies have boards that help the transition from small to large company, open source projects have no such thing.
Wondering what can be done to stop this from happening? Or, companies have boards that help the transition from small to large company, open source projects have no such thing.
One tip I came across last year really helps: add maintainers to your project earlier rather than later. If someone sends s few quality pull requests, I give them commit access.
I give people commit access as soon as I merge a single pull request from them. It works out pretty well. Anyone can merge in other pull requests, fix simple things, etc.
Downside is that I’ve had to clean up things a couple of times when not quite correct things have been merged. It’s only happened around 2-3 times since I started giving commit access over a year ago, so it’s a price that I don’t mind paying.
I’ve heard that suggestion before and it worries me.
Is there someone who reviews all commits?
What do you do when committers add anti-features, disagree on the goals of the project, etc.?
I’ve never had a problem with anti-features or different goals. I’ve only had a few minor problems with correctness.
People just file issues or send an email before making big changes. Then they often send a pull request.
My projects are usually very tiny. That could be the reason it works so well.
fat (best known for bootstrap) also has been thinking about this.
I wonder if this is a particular failing of github to create a sense of community ownership. (I worded that strangely, I don’t mean github really failed, but perhaps there is a better way to express “welcome new developer, come solve these problems for us!”).
Many years ago when I was interested in solving other people’s OpenBSD problems, I’d watch the bugs mailing list. I’d send patches for anything, even if I didn’t know anything about the code in question. There have been a couple other developers over time who’ve done the same. Of course, eventually we get tired and stop, but then somebody new comes along and helps out. I don’t know how to start that or if it just depends on a large potential developer userbase or what. OpenBSD developers burn out (“start slacking”) all the time. Some come back, some don’t. Some qualify as hackathon only developers, who show up just once a year. But there are always more.
Showing even minimal signs of life at all times may help. e.g., there was a time I may have considered sending a patch for enlightenment, but why bother when the project was clearly dead? Small dead projects are prone to private forking. OpenBSD is too large to make that practical or desirable, and at least some part of it is always moving forward. Call it the one foot in front of the other approach. As long as your project is moving, even at glacial speeds, people would rather get their patches integrated than be left behind.
(Tangentially, I have somewhat heretical views about git vs cvs and branching. Maintaining a branch in cvs is so hard that it’s never worth it, and therefore people are compelled to get their patches accepted into the main line, which makes cvs the better choice for long term cohesive development.)
Also, wondering who in the communities I contribute to most is at the highest risk of burnout, & wondering what I can do to help.