Самый первый этап внедрения СПО заключается в том, чтобы убедить руководство организации решиться на этот шаг. К сожалению, иногда на этом всё и заканчивается. Причём не всегда решение начальства обусловлено действительно объективными обстоятельствами. Дело тут вовсе не в косности руководства. Просто аргументы противников СПО показались им более основательными, а возражения сторонников — неубедительными.
Из этого следует, что инициаторам перехода на СПО следует серьёзно подготовиться к решающему разговору с руководством. И ни в коем случае не ждать «лёгкой победы».
Помочь в этом сможет опубликованный на OpenSource.com рассказ Джона Эллисона, который в
Эллисон решил использовать СПО. Прежде всего, по следующим соображениям.
Во-первых, он убеждён, что если за ПО платит правительство, то какие-то результаты должны быть доступны народу. А это обеспечивают прямые или косвенные инвестиции в Open Source.
Во-вторых, его беспокоило сохранение работоспособности всей системы. Проприетарные решения в этом смысле весьма уязвимы — пользователю приходится прекратить применение ПО, если срок лицензии на нёго истёк.
В-третьих, часто пользователю приходится просить разработчика внести изменения в какую-либо программу. Если он не имеет достаточно сильного влияния, то сделать это в случае проприетарного ПО весьма проблематично.
Тем не менее, инициатива сразу же натолкнулась на активное сопротивление со стороны четырёх заинтересованных групп. Эллисон назвал их так: юристы, управленцы, пользователи и продавцы. Он сформулировал главные аргументы противников и привел веские возражения, которые должны убедить руководство принять положительное решение относительно перехода на Open Source.
Юристы утверждают, что поставщик ПО должен обеспечивать техническую поддержку и это должно быть отражено в договоре. Свободное ПО, на их взгляд, не отвечает этому требованию.
На это следует ответить, что поставщики решений с открытым исходным кодом предоставляют точно такую же техническую поддержку, которая указывается в контракте на проприетарное ПО. Разница только в том, что пользователь может организовать подобную поддержку самостоятельно. К тому же поддержка проприетарного ПО становится затруднительной, если разрабатывающая его компания закрылась.
Иными словами, если рассматривать юридическую составляющую технической поддержки, то открытые и проприетарные решения не просто равноценны — первые выглядят предпочтительнее. Именно Open Source даёт заказчику возможность самостоятельно выбирать компанию или даже отказаться от услуг других поставщиков.
Аргумент управленцев чаще всего сводится к тому, что Open Source — это слишком много риска. Причём, как правило, они не могут объяснить, какого именно. Безусловно, в чём-то они правы. Более того, применение любого ПО связано с определённым риском. Поэтому следует оценить, в каком случае он меньше.
Прежде всего важно обратить внимание на странное поведение разработчиков проприетарного ПО. Если код их программ действительно хорош, то почему они скрывают его от общественности и экспертов? В то время как открытые приложения доступны для любой самой строгой экспертизы.
Также можно заметить, что СПО используют крупнейшие коммерческие компании. Причём вовсе не по соображениям философского характера, а потому что эти решения наиболее эффективны.
Пользователи чаще всего говорят, что хотят продолжать работать с тем ПО, которое они знают. Что вполне разумно — незачем менять то, что и так работает без особых нареканий. Но что они предложат сделать, если на покупку привычным им решений в какой-то момент попросту не будет денег? Смогут ли они поручиться за то, что в какой-то кризисный период не будет принято решение о сокращении финансирования именно их организации? Стоит ли привыкать к тому, что в любой момент может закончится?
При этом не стоит скрывать, что некоторые свободные программы лишены каких-то присущих их проприетарным аналогам «украшений». Однако с основными задачами СПО справляется хорошо.
Наконец, на руководство оказывают давление продавцы проприетарного ПО. «Наше — лучшее» — утверждают они. Причём часто они бывают правы.
В ответ на это следует объяснить руководству, что на практике требуется не «лучшее», а «достаточно хорошее». Хотя бы потому, что лучшее решение может слишком дорого стоить.
Программа нужна заказчику для решения конкретных задач, а не для победы на конкурсе пользователей «самых лучших приложений в мире». Незачем покупать какие-то возможности, совершенно не нужные на практике.
При этом, важно подчеркнуть, что если реально необходимое решение не имеет открытого аналога, то его, безусловно, следует купить. Но при рассмотрении вариантов следует всё-таки начинать с Open Source.
