This was done quickly, it mightn't be the most articulate words of advice.
Learn how to lead. Define a project. Start up the outline, explain what you want to achieve. Make it detailed enough for people to understand the intricate methodologies used, without putting a burden upon them to feel forced to look into it without giving a damn. If you do something antiquated, allow for someone else to point it out, learn a new technique which would be more efficient! Allow for people to come, and join the project, when you're in your first BETA release, you'd find that you have quite a few people on board, humble yourself to the public. Look into how F/OSS OS developers, distribution developers get co-developers. Look into things like Ubuntu/Python, and their history, how they started out, and expanded.
If it's interesting enough, and advertised well enough, people that are developing similar technologies, or are interested out of morbid curiosity would come along. Each would most certainly have something to offer, advice/criticism, use this to your advantage. Present new and creative ideas well, and descriptively. Look into open source development mailing lists, internet-relay chat, etc. Learn how to gather information.
Understand the principles of estimation
You're going to have to do a lot of estimation when working with people, and when you have time-lines. Be able to make predictions, and counter-predictions, and counter-counter predictions. You never know when you'll end up in an impossible situation without an idea of how to get out of it.
Understand that people are very different, with many varying colloquialisms. You may certainly encounter that the most able people you have are very difficult to deal with, don't let anyone bully you into decisions, but also maintain equality amongst everyone, listening to their point of views, you could see that this would be very profitable early on. Use people as sources of information, you develop greatly with social interaction. Learn how to be trustworthy amongst your co-workers. Try not to pretend that you're an expert in a field where you have no knowledge. Honesty is the best policy when working on close proximity to others. Being honest helps you learn new and diverse skills that you never imagined would crop up. Even later on, if they present code that's of bad quality, don't be quick to judge, understand the environment under which they're forced to code in. Professional projects tend to put programmers under pressure, causing them to implement things that are not of their best work.
Most people fail to understand that software design and development is almost always a compromise between what the project actually does and getting the project completed or even in its first actual release! Outline your project goals, and the time you need to spend on each aspect of the project.
Further along the road, you'd encounter other problems. I suppose this answers your initial question, at least. There are documents which provide insight into leadership techniques, look into a few of them :)