неудивительно, что на долю IBM пришлось 4,1 %, а на долю Google - 3 % всех изменений в 2017 году (Corbet and Kroah-Hartman 2018: 14-15). В серверном программном обеспечении Apache отмечается, что все взносы в него являются добровольными, как и в случае с Linux, однако в нем не отслеживается, кому платит другая компания за внесение изменений, равно как и в отчете о разработке для пакета LibreOffice не указывается, откуда берутся изменения в нем (ASF 2017; TDF 2016). Кодеры предлагают добровольные взносы, но Linux свидетельствует о том, что кодированием программ, используемых крупными корпорациями, все чаще занимаются сотрудники этих компаний. Это не обязательно подрывает амбиции свободного программного обеспечения, но предполагает дальнейший раскол внутри условно открытого сообщества создателей в зависимости от того, привлекает ли проект институциональную поддержку или нет.
Это поднимает второй важный компонент создания и развития свободного программного обеспечения, поскольку в среде, где более 90 процентов участников могут изменять программу и где все имеют доступ к средствам изменения программы, возникает вопрос о том, как принимать решения об изменениях в коде. Кто выбирает, что будет внесено в программу? Что препятствует распространению множества различных программ? Этот компонент состоит из этики и ряда организационных форм.
Разнообразие организационных форм относится к тому, как устроен каждый проект свободных программ. Если проект остается очень маленьким, в нем может быть минимальная организация; всего несколько человек могут означать, что проект остается полностью открытым для этих людей. Однако даже в небольших проектах сравнительно быстро приходит понимание того, что необходимо контролировать код, чтобы все знали, над какой последней версией следует работать. Среди добровольцев, и, возможно, особенно в начале проектов, многие понимают, что не стоит распылять энергию и усилия на конкурирующие версии. Поскольку код открыт и может быть изменен любым человеком, обладающим необходимыми навыками, всегда есть вероятность, что кто-то будет работать над устаревшей версией или над тем, что уже делают другие. Это привело к появлению репозиториев кода, таких как GitHub или SourceForge, которые отслеживают, над какой версией программы следует работать. Подобные технические решения существуют и в более широких организациях, поскольку репозиторий сам по себе не может решить, какие изменения следует зафиксировать и когда корректировать код. Например, в Apache действует комитетская структура, в которой голоса отдаются тем, кто избран в комитет, и этот же комитет голосует за тех, кто входит в него. Linux работает по модели "благожелательной диктатуры" (или не очень благожелательной, как отмечалось ранее), в которой, когда Linux был меньше, Линус Торвальдс решал, какой код будет использоваться, а затем, по мере роста Linux, ряд других людей были наделены ответственностью за принятие решений по отдельным аспектам кода, при этом последнее слово оставалось за Торвальдсом (Weber 2004: 89-93).
Второй способ координации практики кодирования включает в себя общую культурную приверженность использованию рабочего кода. Часто этот принцип называют принципом "работает ли он", и он отражает одну половину слогана, использовавшегося для описания раннего управления Интернетом: "грубый консенсус и работающий код". Если организационные формы соответствуют "грубому консенсусу", то "работающий код" - это процесс использования программного обеспечения по мере его разработки, чтобы проверить, работает ли оно (Jordan 2008: 52-9). Это кажется технологическим решением, при котором проект выполняет имеющийся у него код, а развитие происходит там, где код оказывается наиболее успешным. Однако это скорее внешнее воплощение культурного выбора природы кода, чем вопрос предоставления технологии решать. Здесь задействованы такие факторы, как элегантность кода, иногда интерпретируемая в терминах того, как мало строк кода требуется, или удобство использования, оцениваемое по тому, легко ли изменять код людям, не являющимся его авторами. В то же время, если функция программы считается достаточно важной, проект разработки может продолжаться, даже если он никогда не будет запущен. Как отмечает Вебер, "техническая рациональность всегда встроена в культурные рамки, которые для открытого кода обычно означают культуру Unix" (2004: 88; Jordan 2008: 52-9).
Практика написания программ интегрирована со способами организации и принятия решений. Последний ключевой элемент также является одной из самых известных характеристик свободного программного обеспечения - его приверженность распределительному определению собственности. Чтобы свободные программы оставались свободными в том смысле, что позволяли любому человеку получать доступ к коду и изменять его, они должны были найти способ существовать в контексте законов об интеллектуальной собственности. Нужно было предотвратить, чтобы кто-то взял свободно распространяемый код и применил к нему ограничительную лицензию, не позволяющую другим работать с ним. Ответом стала инверсия, в которой определенные лицензии, наиболее известная Gnu Public License (GPL), требуют от любого, кто использует этот код, держать его открытым для других и возвращать любые исправления в кодовую базу, в обмен на что они могут брать, копировать, распространять и взимать плату за код. Лицензии часто проходят через широкие консультации, например, третья версия GPL получила в общей сложности 2 636 комментариев. Лицензии - это ключевой момент, когда для свободных программ становится важен опыт, отличный от кодирования. В этом случае возникает практика споров о природе лицензий, которые затем применяются к деятельности по кодированию программ (Weber 2004: 16).
Свободное программное обеспечение и, в некоторой степени, открытый исходный код зависят от сообщества, занимающегося добровольной деятельностью. Это не полноценное "сообщество" в привычном понимании, а сообщество деятельности. Оно направляет свою работу через такие платформы, как репозитории кода, списки электронной почты, онлайновые форумы, конференции и так далее, причем все это специфично для каждого проекта. Сложность здесь в том, что хранилище кода и другие элементы проектов свободного программного обеспечения создают более открытую платформу, отчасти потому, что момент монетизации отвергается. Хотя деятельность и платформы существуют в свободном программном обеспечении, стремление к финансовой выгоде отсутствует.
Как и в случае с технологией блокчейн, это поднимает вопросы о связи между подобными практиками и экономическими практиками, особенно монетизацией. Хотя нет сомнений в том, что свободное программное обеспечение нашло свое применение в ряде экономических практик - IBM и Google были отмечены здесь - указывает на то, что экономическая практика не должна сводиться к функции получения прибыли или дохода. Если экономика не сводится к прибыли и доходам, какими бы важными они ни были, то в отношении цифровых экономических практик важно увидеть, как практики свободного программного обеспечения имеют сходства и различия с практиками поиска, социальных сетей и дезинтермедиации. Без необходимости регистрировать и монетизировать сама платформа может быть более открытой, состоящей из принципов сообщества экспертов, средств разрешения споров и информации как распределенной собственности, которые реализуются в различных местах, таких как репозитории кода, форумы,
