Citat:
Andreja Dulovic: uopste se ne slazem sa ovim.
kvalitet nekog paketa zavisi od skupa faktora medju kojima su znanje programera, ulozeno vreme, ogranizacija procesa "proizvodnje", testiranje, kvalitet specifikacije, integracija komponenti i slicno...
Andreja, pricas o softveru uopste, ja sam pricao o realnosti u OSS svijetu. Ti ljudi koji OSS pakete razvijaju nijesu toliko iskljuceni iz teorije i prakse koja se trosi u komercijalnom razvoju softvera. Radili bi i oni to tako, ali nijedan OSS paket iza sebe nema prvo finansijsku, a samim tim i organizacionu (e sva ta organizacija kad od toga zaposleni ne zive je druga nega prica) infrastrukturu da takvo sto izvede. Prolaze kroz fazu testiranja (gdje se bas ne mogu intervjuisati buduci testeri i traziti "top 10%"), ali masu problema ulove krajnji korisnici.
Sto mi sluzi kao lijepi slagvort da Bojanu odgovorim "o istom trosku".
Bojane, ja model po kome se razvija OpenBSD uopste ne svrstavam u OSS pricu. Po meni, Theo se do kraja trudi da kopira korporacijsko okruzenje i zbog takvog svog principijelnog stava dovijek kuburi sa resursima, novcem, hardverom, kojecime. OpenBSD je solidno parce koda, ali ja nijesam siguran da je Theo do kraja razrijesio "OSS kvadraturu kruga" i pronasao modus kako da on i kljucni dio ekipe od toga zivi. Linus i druzina jeste, na stranu sva GPL/Stallman/GNU praskava ideologija i vatromet.
Citat:
Andreja Dulovic: ideja "heuristickog" testiranja po kojoj se softver testira tako sto se pusti medju korisnike se obicno sprovodi na samom kraju jer greske koje korinici otkriju nisu tako precizno dokumentovane (okolnosti pod kojima je nastala greska), tako da "lovljenje" buga u kodu moze da oduzme vise vremena nego sto bi to bio slucaj konvencionalnim testiranjem, plus, tako "heuristicko" testiranje ne obezbedjuje hijararhiju po kojoj se greske otkrivaju (zna se sta se testira posle cega a sta pre), itd....
Kad vec pricas o manama "heuristickog" testiranja (a koje ja ne osporavam), imam za tebe jednu interesantnu pricicu.
Freescale, tacnije njihovo softversko krilo, bivsi Metrowerks, a u vrijeme kad sam ja tamo radio (valjda i danas) nudio je alat za provjeravanje "full code coverage". Interesantna statistika za tebe je da profesionalno napisane i testirane aplikacije pokazuju tendenciju da "glavna grana programa" (dakle, ono sto se najcesce koristi) zauzima izmedju 30% (kod mission-critical aplikacija, gdje se to cita "zavise zivoti ljudi") do 60-tak %. Sve ostalo je "error-handling", tretiranje neocekivanog/pogresnog/loseg unosa u sistem. Ti alati za "full coverage" automatizuju analiziranje koda i provjeravaju da li kod zna da se izvuce kad se desi greska, kad se ode u neocekivanu (rijedje sretanu) granu izvrsavanja.
Kad ti alati pocnu da se koriste rezultati su zapanjujuci. Odnos softverskih gresaka koje takvi alati pronadju, u glavnoj grani programa nasuprot bugovima u kodu za tretiranje gresaka je, po sjecanju, 2-15% naprema 98-85%. Pazi, u veoma ozbiljnim aplikacijama, profesionalci i razivijali, i testirali.
Zakljucak je da i profesionalno planirana i sprovedena testiranja (cak i u vojnim primjenama, gdje su mission-critical aplikacije i gdje je to strasno vazno) pokazuju JAKU TENDENCIJU da su dobro istestirani djelovi koda uglavnom locirani u glavnoj grani programa. Uprkos svoj teoriji i metodologiji testiranja, uprkos automatizaciji testiranja i svime sto se danas koristi. Ima nesto u onoj staroj "there is always another bug".
Komercijalni softver, kad se proces zavrsi, izidje iz proizvodnje sa mnogo manjim procentom bug-ova od OSS rijesenja. Tu diskusije nema, to je tako.
Medjutim, na duze staze, resursi koje OSS zajednica angazuje (preko truda korisnika) na ODRZAVANJU POPULARNIH OSS PAKETA je nesto sto ja mislim da nijedna korporacija ne moze da izdrzi.
Bas zbog takve tendencije (e malo ko radi full code coverage) i kod komercijalnog softvera, ja tvrdim da OSS rijesenja mogu, cak i sa tako kljakavom metodologijom, a kroz dovoljan broj iteracija (niko ne spori da se tu mnogo vise truda potrosi), dostici kvalitet komercijalnog rijesenja, primarno zato sto na dugi rok akumulira vise resursa. Taj se nivo dostize samo kod popularnih paketa koji se mnogo koriste. Zato sam rekao da je kvalitet OSS rijesenja proporcionalan broju korisnika.
Ako ti treba primjer, zagledni se u GCC. To je bila sprdnja od kompajlera kad je cijela prica pocinjala, danas rijetko ko u komercijalnom svijetu pravi pare na prevodiocima. GCC nije nikakvo super-testirano cudo koje kvalitetom pobi komercijalnu konkurenciju, on je samo dostigao
upotrebljivost, a presudu gdje je taj nivo (e je to fluidno) dali oni koji ga koriste.
Citat:
open source mozda ima odlicna resenja na "low levelu", jer ljudi entuzijasti nesebicno ulazu brainpower, ali tajming i rokovi ne mogu da se postave optimalno kao sto je to slucaj kad ljudi za pare razvijaju sw, pa sve to utice na kvalitet softvera u datom trenutku.
Kljucni ljudi u Linux kernelu odavno nijesu "entuzijasti" u smislu da to rade bez naknade. Drugo, linux kernel drajveri koji se pojavljuju danas su pocesto kod koji zaposleni proizvodjaca hardvera ubacuju u kernel. Ti parcici su razvijeni po komercijalnoj metodologiji i Linux (ovdje mislim na kernel) je sve manje i manje prica o "entuzijastima".
Ne znam koliko se opsti framework kernela moze nazvati "odlicnim", ali sam siguran da je to sve manje i manje vazno. To, takvo kakvo je, oposljava posao poprilicnom broju firmi i "kucnih" korisnika.