Sam Hocevar - новый лидер проекта Debian

Недавно был выбран новый лидер проекта Debian (Debian Project Leader, DPL) - Sam Hocevar, победивший семь других кандидатов благодаря предвыборной платформе, нацеленной на улучшение взаимодействия между участниками проекта. Эти последние выборы состоялись во времена, когда Debian начал терять поддержку как разработчиков, так и конечных пользователей, среди которых замечен некоторый отток в сторону других дистрибутивов, например, Ubuntu. Также остро стоит проблема эффективности работы сообщества и преодоления внутренних разногласий.



Свое первое с момента избрания интервью Сэм дал по электронной почте журналисту Bruce Byfield, пишущему для Linux.com.

Какие задачи вы как новый DPL собираетесь начать решать в первую очередь?

Первую вещь, которую мне предстоит сделать – это собрать информацию о внутренних конфликтах и противоречиях, которые мешают продуктивной совместной работе участников проекта. Я планирую в начале сконцентрироваться на социальном аспекте своей предвыборной платформы, хотя бы потому, что это требует больших временных затрат. Технические же вопросы, о которых я говорил в своей предвыборной кампании, уже начали решаться, не дожидаясь моего избрания. Так, уже запущен проект веб-интерфейса к нашей системе bug tracking в рамках Google Summer of Code. По крайней мере один проект, касающийся инфраструктуры отладки, уже находится в стадии разработки, также несколько предложений по усовершенствованию нашего веб- сайта уже переходят в практическую плоскость.

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

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

Мы также не должны упускать из виду следующий сценарий: «Что будет, если один из ключевых разработчиков попадет в автокатастрофу?». Несколько наших товарищей уже ушли из жизни, а учитывая, что сообщество в целом становится старше и многочисленней, мы, как это ни прискорбно, предвидим, что такие случаи в будущем будут иметь тенденцию только к увеличению. Сюда же можно приплюсовать сценарии, когда ключевой разработчик потеряет интерес к проекту, найдет новую работу, женится, обзаведется детьми... И именно поэтому я делаю большую ставку на привлечение свежих сил – не только для поддержки пакетов, но и для работы в наших ключевых, центральных командах разработки. Иначе, случись что, мы будем лихорадочно соображать, что делать, когда будет уже слишком поздно...

Почему вы считаете, что большее количество работ надо сосредоточить в устоявшихся коллективах разработчиков (teams). И как вы планируете содействовать их создание?

В ситуациях, когда многие задачи ждут своего решения недопустимо долго по причине сильной занятости ответственного за их решение лица, а люди, готовые взяться за дело, не имеют соответствующих полномочий, команда разработчиков – это именно та концепция, которая может помочь делу. Как я сказал в моей избирательной платформе, я хочу постепенно отходить от концепции «владения» пакетами (maintainers). У меня нет права навязывать такую точку зрения, но я могу способствовать этому процессу. Например, приветствовать стремление активистов исправлять ошибки в «чужих» пакетах, а также создавать тимы для пакетов, которые сейчас плохо поддерживаются. Активность такого рода на сегодняшний день воспринимается враждебно, поскольку ставит под сомнение возможности куратора (maintainer) пакета, однако от таких устаревших взглядов надо избавляться.

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

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

Что вы думаете существующем на сегодняшний день процессе вхождения в проект Debian новых кураторов пакетов? Какие конкретные шаги вы собираетесь предпринять для рационализации этого процесса?

Этот процесс действительно очень медленный, поскольку многие считают, что только так можно удостовериться в достаточной заинтересованности и ответственности нового куратора. Самым длительным этапом в рамках этого процесса является ожидание утверждения кандидатуры со стороны DAM’ов (Debian Account Managers). Именно они принимают решение о принятии того или иного кандидата в проект. Нам нужно или больше DAM’ов, или столько же, но располагающих большим свободным временем. Уже были попытки (в том числе со стороны предыдущего лидера) улучшить этот процесс, и я продолжу заниматься этим вопросом.

К сожалению, весь коллектив, занимающийся вопросом принятия новых кураторов, сильно перегружен. Много времени занимает ожидание АМ’а (Application Manager), который сопровождает подавшего заявку на роль куратора через весь процесс утверждения. Нет той волшебной палочки, по взмаху которой вдруг бы появилась куча новых АМ’ов. Я постараюсь еще раз тщательно проанализировать текущий процесс регистрации кураторов чтобы определить, как сделать его проще. Может быть есть смысл шире привлекать к этому делу спонсоров соискателя или заставить его сначала поработать в существующем тиме вместо того, чтобы сразу пускать на поддержку нового софта.

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

Речь шла главным образом об основных тимах (FTP-master, Account Managers, System Administrators), но вообще-то я имел в виду следующее: если кто- то реально хочет помочь комьюнити, но не может начатть работу по причине отсутствия соответствующих привилегий и прав доступа, пусть сообщит мне – посмотрим, что можно сделать в каждом конкретном случае.

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

В своей программе вы упоминали, что было бы неплохо привлекать в Debian помимо разработчиков и кураторов пакетов больше технических писателей, дизайнеров и т.п. Что-то делается в этом направлении?

Моя идея заключается в том, что хотя и есть смысл пропускать этих людей через все тот же процесс утверждения нового куратора, не следует заставлять их проходить этап тестирования навыков (Tasks and Skills test), который, впрочем, не является самым длительным этапом этого процесса. При этом не давать им возможности аплоадить пакеты (что является прерогативой разработчиков и связано с особым доверием со стороны сообщества).

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

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

Людей достаточно и они уже готовы работать при условии создания благоприятной рабочей атмосферы, которая дает осознание причастности и полезности для сообщества.

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

Вы упоминали, что, по вашему мнению, Debian имеет некоторые имиджевые проблемы, особенно в сравнении с Ubuntu. Что это за проблемы и как вы предлагаете их решать?

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

Я предполагаю, что корень зла может скрываться в других аспектах нашего проекта, например, в нашем веб-сайте или системе реагирования на запросы (bug tracking system), которые, возможно, отпугивают конечных пользователей, так что те массово склоняются к Ubuntu. Наш веб-сайт недостаточно динамический, при наличии огромного количества ссылок хромает система навигации... Мы могли бы по крайней мере выложить пару скриншотов создаваемой нами системы.

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

Dunc-Tank - система финансовой поддержки ключевых разработчиков системы – оказалась сомнительным и спорным решением, особенно после того, как в нее был вовлечен DPL Anthony Towns. Будете ли вы повторять попытки внедрения чего-то, подобного Dunc-Tank?

Нет. Я уже взялся за пару дел, на которые я планировал расходовать наши фонды (закупка нового железа, финансовая помощь желающим приехать на съезд, но не имеющим такой возможности), но я не планирую повторять что-то типа Dunc-Tank, я всегда находился в оппозиции относительно этого нововведения. Скажем так, я готов согласиться с чем-то «между Dunc-Tank и ничем», но вовлечение в такие вещи DPL – это определенно дурная идея.

Как вы оцениваете ваши успехи на нелегком поприще DPL?

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

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

Что бы вы еще хотели сказать о предстоящей вам работе или о Debian в целом?

Объем работ предстоит чудовищный, но это все реально сделать. Многие аспекты работы сообщества, например, управление релизами, уже реально улучшены моими предшественниками. Это ясно показывает, что люди не только ведут праздные разговоры об улучшении чего-либо, но и реально делают что-то в этом направлении. И поскольку я не ставлю цели все сделать сам, я был бы счастлив дать возможность разработчикам продуктивно работать над улучшением нашей системы. И, конечно же, любая помощь тут приветствуется!



Интервью брал Bruce Byfield (NewsForge, Linux.com, IT Manager's Journal), перевод Alice D. Saemon