I got a great question this morning on irc. A student in my Mozilla Open Source course wanted to know exactly what the 0.1 release, due this Thursday, should include. I purposely leave the requirements vague for a number of reasons: 1) each project is so, so different that trying to come up with a cookie cutter approach is flawed, in my experience; 2) I don't want to box people into a particular approach--I'm looking for people to learn how to drive their own project.
Having said all that, I'm also aware that when you are first getting started, understanding the landscape is key to feeling like you can get where you are going. So let me tell you some things about a 0.1 release.
The first thing to note is that word release. It's key to beginning our understanding of what's expected. With 0.1 you are, for the first time, releasing something to the world. This implies a few things. 1) you have something to release; 2) you have somewhere to release it; 3) your release makes the first two items visible.
A 0.1 release is a commitment; it's a commitment to yourself, your users, and your fellow developers. It says, "this isn't finished, but it's worth looking at, and shows where I'm going." A 0.1 release, as the number implies, is the beginning of a regular flow of updates. You would just call it "WunderSoftware 2000" if you didn't want you to get anyone's hopes up about its future. Instead, by naming it "0.1" you are creating a timeline, and marking the first tick along its y-axis. "Release early, release often," and we will, with this being our first release.
A 0.1 release announces your work to the world. It hopes to gain traction for your efforts, both in terms of users and potential contributors. Rather than hiding your work away until it's done, you're showing it before it's ready, before it's finished. In so doing you're hoping that people will contribute to helping you finish it--some might offer encouragement, others advice, others reports of issues (i.e., bugs), and still others patches (i.e., code fixes or features). You don't know what might happen, but you open yourself and your project to the possibility of something happening. There is no guarantee, except the guarantee that not releasing will mean you remain alone in your efforts.
Practically speaking, your release should include a blog post announcing the release. Remember to give it some google-juice so that people can find it easily when they are looking for a solution like the one you're building. Answer the common questions people will have about your work, for example: what is this project? where can I get the code? how can I contribute? how do I use this? what is coming next? how do I report an issue? how do I communicate with you about things I notice or feedback I might have? Point people to the "code" you're releasing, which might be actual code, or documents, or tests, or something else. This needs to be available in github or as a patch on a bug. Make it easy to find, easy to fork, easy to use.
Make sure you sell it. I find too many people assume that because they know what they're working on, it will be obvious to others. You want to tell a story about your project. Why is this thing cool? Why are you excited to be working on it? Where is it going? Give people something they can understand quickly: a diagram, screenshots, a screencast.
Your 0.1 and 1.0 releases will be the most difficult. Right now you're starting something where there was absolutely nothing before. The 0.1 release is hard because it requires you to do so much learning, research, and setup. Your 0.2, 0.3, ... releases will more naturally fall into place. You'll get a rhythm going, and know what comes next. As you reach 1.0, and the need to turn your hacks into a "product" or "shipping code," you'll find that it gets hard again.
If it seems like I still haven't answered my student's question it's because I'm not sure there is an answer. I know that this first release is going to be a bit of a mess, since there hasn't been much time, everyone is new to their projects and technologies, etc. However, I want each of my students to have the chance to struggle through this question, and I want them to do it early. A number have already jumped in with both feet. As long as you're pushing yourself, engaging the community, writing down what happens as you go along, 0.1 will be what you see when you turn around and look back at where you started. I'm looking forward to seeing everyone's work.