Но была опасность, что какая-нибудь фирма (та же Microsoft, например) возьмет код Apache и сделает проприетарную программу…
– Вы считаете это опасностью, а я считаю, что это было бы даже хорошо. Во-первых, если бы они исправили ошибку в сервере, то скорее всего не стали бы хранить исправление только для себя. Потому что иначе, когда мы обновим Apache, им придется обновлять свое исправление. Во-вторых, Apache является корректной реализацией протокола HTTP и предоставляет все возможности, которые может и должен предоставлять веб-сервер. Если в Microsoft стали бы его использовать, то не смогли бы утверждать, что протокол HTTP слишком сложен для реализации. Такая ситуация была с языком HTML – когда Microsoft и Netscape реализовали только часть стандарта, а какие-то возможности реализовали по-разному, несовместимым образом. Мы считали, что самый лучший способ противодействовать желанию компаний создавать несовместимые вещи – сделать образцовую реализацию (reference implementation) протокола, причем достаточно хорошего качества, чтобы его могла использовать та же Microsoft. Мы считаем, что нам это удалось.
Прошлое и будущее
Кстати
Одно из нововведений в GPLv3 – совместимость с Apache Licen-se. Авторы GPLv3-софта смогут свободно использовать код Apache и его сателлитов.
За прошедшие тринадцать лет Apache прошел немаленький путь. От небольшого неофициального проекта до Apache Software Foundation. Сообщество выросло от восьми человек до более чем тысячи. Что изменилось за это время в процессе разработки?
Брайен на секунду задумывается. Потом начинает перечислять:
– Люди чаще используют IRC и чаще встречаются лично. Отчасти это связано с тем, что мы регулярно проводим конференцию разработчиков ApacheCon. Мы также делаем такую штуку – называется hackathon. Обычно на выходных перед конференцией собираем народ вместе в одной комнате без всякой повестки дня – люди просто находят тех, с кем хочется работать, садятся и начинают писать код. Это положительно влияет на продуктивность.
Участие в Apache сейчас – хорошая запись в вашем резюме. Люди приходят к нам в том числе из-за этого.
Мы сейчас больше времени тратим на обсуждение политических вопросов. Например, была большая дискуссия во внутреннем списке сообщества о роли женщины в open source. Это действительно очень важная тема – женщин в open source недостаточно, недостаточно женщин-разработчиков. Впрочем, одни этим очень расстроены, другим это не важно. Должны ли мы – Apache Software Foundation – изменить ситуацию? Должны ли создавать специальные места, чтобы женщины могли участвовать в работе над Apache, должна ли быть соответствующая тема на конференции? Так что мы больше времени обсуждаем подобные вопросы – хотя возможно, потому, что наша организация стала более взрослой.
А вы сейчас участвуете в жизни сообщества? Пишете код?
– Я просматриваю патчи других людей – больше времени провожу над разработкой Subversion (система контроля версий, наследница CVS. – И.Щ.), нежели Apache. Хотя еще больше я путешествую и выступаю на разных мероприятиях. Я обнаружил, что говорю лучше, чем пишу код, – так что принесу больше пользы миру, привлекая новых разработчиков и пользователей open source. Недавно я был в Южной Африке, беседовал с государственными представителями, летал в Румынию, в следующем месяце буду в Китае и Шри-Ланке…
Не просто быть хорошим пользователем open source. Нужно как минимум знать английский язык…
– Да, английский язык очень зависим от контекста, иногда даже от тона голоса, и одно и то же предложение может быть прочитано мною и вами очень по-разному. Я могу воспринимать его иронично, а вы можете быть разозлены. Это приводит к спорам, которые отнимают много сил и времени. Личное обсуждение было бы гораздо более приятным. Знание английского действительно очень важно в open source-сообществе. Возможно, на самом деле это не очень хорошо. Я думаю, что хорошие разработчики, для которых английский является родным, понимают, что им нужно писать для международной аудитории. Вероятно, все также постепенно учатся тому, что, когда читаешь электронную почту, нужно предполагать как можно более благоприятную интерпретацию, потому что лучше ошибиться в положительную сторону, чем в отрицательную.
Для создания open source-экосистем в странах типа России нужно еще много потрудиться. Я считаю, что люди могут участвовать в нашем деле, даже если они говорят только на русском, если они сфокусируются на внутреннем рынке. Помимо предоставления поддержки, написания документации, возможны и другие формы участия. Например, русскоговорящий пользователь находит ошибку и сообщает об этом русскоговорящему разработчику. Если это низкоуровневая ошибка, нужно провести определенную работу, чтобы понять, в чем именно она заключается. После этого русскоговорящий разработчик может передать эту информацию другому разработчику, знающему русский и английский, и они могут исправить ошибку. Мы должны развивать федеративную модель сообщества. Такая модель уже действует в проекте Gnome.
К тому же нужно образовывать локальные сообщества. Организовывать списки рассылки, а кроме того, регулярно собираться вместе, обучать друг друга. Так делается в Штатах и в Европе, и действительно помогает. Люди собираются выпить пива вместе, а не только существуют в онлайне.
А что можно сказать про эволюцию глобального сообщества open source за последнее время?
– Открытый софт чаще используется, все больше внедряется в корпорациях. Вы сейчас можете прийти в любую компанию и сказать: "У меня есть программа, которая решит ваши проблемы. Да, и, кстати, она открытая". В большинстве случаев это принимается хорошо. Только не надо говорить: "У меня есть замечательная открытая программа. И, кстати, она решит вашу проблему". Отталкиваться нужно от решения.
Многие компании открывают свои разработки. Посмотрите на Nokia – это была одна из самых проприетарных компаний, даже в большей степени проприетарная, чем Microsoft. Они стремилась закрыть свои платформы как только возможно. Сейчас они продают Linux-таблетки, – Брайен кивает на лежащую передо мной Nokia N770. – И это здорово! Компании начинают "открываться опен сорсу".
Музыка в исходниках
Кстати
Для принятия решений в проектах Apache обычно достаточно найти троих участников, которые его поддержат – при условии, что нет возражений. Такой подход называется "ленивым консенсусом".
Ноутбук Брайена обклеен стикерами: Creative Commons, Magnatune (интернет-магазин, торгующий музыкой без DRM-защиты), логотипы некоторых музыкальных групп. Я знал, что Брайен участвовал в создании некоторых музыкальных сайтов и занимался техническим обеспечением ряда мероприятий, связанных с электронной музыкой.
Правильно ли я понимаю, что вы вовлечены также в движение свободной культуры?
– "Вовлечен" – не совсем верное слово. Лучше сказать, что я фанат свободной музыки. Я не разместил ни одного микса под CC, потому что не смог собрать достаточно CC-лицензированных произведений, чтобы создать микс. Я этого вам не говорил (смеется): у меня есть некоторые миксы в онлайне, но они созданы из несвободной музыки. Я должен как-нибудь сделать полностью лицензионно-чистый микс.
А есть какая-то связь между вашей околомузыкальной деятельностью и open source?
– В 1992 году мы организовали вечеринку на пляже – почти в стиле open source. Мы бросили клич: "Кто может принести звуковую систему? Кто может принести свет?" Все было сделано добровольцами, я координировал процесс и следил, чтобы везде эти добровольцы были. По сути, без всякого бюджета мы организовали вечеринку на шестьсот человек.
Хотя, конечно, между музыкой и софтом есть существенные различия. Программы используются для поддержки производства, у них есть определенная функциональность, которая постоянно улучшается. У музыки нет никакой практической цели – большая ее часть существует для личного удовольствия. К тому же вокруг музыки нет тех систем, которые есть вокруг софта. Здесь нельзя взять какое-то произведение и постепенно его улучшать, выпускать версии 2.1, 2.2, обмениваться патчами и т. д. Хотя есть методы создания новых произведений на основе существующих – ремиксинг. Но это не основной источник музыки на улицах.
Однако я знаю множество диджеев, которые занимаются своим делом не ради денег, а из желания поделиться музыкой. Может быть, в этом тоже есть что-то от open source.
Основание и империя
Некоммерческая организация Apache Software Foundation (ASF) была образована в 1999 году. Целей было несколько. Во-первых, к свободному веб-серверу, владеющему на тот момент 60% рынка, стали проявлять внимание крупные корпорации – в частности IBM и Sun. Вместе с тем пришла и опасность попасть в зависимость от какой-то одной компании, а разработчики Apache хотели сохранить сообщество таким, каким оно появилось: децентрализованным и меритократичным, в котором решения принимаются на основе обсуждения технических вопросов и поиска консенсуса, а не частного коммерческого интереса. К тому же требовалось обеспечить правовую защиту разработчиков на случай претензий третьих лиц. Решением стало создание нейтральной площадки, не зависящей напрямую ни от каких корпораций, не контролирующей финансовые потоки и даже не имеющей собственного оплачиваемого персонала. Активные разработчики Apache, являющиеся членами ASF, зачастую работают на самые разные корпорации, но выступают всегда от своего лица, а не от лица работодателя. Решения в проектах ASF принимаются по принципам консесуса – здесь нет «центральной власти», в отличие от многих других open source-проектов (например, ядра Linux, где Линус Торвальдс и те люди, которым он доверяет, принимают окончательные решения). Главной задачей ASF остается создание и поддержка здоровых сообществ для работы над проектами вокруг Apache: в настоящий момент таких проектов аж 26, над ними работают 1100 участников с правами записи в дерево исходников (commit access). Помимо всего прочего, ASF занимается «просвещением» программистов в области авторского и патентного права и проводит регулярную конференцию ApacheCon, где собираются разработчики Apache и смежных проектов со всего света.
