Это поднимает второй важный компонент создания и развития свободного программного обеспечения, поскольку в среде, где более 90 процентов участников могут изменять программу и где все имеют доступ к средствам изменения программы, возникает вопрос о том, как принимать решения об изменениях в коде. Кто выбирает, что будет внесено в программу? Что препятствует распространению множества различных программ? Этот компонент состоит из этики и ряда организационных форм.
Разнообразие организационных форм относится к тому, как устроен каждый проект свободных программ. Если проект остается очень маленьким, в нем может быть минимальная организация; всего несколько человек могут означать, что проект остается полностью открытым для этих людей. Однако даже в небольших проектах сравнительно быстро приходит понимание того, что необходимо контролировать код, чтобы все знали, над какой последней версией следует работать. Среди добровольцев, и, возможно, особенно в начале проектов, многие понимают, что не стоит распылять энергию и усилия на конкурирующие версии. Поскольку код открыт и может быть изменен любым человеком, обладающим необходимыми навыками, всегда есть вероятность, что кто-то будет работать над устаревшей версией или над тем, что уже делают другие. Это привело к появлению репозиториев кода, таких как GitHub или SourceForge, которые отслеживают, над какой версией программы следует работать. Подобные технические решения существуют и в более широких организациях, поскольку репозиторий сам по себе не может решить, какие изменения следует зафиксировать и когда корректировать код. Например, в Apache действует комитетская структура, в которой голоса отдаются тем, кто избран в комитет, и этот же комитет голосует за тех, кто входит в него. Linux работает по модели "благожелательной диктатуры" (или не очень благожелательной, как отмечалось ранее), в которой, когда Linux был меньше, Линус Торвальдс решал, какой код будет использоваться, а затем, по мере роста Linux, ряд других людей были наделены ответственностью за принятие решений по отдельным аспектам кода, при этом последнее слово оставалось за Торвальдсом (Weber 2004: 89-93).
Второй способ координации практики кодирования включает в себя общую культурную приверженность использованию рабочего кода. Часто этот принцип называют принципом "работает ли он", и он отражает одну половину слогана, использовавшегося для описания раннего управления Интернетом: "грубый консенсус и работающий код". Если организационные формы соответствуют "грубому консенсусу", то "работающий код" - это процесс использования программного обеспечения по мере его разработки, чтобы проверить, работает ли оно (Jordan 2008: 52-9). Это кажется технологическим решением, при котором проект выполняет имеющийся у него код, а развитие происходит там, где код оказывается наиболее успешным. Однако это скорее внешнее воплощение культурного выбора природы кода, чем вопрос предоставления технологии решать. Здесь задействованы такие факторы, как элегантность кода, иногда интерпретируемая в терминах того, как мало строк кода требуется, или удобство использования, оцениваемое по тому, легко ли изменять код людям, не являющимся его авторами. В то же время, если функция программы считается достаточно важной, проект разработки может продолжаться, даже если он никогда не будет запущен. Как отмечает Вебер, "техническая рациональность всегда встроена в культурные рамки, которые для открытого кода обычно означают культуру Unix" (2004: 88; Jordan 2008: 52-9).