Четыре столпа Open Source

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

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

Задача организации Open Infrastructure Foundation (ранее OpenStack Foundation) [1] — формирование сообществ разработки кода, который функционирует в рабочих средах по всему миру, служа двигателем критически важной инфраструктуры и сервисов с большим числом пользователей. Чтобы преодолевать трудности разработки ПО с открытым кодом, открытого взаимодействия и не только, сообщества Open Infrastructure Foundation следуют руководящим принципам Four Opens («Четыре столпа открытости») [2].

Не только открытый код

Термин Open Source пояснений не требует — мы живем в эпоху, когда стало нормой разрабатывать инфраструктурное ПО и оборудование по принципу Open Source, и речь уже давно идет не только о хобби-разработках. В то же время растет число проектов с открытым кодом, жестко контролируемых единственной организацией, в которой работают большинство участников конкретного сообщества. Под контролем такой организации находятся планы развития, процессы проектирования, разработки и пр. Это не новое явление и не всегда проекты такого характера инициируются намеренно. Чтобы этого избежать, нужно изначально нацеливаться на построение вокруг проекта сообщества, основанного на принципах многообразия. Так будет создан залог возможности слаженной работы над воплощением проекта в реальность.

Осознание этой задачи привело сообщество OpenStack к приоритету многообразия с организационной и других точек зрения — был утвержден набор принципов Four Opens, которым должны следовать все участники. С ростом сообществ разработчиков стало сложнее формировать сбалансированную среду, участники которой являются носителями разных культур, говорят на разных языках и нередко работают на конкурирующие компании. Еще сложнее добиться баланса во вновь сформированных сообществах, где большинство участников нередко только начинают знакомиться с концепцией и практикой разработки открытого кода.

Принципы Four Opens помогают преодолевать эти сложности, предлагая рекомендации по формированию среды, в которой участники ощущают уверенность в себе, знают свои возможности и могут взаимодействовать для достижения общей цели. Эти принципы стали фундаментом процедур, которым следуют все сообщества в рамках Open Infrastructure Foundation.

Принципы Four Opens

К числу принципов Four Opens относятся открытое сообщество, открытое проектирование, открытая разработка и открытый код. Каждый из них помогает ориентироваться в динамически меняющейся среде сообщества Open Source. Возможно, перечисленные принципы кажутся очевидными, а следование им — само собой разумеющимся, но это не всегда так.

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

Открытое сообщество

Говоря об Open Source, обычно имеют в виду открытый код и возможность доступа к нему тем или иным способом. При этом могут забывать, что за проектированием, реализацией и сопровождением ПО стоят реальные люди, без которых проекта бы не было. Даже в закрытой корпоративной среде динамические циклы совместной работы всегда сопровождаются сложностями, а в открытой без специальных мер не будет единого понимания процессов, вопросов безопасности и т. д. — такие среды могут отпугивать даже опытных участников.

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

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

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

Открытое проектирование

Открытое проектирование — основа достижения прозрачности и создания гарантий того, что никакое лицо, организация или группа лиц не будет иметь контроль над проектом. Казалось бы, термин «открытое проектирование» говорит сам за себя, но обеспечить такую открытость непросто. Компании нередко самостоятельно начинают проектирование и разработку, а со временем выпускают проект по лицензии открытого кода. Мотивация при этом может быть разной, но сложности построения сообщества и экосистемы вокруг такого проекта всегда одинаковые.

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

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

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

Открытая разработка

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

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

После внедрения нужных инструментов потребуется еще кое-что. Необходимо позаботиться о том, чтобы инструменты, используемые сообществом, были доступными для участников — они должны понимать принцип действия средств автоматизации и участвовать в сопровождении инструментальной цепочки. В OpenStack, в частности, установили соответствующие высокие стандарты и приняли решение о создании фреймворка для непрерывного тестирования кодовой базы, начиная с момента, когда кто-то предлагает исправления. В итоге в рамках соответствующего проекта, получившего название Zuul, создан самостоятельный фреймворк, который используется многочисленными сообществами и организациями. Zuul работает своего рода «привратником» — участники проводят ревизии изменений кода и документации, имея право отклонять или утверждать их, однако в итоге изменения вносятся в проект только в случае успешного прохождения тестирования.

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

Открытый код

В контексте Four Opens открытость кода означает, что ПО необходимо выпускать по лицензии, одобренной организацией Open Source Initiative. Такая лицензия разрешает всем желающим доступ, использование, модификацию и распространение ПО как в оригинальном виде, так и с изменениями. Кроме того, в рамках Four Opens запрещено пользоваться моделью Open Core, когда контролирующая организация исключает некоторые функции из открытой версии проекта, чтобы иметь возможность предлагать платный вариант заинтересованным заказчикам. Принцип открытости обеспечивает доступность кода и других артефактов, а также отсутствие лицензионных и иных юридических препятствий, которые могли бы ограничивать коллективное развитие и сопровождение ПО.

***

Четыре принципа открытости не гарантируют успех и долговечность сообщества и продуктов его деятельности, но обеспечивают мощный фундамент для строительства устойчивой и сбалансированной экосистемы вокруг проектов открытого кода. Технологии нередко выдвигают на первый план, забывая принять в расчет человеческий фактор и важность создания среды, в которой могли бы взаимодействовать участники со всего мира независимо от культуры, языка, карьерных устремлений и политических предпочтений. В сообществах разработки открытого кода, характеризующихся многообразием, это особенно сложно. Доктрина Four Opens была создана как ответ на признание этих трудностей и для того, чтобы их преодолеть, дав участникам общее дело, в которое они могли бы поверить и стать его активными сторонниками.

Литература

1. Open Infrastructure Foundation, 2020. [Онлайн]. URL: https://openinfra.dev

2. Four Opens Book, 2021. [Онлайн]. URL: https://opendev.org/openinfra/four-opens

3. Y. Zhang, H. He, M. Zhou, Commercial participation in OpenStack: Two sides of a coin. Computer, vol. 55, no. 2, pp. 78–84, 2022. [Онлайн]. URL: https://dirkriehle.com/2022/02/21/commercial-participation-in-openstack-zhang-et-al-ieee-computer-column/, doi: 10.1109/MC.2021.3133052/

Ильдико Ванча (ildiko@openinfra.dev) – старший менеджер по сообществам и экосистемам, Open Infrastructure Foundation.