Ако такава машина е на практика невъзможна, тогава е логично да бъде КРАЙНО невероятна.
“Пътеводител на галактическия стопаджия”, Дъглас Адамс
Традиционни проблеми
Съвременната наука работи върху код и големи езикови модели (LLM), но когато стане въпрос за споделянето на този код или с какви данни се захранват езиковите модели, много изследователи реагират така, сякаш са били помолени да рецитират публично “поезията на вогоните”.
Защо? Често се случва кодът да е работен, недокументиран, разхвърлян или персонализиран към лаптопа на даден изследовател. Самите изследователи се притесняват да споделят софтуерния код, върху който работят, защото е възможно да бъдат открити грешки. Не трябва да се подценява факта, че много изследователи, които не са строго специализирани в софтуерното инженерство, нямат умения, инструменти и време да пишат код за изследванията си. Съществуват и институционални ограничения - липса на достъп до инфраструктури или вътрешни регулации на организациите, които не одобряват споделянето на код.
В резултат значителна част от създадения софтуер е като “Безкрайно невероятностия двигател” — мощен, но никой не знае как работи или откъде идва.
Какво е “отворен код и софтуер"?
Софтуер за отворени изследвания означава код, който се използва за генериране или анализ на изследвания, който е прозрачен — всеки може да го чете, тества или критикува; многократно използваем — с документация, примери и разрешително лицензиране; възпроизводим — позволяват на други да повтарят резултатите от вашите изследвания; подобрен чрез сътрудничество — други могат да поправят грешки, да добавят функции или да ги превеждат на друг език.
По-широкото определение за отворен код не означава само достъп до изходния код. Както отбелязват от Инициативата за отворен код OSI, “Условията за разпространение на софтуер с отворен код трябва да отговарят на следните критерии: безплатно разпространение; програмата трябва да включва изходен код и трябва да позволява разпространение както в изходен код, така и в компилиран вид; цялост на изходния код на автора; лицензът трябва да позволява модификации и допълнителна обработка; не трябва да дискриминира лица или групи, нито области на дейност; правата, свързани с програмата, трябва да се прилагат за всички; лицензът не трябва да ограничава от друг софтуер, както и лицензът трябва да бъде технологично неутрален.” (Инициатива за отворен код - OSI, 2024)
Колкото и да е странно, науката може да има код с контролирани версии, управляван от общността, проследяван за грешки и подходящо лицензиран — вместо мистериозни скриптове, изпратени по имейл като:
analysis_final_v7_definitely_final_REAL_FINAL_FINAL.
Как отвореният код и софтуер може да реши традиционните проблеми?
Отвореният код не е просто споделяне, а по-добър начин за създаване на софтуер в науката. Синдромът “това работи само на моя лаптоп” може да бъде решен посредством отворен софтуер, защото предоставя контрол на версиите на кода и запазването им (например в Docker), като по този начин кодът става преносим и възпроизводим.
Проблемът с разбираемостта на изходния код се решава със структурираната документация, например в .README файлове, които са съобразени със стандартите на общността. По този начин т.нар. “спагети код” се превръща в инструмент за многократна употреба. Когато кодът е пълен с грешки, прегледът и проследяването им, например в GitHub дава възможност за тестване от много други ИТ специалисти, които много по-бързо ги откриват.
Изследователите могат да получат академични ползи от споделянето на софтуерен код, ако го направят, така че софтуерът да може да се цитира, например чрез DOI в Zenodo.
Съвместната работа по отворения код помага освен за поправката, разширението и поддръжката, но и за развитието на уменията и капацитета на изследователите.
Практически стъпки за използване на отворен код и софтуер
Стъпка 1: Контролирайте версиите на софтуерния код от самото начало и възможно най-често!
- Използвайте Git+ платформи като GitHub или GitLab от самото начало при писането на софтуер, а не само в края. Публикувайте промените си, следете историята им!
Стъпка 2: Изберете подходящ лиценз!
- Лицензирането показва на потребителите на софтуера какво могат и какво не могат да правят с него. Използвайте choosealicense.com, за да намерите подходящия лиценз за вашата работа.
Стъпка 3: Документирайте всичко!
- Включете README.md файл, за да знаете как да стартирате софтуера!
- Използвайте docstrings и коментари!
- Добавете примери за употреба или малък набор от тестови данни!
Стъпка 4: Пакетирайте и публикувайте!
- Използвайте инструменти като setuptools, conda или pip, за да може софтуерът лесно да се инсталира!
- Създайте DOI с Zenodo, който е свързан с вашето хранилище в GitHub!
- Регистрирайте кода си в тематични хранилища на общността като:
bio.tools (науки за живота)
PyPI (Python)
CRAN (Мрежа за архиви на R)
Software Heritage.
Стъпка 5: Допринасяйте и отчитайте приноса на общността!
- Насърчавайте съобщаването на проблеми!
- Включете вашия ORCID идентификатор в хранилището!
- Добавете как може да се цитира Вашия софтуер, използвайки CITATION.cff или codemeta.json!
Добри практики и примери от ЕС
EOSC подкрепя отворения софтуер като основен елемент от своята инфраструктура за данни и изследвания, насърчавайки принципите на FAIR за софтуер и споделените хранилища.
В науките за живота ELIXIR насърчава споделянето на инструменти със стандартизирани метаданни, тестове и контейнери, което води до по-оперативно съвместим и откриваем код.
Проектите по Програма “ Хоризонт Европа” трябва да гарантират, че изследователският софтуер е:
- Отворен, където е възможно.
- Документиран и за многократна употреба.
- Свързан с постоянни идентификатори.
И в идеалния случай, съобразен с принципите FAIR4RS (откриваем, достъпен, оперативно съвместим, преизползваем изследователски софтуер).
CodeMeta и формат за цитиране на файлове (CFF)
Проектът CodeMeta насърчава изследователите да включват машинночетими метаданни за сътрудниците на софтуера, авторството, версиите и употребата.
Институтът за устойчивост на софтуера предлага шаблони, насоки и обучение на общността за най-добри практики в софтуерното инженерство за изследвания в различни дисциплини.
Заключение
Понякога е трудно за изследователите да приемат, че могат да решат всички проблеми самостоятелно. Но отвореният код не е като отговора на Вечния въпрос “42”, той не е съвършен, той трябва да бъде ясен, разработен в сътрудничество с общността и да осигурява приемственост. Като отварят изследователския софтуер, учените правят науката прозрачна, проверима и използваема.
Следователно, ако изследователите контролират скриптовете си, сложили са .README файлове, обозначили са лиценза и го споделят, галактиката, или поне академичната общност, ще бъде благодарна.