In regards to hobby projects, at what point do you consider it to be mature enough to release the first version to the general public? Do you wait until you have all of the features implemented, or do you release it once you have solid functionality and keep working on it?
Also, what are some of the differences between releasing a hobby project as an open source project?
At idea conception. Given sites like CodePlex and SourceForge, you can "release" your code via open access to the SCM - and when you think it's "ready", you can package it up as a release on the site.
Early and Often for both Open Source and sharing your own toys with the world.
You just need a thick skin to cope with all the muppets who've never released anything telling you how they believe your father is unknown and you can't code your way out of a paperbag. It's character building and yes I'm bitter.
I would say release it when you have enough functionality working to make the application actually useful.
Also, make sure what you do release is bug free as far as you know. Users tend to not want to use buggy software.
Do you anticipate a lot of people using your product as soon as it's made public? If not, I say release it.
If you'll only have a small user base to start with, consider it beta and solicit feedback from your users.
You're better off releasing it BEFORE all the features you want to implement have been implemented. This allows you to test what's already in the code before you start to add more stuff. Just make sure to not let the version number get above 1.0 until your app is feature complete and put plenty of warnings that things aren't set in stone and could very well change later on.
EDIT: Also, read this: producing open source software. The guy that wrote it has lots of experience in the open source world and there's a lot to learn from in there about versioning and just about every other subject that could come up.
As early as you're confident it's a project you're going to spend some time on. Sites such as Sourceforge aren't only a way for you to make your "finished product" [1] available but they save you having to maintain your own infrastructure - SCM, bug tracking (and even if you're the only developer for some time, you really want those).
Most of the projects on Sourceforge and similar sites are pre-beta but that really doesn't matter because, since the state of completeness is advertised for every project, nobody gets disappointed. I've picked up and begun using half-working pre-alpha-quality tools before and was very grateful they were published because there were no alternatives and I would have otherwise had to start from scratch myself. In a couple of cases, I had to make fixes to get the tools working for my case which I then fed back to the author. This is how many projects gain traction.
[1] There's no such thing.
My advice is to either release something publicly once it's reasonably stable -or- the other extreme: have it public from the very beginning and show the evolution. Either way is the same effect -- you don't receive many complaints that someone expects the software to be stable when it isn't.
If you're releasing it to a unmoderated ranked system like Android Marketplace, release it under a different name than you may eventually plan to release it (even if it's including Beta or Alpha in the name). That way, all the "muppets" Sparkes is referring to can relieve the unbreakable tension of their meaningless lives by giving you one-star rankings, but they will not drag down the rating of your eventual finished product.
Here's a slightly contrary position:
Don't release it until you are reasonably sure that someone interviewing you for a job in the future would not consider you for a position after looking at the source code (e.g. make sure the code meets a least some minimal professional coding standard, or is so extremely useful that no one would care.)
This is especially important if it's the type of hobby project coded after a few too many adult beverages, or is coded in unstructured Basic for some legacy emulator.