Azért ez nem egészen így van. Én inkább úgy látom, hogy bár alapvetően mind open, mind closed source szoftverek esetén vannak jól, és rosszul megírt szoftverek, más az oka a minőségnek (vagy annak hiányának).
Open source* szoftverek esetén leginkább a fejlesztők igényességén múlik a szoftver minősége. Nincs megrendelő, aki visszautasíthatná a szoftvert, a felhasználóknak pedig hiába rossz a véleménye, bevételkiesés nem fog emiatt történni. Persze ha megfelelő emberek vezetnek egy projectet, ők visszautasíthatnak kódokat az igényesség hiányára hivatkozva, csak ennek a project szenvedheti kárát az érintett fejlesztők elpártolása miatt (lásd ffmpeg). Viszont nincsenek szigorúan vett határidők, ezért van idő jól átgondolt kódot írni.
Closed source esetén a fejlesztők érdeke az igényesség. Ha rossz minőségű szoftvert készítenek, azt visszautasíthatja a megrendelő, vagy nem fogják megvásárolni a felhasználók. Ráadásul ha egy fejlesztő nem képes betartani a minőségi irányelveket, bármikor elbocsátható és pótolható (abba most ne menjünk bele, hogy ez azért ennyire nem egyszerű). A minőség érdekében a fejlesztés során software review-k során ellenőrzik a forráskódot. Viszont vannak határidők, a fejlesztőket a fejlesztés során fizetni kell, ezért a késés nagyobb költséggel járhat, mint egy kevésbé jól megírt szoftver kiadása. Főleg, ha az adott szoftver a maga területén monopolhelyzetben van. (Jó példa erre a xilinx ise, ami (amennyire én tudom) a xilinx fpga-k kizárólagos fejlesztői környezete. Mivel egy fpga kiválasztásában a fejlesztői környezet sokadrangú szempont, ezért elég, ha a szoftver csak azt a szintet üti meg, ami miatt még nem lesznek a cég termékei kerülendőek.)
*: itt elsősorban azon szoftverekre gondolok, amiket közösségi alapon, profitszerzés célja nélkül fejlesztenek