Вчера я написал заметку о том, что фрагментация в Linux не является проблемой и наоборот является преимуществом. И вы знаете, сейчас прошли уже целые сутки, но ни одного комментария. Стоит мне только сказать хоть слово против Linux, как на меня обрушивается шквал сообщений. Это только о трупах либо хорошо, либо ничего, а Linux и OpenSource вроде бы еще живы. Сегодня я хочу продолжить обсуждение OpenSource и сегодня я укажу на случай, когда фрагментация является откровенным злом и вы узнаете, почему OpenSource развивается плохо и будет развиваться очень плохо. Сейчас мы поговорим именно о фрагментации кода, а не сообщества в целом.
Североамериканские компании не очень то и смотрят на то, есть ли открытые исходные коды или нет, они смотрят на качество. Большинству просто параллельно наличие открытого кода, а некоторые даже считают это злом. Злом считают некоторые программисты, и я тоже к ним готов присоединиться и проблемой тут является как раз фрагментация.
Итак, попробую описать все по порядку. Труд программиста в США – удовольствие дорогое, поэтому даже крупные компании не всегда готовы содержать собственный штат программистов и даже администраторов. Дешевле и проще платить посредникам, которые будут предоставлять готовые решения не только в программных продуктах, но и в ИТ решениях. В северной Америке очень развиты компании, которые предоставляют хостинг ИТ решений. Например, у вас есть компания Х. Вы заключаете контракт с хостингом и все ваши компьютеры будут работать с софтом, который установлен на серверах хостера. Вам не нужны администраторы, чтобы следить на своим парком машин и систем, все работает удаленно и там умные дяди за всем следят.
Лишние затраты на ИТ никому не нужны, поэтому все стараются экономить на этом, а открытые проекты могут сэкономить миллион долларов, а могут принести миллиарды долларов убытков за счет фрагментации. Одной из основных идей открытого кода является то, что любой может расширять код под свои нужды, но никто не делает этого в промышленных целях (это делает, кажется только Google, но они могут себе это позволить).
Так в чем же проблема фрагментации? Допустим, что вы внедрили открытый проект YYY 1.0 и решили его расширить под свои нужды. Вы изменили десяток файлов с исходным кодом и проект стал работать так, как вам это нужно. Здорово? Конечно!!! Но тут выходит YYY 2.0, в котором исходные коды изменены производителем. ИТ отделу компании приходится выбирать – работать на старой версии с возможными дырами или внедрить версию 2.0, но нужно бросить все текущие работы и на этот раз доработать программу YYY 2.0 под нужды компании.
Если у компании внедрено 10 проектов с открытым кодом, в которых произведена заточка под себя, то в ИТ отделе приходится создавать целую группу программистов, которые только и будут что поддерживать и дорабатывать эти 10 проектов после выхода каждой новой версии. Далеко не всегда удается новую версию заточить под себя без проблем, иногда проблемы возникают очень серьезные.
Я сам встречался с этим в компании Интерстеп. В ней мы использовали OLAP систему с открытым кодом Pentaho. Чтобы без внедрить систему в нашу компанию, мне пришлось дописать на Java свой модуль авторизации. На это я потратил неделю, чтобы разобраться в исходных кодах и в файлах конфигурации. Помимо этого был изменен внешний вид (переписыванием кучи java файлов) и переведено все на русский язык, и на это ушло еще несколько дней.
Проходит два месяца и выходит новая версия системы (для открытых проектов это норма, выпускать новые версии каждые пару месяцев) и в нем изменен протокол авторизации и конфигурационные файлы. Внедрить новую версию с ходу не удалось, потому что копирование измененных мной файлов поверх новой версии просто убило систему. Писать все заново – я повешусь, а фирма обанкротится, если я буду каждые пару месяцев бросать все, и заниматься дописыванием Pentaho. Это уже не экономия денег, а затраты, ведь зарплата у меня тогда была 2,5 тыс. долларов. Если посадить меня на поддержку одной только Pentaho, то поддержка обойдется компании в 30 тыс. долларов в год. И это маленький проект.
Зарплаты программеров в США около 100 тыс. долларов в год, поэтому выбрасывать такие деньги на постоянную доработку решаются не многие, особенно, когда не видно выгоды. Такая фрагментация является злом и серьезным препятствием развития открытого кода.
Когда компания решает, какой проект им внедрить, то она не смотрит на наличие исходных кодов точно так же, как моя мама не смотрит на наличие исходных кодов ОС при выборе компьютера с ОС. Им пофиг!!! Проще и дешевле заказать готовое решение за 100 тыс. долларов у консалтинговой компании и двигаться вперед, а не топтаться постоянно на месте, дорабатывая каждую новую версию открытого проекта под свои нужды. Поэтому опытные и набившие оскомины ИТ-шники и программисты выбирают системы за качество, а не за наличие исходных кодов.
На этом можно было бы закончить, но я же сказал, что кто-то считает наличие исходных кодов злом, поэтому нужно объяснить кто и почему. Это некоторые программисты, к которым отношу себя и я. Наличие исходных кодов для программиста это как валерьянка для кота. В них хочется поковыряться и улучшить что-то. Если бы Pentaho в внедряли бы администраторы, а не программисты, то они никогда не стали бы ничего дописывать и вклеивать без швов в корпоративную систему новую систему отчетности. Да, они сделали бы хуже и не так удобно, как я, но тогда не нужно было бы получать вагон проблем при переходе на новую версию.
Чтобы не было соблазна изменять исходные коды, не давайте их программистам просто так. Незачем лезть туда, где должен властвовать разработчик, а не вы. А кому еще могут понадобиться исходные коды, как не программисту? Никому, поэтому они не нужны вовсе. Единственное, когда могут пригодится исходники – когда вы хотите перекомпилировать код, чтобы он выполнялся эффективно на вашем железе, но эту проблему можно решить и без исходников.
Открытость – это хорошо, если в меру и правильно подходить. Фрагментация – это тоже хорошо, если вы зарабатываете на этом и являетесь поставщиком решений, потому что это конкуренция. Но если вы потребитель решения, то фрагментация – это денежная яма, в которую будут засасываться деньги вашего работодателя. Не смотрите на наличие или отсутствие исходных кодов. Не выбирайте сердцем, а выбирайте мозгами и выбирайте за качество. Если ваши качественные параметры удовлетворяет открытый код, то выбирайте его. Если коммерческий, то выбирайте его. Но если вы выберете открытый код, никогда не дорабатывайте его под свои нужды, а если и дорабатываете, то очень нежно и ласково, иначе погрязните в поддержке из-за фрагментации.
Я как кот, которого тянет на код, как на валерьянку. Я могу потратить время, чтобы изменить код, чтобы он работал лучше для нужд компании, поэтому я считаю открытый код злом. Лично мне лень и не интересно было второй раз переводить Pentaho и второй раз писать модуль авторизации, поэтому компания не сможет перейти на новую версию Pentaho или при переходе потеряют все то, что я написал.
Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым
Так разве открытость кодов виновата? На нее же можно просто не обращать внимания!
Да, очень часто разработчики открытых кодов совершенно не думают о совместимости версий. В этом случае получается что продукты хоть и под одним именем, но они разные. Т.е. неизбежно придется чем-то жертвовать: либо оставаться на старых решениях, либо переписывать по новой и даже с нуля. И задачу по решению этой проблемы придется на кого-то возложить. Будь то собственные программисты или какая-то отдельная контора. Получается, что неважно кто именно будет этим заниматься, важно сколько это будет стоить. И на основе этих расчетов и принимать решения.
Так что я не вижу прямой вины опенсорса. Скорее это отличительная черта (и не лучшая) тех кто такие проекты разрабатывает и не задумывается о конечных потребителях. Их решения усредненные, универсальные, удовлетворить каждого невозможно.
Взять ту же 1С:Бухгалтерия. С коробочной версией смогут работать не в каждом учреждении. Все зависти от способа ведения. Я, к примеру, работаю в бюджетном учреждении, поэтому нам нужен соответствующий бухучет. Фирма-представитель имеет конфигурации для хозрасчетных-организаций, поэтому ей придется переделывать конфигурации под нас. Или была раньше ЕТС (единая тарифная сетка), а теперь ввели НСОТ (новая система оплаты труда) и в каждом учреждении могут выдумывать все, что в голову взбредет, но в рамках этой системы. Так что тут совершенно неважно, опенсорс будет или закрытое решение. Для нас оно будет свое, и кому-то придется этим в любом случае заниматься. Я этим заниматься не стану, как не станет и фирма "1С", а будут люди из франшизы, специально выделенные для обслуживания именно нашей организации.
Так что, резюмируя, не вижу никакой разницы.
Михаил, так вы всё таки написали заново модуль авторизации для новой версии Pentaho?
все правильно: если не ворачиваешь в источник то, что добавил сам, то сам же и решаешь проблемы с выходом новой версии. RedHat, Novell, Google, IBM, Intel, Oracle и др. это уже давно поняли, поэтому они синхронизируют свой код (та часть, которая opensource) с кодом полученным из сообщества. остальные сами себе злые буратины.
не фрагментируй там, где этого можно избежать.
тот же принцип и в науке - взял из копилки до тебя произведенных знаний, добавил свое и положил обратно, чтобы потом вернулось к тебе с частичкой твоего, а не девственно новым. как бы принцип опенсурц это и подразумевает - код в первую очередь для всех, и только потом для каждого в частности разве не так?
2Максимов Алексей
Не написал, и не потому, что я не захотел, а потому что у меня были более важные дела на работе и мне начальник сказал забить на Pentaho и все работают со старой версией.
2olegmaster
Мой код никто не будет синхронизировать в Pentaho. Кстати Google тоже не синхронизирует. А если учесть, что ты перечислил поставщиков, а не потребителей, то опять же пример не очень хороший. Это поставщики и они конкурируют на рынке и их врагментация - это плюс. А вот код, написанный компанией Рога и Копыта для своих нужд никому не нужен будет, и писать его нужно только в крайнем случае и нужно отдавать себе отчет, что это приведет к проблемам.
Я не знаю, что написано на табличке, а в LinuxWorld какой-то архитектор Google говорил, что они используют сильно модифицированное и оптимизированное ядро. Некоторые участки кода они открывают, но основные части закрыты. Точно номер не помню, но если найду, то дам ссылку.
еще раз повторяю факты притянуты за уши. Единственный вывод это тот что сделал Notez. Хотя это не проблема открытого кода, а проблема тех кто его дорабатывает.
Вроде бы GPL обязывает открывать все свои доработки тоже под GPL.
Notez, не замечаешь, уже в который раз пишешь не по теме, а разводишь демагогию?
Михаил, несомненно у гугла в андроиде и хромоси ядро переработанное очень сильно, но тем не менее отдача в ванильное ядро есть и не маленькая!
сейчас подумал, зачем гуглу 2 линукса? возможно это как раз результат фрагментации кода? тогда через год-полтора станет ясно, плюс это или минус, если и андроид и хромось продолжат прогрессировать и отхватывать рынок.
Гугл поставщик и они могут содержать и три линукса.
Михаил, в случае проприетарного кода потребитель вообще ничего не сможет доработать под себя, так что уж лучше на старой, но переработанной, чем на новой, но ванильной версии работать, которая тебя не совсем устраивает. в одном ты неоспоримо прав - качество на первом месте. если опенсурс продукт не качественный, то не стоит его использовать. нужно всегда оценивать риски и выбирать с умом. выбор опенсурц кода - большой. за выбор некачественной поделки виноват не программист, который ее дорабатывает, а тот кому доверили выбор решения.
Качественные коммерческие продукты предоставляют интерфейсы, через которые можно изменять проекты под себя и эти интерфейсы не должны изменятся от версии к версии. Если открытый код предоставляет что-то подобное, то ОБЯЗАТЕЛЬНО нужно использовать этот метод, а не лезть в исходные коды. Поэтому я считаю, что для программистов коды - это зло, потому что они в них лезут, а большинство (по моему опыту) открытых проектов не заботятся о предоставлении интерфейсов для настройки, а надеются на исходные коды.
дык наличие интерфейса. имхо, зависит не от открытости/закрытости, а от центральных разработчиков программы. возьмем два браузера: открытый FireFox и закрытый Opera. В обоих есть механизмы интерфейсов:в первом случае - плагины, во втором - виджеты. или там два плеера - Audacious (открытый) и Windows Media Player (закрытый). в открытом есть возможность добавления плагинов, во втором вроде нет. или даже ядро системы - у Linux - 300 системных вызовов, у Windows - бесичисленные необъятные API . глаыная мысль: открытый код может тоже предоставлять интерфейсы, так что это не аргумент.
У Windows Media Player интерфейсов для доработки намного больше, чем у любого другого плеера.
что-то я не слышал, чтобы через WMP можно было смотреть DVB-видео, а вот через плагинный Kaffeine и vlc без проблем, но не в этом суть. одна возможность не решает. важно чтобы эта возможность реализовывалась массово и многогранно, тогда можно говорить,что интерфейс к такой-то программе работает и востребован.
Ты просто не нашел кодек. Для добавления новых функций видео тебе нужно всего лишь написать кодек.
Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
