Самый первый этап внедрения СПО заключается в том, чтобы убедить руководство организации решиться на этот шаг. К сожалению, иногда на этом всё и заканчивается. Причём не всегда решение начальства обусловлено действительно объективными обстоятельствами. Дело тут вовсе не в косности руководства. Просто аргументы противников СПО показались им более основательными, а возражения сторонников — неубедительными.

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

Помочь в этом сможет опубликованный на OpenSource.com рассказ Джона Эллисона, который в 2008-2012 гг. работал на базе ВВС США, где отвечал за программное обеспечение аэро-космического операционного центра (AOC). На момент его прихода ИТ-инфраструктура организации представляла собой довольно типичный «зоопарк», которую автор политкорректно называет «коллекцией автономных систем». Именно в наведении порядка и заключалась его основная задача.

Эллисон решил использовать СПО. Прежде всего, по следующим соображениям.

Во-первых, он убеждён, что если за ПО платит правительство, то какие-то результаты должны быть доступны народу. А это обеспечивают прямые или косвенные инвестиции в Open Source.

Во-вторых, его беспокоило сохранение работоспособности всей системы. Проприетарные решения в этом смысле весьма уязвимы — пользователю приходится прекратить применение ПО, если срок лицензии на нёго истёк.

В-третьих, часто пользователю приходится просить разработчика внести изменения в какую-либо программу. Если он не имеет достаточно сильного влияния, то сделать это в случае проприетарного ПО весьма проблематично.

Тем не менее, инициатива сразу же натолкнулась на активное сопротивление со стороны четырёх заинтересованных групп. Эллисон назвал их так: юристы, управленцы, пользователи и продавцы. Он сформулировал главные аргументы противников и привел веские возражения, которые должны убедить руководство принять положительное решение относительно перехода на Open Source.

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

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

Иными словами, если рассматривать юридическую составляющую технической поддержки, то открытые и проприетарные решения не просто равноценны — первые выглядят предпочтительнее. Именно Open Source даёт заказчику возможность самостоятельно выбирать компанию или даже отказаться от услуг других поставщиков.

Аргумент управленцев чаще всего сводится к тому, что Open Source — это слишком много риска. Причём, как правило, они не могут объяснить, какого именно. Безусловно, в чём-то они правы. Более того, применение любого ПО связано с определённым риском. Поэтому следует оценить, в каком случае он меньше.

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

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

Пользователи чаще всего говорят, что хотят продолжать работать с тем ПО, которое они знают. Что вполне разумно — незачем менять то, что и так работает без особых нареканий. Но что они предложат сделать, если на покупку привычным им решений в какой-то момент попросту не будет денег? Смогут ли они поручиться за то, что в какой-то кризисный период не будет принято решение о сокращении финансирования именно их организации? Стоит ли привыкать к тому, что в любой момент может закончится?

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

Наконец, на руководство оказывают давление продавцы проприетарного ПО. «Наше — лучшее» — утверждают они. Причём часто они бывают правы.

В ответ на это следует объяснить руководству, что на практике требуется не «лучшее», а «достаточно хорошее». Хотя бы потому, что лучшее решение может слишком дорого стоить.

Программа нужна заказчику для решения конкретных задач, а не для победы на конкурсе пользователей «самых лучших приложений в мире». Незачем покупать какие-то возможности, совершенно не нужные на практике.

При этом, важно подчеркнуть, что если реально необходимое решение не имеет открытого аналога, то его, безусловно, следует купить. Но при рассмотрении вариантов следует всё-таки начинать с Open Source.

Версия для печати