The first publicly released version of commercial software is usually buggy. This is in contrast to open source software that is usually very mature and stable by the time it hits version 1.0. ''This is a consequence of how versioning is normally done for open source vs. commercial projects. "Version 1.0" of open-source software could be preceded by literally thousands of "version 0.x" builds; witness the GIMP.'' A corollary is that the first project a developer does using a new technology also often leaves quite a bit to be desired, because the developer has not yet learned the strengths and pitfalls of that technology. WhyDoOperatingSystemsSuck describes this as a reason why people don't move on to something better than what they've got. This is similar to FearOfEarlyAdoption. ''It is a false assumption that the first version of ''any'' new commercial product is going to be lousy. I have worked on commercial products that came out of the box the first time working just fine. I have done it with new (to me) technology, too. Please inspect your own baggage before making SweepingGeneralization''''''s like this one. Thank you for your time, and we now return you to your regularly-scheduled Wiki browsing.'' ---- For non-shrink-wrap software the first release version is often needed in a hurry and on the cheap in order to get buy-in or funding to do it right. The requirements and structure may not begin to come clear until the software begins to grow and develop. Not until it's done can the programmers and designers look back and say "This is how it should've been done." Of course, at that point it can't be boxed off as an internal alpha, prototype, or proof of concept; once the software exists it has to be used to justify the investment. And once it's in use, it has to be improved, rather than redesigned and rebuilt with the lessons learned. Of course, future versions have to be compatible with the monstrosity that was 1.0. ---- See Also PlanToThrowOneAway, SecondSystemEffect, and FlimsyAndBarelyFunctional