In an open-source development community, the "release early, release often" philosophy has many advantages. Your users are also bug testers, co-developers, and quality assurance techs. They can not only report bugs, but also peruse the code itself for its possible causes and write their own patches to recommend fixes. This takes the most time-consuming and tricky part of code development from the hands of the dedicated originators and distributes it over a much larger group of amateurs and hobbyists, who can often quickly identify and correct problems (and actually enjoy doing so). For open-source projects, this method works very well. It has become quite common for download pages to include both a potentially buggy, developmental release, and also the last known stable release of a program. People who just want to use the program can download the stable one, and people who want to be involved with the bug-testing and development can download the development version.
This model most emphatically does not work in closed-source projects.
Professionally-released software under copyrights and licensing regulations is expected to be released in an almost completely pristine, working order. One does not purchase a car from the Ford dealership with the expectation that it will break down on the way home and the owner may be expected to suggest ways to fix it. The average software user doesn't even know how to spell C++, much less program in it. When things don't work on the computer, they have no recourse but to go use something else that does work. While it is expected that version 1.0 of any given program might have a minor bug or two, they are not expected to be game breakers or in any way damaging to the user's precious data. Releasing buggy software doesn't look like an inclusive means of sharing the responsibilities of development to these people, it looks like lazy, incompetent programming. Software development is difficult, and end-users (quite reasonably, I think) expect those with specialized knowledge to shield them from these difficulties.
This clash of cultures is extremely visible in Apple's iTunes App Store. With the release of the iPhone 3G, Apple has opened iPhone app development to the masses, subject to a few restrictions on what the app is and is not allowed to do. The overwhelming majority of these developers are hobbyists and amateurs, and I don't think I'm out of line making the assumption that a good portion of them have open-source backgrounds.
The iPhone's distribution model is not conducive to open-source development. One does not download source code from the App Store, and when multiple versions are available they are generally limited to a full, pay-for version and a free "Lite" version with limited capabilities. The software is distributed with the clear expectation that it will work properly. When it doesn't, the backlash is immediate and strong. Version updates, even for paid apps, are easy to install and cost nothing, but the damage could already be done by the time it becomes available.
To help iPhone users select the apps they need from the overwhelming list of choices available, Apple has a review system built in to the App Store. Users can not only rate the software on a scale of 1-5 stars, but they can also write a short review about the app's merits and drawbacks. When an initial release is buggy, this can be devastating to the app's reputation. A flood of poor ratings and bug complaints can easily become permanent marks of shame on an app's review page, driving potential customers away even after these bugs have been fixed. It's an easy way for a developer to shoot himself in the foot.
Recognizing this problem, the iTunes review page has begun explicitly marking what version of the software a reviewer is talking about. While this can only help, the average customer as likely as not will be put off by bad reviews without paying much attention to the version number. Newer reviews stating that the bugs have been fixed and that the app works fine now will help, but grade-school threats of poor performance going on a so-called "permanent record" have never been so rooted in reality.
Does software need to be perfect on its initial release? Certainly not. Anyone who's ever used a Microsoft product is certainly cynical enough by now to understand a few bugs are reasonable, so long as a simple quit-and-restart of the program will clear it and it doesn't lose (most of) the data. But the core functionality should be stable, and the program should be able to run for extended periods of time without crashing.
As app development in iTunes continues to mature, I'm sure that it will become understood that the average user expects a well-tested and smoothly-functioning app when they download it, especially one they've paid for. Even the basic 99¢ apps will be frustrating to a user who discovers he's just wasted his money (if not due to the loss of a dollar, the implication of more wasted dollars in the future due to further buggy apps). But never before has so much amateur software been made so easily available to so many ordinary users, and software developers on all platforms would do well to learn a lesson from how this unique process is playing itself out.