Going to try to keep it concise. Let me know if I don't cover enough detail
Community/FunIn the real world, people get a job for the salary and stick around for other things. In indie groups, people do it for friends and for fun. Never lose sight of this. It's not the only factor, it may not even be the most important factor, but once you lose the community feel, you lose your group, and you lose your project.
Do anything it takes to recover this once you've lost it. Maintain full communication. Keep your project momentum going. If all else fails, just get together with them and play Minecraft or even Runescape together. Do something together. Just make sure that in their spare time, everyone logs on to your central hub at least a few times a week.
InertiaThis is vital. Don't start a project if you can't maintain momentum. It's really hard to start it back up once it stops. Try to keep someone constantly doing something, maintain an illusion of activity if you have to, even if it's by rambling about future plans on your blog. I highly recommend a weekly blog or report so everyone sees what's going on. Also recommend having a good solid plan when you start; you don't want to put the game on hold for 3 months to review those plans.
CommunicationOk, well, I started doing group projects back in the Web 1.0 days and poor communication often killed things. Early on, email communication is good, especially now that Gmail does thread support. Maybe sign up for a separate "work" email, but link it to your main mail to organize things.
Later on, once emails reach bureaucratic capacity, consider signing up for forums. This makes it easier to share files, share ideas, put up bug reports and to do lists - all those little threads that people will post about once in 2 months but want to quickly reference later.
If you're communicating solely by email, CC stuff to each other all the time. You don't want a "central point" project manager who knows everything but leaves everyone else in the dark. This is confusing and demoralizing, and puts stress on the project manager.
Real time communication sometimes works, but it sucks online. Most people don't really go on IRC unless it's a big group. Skype works better than most IMs. Facebook works too if you don't mind giving out personal details.
LeadershipThis is a major point of argument among indie groups. This will make or break your group.
Democracy really sucks. It's slow, you have to wait for everyone to vote and not everyone logs on. It's pointless, people will just leave a group if they don't like the way it's being led.
Elect a leader, seriously. You will argue on a lot of points, the leader will settle this. Because of this, elect a leader who is the best decision maker. Quite often, this is the lead designer, because they have the best high level view of the game. Yeah, the fricking idea guy. Not a hard rule, though.
Keep in mind that the leader is not always the most skilled person in the group. (S)He's just the director. Respect him/her. If you can't respect them, choose someone who everyone does respect. There's bound to be someone better at programming/art, that's why you're in a group.
CreditGrow the hell up. Stop fighting over credit or do everything yourself. You're not here to show off your skill, you're here to create something together. If someone demands credit, keep a close eye on them, and kick them out before they become parasites.
The leader does not necessarily take most of the credit. If you have a good enough project, ideally nobody should take the credit. You accomplish it together as a team.
MoneyWhen it comes down to splitting money, figure it out before you make any money.. maybe late in the project when you see everyone's contribution.
Honestly, I think salaries with minor commission is the best approach, but not always ideal.
If everyone contributes equally, split the money equally. If someone put (more) money into the game, they get a larger share.
Sometimes you have a guy who invests most of the effort into it, from design to code to art. (S)He hires a few people to do background art, or sprites for a couple of levels, or code some of the minor parts of the game. Nice way to split the money is to give out 10% for minor contributions, 20% for dedicated contributors, 5% to contributions you can live without like background, music, level design. Not set in stone, just what has worked for me.
Project managementI find most RL approaches (gantt charts, etc) don't work in indie development. It's too complicated for a small group, unless you have 5+ full time workers. Part time, I've seen very large groups get managed just fine with a few people in charge.. but you'll eventually hit like 6 'senior leadership' people.
You may eventually want to create a heirarchy, like Lead Programmer, Lead Artist. Don't try to create a heirarchy for everything.. just because you have 3 programmers, it doesn't mean you have to 'promote' one of them. If you can manage it like that, don't fix it if it's not broken.
Seriously consider making a To Do list. You don't need expensive project management software. But people need to know what's being done, who's doing it, how long they (haven't) been doing it, who's responsible for all that.
And they need to know what to do. There are entire books written on how to commmunicate what needs to be done, figure out what works best for you.
Mutual interestAlso very important, make sure you have a group who agree on what the game should look like. Let everyone read the design docs. Nobody wants to make a game they don't want to play. Nobody wants to wonder if the game is going to end up like a game that they're not going to play; even if it does end up a good game, you want to remove all doubts.
Mutual designOne bad general is better than two good generals.
Give full control of design to one person. ONLY one person. One of the biggest mistakes I've ever made was to share design with someone. I based the design similar to Secret of Mana, he made his design similar to Sonic. It became really awkward that our designs just didn't click. Nobody spoke up because they were afraid of hurting feelings, until the group disbanded. Doing a post mortem, we easily identified it as the reason why the project failed.
Of course, make sure your Lead Designer isn't lazy. And everyone is free to recommend things to this Lead Designer, his/her job would be to filter out unsuitable ideas or modify/fix them in a way that they fit in with the rest of the design.
The Mascot/Cheerleader/Village IdiotThere's very often that guy who does nothing. Somehow you let him/her in. He/she might make FPSes while everyone else is making a RPG. Or he/she could just be really incompetent. But they have such an enthusiasm with the project itself that you can't bear to kick them out.
Don't kick them. Morale is vital (see my first point). It's infectious. The attitude of this useless person pays off far more than it does on paper. Give them something minor to do. There's always admin work; cleaning up threads, sorting bug reports and suggestions, setting up repositories or whatever.
Failing that, just keep them for beta testing or updating the project blog (if they can write properly). Or customer service/moderation.