Доклад независимого эксперта Анатолия Якушина «Мюнхенский проект. Победа, которую объявили поражением», сделанный им на XIV конференции разработчиков свободных программ, на первый взгляд не имел непосредственного отношения к теме мероприятия. Тем не менее, его рассказ был встречен с большим интересом, поскольку уроки Мюнхена чрезвычайно важны для нашего Open Source-сообщества, которому только предстоит реализовать сопоставимые по масштабу инициативы.
В последние годы накал противостояния Linux и Windows упал практически до нуля — Microsoft даже стала платиновым участником Linux Foundation. И вдруг на фоне этого благополучия внезапно выяснилось, что мюнхенский проект потерпел сокрушительный крах и власти этого города приняли решение вернуть на десктопы чиновников проприетарное ПО.
Чтобы лучше понять то, что в настоящее время происходит вокруг этого проекта, следует хотя бы вкратце вспомнить ее историю. Проект начался в 2003 г., когда Microsoft объявила об окончании поддержки Windows NT, чем поставила массу организаций в весьма затруднительное положение. Разумеется, администрация Мюнхена не была исключением — она была вынуждена решать проблему перевода множества рабочих мест на новую операционную систему.
На фоне растущего интереса к Open Source Кристиан Удэ, занимавший тогда пост мэра города, заявил, что муниципальные структуры прекращают использование продукции Microsoft и переходят на Linux. Кстати, это решение не было уникальным. В то время стартовало несколько десятков аналогичных начинаний: испанская автономная области Эстремадура, Париж, Страна Басков, некоторые страны Латинской Америки... Почему же именно мюнхенский проект стал самым известным?
Анатолий Якушин считает, что главных причин две. Во-первых, по всей видимости, это самый масштабный проект перехода на Linux, затрагивающий клиентское ПО. Если преимущества Open Source на серверных платформах уже давно никому не надо доказывать, то с рабочими станциями дела обстоят значительно хуже. Мюнхенский успех стал бы настоящим прорывом.
Во-вторых, Мюнхен считается ИТ-столицей Германии. Это огромный центр информационных технологий, за событиями в котором внимательно следит всё сообщество. Возможно, именно поэтому проект с самого начала сопровождался высочайшим уровнем PR-активности, вклад в которую внесли как сторонники, так и противники СПО.
В частности, сразу после заявления Удэ тогдашний CEO Microsoft Стив Балмер прервал свой отпуск и прибыл в Мюнхен. Их встреча заняла четыре часа, и о её содержании ничего не известно, но именно после этого Балмер сравнил Linux с раком. СПО-сообщество торжествовало.
Однако те его представители, хотя бы приблизительно знавшие, как устроена мюнхенская ИТ-инфраструктура, наверняка считали, что радоваться рано. Перевести на Linux предстояло 15 тыс. рабочих мест в 22 различных департаментах, в каждом из которых есть ИТ-отдел, самостоятельно занимающийся вопросами закупки оборудования и разработки ПО.
Поскольку в некоторых департаментах есть ещё и относительно самостоятельные подразделения, то общее число организаций, принимавших относящиеся к ИТ-инфраструктуре решения, на момент начала проекта едва не дотягивало до полусотни. Совершенно очевидно, что в такой ситуации технические вопросы вряд ли могли быть самыми сложными.
Высокое развитие ИТ в Мюнхене тоже не являлось однозначно положительным фактором. Дело в том, что разработкой заказного ПО там занимается огромное количество всевозможных микрофирмочек, состоящих из двух-трёх человек. Благодаря крайне либеральному законодательству по отношению к малому бизнесу они чувствуют себя относительно неплохо.
Разумеется, их заказчиками являлись в том числе и муниципальные органы. В результате к 2003 г. число всевозможных программулек и программулечек в органах местной власти достигло 22 тыс.
Очевидно, что перевести всё это «хозяйство» на ПО, соответствующее принципам Open Source — задача архисложная. Даже активная поддержка со стороны муниципального руководства не слишком упрощает её решение.
Помимо сугубо внутренних проблем добавились внешние. В
Нельзя сказать, что время было потрачено впустую. Не исключено, что именно благодаря этим исследованиям СПО-сообщество убедилось в ничтожности глобальной патентной угрозы, что впоследствии подтвердилось на практике. Но непосредственно мюнхенскому проекту лишняя задержка вряд ли пошла по пользу.
К тому же выяснилось, что угроза всё-таки есть. Правда, не со стороны Microsoft, Novell и других ИТ-гигантов. Мюнхенские микрофирмы отказались предоставлять муниципалитету исходные коды своих программ, причём в полном соответствии с договора, по которым они работали.
В России, кстати, подобная ситуация уже невозможна. У нас существует федеральный закон, согласно которому собственником продукта, разработанного по госзаказу, является государство. Правда, Анатолий Якушин уточнил, что полностью угроза не ликвидирована. В случае предоставления ПО как сервиса государство теряет полный контроль над решением, что чревато определёнными проблемами.
Тем не менее, в 2007 г. в Мюнхене начались первые пилотные внедрения, а в
Разговоры о провале проекта начались только спустя четыре года. Странно, не правда ли?
К сожалению, в дело вмешалась большая политика. В 2014 г. Кристиана Удэ на посту мэра сменил Дитер Рейтер, не скрывавший своих симпатий к Microsoft. Именно благодаря ему, кстати, штаб-квартира этой компании переехала в Мюнхен. Однако даже новая администрация не могла переписать историю и сделать из успешного проекта провальный. Речь могла идти только о дальнейших перспективах развития.
В
В результате муниципалитетом было принято некое невнятное решение, согласно которому пользователи, желающие использовать Windows, могут его использовать. А к
Означает ли это, что российское СПО-сообщество должно возрадоваться и успокоиться? Мол, самое масштабное внедрение свободных решений на рабочие станции оказалось весьма успешным и надо двигаться по той же проторённой дороге. Разумеется нет — в ходе реализации проекта было допущено множество ошибок, которые следует изучить, чтобы в дальнейшем не повторять.
Впрочем, сам Анатолий Якушин утверждает, что у него не поворачивается язык называть это ошибками. В конце концов, Мюнхен был первым и работа проделана огромная. Конечно, недостатки были, причём часть из них носила вынужденный характер, но упрекать в этом разработчиков не стоит.
Поэтому уместней говорить не об ошибках, а о проблемах, которые так или иначе негативно повлияли на успех проекта, если под этим понимать не перевод ИТ-инфраструктуры на СПО, а её общую модернизацию. Анатолий Якушин отмечает несколько наиболее важных факторов.
С самого начала проект был чрезмерно политизирован и идеологизирован. Разработчики слишком много говорили о преимуществах модели Open Source. Это получало одобрение со стороны мирового СПО-сообщества, а вот непосредственно пользователей весь сопутствующий шум откровенно пугал.
Анатолий Якушин уверен, что если участники проекта занимаются внедрением свободных решений, то они должны заниматься непосредственно внедрением свободных решений, а не бегать и кричать о достоинствах Linux. Иными словами, разработчикам лучше заниматься своими прямыми функциями, а не агитацией.
Следствие чрезмерной политизации — отсутствие должной поддержки со стороны конечных пользователей, полноценный диалог с которыми так и не получилось наладить. Соответственно, вместо их помощи при внедрении разработчики зачастую сталкивались с сопротивлением.
С самого начала стоимость реализации работ была занижена. В начале
В результате на многое попросту не хватило денег. В частности, разработчикам пришлось принять существовавший на то время машинный парк, состоявший из откровенно устаревших компьютеров, что привело к дополнительным сложностям.
Разработчикам не удалось получить от муниципалитета согласия на реинжениринг управленческих процессов, хотя они пытались это сделать. В 2013 г. структура мюнхенской ИТ-системы практически не изменилась по сравнению с 2003 г-м, что и было отмечено в отчёте компании Accenture.
Анатолий Якушин считает, при перед началом реализации достаточно масштабного проекта следует в обязательном порядке получить от заказчика согласие на изменение бизнес-процессов, которые явно мешают нормальному функционированию ИТ-инфраструктуры. Проще говоря, на наведение элементарного порядка там, где это явно необходимо.
Много проблем создало решение создавать собственный дистрибутив. Справедливости ради следует признать, что на момент начала проекта подобный подход был общепринятым — считалось, что для любой задачи можно и нужно создавать некий оригинальный дистрибутив.
К тому же это получилось в некотором смысле вынужденно. В качестве базового дистрибутива планировалось использовать SUSE, но в 2003 г. эту компанию приобрела американская Novell, что изрядно скомпрометировало бренд в глазах немцев. Другого же поставщика найти не удалось.
Получилось так, что начиная с какого-то момента времени работа над дистрибутивом для некоторых участников превратилась в основную цель. Очевидно, что это отнимало у проекта огромное количество ресурсов. В частности, Анатолий Якушин упомянул про жалобу разработчиков, которые не успевали протестировать решение на пятидесяти различных аппаратных конфигурациях.
К сожалению, закрытость дистрибутива привела к тому, что разработчики не получили практической поддержки со стороны сообщества. Подобный подход превратил потенциальных участников в обычных болельщиков — разница тут очевидна.
На это обратил внимание участников конференции генеральный директор компании «Базальт СПО» Алексей Новодворский. После завершения доклада Анатолия Якушина с его стороны последовала весьма эмоциональная реплика, где он упомянул созданную в рамках мюнхенского проекта единую систему управления GOsa, код которой до сих пор закрыт. Он сослался на свою беседу с разработчиками — они только собираются открыть код в будущем году, но это решение ещё не окончательное.
Анатолий Якушин вспомнил забавную историю. В сентябре 2013 г. в честь окончания мюнхенского проекта был выпущен специальный диск, на котором было написано LiMux. Однако на нём была Ubuntu 12.04.
Это породило конспирологическую теорию, согласно которой никакого LiMux вовсе не существовало, а внедрялся дистрибутив Ubuntu, что тщательно скрывалось от общественности. Разумеется, это не соответствует действительности — только Open/LibreOffice получил от мюнхенского проекта более 300 патчей.
Эти проблемы послужили причиной того, что сроки исполнения необходимых работ вдвое превысили ожидаемые. Тем не менее, несмотря на многочисленные трудности и ошибки, главный итог мюнхенского проекта заключается в том, что он на практике доказал возможность перевода на СПО сколь угодно крупной инфраструктуры. Причём с результатом не хуже, чем при применении проприетарных решений. А это — безусловный успех.