Traditional wisdom says that the "code first, design later" approach is a bad idea. However, Charles Miller points out that when it comes to open source projects, it's mandatory:

I would almost go as far as saying that starting an open source project with no code and a committee trying to decide what to do next spells inevitable doom.

The best way to start an open source project is with code. Working code. Hack away at home on weekends, maybe get a couple of friends to help you out, and don't go public until you have something to show people that does something interesting, and that other people can use to build more interesting stuff on top of. You need this for a bunch of different reasons: it establishes the original contributor's bona fides in the open-source meritocracy, it shortcuts all sorts of damaging debates about coding styles and architecture that can stop a project before it starts, and so on.

Most importantly, though: working code attracts people who want to code. Design documents attract people who want to talk about coding. I've seen what happens on projects that start with no code and a commitment to produce a design. Some of the procession of UML diagrams were really well put together, but that's about the extent of it.

As I've said before, good programmers get off their butts. Obviously, you want to consider what you're going to do before you do it. But there's a rapid point of diminishing returns for thinking versus doing.

Software development is a wicked problem: you never fully understand the problem you're trying to solve until you reach the end. So the sooner you start, the better.