Подготовка разработчиков свободного программного обеспечения

Производство свободного программного обеспечения (ПО) – тенденция развития современных информационных технологий. Одна из задач вуза – это подготовка студентов, способных создавать подобные программные продукты. На государственном уровне обращают внимание на необходимость подобной подготовки, но образовательные программы несколько отстают. Предлагается в существующих дисциплинах, связанных с разработкой ПО, повысить внимание качеству создаваемого программного кода для возможности его свободного использования. Навык создания качественного кода проще всего вырабатывается при командной работе над проектом.

ВВЕДЕНИЕ

Свободное программное обеспечение (СПО) в последнее время вызывает всё больший интерес российского программистского сообщества. За рубежом развитие СПО диктуется, в основном, вопросами эффективности разработки программных продуктов, в России добавляется фактор импортонезависимости [1]. Правда, порой даже у профессиональных программистов нет чёткого представления, в чем различие между свободным, открытым и бесплатным программным обеспечением, каковы тенденции развития этого направления, какие существуют проблемы в этой области.

Под бесплатным ПО понимается продукт, за который пользователь не платит, под открытым такое, исходный код которого можно посмотреть, со свободным же можно делать что угодно, но не закрывать.

СПО – это программное обеспечение, распространяемое на условиях свободного лицензионного договора. На его основании пользователь получает право использовать программу в любых не запрещенных законом целях. Он может получать доступ к исходным текстам программы как в целях её изучения и адаптации, так и для переработки, вносить в неё изменения, распространять программу (бесплатно или за плату).

Лицензия определяет, что можно делать с программой. В неё включается следующее:

• можно ли модифицировать код без указания автора (BY);
• если кто-то взял код за основу, то должен ли он использовать ту же самую лицензию (SA);
• можно ли зарабатывать на этом коде (NC);
• можно ли вообще модифицировать этот код или нужно использовать его только в исходном виде (ND);
• какие организации могут пользоваться кодом.

Аббревиатуры в описаниях условий лицензий общеприняты, они имеют стандартные символьные обозначение:

Отметим некоторые популярные лицензии.

GNU GPL (GNU General Public License) — универсальная общедоступная лицензия. По ней пользователь получает четыре свободы:

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

Похожая на GPL лицензия для продуктов Mozilla: Mozilla Public License. Но она имеет существенное отличие: код под этой лицензией можно использовать вместе с закрытым кодом, права на которые есть только у его разработчика.

Лицензия Apache разрешает делать с кодом что угодно, главное — указать всех авторов и все патенты, которые использовались при разработке.

Использование СПО позволяет решать следующие задачи [2]:

• импортозамещение проприетарных компонентов информационных систем;
• стимулирование развития отечественной отрасли разработки программ для ЭВМ;
• расширение участия отечественных разработчиков в государственных проектах;
• обеспечение высокого уровня технологической независимости;
• уменьшение числа нарушений правовой защиты программ.

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

Переход на СПО — мировая тенденция. По результатам опроса на Stack Overflow (70 тысяч разработчиков) в 2022 году Linux как основную операционную систему использовало около 40% специалистов. (в 2018 году 23%). По экспертным оценкам объем рынка разработки программного обеспечения с открытым кодом к 2026 году составит 37 млрд $, а сервисов на его основе – 66 млрд $. На смену противостоянию открытого и закрытого ПО приходит конвергенция обоих подходов к разработке и распространению ПО. Корпорации используют каждый из подходов там, где он наиболее выгоден. Развитие по открытой модели наиболее интенсивно идёт в области системного и кроссотраслевого ПО, в то время как в области прикладного и узкоспециального профессионального ПО преобладают проприетарные продукты.

Со стороны Правительства РФ принимались определенные усилия, направленные на развитие СПО, но, к сожалению, они не всегда приводили к успеху. Так, в 2008 году была предложена концепции развития разработки и использования СПО, но на этапе практического внедрения стали возникать затруднения, связанные с нехваткой грамотных сотрудников, дефицитом информации, недостаточной популяризацией и т. п. В 2009 году была создана РАСПО (Российская ассоциация СПО), которая просуществовала до 2016 года. План перехода государственных органов и федеральных бюджетных учреждений на СПО 2010 года выполнен не был. В 2011 году был объявлен конкурс на создание прототипа Национальной программной платформы (НПП) [3]. Но уже в 2012 году результаты создания прототипов базовых компонент НПП были засекречены, а сам проект был безрезультатно закрыт в 2015 году.

ПО с открытым исходным кодом становится все более востребованным и в российских компаниях. Здесь сообщество разработчиков Open Source достаточно сильное: по данным JetBrains, на РФ приходится 7% поставщиков международных проектов с открытым кодом (ОПО), 5 место в мире после США, Китая, Индии и Японии. GitHub к 2030 году ожидают увеличение влияния российских разработчиков на сообщество. Доля продуктов с Open Source-элементами в реестре отечественного ПО может достигнуть 85%.  К 2026 году 92% российских компаний будут использовать решения на базе Open Source.

Тем не менее, распространение СПО в России могло бы быть и большим. Сдерживающие причины следующие:

• недостаточная осведомленность российского ИТ-сообщества о продуктах с открытым исходным кодом, его возможностях и особенностях;
• непонимание руководителями механизмов развития открытых продуктов и связанное с этим недоверие к ним;
• привычка к определённым проприетарным продуктам и незнание юридических аспектов использования открытого ПО;
• отсутствие практики создания отраслевого СПО с использованием возможностей его функционала для сокращения бюджетных расходов.

Конечно, разработка СПО – не такая простая задача. В работе Карла Фогеля [5] отмечается, что лишь 5-10% всех проектов СПО завершается успешно. «Когда проект по разработке свободного ПО садится на мель, причиной тому чаще всего будет неумение разработчиков (или менеджеров) учитывать специфические проблемы разработки открытого ПО, хотя к проблемам, присущим разработке коммерческого ПО, они могут быть основательно подготовлены». Замечено, что чаще всего в проекте распадается коллектив разработчиков. Но если вести проект в учебном заведении, где ядро коллектива составляют опытные преподаватели, есть реальный шанс поддержать проект в течение всего цикла разработки за счёт привлечения все новых заинтересованных студентов.

Ситуацию может улучшить внедрение тематики разработки СПО в учебные программы. В октябре 2021 года Минцифры и АНО «Цифровая экономика» представили НКО Russian Open Source Foundation, на базе которой разработан проект «Стратегия развития программного обеспечения с открытым кодом в России» [4]. В одном из разделов этого проекта предложены меры по усилению кадрового потенциала, которые напрямую касаются высшей школы. Среди них указаны такие:

• преимущественное использование продуктов с открытым программным обеспечением (ОПО) в учебных заведениях, организация доступа к национальному облачному сервису публичных репозиториев;
• грантовая поддержка преподавателей, кафедр и лабораторий, которые разрабатывают учебные курсы и другие образовательные продукты на основе ОПО;
• разработка программ переподготовки преподавателей для обучения их использованию ОПО, а также организация переподготовки, включая её грантовую поддержку;
• стимулирование участия ИТ-компаний в образовательных учреждениях для преподавания практических аспектов программных технологий и для руководства студенческими проектами в области разработки ОПО;
• возможность представления ВКР в качестве вклада в продукт ОПО или результата работы в отечественных ИТ-компаниях;
• включение метрик, связанных с участием в разработках ОПО, в КПЭ вузов технической направленности и установление критериев получения преподавателями надбавок за академическую деятельность;
• разработка и внедрение образовательных материалов по открытой модели разработки, основам организации сообществ программных продуктов с открытым кодом и ведения бизнеса на базе таких продуктов;
• проведение общенациональных мероприятий по привлечению студентов в разработку ПО с открытым кодом под эгидой представителей отечественных компаний.

Итак, если есть необходимость в развитии этого направления, следует привлекать к разработке СПО больше программистов из студенческой среды, разъяснять все вопросы, связанные с СПО.

Учебная дисциплина, призванная подготовить студентов для решения этих задач, – это «Программная инженерия», которая входит в большинство учебных планов вузов, где есть направление «Прикладная информатика». Именно она даёт возможность получить на выходе качественного специалиста.

Что конкретно мы хотим видеть в результате обучения?

1. Главное – умение и стремление создавать качественный код: стиль написания, комментарии, документированность для возможности его развития.
2. Умение читать чужой код, разбираться в нем, модифицировать и документировать его.
3. Владение инструментальными средствами разработки.
4. Способность работать в коллективе разработчиков.

Мы проанализировали рабочие программы (РПД) некоторых вузов на соответствие требуемому профессиональному уровню, и оказалось, что  внимание именно к этим аспектам было недостаточным.

В некоторых РПД указываются подходящие компетенции. Например,

• (ОК-3) способен работать в коллективе, нести ответственность за поддержание партнерских, доверительных отношений;
• (ПК-14) способен принимать участие в реализации профессиональных коммуникаций в рамках проектных групп, презентовать результаты проектов и обучать пользователей ИС.

Посмотрим на главное: умение создавать качественный код. Здесь мы не говорим об отсутствии ошибок, обратим внимание на качество текста. К сожалению, именно этот фактор проходит мимо внимания преподавателя. Действительно, если студент сдаёт программу, то пусть она хотя бы не падает и выдаёт правильный ответ. В результате мы получаем юного гения, который гордится, что его изделие работает, а никто не может понять, почему. И кому нужен такой код, даже открытый, если его невозможно развивать?

На самом деле, качество текста – понятие достаточно простое, которое практически всегда обеспечивается стилем. Можно заранее задать некоторый стиль, который обеспечит лёгкость понимания текста не только преподавателем, но и коллегами-студентами. И тут мы переходим к другому аспекту подготовки специалистов в области СПО – коллективной разработке.

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

Профессиональные разработчики, волею судеб оказавшиеся в роли вузовских преподавателей, прекрасно знают эту проблему и стараются по мере возможности её решить. Приведём пару примеров. В Высшей школе экономики широко используют проектное обучение, в ходе которого формируются группы бакалавров, которыми руководит магистрант. Студенты совместно работают над курсовыми проектами и ВКР. Очень интересным был опыт коллективных работ в Гусевском стекольном колледже. Это даже не вуз, но его учащиеся со своими программными проектами успешно выступали на крупных конференциях.

Что мы можем предложить?

Студенческие проекты представляют собой важную составляющую учебного процесса: они позволяют студентам применять теоретические знания на практике, развивать навыки командной работы и самоорганизации, изучать новые технологии и методологии. Но в обычной практике дипломные и курсовые проекты разрабатываются студентом в одиночку, хотя и с научным руководителем. Значит, весьма важные для программиста командные навыки просто не смогут сформироваться, не говоря уж об опыте командной работы над проектом. О столь полезном навыке, как руководство проектом, и говорить не приходится. Особенно ярко это проявляется при реализации крупных проектов в области создания программного обеспечения. Отсутствие навыков работы в команде сказывается и на производительности молодого сотрудника, и на его адаптации к рабочему процессу.

Первое, что приходит в голову – давайте разделим студентов на команды, дадим им проекты, и пусть работают. Но студенческие проекты характеризуются рядом особенностей, которые необходимо учитывать при разработке системы управления ими. Они, например, имеют ограниченные ресурсы, не производственные, а образовательные цели, излишнюю изменчивость требований и, конечно же, необходимость поддержки  конструктивного взаимоотношения участников проекта.

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

В команде должны быть представлены основные роли исполнителей: руководитель проекта, архитектор, программист, тестировщик. Каждую из ролей может исполнять как один человек, так и несколько. Роль руководителя, естественно, играет не только преподаватель, но один из членов команды. Он должен отвечать за весь проект. Оптимальный размер студенческой команды – три-четыре человека. Может быть, конечно и два, и пять, но в первом случае взаимодействие участников слишком упрощено, а во втором команда из новичков может быть трудно управляемой. В случае двух человек им можно предложить роли разработчиков клиентской и серверной частей приложения. 

Выбор технологии разработки может быть свободным, но должна быть одна из систем контроля версий (например, Github).

Второе предложение касается продолжения работы над неоконченными интересными проектами. Студенты выкладывают свои разработки в открытый доступ, но потом это никем не используется. Преподаватели дают похожие темы из года в год, как правило, никак не учитывая предыдущие наработки. Причина понятна: документация невысокого качества, стиль тоже, да и руководство с подозрением смотрит на повторяющиеся темы.

Третье предложение – стараться организовать студентов для участия в реальных проектах СПО.

1. Свободное программное обеспечение в госорганах. [Электронный ресурс] URL: https://digital.gov.ru/ru/activity/directions/106/ (дата обращения 28.8.2023).
2. От Open Source к ОПО? Факторы развития свободного программного обеспечения в России. [Электронный ресурс] URL: https://www.comnews.ru/digital-economy/content/217248/2021-11-08/2021-w45/open-source-k-opo-faktory-razvitiya-svobodnogo-programmnogo-obespecheniya-rossii/ (дата обращения 28.8.2023).
3. Национальная программная платформа (НПП). [Электронный ресурс] URL: https://www.tadviser.ru/index.php/Продукт: Национальная_ программная_платформа (дата обращения 28.8.2023).
4. Стратегия развития программного обеспечения с открытым кодом в России до 2024 года. [Электронный ресурс] URL: https://d-russia.ru/wp-content/uploads/2021/10/proekt_strategii_opo_30_09_21.pdf (дата обращения 28.8.2023).
5. Карл Фогель. Создание Свободного Програмного Обеспечения. Как вести успешный открытый проект.   [Электронный ресурс] URL: https://producingoss.com/ru/index.html (дата обращения 28.8.2023).