Yes, I agree. Free labor is cheap, but you get what you pay for. I think volunteer projects are great for learning new things and getting experience, but it's excruciatingly difficult to seriously build a game which you want to release based on free labor. I personally would never attempt it or join a volunteer project. That's not to say it can't work though. I met a team of developers upstairs in our building who are all working together for free on an HTML5 MMO (top down shooter). Each of them are living off of personal savings from prior jobs and have been slaving away on this project for almost two years. One of them has until next summer until his bank account runs dry, so you can guess what kind of stress and pressure they're under. So, I suppose it's worth noting that "free" labor is never free for everyone -- bills and living expenses don't stop.
If he's talking about getting people to work on the project for free, though, these things become much more complicated.
I disagree and still stand by my original claim.
Game design needs to be done from day 1.
Only as little as possible to avoid severe creative differences.
Nobody wants to work for free on somebody else's game design. It's much more useful to motivate people by giving them input in the design itself, so it's not "my game", it's "our game", which is a kind of creative reward that has value in itself even without pay.
You have to narrow the game design down enough to avoid a complete lack of direction, feature creep, or conflicts between team members. Such as: one only likes JRPGs, the other only likes FPS - how do you resolve this? You don't. You only recruit one of them based on their having similar interests in line with the overall goal.
Narrow it down only just enough, but leave it open so contributors can feel like it's their game. Achieving that balance in itself is something of an art.
Imagine you're brought on as an artist onto a project and are told by someone, who doesn't really know what they want, to make the art for their game. You have no idea what they're trying to build and it could change at a moments notice. A detailed game design is something solid to stand on and something to work off of. It tells you exactly what needs to be built and how it should all work together with other parts of the game. Without it, it's like you're standing on a constantly shifting sand dune which changes form with the winds. When you have to build concrete assets, it's excellent to have as much requirements definition as possible. Naturally, the game designer can't detail out every single nuanced detail, so the *creative* part for an artist is in the actual creative production of the asset. The look, feel, character, style, etc.
If you think the artist is going to be annoyed by a lack of definition, just imagine how much more annoyed a programmer would be (speaking as a programmer myself). I WILL not write up a complete game system if I don't know exactly how it needs to work. There isn't any "figure it out as you go". I also happen to design my own game, but I haven't designed all software I've built. There is nothing more sexy to me as a programmer than an air tight design. There's no thinking required, just implement it to the spec! There is no confusion. You know what needs to be built. It's very refreshing to work on projects with clear definition.
One thing you do allude to, which is critical, is "stakeholder buy-in". You don't need to give everyone on the team creative control / input on the game design. Chances are actually really good that most people are actually not very good game designers. It's actually *really hard* to do correctly. A programmer is an expert at writing code. An artist is an expert at art. A producer is supposed to be an expert at project management. A writer is an expert at writing. Game designers are experts at building game systems. You wouldn't want your artist writing code, or your programmer creating art, so why would you have either of them doing game design? That's not their specialty, and not the only way they have creative input into the production of a game.
Yes, this is bad. What you describe is exactly what you want to avoid in a serious project. Pick any well produced game and really look at the art style in it. It's consistent. The color palettes are intentionally chosen to create an intended feeling / atmosphere. Think of Skyrim, how they have a bit of a saturated color palette and pretty realistic character models and environments. Now, imagine what Skyrim would have looked like if they had 30+ artists come in, each with their very own unique interpretations on what the game should look like. Some would go for a my stylized approach, others go for hyper-realistic, some go for cartoonish, etc. In a vacuum, each art asset would look good, but when you put them all into the same universe together, you can't convince the player that the game world has consistency and you break the suspension of disbelief, which causes a loss of player immersion (which some mods break).Where volunteer projects are concerned, that's almost impossible. People will come and go from week to week, maybe only contribute a couple sketches, or one sprite. Things are unfortunately very unlikely to match.
Art and style guides needs to be done from day 1.
And most artists who will work for free are both unwilling and unable to follow a strict style guide.
The rare and magical exception to this is FAN games, which are ripping off a very popular IP that the artists want to copy.
For example, some Zelda fan games have gone pretty far in getting various artists to work together to make consistent assets. They are also more motivated by fandom.
However, this is also illegal.
For programming, it's a little easier for somebody to drop in and contribute a function or two.
In the case of artists, you may either have to learn to accept inconsistency, or bite the bullet and pay for art.
If you're really lucky, you may find a half decent artist who will contribute to the project in a big way for free, but you'll have to pay them in spades in terms of letting them reign as king over game design and story in order to get that kind of investment. You'd basically just be finding an artist to work for to make his or her game idea. And even then, they may still flake off one by one, and have to be replaced, completely gutting all of the game's story and art for a new artist to move in.
Keep it simple, and make sure all the art for the game can be finished in a few weeks by one artist; that will maximize your chances of making it work.
As for programming, it's equally problematic to have people pop in and write up a function or two and disappear. As a programmer, you *have* to be familiar with the code base / framework you're working within. That costs time for us to get familiar with it (ramp up time). If a programmer doesn't spend time getting familiar with what they're working with, they run a huge risk of breaking something or writing code which has already been done.
Anyways, I guess my whole point here is that people are super important to the success of a game project. In some jobs, people can be treated like interchangeable components -- not in game development! The ramp-up time for a person to really get into a project and become an expert is long, and you can't ever carelessly throw away your most valuable resource (staff) through people mismanagement. If you're going to be serious about building a game and releasing it commercially, you can't afford to screw up the building of your team. If you're just working on a school project or hobby project, recruit away!