A nyílt forrású vagy a proprietary szoftver jobb minőségű?

Szoftver

A forráskód-elemző szoftvert gyártó Coverity hosszú évek óta rendszeresen készít jelentést a nyílt forrású programok forráskódjának minőségéről. A vállalat nemrég publikálta "2012 Coverity Scan Open Source" című jelentését.

Örök vita a nyílt forrású és a proprietary szoftver tábor közt, hogy melyik fejlesztési modell eredményez jobb minőségű szoftvert. A Coverity állítja, hogy mindegyik oldalnak igaza van és egyben mindegyik oldal téved. A Coverity ugyanis azt állítja, hogy attól függ, hogy kinek van igaza, hogy mekkora kódbázisról beszélünk.

Infografika:

Coverity infografika

A Coverity 2012-es jelentése 450 millió sornyi forráskód elemzése alapján készült. Körülbelül 68,5 millió sornyi nyílt forráskód és körülbelül 381,5 millió sornyi proprietary kód került elemzésre.

Az eredmény: mind a nyílt forráskódú, mind a proprietary szoftvernél nagyjából azonos az átlagos hibasűrűség (1000 tesztelt kódsoronként talált hiba). Ez az érték nyílt forrású szoftvernél 0,69, proprietary szoftvernél 0,68.

A felmérés legérdekesebb része pedig az, hogy milyen hatással van a kódbázis mérete a kódminőségre.

Ha kisebb kódbázisról beszélünk (500 000 – 1 000 000 kódsor), akkor a nyílt forrású szoftver lényegesen jobb minőségű. Ha nagyobb a kódbázisról beszélünk (1 000 000 kódsor felett), akkor nyílt forrású szoftver több hibát tartalmaz (vagyis a zárt forrású szoftver jobb minőségű), de a különbség kicsi (0,75 vs. 0,66).

A részletek itt olvashatók.

( aga_et v | 2013. 05. 10., p – 21:55 )

Nem találtamott, hogy milyen módszerrel csinálták, és furának tartom a két számot. Mintha az ellenőrzött open source kódsor egy tizedesjeggyel kevesebb lenne, ami millárdos nagyságrendnél már nem igazán elhanyagolható.
--
AGA@
Fork portal és az egyik logóm :)

Mi köze van ennek ehhez? A Coverity forráskód-elemző szoftvert gyárt. Vannak vállalatok, akik licencelik ezt a szoftvert és futtatják a saját, prop. forráskódjaikon. A Coverity pedig akár anélkül, hogy egy sor prop. kódot látott volna, statisztikákat kap a cégeknél futtatott elemző által kiköpött eredményekből.

Miért kellene a properietary kódoknak szabadon hozzáférhetőek lenniük?

--
trey @ gépház

Semmi, gondoltam hogy ez van mögötte. Le is írtam, csak aztán inkább kitöröltem.

Viszont ez tovább bonyolítja a képet, mert a Coverty forráskód-elemzőjének használata már a minőségorientáltság indikátora lehet. Tehát kb. olyan mintha a népesség átlagos kondícióját az edzőteremben mérnék föl. De az is lehet, hogy ez hülyeség, és később majd kitörlöm :)

( prion | 2013. 05. 10., p – 23:46 )

szerintem az is érdekes lenne, ha azt is kalkulálnák, hogy mennyi és milyen jellegű erőforrás elköltése mellett jött ez létre.

( sz332 v | 2013. 05. 11., szo – 06:47 )

Még megnézném, hogy a hibákat mennyi idő alatt javítják, mennyi olyan hiba van, ami kritikus,
de nincs javítva, valamint egy nyelv szerinti összehasonlításra is kíváncsi lennék.

( activer69 | 2013. 05. 11., szo – 07:08 )

Az aktív ÉS mature opensource projektek adnak jó minőségű kódot+dokumentációt. Erre csak rásegít, ha valami cég ill. alapítvány áll mögötte.

A tulajdonosi szoftverek minőségével nekem összességében jobbak (sokkal jobbak) a tapasztalataim. Ráadásul sok proprietary szoftvernek nem létezik opensource alternatívája (pl. Kofax VRS).

Ezek a tesztek, statisztikák pedig befolyásolhatók. Pl. simán össze lehet válogatni a sourceforge-ról csomó gagyi opensource cuccot, majd ezeket össze lehet vetni sok száz tesztelővel átnézetett tulajdonosi szoftverekkel és a különbség óriási lesz. De ha ugyanide opensource-hoz beválogatnak bizonyítottan jó projekteket (apache http szerver, libreoffice, linux kernel stb.), akkor valszeg simán győz az opensource.

-----------------
-activer
document.write(new Date().getFullYear()+1) will be the year of Linux on the desktop!

Egyetértek, annyi kiegészítéssel, hogy a LibreOffice-nak még nagyon-nagyon sokat kell dolgoznia
a minőségen, mert a stabilitással még gondok vannak, viszont látszik, hogy fejlődik, és az is,
hogy sok régi kódot örököltek, amin elég sokat dolgoznak. Valamint pont a linux kernel az, amibe
most már jórészt nagy céges alkalmazottak commitolnak.

Nem, magyar szakmai körökben elterjedt kifejezés, l. ULX (http://www.ulx.hu/20090604456/Nyilt-forraskodu-vallalati-szolgaltatasok…) vagy LIPSZ (http://www.lipsz.hu/velemenyek/99-a-tulajdonosinyilt-forraskodu-kontinu…), IT Business (http://www.itbusiness.hu/Fooldal/hirek/kozigazgatas_n/Szabad.html) stb. Megfelelnek?

-----------------
-activer
document.write(new Date().getFullYear()+1) will be the year of Linux on the desktop!

Ha már a magyar nyelvet – és az ahhoz tartozó technicus terminusokat – szapulod, akkor legyél szíves venni a fáradtságot, hogy leszoksz az igénytelen írásmódról, vagy pedig csöndben maradsz és lenyeled a békát, hogy vannak olyan emberek, akik jobban tudnak magyarul, mint te – köztük én is.

Az értelmesek nevében köszönöm.
______________________
this comment is cc by-nc 2.5

fapfapfap. valamit a temahoz?

amugy ha ennyire penge vagy, legyszi miutan fejbevagod magad egy angol szotarral, keresd ki benne a proprietary jelenteset, rakd ossze angolul, majd ird le, hogy szerinted azon kivul, hogy valamelyik hulye fordito a hasara utott, miert jo ez a forditas.

vagy inkabb csak menj vissza legozni, mindenkinek jobb lesz.

Úgy érted, a google translate szar minőségű szoftver mert propr..., ezért ne azt használja a nyelvtanuláshoz? Vagy rosszul értelmezem a szavaidat, és valami más, mélyebb, rejtett gondolatod van a témával kapcsolatban? Kicsit nehezen fejezed ki magad mostanában. Legalábbis így (fél)magyarul.
--
♙♘♗♖♕♔

Rendben. Sajnos nincs legókészletem. Én tépem itt a számat, de a blőd hasonlataid alkalmazásával – amiért sokszor komolytalanná válasz – te fogsz veszíteni ebben a vitában.

http://oald8.oxfordlearnersdictionaries.com/dictionary/proprietary
http://oxforddictionaries.com/definition/english/proprietary?q=propriet…

A proprietaryben benne van az árnyaltság a cég vagy vállalat sajátos termékének hangoztatására a védett jellegével, a cég saját malmára hajtó összetevőinek kiaknázásával együtt.

Sajnos a magyar nyelv az angollal szemben szubsztrátum-nyelv és _kényelmesebb_ angol szavakat használni az olyan magyar majdnem megfelelői mellett, ami nem pontosan _egy_ frappáns szóval adná vissza ezt az árnyalt jelentést.

Madarat fogtál, mert az „ikszedik véletlenszerű fordító” (sic!) – aki mellesleg-esetleg hülye is és joviálisan a hasára is csap a hatás kedvéért – megmondja neked, hogy a proprietary szót csak „sajátos tulajdonosi software-ként” lehet a magyar nyelvbe és szakszövegekbe átültetni.

A tulajdonosi szó nem a fordítások non plus ultrája, de hangoztatja azt, hogy valamihez szigorú szabályok mellett köthető dologról van szó, amihez valakinek vagy valamely cégnek az érdeke fűződik és nem pedig parlagon heverő software-ről van szó, amit bárki kénye-kedve szerint, kötöttségek nélkül használhat fel.

Most rajtad a sor.
______________________
this comment is cc by-nc 2.5

Hát ha már igy kiemeled az apache http-t, én eléggé biztos vagyok benne, hogy az iis az elmúlt mondjuk 5 évben köröket ver rá biztonsági hibák száma terén. (mármint sokkal kevesebbet tartalmaz az iis :)

Egyébként mindkettőt üzemeltetek, semmi komoly gond nincs egyikkel sem.

Egy gyors keresés:

Apache 2.2.x 2003-2013 között 56 vuln:
http://secunia.com/advisories/graph/?type=adv&period=all&prod=9633

IIS 7.x 2003-2013: 8 vuln:
http://secunia.com/advisories/graph/?type=adv&period=all&prod=17543

(de még a 2.4-es is 9-et összehozott már pedig még "gyerek", azért választottam a 7.x-et a 2.2-vel, mert hasonló az időszak)

Belemehetünk a sebezhetőségek súlyosságába is, de ott sem lesz jobb a helyzet. Be kell látni, hogy az IIS a 15 évvel ezelőtti katasztrofális biztonsági szintjéről az elmúlt években az egyik legbiztonságosabb lett.

( turul16 v | 2013. 05. 11., szo – 08:09 )

Erdekes lenne latni a hasznalt program nyelveket is, ill. nyelvenkenti statistikat.

pl. javanal, normal esetben a findbugs kiszur egy csomo dolgot, jobb esetben commit elott.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( zdesigner | 2013. 05. 11., szo – 10:05 )

Linuxon a csodálatos bináris nVidia driver miatt szívok mindig. A Skype egy ideje stabil és a flash is rendben van. Régen ez a kettő fagyogatott néha. A „Unity bugjai” érdekes módon csak az nVidiás gépen jönnek elő és a Launchpad-es bugreportokban is gyakran kiemelik, hogy a bug reprodukálásához bináris nVidia driver kell. Ennyit tapasztalok a zárt szoftver jobb minőségéből. Ha ezek nem lennének, nem szívatna az „Ubuntu”. Illetve a Gnome-féle elmebetegségi hullám (minden funkció megy a kukába) zavar még hihetetlenül, de az egy másik kategória.

--
Ingyenes Ubuntu One tárhely:
https://one.ubuntu.com/referrals/referee/170278/

( Fisher v | 2013. 05. 11., szo – 10:15 )

Tehát nem attól függ a kód minősége, hogy nyitott vagy zárt ajtók mögött kódolnak. Nahát :D

( Replaced | 2013. 05. 11., szo – 11:12 )

mi napi szinten hasznalunk coverity-t, azert nem egy magic bullet es nem attol jo es karbantarthato a kod, hogy nincs benne coverity finding

pl.:

int power(int a, int b)
{
return a * b;
}

ez coverity szerint jo kod

szerk.:
nem is emlekszem olyan esetre, amikor egy bejelentett hibat coverity talalt volna meg
QR az egy jo dolog, de nem attol lesz bugmentes a kod

--
NetBSD - Simplicity is prerequisite for reliability

Ezt nyilvan nem fogja megtalalni, ahhoz tudnia kene mi az a power, es hogy annak mi a keplete.

Egyebkent a hello worldnel nagyobb programokban van par "trukkos" megoldas, amit hajlamos hibanak velni, szoval a false positive aranya nem valami jo. Nyilvan az az elonyosebb, ha ilyenkor is szol, viszont ez a statisztikajukat eleg komolyan befolyasolja. Prop. SW-eknel ugye forras (es hozzaertes) hianyaban nem tudjak megallapitani, hogy ez tenyleg hiba-e.

--
The programmers of tomorrow are the wizards of the future. You know, you're going to look like you have magic powers compared to everybody else. -Gabe Newell

( al3x v | 2013. 05. 12., v – 00:52 )

Azt nem ertem, hogy az elterjedt "zart forraskodu szoftver" (vs. "nyilt forraskodu szoftver") miert nem volt jo megnevezes? Regebb ota van a koztudatban mint a "tulajdonosi szoftver".

Az egésszel egyébként az a bajom, hogy igazából az, hogy nyílt vagy zárt forráskódú, az nem
jelent semmit, amikor egy rakás olyan projekt van, ami közösségiként indult, de mára a kód 90%-át
profi céges alkalmazottak tolják bele, megfelelő tesztrendszerrel a hátuk mögött, vagy korábban propertiary volt, de most megnyitották, vagy van egy open source verzió is, de valójában egy vagy több cég áll mögötte, és ők adnak supportot. Szóval mára már nem teljesen fekete és fehér az egész open source világ.

Feltételezem arra gondol, hogy egy nagy cégnél profi programozók/tesztelők/stb. a napi 8 óra munka után otthon hegesztik az open source valamit. Tehát aki végzi ugyanaz a személy, így a két kód minősége is közelít. Azonos nem biztos, hogy lesz, de közelít. Vagy például sok helyen lehet azonos a kódbázisa a pénzes és community verziónak, így a minősége is közel azonos.

"Belépés díjtalan, kilépés bizonytalan."

Még jó hogy, logikus, ezért is írtam: "két kód minősége is közelít". Tehát közelít és nem azonos.

Másik, ahogy van programozó, egyéb szakmákból is vannak az open source részen, tehát feltételezem van ott az általad felhozott peer review/QA/... foglalkozású ember is.

"Belépés díjtalan, kilépés bizonytalan."

Igazából arra próbáltam utalni, hogy ami régen volt elv,mely szerint az opensource alkalmazásokat szabadidőben fejlesztik hobbisták, már réges régen nem állja
meg a helyét, sok sikeres open source könyvtár/termék lényegében egy szűk profi kör által készített kód, aminek egyébként ingyében megkapod a forráskódját, de
vehetsz hozzá céges támogatást is.

( fdavid | 2013. 05. 14., k – 10:55 )

Azert azt fontos lenne leszogezni, hogy a statikus kod analizissel megtalalt hibak (vagy potencialis hibak) szama nem egyenlo a szoftverben meglevo hibak szamaval. Ezern kivul a statikus kod analizis ugyan rengeteget tud javitani a kod minosegen, de onmagaban azert semmit nem jelent.

Tehat az osszehasonlitas tokeletesen semmitmondo, es bizonyos ertelemben hamis. Raadasul nem en hamisitottam, tehat hiteltelen. ;-)