My experience is that there's a balance to be achieved.
Right now, I'm working (in the sense of answering questions and providing development suggestions, without seeing any code) with a developer who's producing what looks to be a very exciting FOSS project that utilizes code I've written. The public release has been repeatedly delayed by realizations of design changes that will make the project much better in the long term, but which require significant rewrites of code that's already been written and that was already "working". My view is that, had a working but imperfect release been made as soon as there was something working to show, ideas for changes (and actual patches) could have come from the broader community that's interested in this project an accelerated it forward rather than having the issues surface slowly, one-at-a-time, as the developer thinks of them and asks for design feedback from myself and other interested members of the community. So from this standpoint, I'm very much an advocate for "release early, release often".
On the other hand, low-quality releases can make a new project look bad before it even gets off the ground. Some pitfalls I've seen include:
- Skeleton trees with interface definitions but no code.
- Code that doesn't successfully compile for anyone but the developer.
- No instructions for how to build/run the program.
- No documentation of what aspects can be expected to work.
- Unclear description of what the program even does or will do.
- Lack of any demonstration of usefulness.
For the last point, I'm thinking of things like:
- Compiler/interpreter that can't even compile/run a hello-world type program.
- Emulator that can't at least run a sample program of some sort or otherwise demonstrate that it's doing something.
- Image processing tool that can't do anything but load and resave the unmodified image.
- Game with nothing but a title screen.
These kinds of problems lend to a "vaporware" image that can be hard to shake unless you're very open about the lack of working code to begin with.
Finally, make your version numbers make sense. Don't call your project "1.0" until it does what users expect it to do without crashing. I've always had luck with using version numbers around "0.5" for initial public release and going from there, but I've also seen things like "0.1" or "0.10" that make sense.