szoftverpublikálás
Posted by razor | Filed under Bioinformatika, Filozofálás
Már rágódtam rajta, hogy a klasszikus cikkek publikálása mellett a különféle adatokat és programokat is valami átláthatóbb rendszerben kéne a műértő közönség elé tárni. Most a különféle bioinformatikában, biológiában, vagy egyéb természettudományos területen használt és fejlesztett szoftverekről lesz szó. Boscoh hasonló dolgokról ír egyébként, csak hamarabb jutott a gép elé.
Gondolom nem ismeretlen szituáció, hogy valaki publikál egy programot, pontosabban ír egy cikket róla, begyűjti az impakt faktort, sikert, elismerést, pezsgőt, kurvákat, majd sorsára hagyja, és a cikket 1-2-3 év múlva elolvasó szerencsétlen találkozik egy használhatatlan kódhalmazzal, amihez vagy van leírás vagy nincs, vagy lefordul valami csoda folytán vagy nem, vagy működik a webszerver ahova felrakták, vagy nem. Arra az alapvető problémára, hogy hol tároljuk egy program kódját, hogy kövessük nyomon a változásokat, jelentsük a hibákat, stb, már a fent linkelt posztban is leírják a kézenfekvő megoldásokat. A Github, SourceForge, Google Code csak az első néhány példa.
A baj ezekkel azonban az, hogy az ártatlan kutató, aki esetleg nem bioinformatikus és nem szereti a gcc verziószámát állítgatni, vagy a Makefile-t piszkálni, nem biztos, hogy eligazodik. Talán azt lehetne csinálni, hogy a CPAN vagy esetleg a Gentoo csomagkezelő rendszeréhez hasonlóan bizonyos alapvető rendszereken a beküldött programok automatikusan tesztelésre kerülnének, és áttekinthető lenne, hogy milyen operációs rendszerek, fordítóprogramok, könyvtárak esetén bírható működésre. A binárisok megtartásával pedig annak is könnyebb lesz az élete, aki csak egy működő programot akar letölteni.
Természetesen ezekhez az is szükséges lenne, hogy a szoftverek publikálás előtt sokkal szigorúbb, a cikkekhez hasonló peer review folyamaton essenek át. Az egyik fele ennek a technikai részek átvizsgálása, ugyanis az nem a legideálisabb megoldás, hogy a fejlesztő közli, az ő szoftvere márpedig csak a xy fordítóprogram z verziójával fordul le, és csak az ő bemeneti formátumát fogadja el, a kimenet pedig olyan-amilyen és kész. Az általában használt egyszerű formátumok (tab delimited fájl, csv, fasta, gff) támogatása kéne hogy a minimum legyen, amellett, hogy több különböző rendszeren is működőképes a program, esetleg minimális energiabefektetéssel lefordítható és működésre bírható, komolyabb informatikai tapasztalat nélkül is. A másik hangsúlyos terület pedig az alapvető működés, az opciók és elfogadott formátumok részletezése, és a kimenet pontos magyarázása és értelmezése.
Egy jól működő “szoftver peer review” és néhány oldal/publikálási felület esetén szükségtelenek lennének pl a Bioinformatics-ban rendszeresen megjelenő egy oldalas példamagyarázatok és a kód részletes leírásától 10 oldalas algoritmus bemutatások. A szoftverek hivatkozása, nyomon követése, módosítása, újrafelhasználása is jóval könnyebb lenne. [Mivel természetesen kötelezően open source az egész.]
Innentől kezdve már csak az impakt faktor fetisiszta pályázati bírálóbizottságban ülő “szakembereket” kéne meggyőzni arról, hogy a 0 IF nem feltétlenül jelenti azt ebben az esetben, hogy a program nem jó semmire, ha 20 hivatkozás van rá más cikkek Materials and methods részében.
Tags: peer-review, publikálás, szoftver
