Модуль 1. Введение

Движение открытой науки за последнее десятилетие изменило научную коммуникацию. Сначала издательской нормой стал открытый доступ к публикациям, затем – открытость исследовательских данных. Принципы FAIR, сформулированные Уилкинсоном и коллегами, задали ориентир для управления данными: данные должны быть находимыми, доступными, совместимыми (интероперабельными) и пригодными к повторному использованию. Вокруг этих принципов выросла целая профессиональная область – управление исследовательскими данными (research data management, RDM), – и библиотеки заняли в ней заметное место.

Рекомендация ЮНЕСКО по открытой науке относит к открытому научному знанию широкий круг результатов – публикации, данные, метаданные, образовательные ресурсы, программное обеспечение и исходный код, открытое оборудование; для целей курса мы сосредоточимся на трех цифровых объектах и включаем в их число программное обеспечение – наряду с публикациями, данными, метаданными и другими результатами. Первые два за прошедшие годы обросли устойчивыми практиками описания, каталогизации и архивирования. Третий – исследовательское программное обеспечение (research software) – остается в своего рода «слепой зоне»: его публикация, описание и сохранение обеспечены институционально слабее всего.

Под исследовательским ПО рабочая группа FAIR4RS понимает «исходный код, алгоритмы, скрипты, вычислительные конвейеры и исполняемые файлы, которые были созданы в ходе исследовательского процесса или для исследовательских целей». Это широкое определение – под него подходит и скрипт обработки данных на пятьдесят строк, и крупная библиотека научных вычислений, которую сообщество развивает десятилетиями. В модуле 2 мы уточним это определение и покажем, чем код принципиально отличается от данных; пока достаточно зафиксировать, что без работающего кода значительная часть современных научных результатов невоспроизводима.

Тезис о «слепой зоне» подтверждается измерениями. Шарма и коллеги, проанализировав 453 статьи из биомедицинских журналов, обнаружили, что около половины публикаций не содержат исходного кода, необходимого для воспроизведения результатов. Карлин и коллеги, изучив институциональные репозитории Великобритании, показали, что программное обеспечение в них практически не представлено: большинство репозиториев вообще не учитывают код как самостоятельный тип научного результата. Карвер с коллегами по итогам опроса более тысячи исследователей зафиксировали озабоченность устойчивостью и долгосрочным сопровождением научного кода при недостаточной институциональной поддержке.

Корень проблемы – в природе самого объекта. Данные фиксируются на момент публикации, а код «живет»: он непрерывно меняется, зависит от вычислительного окружения и теряет работоспособность, когда меняются библиотеки, компиляторы или операционные системы, на которые он опирается. Хинсен назвал это явление «обрушением программного обеспечения» (software collapse): код перестает работать не потому, что в нем что-то изменили, а потому, что изменилось его окружение. Существующие схемы описания – Dublin Core, DataCite – и привычные библиотечные репозитории не приспособлены к тому, чтобы фиксировать зависимости, версии и совместимость окружений.

Ответом научного сообщества на эти трудности стало появление новой профессиональной роли – инженера исследовательского ПО (research software engineer, RSE). Это специалист, сочетающий предметную научную подготовку с инженерной культурой разработки. Вокруг этой роли сложились сообщества и сервисные организации: британский Software Sustainability Institute, нидерландский Netherlands eScience Center, немецкое сообщество de-RSE. Анцт и коллеги описали устойчивость исследовательского ПО как системную задачу, которую невозможно решить силами отдельного проекта: она требует инфраструктуры, обучения и стимулов на уровне организаций и фондов.

Между повседневной практикой исследователя и инфраструктурой остается разрыв. Исследователь пишет код, чтобы получить научный результат, и редко располагает временем и навыками, чтобы подготовить его к публикации по всем правилам: выбрать лицензию, оформить метаданные, депонировать в архив, обеспечить цитируемость. Именно здесь возникает потребность в посреднике, который переводит требования открытой науки на язык конкретных действий и инструментов.

Посредником, который переводит требования открытой науки на язык конкретных действий и инструментов, способна стать научная библиотека, и здесь важна аналогия с управлением данными. Сервисы RDM выросли в библиотеках во многом потому, что фонды сделали планы управления данными (data management plans) условием получения гранта; внешнее требование создало внутренний запрос. С программным обеспечением такого общего требования пока почти нет – и в этом, как мы увидим в модуле 5, состоит одна из главных проблем. Но это не повод откладывать работу: библиотека может выступить инициатором, перенося на код уже отработанные практики курирования данных и адаптируя их к специфике ПО.

Чтобы такая работа была предметной, библиотекарю нужны три вещи: язык, на котором можно описать разные типы программных объектов; перечень того, что стоит прикладывать к публикуемому коду; и понимание того, чего требуют – и чего не требуют – действующие политики. Этим трем задачам посвящены первые модули руководства. В модуле 2 уточняется, что такое исследовательское ПО и чем оно отличается от данных. В модуле 3 предлагается типология, позволяющая провести первичную сортировку программных объектов. В модуле 4 разворачиваются принципы FAIR4RS и рамка из тринадцати категорий практик публикации. В модуле 5 показывается, как эти артефакты отражены в реальных политиках журналов, университетов, фондов и инфраструктурных инициатив. В модуле 6 разбирается российский контекст, где код регулируется прежде всего как результат интеллектуальной деятельности. Модуль 7 – практикум – доводит читателя от репозитория с кодом до цитируемого, заархивированного и снабженного метаданными программного объекта. В модуле 8 обобщаются практические выводы предыдущих модулей в модель библиотечного сервиса поддержки кода. Сквозная мысль руководства проста: «исследовательское ПО» не следует трактовать как однородную категорию. Скрипт анализа и зрелая библиотека научных вычислений требуют разного описания, разного цитирования и разных стратегий сохранения. Библиотекарь, который умеет различать эти случаи, работает не вслепую, а по понятному алгоритму. Наша цель состоит в том, чтобы выстроить этот алгоритм.

1. Почему открытый доступ к публикациям и принципы FAIR для данных закрепились в институциональной практике раньше, чем практики работы с кодом?
2. В чем состоит «обрушение программного обеспечения» и почему оно делает код более хрупким объектом сохранения, чем данные?
3. Какую роль в вашей организации мог бы взять на себя библиотекарь или RDM-специалист в отношении исследовательского ПО уже сегодня, не дожидаясь внешних требований?