Мюнхенский проект. Победа, которую объявили поражением (Анатолий Якушин, OSSDEVCONF-2017)
Материал из 0x1.tv
- Докладчик
- Анатолий Якушин
В докладе рассматривается анализ проекта по информатизации муниципалитета Мюнхена с момента его старта до сегодняшнего дня. Исследуются основные особенности реализации, истинные и мнимые недостатки проекта, типичные ошибки и трудности при массовом внедрении продуктов со свободными лицензиями.
Содержание
Видео
Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.
Презентация
Thesis
Под термином Мюнхенский проект в современной аналитической литературе принято понимать масштабный проект по информатизации подразделений г. Мюнхен (Бавария, Федеративная Республика Германия). Другим распространенным наименованием является LiMux, по названию дистрибутива GNU Linux, разработанного в рамках данного проекта.
Проект по информатизации Мюнхена был широко анонсирован в 2003 году, однако его практическая реализация началась несколько позже. В 2013 году муниципалитет и разработчики проекта объявили о его успешной реализации.
Поэтому сообщество свободных разработчиков с большим удивлением отнеслось к массовым публикациям, которые стали появляться в прессе с февраля 2017 года, в которых говорилось о крахе проекта, полном провале, отказе от предыдущих разработок в манере эпохи войн операционных систем.
Следует отметить, что со времени первых анонсов о Мюнхенском проекте, его реализация находилась под пристальным вниманием всех заинтересованных разработчиков, ввиду значимости проекта и его масштабности. Несоответствие публикаций 2017 года информации последних пятнадцать лет заставило автора вновь проанализировать историю реализации проекта и его нынешнее состояние.
Как показал проведенный анализ, слухи о крахе проекта сильно преувеличены. В полном соответствии с заявлениями разработчиков, свободное ПО установлено на 15 тысячах рабочих мест и исправно функционирует, обеспечивая инфраструктуру огромного города.
В дальнейшем планировалось создать новую web-ориентирован-ную версию, однако в планы информатизации вмешалась большая политика. В 2014 году Кристиана Удэ, который занимал пост мэра Мюнхена с 1993 года сменил Дитер Рейтер, который не скрывает того, что является давним приверженцем Microsoft. Одним из первых мероприятий нового мэра была широкомасштабная поддержка по переезду европейской штаб-квартиры Microsoft в Мюнхен.
Несмотря на столь мощный ресурс сторонников проприетарного ПО городской совет в марте 2017 года принял весьма осторожное решение, допускающее использование продукции Microsoft на рабочих местах муниципалитета, и не более того. Нового клиента планируется создать к 2020-2022 годам, и каким он будет, покажет время.
Проведенный анализ позволил выявить типичные проблемы, возникающие при реализации масштабныз проектов, даже вне зависимости от лицензий ПО, применяемого при реализации. Из уважения к титаническому труду разработчиков, нет желания называть эти проблемы ошибками. В очень многих вопросах команда Мюнхенского проекта была первопроходцем, а наша задача увидеть эти проблемы и найти пути их решения.
На какие проблемы стоит обратить внимание, тем более, что они повторяются и при реализации других крупных проектов со свободными лицензиями.
Крайне высокая степень политизированности проекта. Разработчики с самого начала очень много говорили о своеобразии своего проекта, использовании свободного ПО, отказе от проприетарных форматов данных. Им рукоплескали сторонники по всему миру, однако собственно пользователей проекта подобная шумиха скорее пугала, о чем есть немало публикаций. Особый статус в некоторое моменты приводил к полному неприятию со стороны пользователей и жалобам на недостатки системы, хотя имевшие место проблемы никак с выбранным ПО связаны не были.
Отсутствие поддержки со стороны конечных пользователей. Следствием высокой политизированности стало отсутствие адекватной поддержки со стороны конечных пользователей. Разработчики не сумели наладить с ними полноценный диалог, создать краудсорсинговые группы из наиболее продвинутых пользователей, склонить их на свою сторону при разработке и внедрении.
Заниженная стоимость проекта. Изначально широковещательно объявлялось о рекордно низкой стоимость проекта, за счет бесплатности свободного ПО. Данный прием широко использовался на рубеже 2000 годов для пропаганды внедрения СПО, однако уже тогда было понятно, что стоимость проекта на СПО ниже проекта на проприетарном программном обеспечении только на стоимость лицензий. И это в самом идеальном варианте. Реально стоимость свободного проекта может быть весьма высока, хотя бы ввиду того, что требует найма высокооплачиваемых специалистов. Стремление к экономии заставило разработчиков принять машинный парк as is, что в последующем существенно замедлило работу по внедрению ввиду огромного парка устаревшей техники.
Отсутствие договора на реинжениринг. Как показывает описание IT-инфраструктуры Мюнхена перед стартом проекта, эта городская служба представляла собой мешанину из разных систем, каждый отдел муниципалитета имел свой IT-отдел, поддержку оказывало три различных, конкурирующих между собой фирмы и т.п. Разработчики изначально предполагали проведение реинжениринга бизнес-процессов города, провели колоссальную работу по фиксации имеющегося городского хозяйства и разработке плана по его модернизации, но в конечном итоге так и не смогли добиться от городского совета реализации предварительных договоренностей. В итоге систему внедряли на имеющихся структурах, что существенно сказалось на итоговом качестве.
Создание собственного дистрибутива. Созданный в рамках проекта дистрибутив LiMux так много описывался в прессе, что создается впечатление, что его создание было конечной целью проекта. В реальности, разработанный дистрибутив является только платформой. Собственно проект базируется на разработанном программном продукте WollMux — java приложении, работающим через UNO с OpenOffice/LibreOffice. Следует отметить, что WollMux является кроссплатформенным и прекрасно работает на любой современной операционной системе. Таким образом создание собственного дистрибутива в какой-то момент стало самоцелью, отнимающей огромное количество времени. Следует признать, что в начале 2000-х подобный подход был общепринятым, оригинальные дистрибутивы создавались по любому поводу. Гораздо позже стало очевидным, что полноценная поддержка дистрибутива на всех этапах жизненного цикла, это весьма нетривиальная техническая задача, решить которую успешно может специальный коллектив, ориентированный только на создание платформ. И совместить полноценное дистрибутивостроение с разработкой и поддержкой прикладного ПО практически невозможно.
Сроки проекта. Все перечисленные и множество других проблем привели к тому, что реализация проекта затянулась на сроки, вдвое превышая обещанные. Это несомненно сказалось на реализации ожиданий и участников и заказчиков и разработчиков, во многом породив негативное отношение к проекту в IT-индустрии, причем по большей части негатива, реально неоправданного.
В итоге следует отметить, что авторы Мюнхенского проекта доказали, что сколь угодно крупная инфраструктура может быть реализована только с использованием свободного программного обеспечения и результат как минимум не будет хуже, чем при использовании проприетарного ПО.
Примечания и ссылки
!.jpg)
Plays:318 Comments:2