This is a problem I've totally run into before, and have been on both sides of from when I was a little kid posting in Usenet in the mid-1990's until today where I've tried on a few occasions to support groups doing fan games or open source games.
Basically, if you aren't paying people, then you are throwing a party, and if your party isn't great, people check out. Motivation, drive, focus are things you end up with by accident, and when it's a group project it becomes very tempting to let someone else make the first move and not look like a fool. And anything you do might be worthy of extended discussion the first time you do it. Which in combination with large scope(which tends to inflate as a way of avoiding reaching a concrete and coherent resolution on any decision), makes things go slower, and slower, and slower, until everyone has given up.
Plus it's easy to build a very flimsy kind of hype around the idea of "making a game" because games are fun at the surface, so lots of people sign up for what they hope will be a lightweight experience only for it to gradually sink in that there is a huge boulder to push up the mountain before the game can even resemble anything, and the things they thought they would work on and want to voice their opinions about are actually pretty simple decisions or only become relevant much later, while the majority of the work consists of blundering through the dark barely understanding how to move the project forward and learning new skills constantly to do so.
And even if you are paying people, this happens. Hiring people is a two-way thing in that while on a small team you would like for them to self-start and cover for you on many different fronts like intelligent automatons, the reality is that the average candidate will tend to hope that the job will be a straightforward fit to their very specific fixations and not require anything outside of that. Even more so when they're on a short term contract and already have the next gig on their mind - they may put on a brave face to pay bills, but no spoons will be spared to give your project special consideration, and if you let someone on who isn't up to it or is given insufficient direction, they crumble with anxiety and may be damaged by this toxic mix of obligations and inability to fulfill them.
And when put that way it becomes a little more apparent that team building is a kind of design process - you have to design both roles that you can fill and a workflow that puts those roles together in a way that does not blow up. Functioning game studios end up with a lot of overhead in the process because, as it turns out, what's acceptable for most people tends to be that mix of regular hours, a desk, bosses, meetings, and separations between "creative" and "business" roles. With all that stuff in place, the team can move forward and accomplish things even though not every member of it is a perfect fit or wholly engaged every day.
My solution has been to downscope to a project size that works for me alone and then fill in gaps by adding other people only once I think I have a clear role for them that doesn't cascade into "now you do all the work for me" - a lot of the fantasy of team building is that you just assemble the "artists/programmers/designers/writers" in a room and they automatically know what to do and how to resolve project decisions. Nobody does. Even if you've got motivated and skilled folks they will have blinders and bottlenecks. Even major, apparently better financed and organized stakeholders like publishers will fail at giving your project special attention and default to giving the low-quality, polish-focused feedback that you could get from any random player.
If you don't actually have the game done in any form yet I suggest rebooting it in a limited format that you can adapt from - the PICO-8, Twine or Bitsy version of the experience. Throw on as many limits as you can to avoid upscoping, even if it that means it becomes more like a mockup than a functioning game. If you can't finish it in that form, where the limits stop you from tacking on more stuff, then you don't have the game yet, you have an incoherent mess to untangle and prioritize. The team will have a much easier time seeing a working result and giving feedback on that than sitting in a long meeting going, "well, we could do any of these 50 things, let's keep all our options on the table."
Laatly, remember to mix group interactions with one on one interviewing. People share themselves differently in the two contexts and a lot of basic management issues can be resolved by going to person A and asking, "what's bugging you right now?" and then going to person B and saying "hey, person A is worried about X. Do you think you can help?" Because it will turn out that the communication just didn't happen before and they needed a go-between.