"a zárt forrású cuccok kódminősége mindig messze rosszabb volt, mint az átlagos open source projektek kódminősége"
Elhiszem, hogy a te esetedben ez így volt, de ebből még nem érdemes általánosítani.
"Tapasztalataim szerint a kódminőség az utolsó utáni szempont, közvetlenül a tesztelésre hagyott elegendő idő előtt. A határidő vége felé pedig megjelennek olyan workaroundok, amelyekről az igényesség jut legutoljára az ember eszébe."
Ezt próbáltam leírni ebben a mondatban, igaz kicsit homályosan fogalmaztam: "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."
Nyilván nem minden projecttel tegnapra kell végezni, illetve adott esetben a késés miatti többletköltséget kompenzálhatja a magasabb minőségi követelményeknek megfelelő szoftver alacsonyabb üzemeltetési igénye. Tehát itt több, egymásnak ellentmondó szempont van, és sok esetben sajnos bizonyos szempontok csak a kódminőség rovására érvényesülhetnek. De ez még nem zárja ki, hogy sok esetben jobban megéri jobb minőségű kódra, ezáltal jobb minőségű szoftverre törekedni még az emiatt megnövő fejlesztési költségek és időigény miatt sem.