I hope I can make the links you need to see the logic that other posters have been attempting to convey.
With non-sponsored open source software in most cases the developer is creating the software mostly for their own personal understanding of the concepts of software design or to develop their own personal tools for whatever other personal projects they are working on. At this level the software is unpolished, providing only enough of an interface for a single person to utilize. You can start to have other developers joining the project for their own personal growth and understanding. An interface design major might put a better GUI front end to the project. Someone who needs to learn about database design might put more robust SQL statements into the code, or make the code behave better with the APIs of a certain database engine. Regardless of who comes in and adds to the project, with non-sponsored open source, there is no vested interest beyond what a person puts in for their own personal growth and understanding. Also, everything with the development of an application is a serious might. At this level, it's not very often that people training in QA have any interest in getting involved as college classes on System Analysis tend to focus on Use Cases and hardly ever suggest students go out and find an open source project to test. Not that they would get anywhere with the egos that tend to be involved in many of the non-sponsored open-source projects. Coders at this level can, at times, have very strong emotional attachments to their code and take a criticism as a challenge to duel.
The next level is sponsored open source. At this level, you're going to have people putting money into a project to help make it as good as it can be. This incentives developers into producing cleaner code with better functionality that would appease a more wide spread audience. As the project grows and gets more monetary involvement a lead developer may look over the system he's building as a whole and try to identify areas that need to be improved and features that would be good to add. For this he may start looking to hire on people to start fulfilling the roles where he isn't necessarily the best fit in the interest of putting out a better project. Depending on the project lead's ability to take criticisms in the face of this goal, he may actually hire on some Analysts to perform QA and testing on the project to help it appeal to a wider audience as well as some form of tech support to help the end users in utilizing the application.
The last level is "sponsored" closed source (quotes denote redundancy). If a person or business is developing closed source, it's because they live or die by the code they're writing, and they have every intention on living by it. This code is either going to be in a product that is to be distributed to end users, or it is an internal application that is going to handle some aspect of internal business processes. In the former case it absolutely has to be easy to use, well documented, well tested, patched and maintained, and have support teams available to help the end user troubleshoot any problems that may be cropping up. If any part of this does not live to some kind of market standard, the product will fail. In the latter case much of the same philosophies apply with the addition of mission critical reliability. If internal software is regularly choking and losing customer records to a buffer overflow three times a week one can assume that if it isn't fixed in short order the entire business will very shortly wind up on the rocks. For both of these cases, companies that develop closed source software will set up an entire department of Quality Assurance and Testers to make sure that what gets put into production is the absolute best it can be.
I'm sure there may be some other aspects of these three tiers that I have completely missed the mark on, but this is what comes to mind the quickest for explaining the reasons why closed source software has the greater likelihood of being higher quality applications