Pull to refresh

Comments 20

На мой взгляд, при словах open-source у многих людей сразу возникают ложные ожидания.

Например, считается что open-source проекты развиваются сообществом. Во-первых, у всех разные определения понятия «сообщество» в плане численности и объема вклада. Во-вторых, какое бы вы ни дали определение сообщества, такие проекты вы в природе найдете; но это будут скорее исключения. Правильней было бы сказать так: open-source — это проекты, в которых сообщество имеет возможность принять развитие; но вовсе не обязано, и не факт, что оно это делает. Собственно, в этой статье это и описано. Для компаний имеет смысл выбирать open-source компоненты для критичных компонент только в том случае, если имеется возможность привлечь людей/партнеров для поддержки; но ни в коем случае нельзя рассчитывать на бесплатную поддержку некоего абстрактного сообщества.

Также, есть расхожее мнение о том, что open-source проекты более безопасны, так как любой желающий может проверить код. Опять же, ключевое слово «может»: не факт, что кто-то это в реальности делает. Но лично вы — да, можете. Я бы сказал так: если вам важна безопасность, и вы можете найти компетентных спецов, которые могут проверить код, и вы намереваетесь это делать, то, да, open-source имеет для вас преимущество.

Open-source часто ассоциируют с финансовой выгодой: никто не требует покупать лицензии, не навязывает тех. поддержку — снижение операционных затрат вроде как налицо. Как по мне, корпоративный проект, основанный на open-source компонентах и на таком вот видении, скорее всего потерпит крах. Не обязательно, но с довольно большой вероятностью.

Правда, с точки зрения рынка open-source имеет неоспоримое преимущество в том, что потенциально много компаний могут осуществлять тех. поддержку. Опять же — «потенциально», «могут», и там еще нюансы.

Еще один неоспоримый плюс в том, вы имеете возможность добавить свои фичи даже если создатели/мейнтейнеры не поддержат ваши изменения. При условии что, вас устраивает лицензия, у вас есть спецы, вы готовы далее поддерживать форк и т. п.

То есть open-source — это скорее о возможностях, но не о дивном новом мире, где всё делается за вас.

Я думаю, что вообще термин опен-сурс сейчас очень неверно понимается. Что такое опен-сурс и зачем он нам нужен? Является ли опен-сурсом ситуация, когда вендор нам даёт исходники и мы действительно можем их изменять? А если исходники дают, но под ограниченной лицензией? Короче, все сложно и "бытовое" понимание опен-сурс создаёт реально ложные ожидания
Возможно, что мы находимся на пороге, когда родится какой-то новый подход, который избавлен от недостатков существующей ситуации. А возможно, что и нет и мы дальше будем "катить квадратное и гласить круглое" и страдать.

UFO just landed and posted this here

Одна из плоскостей — не любой код, выложенный на гитлабе/гитхабе, можно переиспользовать. В силу лицензии. Это как "не любая картинка или статья из интернета может быть размещена (скопирована) в Ваш блог/сайт и пр."

Интересно, а в чем смысл такого кода? Академический или просто ознакомительный или еще что-то?
  1. Убедить клиента, что вот он код. Разработчик ничего не скрывает. Бери и проводи аудит.
  2. Разделить коммерческое использование и личное или в образовательных целях. Хочешь попробовать — можешь скачать исходники и собрать, запустить. Но если используешь для коммерции — будь добр заплати.
    Я думаю, что кейсов можно придумать массу.
корпоративный проект, основанный на open-source компонентах и на таком вот видении, скорее всего потерпит крах

Корпоративный проект, основанный на docker+nginx+postgres+symfony+vuejs скорее всего потерпит крах? Как-то очень необоснованно звучит, не находите?


Конечно не все открытые продукты настолько массовые, но проводить параллель между платой за лицензию и вероятностью успеха проекта нет никаких оснований.

А что вы подразумеваете под успехом проекта?

На самом деле есть четкое определение: проект успешен тогда, когда он выполнен 1) в срок 2) в бюджет 3) достигнуты цели проекта.

Цитата, которую вы привели, относилась к проектам, целью которых являлась снижение операционных затрат, связанных с сопровождением ПО. То есть простыми словами: финансовому директору подавался на стол проект, который говорил: вот сейчас мы за время Х и с бюджетом Y перейдем на open-source технологии, и будем тратить на Z меньше. Так вот в большинстве случаев такие проекты терпят крах. Да, не всегда, конечно, но чаще чем другие. Переформулирую: ожидания по X (сроки), Y (бюджет), Z (цель — снижение затрат) как правило занижены в несколько раз по сравнению с реальностью. Особенно если у компании был не большой опыт работы с open-source. То есть такие проекты имеют очень, очень высокий уровень риска.

Если не брать во внимание новости и слухи, то лично я работал на проектах в продуктовой компании, которая использовала в частности Oracle базы данных. Потом решили перейти на PostgreSQL. А что — почти то же самое, только за лицензию платить не нужно. У нас есть аксакалы Оракла, они быстро освоят PostgreSQL — это было общее видение. Как бы не так. Я не девелопер, но участвовал в общих митингах, и был свидетелям того, с каким скрипом всё продвигалось. В конце-концов мы справились, но явно не в ожидаемое время и бюджет.

Если переходить с postgres на оракл, тоже успех не гарантирован. Или внедрение какого-нибудь SAP.


Из ваших слов можно сделать вывод, что именно опенсорсность увеличивает риски перехода, однако к этому нет оснований. При переходе риски есть всегда. Банально, может просто не хватить квалификации и ума у участников проекта (не говоря уж о других проблемах).

Если переходить с postgres на оракл, тоже успех не гарантирован.

Не гарантирован. Но есть разница.

Если вы будете переходить с Postgres на Oracle, то при заключении контракта, Oracle вам будет очень настойчиво предлагать тренинги. И, если вы дадите себя уговорить, то ваш спец Петя уже сходу хоть немного узнает специфику Orcale и сможет сравнить с Postgres. Определенный процент проблем на старте это уберет. В отличии от перехода Oracle->Postgres, когда Петя будет в авральном режиме шерстить StackOverflow после заведения блокера. Очень мало кто при переходе на бесплатные open-source компоненты заказывает специализированные тренинги для своих сотрудников, и это первый фактор риска.

Еще Oracle предложит вам тех. поддержку, так что Петя даже сможет написать кому-то и ожидать получение ответа в оговоренные сроки. Для вашего примера: какой процент компаний подписывает контракт со сторонней компанией на тех. поддержку docker, nginx, postgres, symfony, vuejs, ...? Этого обычно не закладывают в бизнес-кейс, ибо тогда он становится не таким привлекательным.

Эта разница… исчезающе мала. Для того же постгреса есть постгрес про, которые с радостью возьмут деньги за поддержку. Для кубернетеса есть условный флант, который будет поначалу поддерживать кластер, обучит инженеров, а потом… сами знаете, что потом.


Тут скорее вопрос в том, что успех проекта зависит от кучи факторов и использование или неиспользование опенсурс не является решающим. Ну, а чо — давайте тогда вообще не пользоваться открытыми стандартами на языки типа С, С++, Джава....

Эта разница… исчезающе мала. Для того же постгреса есть постгрес про, которые с радостью возьмут деньги за поддержку. Для кубернетеса есть условный флант, который будет поначалу поддерживать кластер, обучит инженеров, а потом… сами знаете, что потом.

Конечно есть. Но вот только мало кто этим пользуется. Большинство рассчитывают, что без этого получится обойтись.

Ну, а чо — давайте тогда вообще не пользоваться открытыми стандартами на языки типа С, С++, Джава....

А это к чему? Мы здесь говорим про нереалистичные ожидания в финансовом аспекте.

В статье стоило затронуть проблематику появления/актуальности лицензий вроде BSL (Business Source License) ввиду предложений Open Source-решений в виде сервисов (DBaaS и т.п.) крупными облачными провайдерами. Это о проектах, которые не так малы, как curl, но и не создаются гигантами вроде Facebook… Тема (на примере CockroachDB) в полной мере раскрывалась здесь.

По словам Даниэля Стенберга, к нему часто обращаются международные компании с просьбами помочь решить проблему в cURL. Но каждый раз, когда он просит оплатить его работу, беседа почему-то прекращается.

К нему обращаются не международные компании, а рядовые специалисты из этих самых компаний. У них нет бюджета, чтобы его тратить, и нет возможности выделить бюджет, чтобы, опять же, тратить. Поэтому, как только речь заходит за деньги, они сливаются.
А человеку надо себя позиционировать как independent contractor с максимальными знаниями о продукте и навыками решения проблем и выставлять ценник по $100/час.
Хотите помощь? Пожалуйста, вот моя (e)-визитка, сайт, часовая ставка, документы фискальные по образцу страны проживания автора инструмента.

А международные компании обращаются по-другому. Типа, мы хотим использовать вашу либу или инструмент в очень важном проекте для очень важного заказчика, поэтому нам нужен SLA 99,9%, реакция в течение 3 часов, и т.п., за, скажем, 50 тысяч долларов в год. Подпишите пожалуйста типовой контракт на 500 страниц, где каждый чих расписан очень подробно (и, скорее всего, в нашу пользу).
Не понимаю как из «По данным Linux Foundation, 72% компаний из Fortune 2000 используют open source инструменты для решения своих задач. При этом 55% задействуют открытый код в коммерческих продуктах.» следует «Open source — основа интернета». Можно уйти в дебри и сказать, что опенсорс разрабатывается в том числе и на софте, которое не опенсорс. И на железе, которое спроектировано, наверно в большинстве случаев не в опенсорс софте. Неопенсорс — основа опенсорс? Как вступление реферата прочитал.
Например, из 25 тыс. коммитов в репозитории cURL, 14 тыс. принадлежат автору — Даниэлю Стенбергу (Daniel Stenberg).

А вот из этого я сделал прямо противоположный вывод (и, вероятно, был далеко не один) — наоборот, 11 тысяч коммитов (почти половина) сделана не автором, а другими разработчиками, как раз-таки сообществом — правда, хвост распределения довольно быстро убывает: 100 или больше коммитов у 11 человек, 50 или больше — у 17. (Вообще, количество коммитов — метрика тоже довольно такая себе, по-моему, еще хуже, чем количество строк кода.)

Даже не представляю какое можно придумать решение на сегодня. При переводе опенсорса на платные или частично платные лицензии аутсорсинговые компании СНГ, особенно ориентированные на JS просто сгорят.


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


Почему загнётся аутсорс JS? Ну пожалуй потому что сложно найти продукт на JS без webpack или nodejs, а платить мы не понимаем, вот и придется либо клиенту говорить что мол "нужен бюджет побольше", либо разрабам говорить что "ваши инвойсы пошли на вебпак, но вы держитесь".

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


А ведь всё к тому идёт, сейчас на некоторых сайтах уже даже статьи дают читать только платно.

Может, всё проще?
Создатель кода не знает как/не может его монетизировать;
Боится нести ответственность, ведь если купят, скорее всего потребуется дорабатывать и править баги, причем некоторые в срочном порядке;
Боится нести ответственность

звучит осуждающе

Однако никто не мешает (и многие так и делают) выпускать коммерческие версии опенсорс продуктов.
Only those users with full accounts are able to leave comments. Log in, please.