Open source продукты стали жизнеспособной альтернативой проприетарным решениям, покинувшим рынок. Однако российским организациям еще предстоит сформировать компетенции для того, чтобы перейти от операционного «латания дыр» к стратегическому использованию технологий с открытым кодом. Например, задуматься о том, как распространение собственных разработок в таком формате может поспособствовать развитию продуктов и бизнеса.
Также потребуется внимательнее относиться к тренду на изменение лицензий популярных open source продуктов и разобраться с его предпосылками. Последний аспект имеет отношение к так называемому жизненному циклу open source решений и соответствующим рискам: смены лицензии в силу выбора иной бизнес-модели, прекращения распространения решения по open source лицензии или полного ухода с рынка компании-разработчика. Как раз о подобных ситуациях мы и поговорим в этом материале: обсудим, почему open source разработки откладывают в «долгий ящик» или вовсе бросают без какой-либо надежды на дальнейшее развитие.
Disclaimer: В материале речь не идет о сравнении открытого и проприетарного ПО, а о частном случае сложностей с open source проектами, которые в целом встречаются и у проприетарных решений. Также относительно open source специфики — удалось взять комментарии у представителей российского рынка.
Потеряли интерес и закрылись
В 2004 году TrueCrypt выпустила первую версию одноименной утилиты для шифрования данных. На тот момент в основу проекта легла кодовая база другого открытого криптографического инструмента — E4M. Но вскоре после релиза разработчики получили письмо от генерального директора компании SecurStar. Он утверждал, что автор E4M — бывший сотрудник организации, который воспользовался корпоративными разработками. Якобы он не имел права распространять их под открытой лицензией.
Чтобы разобраться в ситуации, команда TrueCrypt временно прекратила распространять инструмент. Соответствующее сообщение появилось в сети usenet [это — одна из старейших сетей для общения по принципу «один для всех»]. Спустя полгода команда TrueCrypt выпустила вторую версию утилиты (уже без проприетарного кода) под собственной открытой лицензией TrueCrypt Collective License.
Инструмент получил одобрение сообщества и приобрел широкую популярность, в том числе благодаря поддержке отрицаемого шифрования. Это — особый способ криптографического преобразования, когда пару сообщений шифруют несколькими ключами одновременно. Задача такого подхода — обеспечить высокую стойкость к принуждающим атакам. Он позволяет скрыть секретное сообщение от третьей стороны, даже если той станет известен один из ключей для расшифровки.
TrueCrypt активно развивался на протяжении десяти лет, но в 2014 году авторы объявили, что сворачивают проект. На его сайте появилась плашка, что код утилиты небезопасен, вместе с подробной инструкцией по миграции на альтернативное решение (BitLocker от Microsoft). Тогда же вышла последняя версия утилиты, из которой убрали возможность шифрования данных, оставив только функции расшифровки.
Новость вызвала множество вопросов в open source сообществе. Проведённые аудиты не выявили проблем с безопасностью, и в Linux Foundation даже планировали создать форк TrueCrypt, чтобы перезапустить его под новым названием. Отсутствие видимых недостатков и каких-либо внятных объяснений со стороны команды разработки стали почвой для подозрений. В рекомендации использовать BitLocker — инструмент с закрытым исходным кодом — многие увидели «свидетельство канарейки» — якобы разработчики пытались намекнуть, что TrueCrypt могут применять для слежки. Противники этой теории в качестве контраргумента приводили интервью одного из авторов TrueCrypt. По его словам, команда просто потеряла интерес к разработке ПО. Хотя, разумеется, нашлись и те, кто не поверил в искренность его ответов.
Картина прояснилась в 2015 году, когда один из аналитиков команды Project Zero, которую собрала компания Google, все-таки обнаружил две серьезные уязвимости в драйвере TrueCrypt, который решение устанавливает на Windows. С их помощью злоумышленники могли получить более высокий уровень привилегий в операционной системе. Выявленные уязвимости подтолкнули многих из преданных пользователей продукта к миграции на альтернативные open source решения — например, VeraCrypt и DiskCryptor. Участники комьюнити продолжают выпускать для них обновления.
Не смогли договориться
В 2017 году российский разработчик представил набор утилит для серверного мониторинга netutils-linux, например, для работы в дата-центрах и на инфраструктуре провайдеров. Под хабрапостом разработчика появилось множество положительных отзывов, а также идей по развитию решения. Например, один из участников дискуссии предложил реализовать настройку XPS (Transmit Packet Steering) для распределения пакетов. И позже автор выпустил соответствующий апдейт.
Но уже в декабре 2018 года вышло последнее обновление инструмента. Как пишет автор, он не смог договориться с бывшим работодателем о принадлежности прав на проект. В попытке продлить ему жизнь, разработчик поддержал идею сделать форки — всего их три (под лицензией MIT) — однако они тоже давно не обновлялись. Последние коммиты сделаны год назад и касаются незначительных изменений вроде исправления опечаток.
Сократили финансирование
В 1970-х Французский национальный исследовательский институт INRIA развивал сеть CYCLADES, которую можно считать предшественницей интернета. Позже один из участников проекта — Винсент Квинт — переключился на новую для того времени сферу: разработку инструмента для веб-серфинга со встроенным WYSIWYG-редактором.
Команда Квинта продемонстрировала свой браузер на одной из первых конференций, посвященных веб-технологиям. На ней были представители W3C, которых заинтересовали наработки французских исследователей. Руководители W3C взяли проект под свое крыло, который впоследствии получил название Amaya.
Винсент Квинт говорит, что его команда хотела предоставить пользователям возможность не только получать информацию из интернета, но и генерировать контент самостоятельно. В этом состояло главное отличие Amaya от других веб-инструментов того времени вроде Mosaic. Проект Квинта развивался под эгидой W3C почти 20 лет, но в 2013 году его закрыли. Основатели консорциума пересмотрели свою политику — их уже не так интересовало экспериментальное ПО, поэтому финансирование подобных инициатив сократили.
Главные разработчики Amaya покинули проект, из-за чего возникли серьезные технические сложности — например, пропала возможность поддерживать самописный движок для рендеринга. К сожалению, браузер не удалось возродить даже усилиями комьюнити. Исходный код выложили на GitHub, но сейчас эта страница недоступна. Но проект остается в памяти резидентов площадок вроде Hacker News.
«Чемпиона продукта» арестовали
ReiserFS — это файловая система для Linux, разработанная в 2001 году компанией Namesys под лицензией GPLv2. Она получила признание среди специалистов за новый подход к хранению и организации данных, ориентированный на повышение производительности серверов. Так, ReiserFS стала первой файловой системой, входящей в стандартное ядро Linux начиная с версии 2.4.1. Свое название она получила в честь основателя компании и главного разработчика Ханса Райзера.
С ним же связана история закрытия ReiserFS. В 2006 году его взяли под арест по подозрению в убийстве. Судебный процесс длился пару лет — по его итогам Ханса приговорили к 15 годам лишения свободы. Новость о преступлении Райзера вызвала бурную реакцию в сообществе — на форуме Slashdot тематический тред собрал 1651 комментарий. Но пользователей больше волновала не столько судьба разработчика, сколько будущее файловой системы. Некоторые комментаторы шутили, что правоохранители разрешат Райзеру программировать в камере.
После ареста основателя компания Namesys прекратила свою деятельность, однако разработка ReiserFS продолжилась ее сотрудниками и другими добровольцами. Но даже несмотря на усилия энтузиастов, проект начал угасать. В 2022 году на форумах стали появляться треды о том, что интерес аудитории к системе потерян и, возможно, скоро ее перестанут поддерживать.
Опасения резидентов Hacker News подтвердились: в прошлом году ReiserFS получила статус obsolete в ядре Linux 6.6. По этому поводу высказался сам Райзер, подчеркнув возможности четвертой версии ReiserFS, в которой были учтены многие недостатки третьей. Однако специалисты предполагают, что к 2025 году ReiserFS полностью исключат из Linux kernel. В ответ на эту новость Эдуард Шишкин, который продолжил разработку системы после Райзера, заявил об отсутствии достойных альтернатив.
Он также упомянул, что происходящее никак не повлияет на разработку пятой версии ReiserFS, так как это «совершенно независимый проект». Несмотря на категоричный настрой Шишкина, в сообществе все же задумались об альтернативах. В качестве примера приводят Btrfs, в разработке которой участвуют крупные компании вроде SUSE и Fujitsu. О перспективности проекта говорит и тот факт, что в 2020 году Btrfs стала стандартной файловой системой для Fedora.
Что думают эксперты
Такие кейсы, как и ситуации со сменой лицензий на распространенные open source решения, говорят о том, что отсутствие стратегического понимания комплексной природы open source может обернуться рисками. Чтобы узнать, как к таким историям относятся представители российских ИТ-компаний и не только, и на какие характерные риски стоит обратить внимание, я обратился к коллегам за комментариями.
Приходилось и постоянно приходится сталкиваться с подобными ситуациями. Замена версии ПО по причинам безопасности — это довольно частое событие. В мире ПО не предусмотрена многовековая работа на одной версии, и если кто-то так ведёт бизнес, ему будет больно. Постоянно обновлять ПО — это единственный возможный путь ;) другого просто нет. Поэтому тот, кто уже так делает, вряд ли столкнется с гигантскими проблемами с миграцией open source куда-либо.
Есть ещё один момент: опенсорс можно форкнуть и развивать самому, это могут сделать представители сообщества, как было с TrueCrypt (его замена — VeraCrypt). Поэтому вероятность найти выход в мире опенсорс чуть больше, если сравнивать с банкротством компании-разработчика какой-то закрытой технологии.
В целом риск я вижу только один — возможность внедрения закладок, но это решается путем создания доверенных сборок и репозиториев, которые проверяют код на безопасность и закладки. Остальные риски открытого ПО (необходимость наличия сотрудников с необходимыми компетенциями, исчезновение этого ПО, сложность поддержки, отсутствие полной документации, отсутствие гарантий) вполне решаемы квалифицированными ресурсами, либо коммьюнити (пример MySQL->MariaDB, TrueCrypt->VeraCrypt, gogs->gitea, OpenOffice -> LibreOffice).
Если говорить о рисках, то одним из них может быть недооценка затрат, требуемых для внедрения OSS технологии «из коробки». С учетом сильной инженерной школы в наших широтах, организации могут предпочесть вырастить экспертизу внутри себя, практически не учитывая факторы наличия необходимых специалистов на рынке, их стоимости, ресурсоемкости и сроков выполнения поставленной задачи. Поэтому наличие локального вендора, предлагающего все тот же OSS, готового обеспечить поддержку и сопровождение на протяжение всего жизненного цикла программного обеспечения в организации, может стать отличной и в то же время более дешевой альтернативой.
Каких-то неочевидных рисков мы не видим. Однако хотелось бы отметить риск того, что субъекты КИИ часто переходят на те технологии, которые недостаточно хорошо обеспечены локальными компетенциями. В результате этого, например, в объектах КИИ или ещё в каких-то чувствительных областях могут быть внедрены технологии, которые не выдержат испытания временем и, как в описанных в статье примерах, перестанут развиваться.
Из самых свежих историй, связанных с рисками, — блокировка доступа к сервисам Docker Hub с российских IP. При этом при использовании недоверенных зеркал и методов обхода блокировок высок риск получить вместе с новыми технологиями какие-то закладки-вредоносы или оказаться подверженным другим угрозам.
Основным подходом к работе с такими рисками (как мы с экспертным сообществом и описали в проекте Концепции создания и развития экосистемы репозиториев программного обеспечения, находящихся на территории и в юрисдикции Российской Федерации) является развитие компетенций, совершенствование образования, в том числе более глубокое обучение принципам, практикам и культуре эффективного и безопасного использования и разработки открытого и свободного программного обеспечения и решений, созданных на его основе.
Могу прокомментировать в контексте технологий, связанных с обработкой и анализом данных. Российский рынок на данный момент отличает достаточно низкое понимание природы open source и сопутствующих рисков. Некоторые компании выкладывают свои наработки в open source, но при этом не собираются его поддерживать и развивать. Смысл таких действий понять сложно. Если вы создали продукт и согласны выложить его исходники, это не делает его автоматически полезным и действительно open source.
Некоторые компании не понимают модели лицензирования и силы, стоящие за тем или иным продуктом. Из-за этого они могут попытаться сделать форк проекта, который в дальнейшем будет невозможно развивать. Например, несколько российских компаний сделали свой форк популярного проекта Dremio, которые является open core, а не open-source (то есть у проекта нет открытого процесса разработки и сообщества, есть только код, который можно прочитать). В результате компании тратят деньги на форки, которые заведомо невозможно должным образом поддерживать.
Другие компании, обжегшись на уходе коммерческих вендоров, объявляют, что их стратегия теперь: «используем только open-source проекты». При этом данные компании как правило не осознают реальную стоимость развития и поддержки таких проектов, которая обычно измеряется в десятках и сотнях миллионах рублей в год.
Поэтому через некоторое время после сегодняшней эйфории в духе «мы свободны, все под нашем контролем» придет осознание реальности: нужные фичи не появляются, некому оперативно исправить баги и т.д. В итоге большинство компаний, которые сейчас делают ставку на «только open source» проиграют стратегически, так как не смогут поддерживать должный темп разработки. Для преодоления этой проблемы нужно вернуть доверие компаний к вендорам, но уже не западным, а российским.
А последние, к слову, не прочь заработать быстрых денег в условиях резко образовавшегося дефицита предложения. Это выливается в необоснованный рост цен и большое количество форков open source проектов, в которые компании-разработчики практически ничего не вкладывают. Потребуется время, что бы все участники процесса — вендоры и компании-потребители — нашли правильный баланс для успешного развития технологий.
Есть еще один риск — покупка open source и изменение вектора развития. Пример MySQL, Nginx показал, как это может быть. Риски конечно же есть, как и в любом ПО, даже в проприетарном не все гладко. Если говорить о мировой практике, то обычно, если ПО востребовано, то появляются форки, для примера: OpenSearch, MariaDB, Rocky Linux. Для большой компании поддерживать свой форк открытого ПО не составит проблем. А если нет нужды или средств, то переход на конкурирующий софт, благо обычно есть несколько альтернатив.
Мы в EdgeCenter были перед выбором, на какой диструбитив перейти после того, как RedHat отказалась от Centos. В рабочем порядке переустановили на всех серверах Centos на Stream 8 и не спеша размышляем о переходе на Ubuntu.
Мы — как инвесторы — не очень жалуем open source решения стартапов в силу того, что заработок на такой модели зачастую не так очевиден, либо отложен. Да, есть много успешных примеров вроде Nginx и других, а также Postgres Pro, которые показали, что в России можно делать очень успешный бизнес на базе open source с выручкой в миллиарды рублей. Однако сам по себе подход на основе открытых технологий требует стать достаточно популярным и компетентным в свой сфере, а только потом дает возможность строить бизнес, а не проект для души.
На заре компании Naumen, где я выступаю в роли акционера и председателя совета директоров, мы начинали работу в парадигме open source одни из первых в России. Но 23 года назад это было совсем тяжело. Клиенты брали бесплатно софт, а услуги не заказывали, потому что «все и без этого работает». Либо хотели доработок без оплаты. В те времена я даже делал Naumen Public License и верифицировал ее в OSI, но сейчас компания не выпускает продукты по open source лицензиям. В целом в российском корпоративном мире capex (капитальные затраты) чаще даются заказчику гораздо проще, если сравнивать с оплатой подписки или услуг, а 20+ лет назад покупка лицензии была самой понятной статьей в ИТ-расходах.
Что еще почитать по теме:
Комментарии (58)
PereslavlFoto
02.06.2024 09:05+1При этом данные компании как правило не осознают реальную стоимость развития и поддержки таких проектов, которая обычно измеряется в десятках и сотнях миллионах рублей в год.
Мы используем open source программы, потому что реальная стоимость поддержки такой программы для нас нулевая. Мы не тратим ни одного рубля на копирование и установку, программа просто работает.
dmitrykabanov Автор
02.06.2024 09:05Все так, но потом начинаются вопросы: а можем ли мы коммерциализировать свое решение на основе OSS-компонентов, (про лицензии же не подумали, пока все просто работало); а будут ли решение обновлять и будет ли оно доступно завтра и с какой вероятностью (см. кейс Greenplum); а что с ИБ-сертификацией и так далее. Т.е. на серьезном корпоративном уровне уже не все так просто выходит
PereslavlFoto
02.06.2024 09:05+1OSS компоненты можно продавать. А если взять коммерческие программы, тогда коммерциализировать такое решение можно будет только в одном случае — если владелец коммерческих программ дозволит коммерциализировать. Обычно он запрещает так делать.
Никакая коммерческая лицензия не обещает обновлять программу и не обещает доставлять её завтра. Поэтому программу надо скопировать и хранить у себя. Лицензия не влияет на работу поставщика.
dmitrykabanov Автор
02.06.2024 09:05Можно или нельзя — зависит от лицензии как раз, потому что широта понимания "продавать" достаточно велика (в каком виде и каким образом, по какой модели). Например, в облаке вы не сможете продавать эластик (managed service). С терраформ и прочими продуктами hashicorp что-то тоже не все так просто — интересно, почему :) матчасть надо знать
PereslavlFoto
02.06.2024 09:05Для того, чтобы продавать Эластик, была создана отдельная версия.
https://en.wikipedia.org/wiki/OpenSearch_(software)
Взяв за основу тот Эластик, который раньше распространялся по Apache License, люди доказали, что свободная лицензия позволяет продавать ПО.
dmitrykabanov Автор
02.06.2024 09:05+2Вы весь разговор в бинарном ключе понимаете в духе какого-то спора или выбора между OSS и проприетарным ПО. А такого спора или выбора тут нет, как и сравнений в духе "хуже/лучше". Речь о том, что для работы с OSS нужны компетенции: от понимания лицензий до остального.
В кейсе с эластиком — aws выступает как раз организацией с такими компетенциями, которые позволяют развивать дальше открытый продукт (доказывать возможность продавать что-либо не является там целью)
PereslavlFoto
02.06.2024 09:05Однако такие же компетенции нужны и для работы с коммерческим ПО.
В кейсе с эластиком мы видим, что никакое предприятие, никакой автор не может отозвать права, переданные по свободной лицензии.
dmitrykabanov Автор
02.06.2024 09:05+1Не буду спорить, в дальнейших публикациях поясню, почему компетенции тут невозможно уравнивать 1 к 1.
Про отзывать речь и не идет — просто облачникам пришлось идти договариваться на коммерческой основе в случае с эластик. aws же как облачная платформа, имеющая достаточно компетенций в OSS-среде, пошла другим путем, вот и все. Просто мир чуть сложнее очень хорошего опенсорса и очень плохого коммерческого ПО
PereslavlFoto
02.06.2024 09:05+1Опенсорс не очень хороший. Коммерческое не очень плохое.
Я вижу различие вот где. Опенсорс можно использовать в своей работе, а за коммерческое придётся или платить из зарплаты, или искать крэки и хаки.
dmitrykabanov Автор
02.06.2024 09:05+1Удивитесь, но о сравнении в материале вообще речь не шла :) говорю только о том, что для использования OSS нужно понимать его специфику (с чем большие проблемы на рынке)
PereslavlFoto
02.06.2024 09:05То есть надо уметь с ним работать? Это везде так.
LaTeX vs PageMaker. Audacity vs CoolEdit. Thunderbird vs Outlook. Inkscape vs CorelDraw.
0mogol0
02.06.2024 09:05+1нужно понимать его специфику
угу... например, если в какой-то момент Амазон решит прекратить спонсирование OSS, сумеют ли его мейнтейнеры найти других таких спонсоров? или просто проект начнёт тихо загибаться, потому что большинство разбежится в поисках проектов, которые оплачиваются, потому что коммитами в репу еду оплатить неполучается.
и это мы ещё не рассматриваем ситуацию, когда небольшой проект предлагают купить хакеры, которые потом внедряют в него вреднонос... Это безусловно можно заметить, но для этого ваши программисты должны мониторить каждый коммит.
dmitrykabanov Автор
02.06.2024 09:05для амазона это имиджевая история теперь, поэтому будут поддерживать (денег хватает), плюс — они это в первую очередь для себя и делали :) во многом
0mogol0
02.06.2024 09:05+1ну конкретно этот проект - возможно.
Хотя я бы не удивился, что в какой-то момент наработав опыт и поняв, что нужно пользователям - они выпустят свой "закрытый" продукт для пользователей AWS, а этому позволят плыть свободно дальше. Т.е. да, можете его развивать, форкать сколько угодно, но и деньги разработчикам вам придётся платить самим.
Но ведь подобных проектов - сотни и тысячи. И в какой момент кто-то решит соскочить - предугадать не дано и это тоже риск.
Kristaller486
02.06.2024 09:05+1Согласен, матчасть надо знать. Эластик и терраформ больше не open source. Для таких мувов даже свой термин придумали - source available software.
PereslavlFoto
02.06.2024 09:05Да почему же Эластик, который распространялся по свободной лицензии, больше не распространяется по ней? Свободную лицензию нельзя отозвать. Поэтому Эластик просто переименовали: теперь он называется OpenSearch.
0mogol0
02.06.2024 09:05Мы используем open source программы, потому что реальная стоимость поддержки такой программы для нас нулевая. Мы не тратим ни одного рубля на копирование и установку, программа просто работает.
хм... ну видимо вам очень повезло. Приходилось общаться с конторами, которые даже Libre Office надо было допиливать в плане добавления корпоративных шаблонов, форматирования и т.п.
Да, это не очень долго, но времени требует, а время айтишника = его зарплата.
PereslavlFoto
02.06.2024 09:05+2Любую программу надо допиливать в плане добавления корпоративных шаблонов и форматирования. Это не зависит от лицензии.
dmitrykabanov Автор
02.06.2024 09:05Да, допиливать и лицензии — это разное. Про допиливать — вопрос в компетенциях для работы с тем или иным тех.стеком. За пять минут не поменять это все при переходе с одного решения на другое. И людей поискать еще нужно.
Про лицензии — есть OSS-лицензии, которые просто не позволяют коммерциализировать производные продуктеы. Однако многие не понимают этого
PereslavlFoto
02.06.2024 09:05есть OSS-лицензии, которые просто не позволяют коммерциализировать производные
С другой стороны, закрытые лицензии не передают исходного текста, поэтому запрещают создавать производные работы.
dmitrykabanov Автор
02.06.2024 09:05+1Не передают исходного текста != запрещают производные работы
0mogol0
02.06.2024 09:05угу... можно найти море продуктов, которые, например, требовали БД для своей работы и от вас требовалось лишь предоставить поддерживаемую БД (MS SQL / Oracle / DB2 / Postgre итп).
0mogol0
02.06.2024 09:05+1Вот только часто объем доработок для проприетарного и OSS - разный. Плюс нередко приходится переучивать на новый софт пользователей.
Поэтому OSS - это чаще всего не про экономию.
PereslavlFoto
02.06.2024 09:05+1Да, вы правы, здесь надо уточнить.
Представим, что руководитель поставил перед вами задачу. Для её решения нужна специальная программа. Срок выполнения задачи — два месяца, расходы вы сами определяете из своей заработной платы, размер вашего заработка зависит от результата.
Тут возникает выбор, что купить: лицензию, еду или одежду. OSS позволяет мне купить еду или одежду, тем самым даёт огромную экономию.
0mogol0
02.06.2024 09:05Срок выполнения задачи — два месяца, расходы вы сами определяете из своей заработной платы, размер вашего заработка зависит от результата.
Эээ, как интересно у кого-то работа устроена... У меня и всех моих знакомых расходы на софт для работы оплачивал работодатель. Век живи, как говорится...
Тут возникает выбор, что купить: лицензию, еду или одежду. OSS позволяет мне купить еду или одежду, тем самым даёт огромную экономию.
Опять же может возникнуть интересная ситуация, если вы уложились в два месяца с проектом - то всё прекрасно.
Но если вам потребовалось пять месяцев, потому что продукт оказался сложнее, чем вы предполагали (на основе опыта с проприетарным софтом), то три месяца вы будете есть ту
одеждуеду, которые купили за два оплачиваемых месяца.PereslavlFoto
02.06.2024 09:05Работодатель предлагает найти грант на покупку софта, либо разыскать спонсора, либо получить деньги где-нибудь ещё.
Если потребовалось пять месяцев, значит, надо работать сверхурочно или отложить другие, менее важные задачи.
0mogol0
02.06.2024 09:05Работодатель предлагает найти грант на покупку софта, либо разыскать спонсора, либо получить деньги где-нибудь ещё.
эээ, мы сейчас точно говорим о работе по найму, а не о коммерческом подряде, когда нанимают внешнюю фирму / ИП, чтобы тот за фиксированную сумму выполнил определённую проект?
Если потребовалось пять месяцев, значит, надо работать сверхурочно или отложить другие, менее важные задачи.
Эээ, сверхурочные работодатель оплачивает? или мы опять не про наёмного работника говорим?
PereslavlFoto
02.06.2024 09:05Речь про штатное место, конечно. За сверхурочную работу потом будет отгул, если не забыть.
0mogol0
02.06.2024 09:05Речь про штатное место, конечно.
тогда с какого работник должен сам покупать лицензии за свой счёт? Его задача делать работу, а задача работодателя предоставлять необходимые инструменты для изготовления: компьютер, лицензии на софт, рабочее место (если работа в офисе) итп.
Другой вопрос, что работодатель может посчитать и решить, что зарплата пяти программистов на лишние три месяца обойдется ему дешевле, чем лицензия на проприетарный софт, и тогда вполне логично использовать OSS.
И вот это уже вопрос экономики. Точно так же он может прийти к выводу, что лучше нанять внешнюю фирму на внедрение или купить лицензию на другой софт, подешевле, но с меньшим временем на доработку. И это будет зависеть не от открытости сорцов (может кто-то решит использовать freeware), но от общей стоимости внедрения и эксплуатации.
За сверхурочную работу потом будет отгул, если не забыть.
отгул - это по факту оплата в размере суточной ставки, т.е. тоже деньги работодателя.
0mogol0
02.06.2024 09:05я вам про деньги, а вы про день быстрее...
по остальному я так понимаю, возражений нет?
PereslavlFoto
02.06.2024 09:05По остальному ответ простой. В штатной сетке нет пяти программистов, а в бюджетной смете нет денег на покупку лицензий. Чтобы получать доход, учреждение вынуждено экономить на всём, даже на освещении.
0mogol0
02.06.2024 09:05В штатной сетке нет пяти программистов, а в бюджетной смете нет денег на покупку лицензий. Чтобы получать доход, учреждение вынуждено экономить на всём, даже на освещении.
это мне напоминает 90ые, когда ради того, чтобы нарисовать пару линий на Западе платили $20 за простенький шароварный редактор, а в России ставили крякнутый Фотошоп, то что он требует более высокой квалификации работника и больше времени на освоение - тогда никого не волновало, так как "куда он денется с подводной лодки".
А потом пошли рейды управления К, специалисты освоившие фотошоп или требовали совсем других денег, или уходили, и в итоге бизнес понимал, что надо что-то менять, так на имеющейся модели работать больше не получается.Возможно "учреждению" стоит пересмотреть свою бизнес-модель, чтобы "получать доход" на более солидном базисе.
PereslavlFoto
02.06.2024 09:05С одной стороны, вы правы. Пошли рейды (в коммерческих местах), специалисты уходили, бизнес не мог работать на прежней модели.
С другой стороны, сейчас ставят крякнутый Фотошоп, потому что он был освоен ещё двадцать лет назад. Рейдов пока ещё нету. А люди, которые проработали двадцать лет, никуда не денутся в районном городе.
Вы правильно говорите про пересмотр бизнес-модели. Это общее мнение. Но тут возникает одна трагическая проблема. Хороший директор предприятия предпочтёт работать на прибыльном коммерческом предприятии. Ему просто не интересно интриговать, чтобы потом управлять учреждением.
lorc
02.06.2024 09:05+1Плюс нередко приходится переучивать на новый софт пользователей.
Переучивать приходится если начали работать с закрытым решением, а потом его у вас отобрали (лицензии больше не продают, государство запретило, производитель прекратил поддержку, мало ли причин).
А если вы сразу начали с OSS решений, то переучивать никого не надо. И отобрать их сильно сложнее.
0mogol0
02.06.2024 09:05А если вы сразу начали с OSS решений, то переучивать никого не надо. И отобрать их сильно сложнее.
В идеальном мире да, к вам приходят специалисты tabula rasa, вы их учите с нуля на какое-то решение и они до пенсии у вас работают.
В реальном мире чаще всего вы берёте специалиста с опытом работы в том или ином софте, и если вы используете не самое распространённое решение - вы практически автоматом закладываетесь а) на переучивание, б) на повышение з/платы, так как выбор специалистов с таким скиллом не велик и придётся доплачивать (возможно и немного).
В качестве решения можно настаивать на обучение в школе на OSS решении, вот только для этого они должны быть зрелыми и стабильно работающими и едиными для всех. Сразу правда возникнет вопрос, почему выбрали линукс, а не фрю или ещё кого-то...
Ну и главное, не должно возникать ситуаций, когда вам потребовалось сменить ваше OSS решение, потому что его забросили развивать (или развитие пошло в ненужную вам сторону), оно не поддерживает требуемое вам теперь новое железо или софт. В принципе и в открытом, и в закрытом можно оставить заявку на добавление фичи, но в коммерческом продукте - это определяется вашей ценностью как заказчика, в мире OSS - это больше определяется видением будущего мейнтейнером (ну или вы должны сами профинансировать эту фичу, но тогда OSS это уже открытый, но отнюдь не бесплатный для вас софт).
santjagocorkez
02.06.2024 09:05Можно скриншоты из внутренней системы (обезличенные) о том, как xz был заветирован до попадания в прод? Обязательный признак: автоматически (ведь не потрачено ни рубля, даже зарплаты специалистов). Обязательный признак: автоматика тоже бесплатная.
Потом можно отдельно подискутировать о том, был ли отправлен в апстрим багрепорт с предупреждением, и, если нет, то как так выходит, что «BSD-like позволяют брать и не отдавать взамен ничего, а GPL-like от такого защищены»
PereslavlFoto
02.06.2024 09:05Скриншоты о том, как LaTeX заветирован для использования в подготовке оригинал-макетов? Это было личное решение специалиста, который выбрал OSS, чтобы не платить за платную программу.
Зарплату приходится платить независимо от использования программ. Единственная связь между программами и зарплатой состоит в том, что сотрудник тратит зарплату на покупку лицензий.
santjagocorkez
02.06.2024 09:05Зачем отвечать на вопрос, который не задан, и не отвечать на вопрос, который задан?
PereslavlFoto
02.06.2024 09:05Вопрос был такой: как руководитель разрешает использовать свободное программное обеспечение и каким документом это разрешение закреплено.
Ответ: руководитель не считает нужным решать такие мелкие вопросы, которые не требуют расхода денег.
Вопрос: как был отправлен багрепорт.
Ответ: в практической работе у специалистов возникают не багрепорты, а результаты практической работы. Например, СПО QGIS создаёт не багрепорты, а карты. Например, СПО Exiftool создаёт не багрепорты, а метаданные к мультимедийным документам.
santjagocorkez
02.06.2024 09:05Вопрос был: как компания предотвратила активными действиями дарение своего сервера той группе, что внедрила байпасс для ssh через libxz (кейсу всего пара месяцев, много шума было)?
Ответ «сообщество OSS достаточно активно само в предотвращении» не принимается, это пассивные ожидания. Более того, иронично, что в данном случае лучшим другом OSS оказалась Microsoft. Еще более того, совершенно случайно, это же надо, инженер полсекунды засек. В общем, интересует доказательство того, как в компании совершенно независимо от «сообщества» предотвратили бесплатную сдачу серверов вместе со всем содержимым группе, строящей за атакой на исходный код xz.
PereslavlFoto
02.06.2024 09:05Свободное программное обеспечение работает в компьютерах сотрудников. Весь ваш вопрос относится не к лицензированию, не к полезному использованию СПО в ежедневной работе — а только к доступу через SSH, хотя сотрудники никогда не используют этот протокол удалённого доступа, потому что им не нужен удалённый доступ.
santjagocorkez
02.06.2024 09:05Забавно, опять вместо прямого ответа набор пиар-штампов. Из чего я делаю вывод, что «нулевая стоимость поддержки» означает не более, чем «авось, кто-то что-то сделает, и нас пронесет».
K0styan
02.06.2024 09:05+1Для большинства мелких компаний, у которых весь IT персонал - это эникейщик (и хорошо если штатный, а не приходящий) это работает именно так.
15432
02.06.2024 09:05С TrueCrypt я помню несколько иную историю. Автор годами пилил удобный и бесплатный софт, ему кидали чутка донатов, не сильно много, но уж как есть.
А потом внезапно на аудит безопасности собрали больше 60 килобаксов и автор обиделся. Мол, мне вы донатить не хотите, а тут левым людям на копание в моем коде вы с радостью набрали. И
продалсяпередал дела Microsoft.dmitrykabanov Автор
02.06.2024 09:05Спасибо! А есть где почитать про «автор обиделся»? Вдруг у вас ссылка сохранилась
15432
02.06.2024 09:05официальной причины так и не было представлено, это домыслы сообщества, связанные с тем, что проект закрыли вскоре после сбора денег на аудит
petropavel
Хорошая статья про преимущества Open Source. "Не смогли договориться", "кончились деньги" и "главного разработчика арестовали" — это может случиться и с closed source продуктом, арестовали же не за то, что он Open Source пилит, а за убийство.
Но Райзера арестовали в 2006. Только год назад ReiserFS стала obsolete. И наверняка пару лет ещё вполне проживёт. 20 лет! После исчезновения главного разработчика. Вполне достаточно, чтоб неспеша разобраться с альтернативами и плавно перейти на что-то другое. Closed source продукт накрылся бы гораздо быстрее.
dmitrykabanov Автор
Да, частные случаи рисков (см. дисклеймер). Где-то более выражены (если сравнивать с проприетарным ПО), а где-то менее, сравнивать смысла нет, а вот знать специфические кейсы — вполне полезно. Относительно недавно делал семинар на эту тему
0mogol0
Вот только для проприетарного, востребованного софта можно купить всю компанию с кодом и лицензиями, клиентской базой. У OSS не очень понятно, что и у кого брать. Да, можно сделать форк - но его могут сделать и другие, и по прежнему останется вопрос как зарабатывать деньги.
Это не значит, что в каких-то ситуациях проприетарный продукт не накроется быстрее (например, если софт узкоспециализированный, требуется небольшому числу заказчиков и зависит от одного разработчика, который внезапно
померперестал его дорабатывать). Но в общем случае говорить, что OSS будет работать дольше, чем проприетарный софт в отсутствии поддержки - это ИМХО чересчур большое упрощение ситуации.dmitrykabanov Автор
Без OSS в любом случае не получится, но с ним нужно уметь работать. Многие все еще не в курсе, что с OSS-лицензиями происходит (даже не отслеживают что-то помимо громких кейсов), хотя это и не связано с санкциями от слова совсем
0mogol0
ИМХО, это должно стать головной болью вендоров. Т.е. если предприятие не огромный холдинг со своим департаментом разработок, то именно вендор / поставщик IT решения должен думать, как обеспечить выполнение решение задач предприятий, параллельно отслеживая изменения лицензий, блокировок итп.
Но да, предприятиям придётся платить больше, так как раньше они приобретали готовый коробочный продукт, а здесь придётся приобретать "решение".
dmitrykabanov Автор
Так и есть! Но даже локальные разработчики ПО (а они тоже разные) не всегда видят глубину картины. А с другой стороны, разработка же идет не только на стороне вендоров, а у предприятий все еще хуже с профильными вопросами
PereslavlFoto
Есть востребованный проприетарный софт для сканирования фотоплёнок. Его делала компания Nikon. Много лет назад она остановила разработку и вышла с рынка, перестала делать и продавать сканеры.
Купить этот проприетарный софт нельзя, Nikon не продаёт. Сделать форк нельзя, нет текста программы. Ничего нельзя сделать, всё запрещено.