Нередко потенциальные заказчики, особенно из компаний покрупнее, спрашивают нас про доступ к исходному коду системы.
Мол, вдруг с вами что-нибудь случится, и вообще.
В некоторых случаях мы идем навстречу и (под внушительные финансовые гарантии НЕутечки) отдаем исходный код заказчику.
Некоторые случаи — это когда размер ожидаемой прибыли позволяет примириться с нелепыми причудами клиента.
Потому что исходный код ему нужен как рыбе зонтик.
Мода на программное обеспечение с открытым исходным кодом (далее — open source), дорогие читатели... Мода, она и есть.
В основе любого модного поветрия лежат несколько вполне рациональных предпосылок, действительных, однако, для ограниченного множества случаев.
И при бездумном приложении... Как сказал Барак Хусейнович Обама, «даже если у вас есть отличный молоток, это вовсе не значит, что каждая проблема является гвоздем».
Собственно, касательно open source таких изначально рациональных тезисов три:
- Открытый исходный код безопасен и надежен
- Позволяет самостоятельно модифицировать ПО
- И быть независимым от вендора
Тезис про безопасность и надежность
... справедлив для простых приложений с ограниченной функциональностью.
И только.
Модель open source подразумевает, что неограниченное количество разработчиков имеют доступ к исходному коду ПО и могут предлагать свои изменения.
Для простого софта вполне может существовать первоначальный разработчик-энтузиаст (или группа таковых), которые в состоянии окинуть взглядом весь код продукта и держать его развитие под действенным контролем.
При этом ответственность выделенного человека (и/или группы лиц) за качество работы ПО отсутствует даже теоретически.
Речь может идти сугубо о доброй воле и личной добросовестности отдельно взятого индивидуума (-ов).
Пример из жизни: катастрофа безопасности протокола шифрования SSL, который добавляет буквочку s после http в адресной строке вашего браузера.
Суть в том, что почти четыре года, с 2011 по 2014, основной протокол шифрования Интернета, основанный на ПО с открытым исходным кодом OpenSSL, имел не то, что уязвимость, а мега-дыру размером с Гранд Каньон.
В зоне риска оказалось порядка пятисот тысяч (якобы) защищенных сайтов.
Важно, что мега-дыра появилась в OpenSSL не общим путем, а стала именно что результатом модели open source: некий сторонний чувак предложил очередную оптимизацию, команда энтузиастов толком не проверила, косячный код попал в релиз и был мгновенно растиражирован.
Выпускай OpenSSL коммерческий вендор, если бы он даже сумел НЕ обанкротиться в результате скандала и вытекаюших судебных исков, то однозначно был бы вынужден уволить все руководство к уважаемой маме Кузи. В назидание, так сказать, преемникам.
Как вы думаете, какую ответственность понесли разработчики OpenSSL?
Вот именно.
Меж тем, по данным той же статьи Википедии, спустя более чем два месяца (!) после обнаружения проблемы, в зоне уязвимости продолжали оставаться более трехсот тысяч сайтов.
А сколько таких open source дыр еще ждет случайного открытия.
Для больших сложных систем (IEM-решения Ultimate — это миллионы строк кода) достаточного количества организованных добросовестных компетентных энтузиастов-бессребреников не может быть даже теоретически. Иначе к 1980 году коммунизм таки был бы построен.
Напротив, коммерческий вендор ПО имеет как организованную команду, так и деньги на ее содержание. А главное — очевидную жесткую мотивацию на то, чтобы его продукт работал хорошо.
И ответственность.
Модифицируемость
Безусловно, свободное распоряжение полным исходным кодом любой программы дает максимально возможную модифицируемость оной.
Однако, переводя взор с модных сферически-вакуумных коней на приземленные нужды бизнеса, необходимо понимать, что “максимальная возможная модифицируемость” отнюдь не равняется “максимально полезной”.
В противном случаем (чего уж там мелочиться) надо пользовать ОС только с открытым кодом, CPU только с модифицируемым набором команд, etc.
Ну а вдруг?
Враг не дремлет! Надежность, безопасность и импортозамещение во главе угла!
Спросите прапоров и фесебешников.
Руководствуясь здравым смыслом (= максимизацией прибыли бизнеса в долгосрочной перспективе), вопрос должен быть переформулирован:
- какие требования к уровню модифицируемости системы налагал бы императив возможности реализации любого потенциально полезного функционала?
Оказывается, такой постановке задачи вполне удовлетворяют открытые системы (не путать с открытым исходным кодом!).
Обладающие интерфейсами для реализации практически произвольного функционала; исходный же код при этом самой системы закрыт.
Бытовым примером открытой системы является ОС Windows. Система с закрытым исходным кодом, на базе которой, однако, Windows-приложение может реализовать почти произвольное поведение.
Ограничения же, накладываемые операционной системой, относятся в первую очередь к безопасности, разграничению доступа к физическим ресурсам ПК и реализации многозадачности.
Спускаясь из теоретических эмпиреев к нашим баранам, платформа Ultimate Solid является аналогом ОС Windows.
А работающие поверх нее 100% открытые конфигурации (коммерческие e-Trade, e-Service, Industrial или же бесплатная Ultimate 2C; или любая другая, написанная сторонним разработчиком) реализуют любой мыслимый полезный функционал.
Независимость от вендора
Как вы уже догадались, с независимостью на практике дела обстоят примерно так же, как и с безопасностью и надежностью.
По тем же самым причинам.
Для масштабных сложных систем эта “независимость” диалектически обращается в свою противоположность.
Только рабовладельцем в данном случае становятся опять-таки НЕ мотивированные коммерческие компании, кровно заинтересованные в лояльности потребителей и ответственные деньгами вплоть до собственного выживания, а расплывчатая тусовка анонимных программеров, для которых поддержка и развитие используемого вами продукта являются не более, чем хобби.
И попробуйте предъявить претензии.
А может быть, вы хитрее папаши Мюллера, и думаете, что вот, мол, скачаем исходники, наймем программеров в штат и будем далее “поддерживать” и “развивать”?
Под полным, типа, контролем и чутким руководством.
Но где же эти дни беспечных ликований,
Дни искренней любви? Увы, осенних гроз
Они не вынесли, — и вот царит мороз
Тоски, усталости и нет очарований.
Нет никакой гарантии, что внесенные вашими разработчиками изменения в open source ПО будут приняты основной командой (Core Team).
Ложная уверенность в собственных силах в сочетании с отсутствием компетентного руководства (а откуда вам его взять?) толкает ваших штатных программистов на внесение изменений в исходный код вместо использования открытых интерфейсов.
Слабоумие и отвага: шо, мол, я школьник — документацию по API читать? Чай, щи лаптем не хлебаем, щас залезу в ядро и все сделаю правильно.
Таким образом, дальнейшее обновление системы из общего репозитория становится все менее возможным, а начиная с какого-то (не очень) прекрасного момента - невозможным вовсе.
Вот так, мелкими, но быстрыми шажочками, вы ВНЕЗАПНО оказываетесь один на один с самопиской.
Надо сказать, что и мы сами периодически возвращаемся к идее выложить исходники платформы Ultimate Solid в общий доступ.
Так сказать, превентивный оптовый ответ нынешним и будущим фанатам иметь исходники. Чтоб с каждым отдельно не возиться.
Но каждый раз, (по крайней мере — пока), от этой мысли отказываемся.
И вовсе не потому, как можно было бы подумать, что переживаем насчет возможного появления конкурента (-ов) на базе наших же наработок.
Отнюдь: мы, как люди а) в проблематику погруженные и б) трезво мыслящие, понимаем, что скорее всего вообще никто и никогда не захочет даже просто разбираться в тех самых миллионах строк кода.
И уж тем более брать на себя титанический и заведомо нерентабельный труд их “улучшения”.
Останавливают нас как раз опасения репутационных рисков.
Никто не застрахован от появления инициативного дурака (а по таинственным причинам, энергичность таких товарищей прямо пропорциональна степени некомпетентности), который, “улучшив” исходный код, начнет налево и направо продвигать “улучшенную” платформу по мотивам Ultimate Solid.
Безнадежно компрометируя оригинал.
А мегабайты исходных кодов конфигураций Ultimate, то есть как раз того слоя системы, который и реализует функционал, интересующий бизнес-эксплуатантов, и так полностью открыты.
Модифицировать не перемодифицировать.
