Have you considered adding your project to a site like https://www.codeshelter.co/ ?

I don't have experience with it, but it seems active and better than abandoning a project.

Good luck!

> I've had a few people offer help over the course of the years, but unfortunately they don't always have all the skills needed, so they can only help with a part of the project.

So whats wrong with allowing them to help with those parts?

Allowing people to help also takes time...there's a non-trivial management effort involved...one that's too frequently forgotten about in these discussions.

This is very true. Even when collaborating with very skilled engineers, it takes a lot of time and energy to respond to ideas, questions, and review PRs. It’s like a regular programming job to a certain degree, but you’re typically not paid for doing it.

Software can be shitty garbage in many ways. It can be shitty garbage by having lots of bugs, and it can be shitty garbage by having a maintainer which cares more about bottlenecking all changes than about the future of a project.

But everyone is free to make shitty software, so have at it.

Wow, calling people's software shitty because they care enough about it to want to vet contributions?

I don't know why you're being downvoted for a truly honest question.

The answer to this is that getting partial help sometimes costs more time than getting no help at all.

This seems like one of the potential tragedies of the "all volunteer" development model. Many of the factors that play into Brooks's Law apply just as much to volunteer efforts as they do to commercial efforts.

One of them is the cost of communication. My sense is that the overall cost of communication scales in a manner that's more in line with the number of active contributors than it does with the actual volume of communication that they produce. Even the actual time spent communicating may not do so, but the kinds of communication - getting to know new people and new teams, negotiating different and potentially conflicting needs, stuff like that - tend to be more tiring than the communication you get in a stable team of people who have been working together for a while.

But, if you can't make a living doing it, then you probably aren't prepared to contribute more than a very small amount of your time. A large group of people doing that might have an outrageous communication cost relative to its productive output. With the brunt of that being born by the maintainer.

I would imagine that, if we could figure out a better way to enable maintainers to support themselves and their families while also working on their project full time, things might work out better. More time spent programming means less need to negotiate with and review contributions from others, and the work getting done more quickly because it's being done by the person who knows the code best, and the job being both less tiring and less thankless, and possibly leads to higher quality (by virtue of being more coherently designed) software in the long run.