3 times in a row is a bad streak, so I understand your need to assess the situation (and that's a good thing to do).
First of all, my instinct would be to find the underlying cause. It is POSSIBLE but UNLIKELY that you just happened to hire a full crew of misfits, and even if it is the case, this could be boiled down to one underlying cause.
So let's examine the likely culprits:
1. Were the people on the team the RIGHT people?
When working for free, you generally have to select from a much smaller pool of potential individuals, and oftentimes without proper background. It's not that they don't have proper skills, but without previous experiences, it's very hard to judge of a person's worth.
Thus, you end up hiring a lot of people without much of an idea of what you're doing.
Put the wrong blend of people together, or even just one 'bad' person in the mix, and before you know it, things all go to shit...
2. Was the vision clear?
It's perfectly possible you've hired a bunch of skilled people to do the 'next RTS', but everyone had a fairly different idea of what that meant.
Since your team is working for free, they're all hoping to achieve something more from this product. For some, it's a step into a day job in the video game industry, for others, it's learning, for others yet, it's doing something amazing without external influences from a publishers, etc.
Was that clear with all team members from the get-go? Did some people join despite not being aligned with the general or specific vision of the project? (This is more based on SC than C&C for example, or here are the core values of this game, etc.)
3. Was the RIGHT person in charge? And was there really SOMEONE in charge?
Most projects benefit from having a single entity that has total and complete power over each area of development. This can be broken down per section (a lead for art, a lead for programming, a lead for management, etc.) but there needs to be someone.
Was it clear before the project started who these individuals would be, and how they would exercise their authority? How much freedom was given to other team members?
Finally, in practice, who ended up 'making the calls'. Was that as intended?
It takes development skills to contribute to a team positively, but it takes a much different skillset to LEAD them. Did anyone in your team possess this skillset and some experience?
Video game development tends to mix 2 major things: creativity & problem solving (pragmatism).
Creativity can come in the form of art, and design (mostly), while problem solving comes under Management, Programming and QA most of the time (depending on the project that can often vary, and most designers, especially level designers, tend to fit both sides of that coin).
This is a constant clash between several groups of individuals that happen to be at different points along these two scales.
As a general rule of thumb, unless you happen to come across a (much desired!) technical-oriented and organized artist (possibly with freelance experience which hints at a good ability to self-organize), you're generally dealing with 'chaotic beasts' that can really contribute to your project creatively, but need to be handled very differently from say, your programmers. Likewise, Programmers will generally tend to be more pragmatic (unless you come across a pearl of a gameplay programmer!).
Depending on your personal background, you will interface better with one group, and much less so with the other. As a result, you will tend to understand the concerns of one group, while the other's will elude you. Despite fully trusting your team, it will be easier to act on things you understand than things you don't.
Now, imagine that everyone on your team has this issue.
If the situation is left unchanged, 'clans' will form, and they'll blame each other for everything that is wrong instead of trying to fix the problems. This is bad. Very very bad.
What it needs is management, that is, someone that will take point, 'translate' the information for one group to the other to help bridge out communications, and take the blame for everything (and I mean, EVERYTHING). You don't want them to live with the feeling they're surrounded by slacker-no-good-doer-enemies. By giving them a leader, you're telling them:
If there's an enemy, then there's only one: me, but fear not, I'm on your side, and I'll bleed to help you achieve what you're trying to do.
It is much harder for a team to hate one another when you point the cause of everything bad on yourself, and remind them of what successes they're having as a group.
A bit more on being the 'bad' part of the team: I realize there are two different approaches to this. Some prefer to say we fail as a team, or we win as a team, and I tend to practice that a lot, but from my indie experience, I've had more success being the 'weakest link' as it provides unpaid teammates with a tangible reason for all of their 'why's and, imo, it works better with people with less industry experience & maturity.
In both cases, the most important part is to remember that you need to be there every step of the way, and help wherever you can (whether you've done 'this' before or not, whether you care or not, whether it feels important or not). Sometimes, it is true that the best thing the leader CAN do is bring donuts: these are the good days, when your team knows what it's doing!