Comments 62
Главная проблема открытого и свободного кода в том, что базовые механизмы манетизации кода в современном обществе основаны на копирайте. В мозг вбивается стереотип - открытое значит бесплатное. Причем бесплатное для всех. И для простых пользователей и для корпораций. ИМХО, чем больше будут распространены лицензии ограничивающие коммерческое использование без согласия автора - тем лучше. Желательно липкие лицензии.
Вторая проблема, по моему мнению, в том, что написание и поддержка продукта - это две совершенно разных задачи, требующие совершенно разных скилов и навыков. Нет никакой структуры пооддерживающий свободный критически важный код на организованной основе, которой можно передать поддержку своего проекта если он вдруг стал популярен, но тянуть его в одиночку нет ни сил ни времени.
Третья проблема, что деньги от продажи продукта не пахнут, а вот спонсорские деньги зачастую пахнут той или иной идеологией спонсора. Пример Фаерфокс, где приход спонсор-ориентированного менеджмента привел к превращению свободного и открытого проекта, в проект зависящий от мнения базовых спонсоров, так же, как коммерческие продукты зависят от мнения акционеров.
Абсолютно мое ИМХО. Не притендующее на какое то навязывание.
Это противоречит самой религии FOSS
И для простых пользователей и для корпораций. ИМХО, чем больше будут распространены лицензии ограничивающие коммерческое использование без согласия автора - тем лучше
Ну чисто имхо. Я могу ошибаться но разве тут не проблема яйца и курицы? Если корпоративный сектор не будет использовать на своих облаках продукт - то будет ли он популярен? Например кому нужна монга - если на авс или ажуре ее нет? Да ее будут юзать кто-то на своих проектах, но не так масово. С другой стороны согласен что как-то обидно что тот же амазон например получает дуньги за продукт который они не разрабатывали. Сложно это все, но вариант "все запретить" мне не кажется выходом из ситуации
"все запретить"
это точно не выход. Это цензура... Вопрос в другом [Сейчас я займусь своим любимым делом и начну цитировать Столмана.]
В случае с ПО существуют две модели развития событий: либо вы используете программу, либо программа использует вас. Чтобы программу использовали именно вы, вам нужны определенные свободы. Эти свободы по сути являются критериями свободного ПО.
Обратите внимание, критерием свободного ПО является та свобода которую она дает пользователю. Не открытость, не бесплатность, а именно свобода. Свобода пользователя. а не владельца программы или авторских прав на неё.
В последнем случае все равно есть кто-то, кто управляет этой программой, поэтому мы говорим, что он управляет и ее пользователями. Выходит, что несвободная программа - инструмент несправедливой власти.
RMS предлагал 4 свободы: запускать, изучать, распространять и вносить вклад. Достаточно ли их сейчас чтобы обеспечить свободу? К сожалению нет. Их было достаточно в 88 году, когда программами торговали. НО недостаточно сейчас. Тот же Амазон извлекает прибыль не продавая программы, а пользуясь их несвободой манипулируя пользователями и их данными.
Amazon Kindle - вредоносное ПО. Она наносит удар по исконным свободам читателя - например, по свободе покупать книги за "наличку" и сохранять инкогнито.
Я, кстати, только так и покупаю книги. Amazon же заставляет пользователей выдавать себя. Они там, в Amazon, знают, кто какие книги прочитал. Это удар по правам человека, так быть не должно! Далее, у нас есть свобода дать книгу другу или даже продать ее. Из-за "цифровых наручников" Amazon мы так поступать больше не можем.
Фактически, выпуская софт под лицензией позволяющей её использовать компаниям типа Амазон, программист становится участником легализованного преступления. Когда, я говорил об ограничении лицензий для корпоративных продуктов, я говорил о том, чтобы автор мог пресечь злоупотребелние лицензией, а не о том, чтобы продавать свои убеждения за деньги...
Со всем согласен, но тут остапа понесло
Amazon Kindle - вредоносное ПО. Она наносит удар по исконным свободам читателя - например, по свободе покупать книги за "наличку" и сохранять инкогнито.
Такая возможность до сих пор есть. Можно прийти в книжный магаз и за наличку купить книгу и остаться инкогнито. А потом ее дальше отдать или продать.
Но, а что делать в мире где я например уехал в другую страну на месяц (командировка например) и сходил на конференцию а там сказали - есть такая классная книга. Ждать возвращения? заказывать доставку (при этом не амазон будет знать что вы купили а 2 таможни 2 государств)? Или купить онлайн на читалку и прочесть за 2-3 вечера?
Попросить у друга электронную версию и прочесть...
Представьте, что хороший друг попросил у вас копию программы. Вам придется выбирать из двух зол. Первая из зол - дать копию и нарушить лицензию. Вторая из зол - отказать другу и соблюсти лицензию. Если вы оказались в такой ситуации, выбирайте наименьшее зло. Позвольте другу скопировать программу.
Почему это зло наименьшее? Потому что тем самым вы нанесете вред тому, кто его заслуживает. Предположим, что ваш друг - достойный член общества и заслуживает вашей помощи. Разработчик проприетарной программы, напротив, покушается на солидарность вашего общества - а это очень плохо.
Вопрос выбора - это всегда вопрос ценностей.
Правильная тема на самом деле.
Чем шире и интенсивнее используется продукт, тем больше вероятность обнаружить в нем дефекты (и закрыть их). В том числе и дефекты производительности на больших объемах данных. Одно дело если БД используется в пет-проектах для домашней бухгалтерии и совсем другое - в банке с десятками миллионов клиентов и сотнями миллионов бизнес-операций в сутки. И чем шире и дольше используется продукт, тем он становится устойчивее и функциональнее.
Но тут сразу встает вопрос о котом я постоянно говорю - крупный энтерпрайз требует поддержки продукта. И готов за нее платить. Т.е. продукт, продолжающий оставаться открытым (в целом, для энтерпрайза открытость кода - это плюс т.к. любой чужой код там проходит внутренний аудит, даже если речь идет о вендорах, разрабатывающих что-то по заказу - приемка поставок идет на уровне исходников), уже перестает быть бесплатным. Как на уровне поддержки, так и на уровне заказа новых фич.
И тут, действительно, встает вопрос курицы и яйца - прежде чем продукт заинтересует энтерпрайз он должен в достаточной степени развиться, но на одних пет-проектах он не разовьется до уровня заинтересованности энтерпрайзом.
А зачем? Зачем сообщество должно бесплатно делать для кровавого энтерпрайза продукт удовлетворяющий его запросы? Притом что для большинства проектов сообщества эти требования избыточны...
Крупный энтерпрайз вполне осознано использует ОТКРЫТЫЙ код, не только для прозрачности, но и для распределения затрат на разработку и для гарантий того, что в один момент не вырастет стоимость лицензии раз так в 100500. Этот код поддерживают программисты на зарплату.
НО если код разработал инди разработчик, то скорее всего энтерпрайз код отожмет бесплатно. Исключения редки. О чем Вы, в общем, и писали ниже. И зачем тогда инди разработчикам бесплатно работать на энтерпрайз?
В статье автора описана ситуация именно инди разработчика в ОТКРЫТОМ коде.
Зачем сообщество должно бесплатно делать для кровавого энтерпрайза продукт удовлетворяющий его запросы?
Никто никому ничего не должен.
Но вы же не хотите ситуации - вот создали свою суперпупермегаэффективную БД. Но в итоге она используется исключительно на мелких пет-проектах. Потому что на крупных проектах никто не хочет связываться с продуктом разработчика-одиночки, который "никому ничего не должен" и развивает свой проект в свободное от всего остального время по принципу "я художник, я так вижу". А в энтерпрайзе огромное количество нефункциональных требований, которые везде свои и на которые вам, как свободному разработчику, совершенно справедливо покласть - вам энтерпрайз не платит и вы не обязаны подчиняться его требованиям.
А если энтерпрайз вдруг возьмет ваш код, то сначала он должен сделать его полный аудит, потом привести в соответствии со своими НФТ, провести полный цикл тестов (включая нагрузочные и интеграционные) и потом самостоятельно поддерживать.
Все это в сумме может оказаться не дешевле (по затратам времени и ресурсов) чем просто вязать вашу идею и реализовать ее самостоятельно. А поскольку алгоритмы не во всех странах патентуются (в РФ нет точно), то тут еще и с лицензиями никаких проблем не будет - "мы сами это придумали и попробуйте доказать обратное".
OpenSource - это очень хороший и правильный путь развития на уровне сообщества единомышленников. Но как только речь заходит о бизнесе и деньгах, все выглядит совсем иначе.
Тут как с наукой - есть фундаментальные исследования, по ним публикуются статьи в открытом доступе - опубликованные идеи и результаты доступны для использования всему сообществу.
Но как только речь заходит о коммерциализации - все. Если придумали что-то, что можно коммерциализировать, оформляется патент (который можно кому-то потом продать). И тогда уже никаких статей (которые могут раскрыть технологию или которые можно противопоставить по новизне патенту). Тут "или-или". Видишь коммерческий потенциал - патент. Не видишь - статья.
OpenSource - это деформация Свободного ПО под влиянием того, что основные спонсоры открытых проектов - корпораты. OpenSource деиделогизирует совместную разработку и убирает из неё стремление к свободе, делая акцент именно на совместной работе. Что удобно для корпоратов.
Тут кстати недавно была очень интересная статья про гит и фэйсбук с мс. Одни пришли и сказали сделайте нам как мы хотим - разработчики гита их послали (и были с своем праве правы). Но когда пришел мс и под них тоже не прогнулись и мс сделал свой гит со всем чем надо то у разработчиков гита возникла ситуация - что они или принимают новую версию и ее продолжают мейнтейнить или со временем остаются на обочине былой славы. Плох ли результат этой истории - не знаю. С одной стороны разработчикам скормили чужое и это наверно обидно, но вот с другой стороны мне как пользователю - работает все, еще лучше и быстрее и с новыми фишками - спасибо возьму еще.
А вообще в этом мире надо уметь договариться. Без этого навыка останешься или без проекта или с проектом для себя
Договариваться можно только людям друг с другом, а не с крокодилом.
Человек руокводствуется воспитанием, моралью и прочими субъективными качествами. Корпорации руководствуются только собственной прибылью.
Корпорации принадлежат людям и управляются людьми.
Просто люди разные бывают. Есть те, с которыми можно договариваться, а есть с которыми нельзя.
Есть теория, что на вершину власти прививаются люди, обладающие психопатическими чертами (в той или иной степени, не психопаты в полном смысле, но имеющие рях признаков, психопатам свойственных) - отсутствие эмпатии, эгоцентризм... Вот с такими, да, не договориться.
Есть теория, что на вершину власти прививаются люди, обладающие психопатическими чертами
ничем не потвержденная. На самом деле основное отличие мэнеджеров от неменэджеров с каким ресурсом они работают и какие задачи им ставятся. Поверьте - управлять людьми - это не такая простая вещь как кажется. У меня знакомый имеет 100+ людей в подчинении в ит компании. Старался сделать процессы и правильную культуру. И? все равно есть куча людей которым все не то и не так. Прям ноют и требуют как дети. И с таким количеством людей невозможно к каждому относится по приятельски и сюсюкаться. Потому что сразу начинают абузить это.
Но компании разные бывают и ваш опыт может отличаться от моих знаний и опыта
Речь не о менеджерах. Менеджер - это просто наемный работник.
Да. В корпорациях принят принцип коллективной безответственности. Менеджеры просто наёмные работники. Деректора - просто наемные работники. Акционеры не вмешиваются в работу, а только контролируют прибыль. И с кем договариваться?
В корпорациях принят принцип коллективной безответственности.
Ну нет же) Вас когда нанимают в корпорацию не говорят - вот тут кухня с печеньками, вот тут переговорки, а вот тут - ваше место для безответственности.
Просто в больших компаниях нельзя мерять температуру по отзыву одного своего знакомого, просто потому что это лишь фидбэк на одном проекте. А проектов может быть куча. Ну ладно он мог поболтать с кем нибудь на курилке и узнать про парочку, но бьюсь об заклад что он точно сказал что есть другой отдел где все в порядке с руководством. Поэтому корпорация - это как бы группа компаний и выбирая проект на какой попадешь Ты как бы выбираешь конкретную компанию. И да - культуры этих "компаний" может быть разная потому что могут ошибиться с наймом. Как и везде.
И с кем договариваться?
Можно пойти выше а потом еще выше и вот если там отказали - наверно ваша идея не такая уже и классная или просто банально не нужна компании. Это как с мемом про колесо - нет времени сменить на круглые - мы все время в огне.
Популярность никому не интересна в рамках разговора "опенсурс - это неоплачиваемый ад, где все от вас что-то требуют". Тут как бы по определению продукт (либу, программу) кто-то использует, другой вопрос, что иногда приходят и требуют исправлений (не всегда в вежливой форме), а положительной отдачи (в том числе и финансовой), считай, никакой.
Хм, а почему бы не попробовать дать аналогию, скажем, из мира искусства. Ар брют - ближайшая аналогия IMHO. Тогда становится ближе позиция я сделал произведение, и у меня нет настроения на сопровождение оного. У арт объектов уже есть сложившаяся практика авторских прав, прав на заимствование, а главное понимание что изменить объект требует усилий и настроения.
Нет никакой структуры пооддерживающий свободный критически важный код на организованной основе, которой можно передать поддержку своего проекта если он вдруг стал популярен, но тянуть его в одиночку нет ни сил ни времени.
Думаю, структура, если и появится, может скатиться на чисто коммерцию, как описано у вас в проблеме 3.
Но вы сами практически сформулировал решение, почти как у Пушкина )):
"Не продаётся софт открытый,
Но можно софт саппорт продать" (простите Александр Сергеевич!)
Т.е. автор (или кто-то, у кого есть опыт, время и желание) может поддерживать за деньги. Тут, конечно, будет вопрос качества...
И полностью согласен - для компаний использование только с согласия автора.
Чтобы open source приносил создателю выгоду, вовсе не обязательно монетизировать проекты. Если сам по себе проект является, допустим, какой-то библиотекой, которую используешь в своей работе, то такой проект можно развивать в рамках своей основной профессиональной деятельности. И когда эта либа используется, скажем в 10 твоих рабочих проектах, то довольно удобно, что совершенно посторонние люди помогают тебе находить и исправлять недочёты. Ведь тем самым они улучшают и те твои 10 проектов, за работу над которыми тебе платят.
Однако это работает ровно до той поры, пока ты не сменишь работу или стек. У меня сейчас три таких проекта, надо, наверное, кому-то отдавать, потому что даже если надо потратить каких-то полчаса на это, я буду две недели собираться. И даже если бы у этих проектов была какая-то монетизация, вряд ли бы это поменяло моё отношение, т.к. уровень интереса стал настолько низок, что я лучше несколько часов погуляю или просто побездельничаю, чем буду тратить время на это, даже за 50/100/200$ в месяц.
Предполагал ли я такой расклад, когда начинал эти проекты? Нет конечно. Я думал, что они будут развиваться, станут популярными, буду вписывать их в резюме. Но увы. Поэтому сейчас я с удовольствием делаю коммиты в чужие репозитории - это тот формат работы, который меня устраивает на 100% и не доставит головную боль в будущем. А заводить свли проекты - спасибо, наелся.
Ведь тем самым они улучшают и те твои 10 проектов
Или не улучшают, если пользователи приносят свои корнер кейсы, которых у вас нет
Ага, а за ними ещё разгребай баги в их глючных PR
Корнер кейс - такое дело, что сегодня его нет, а завтра он наступит. Понятное дело, что не все пулл реквесты одинаково полезны. Однако я не думаю, что существуют в большом количестве примеры, когда из-за вклада opensource сообщества проект стал в какой-то степени хуже.
К сожалению, в большом бизнесе нет принципа "не нарушать". Есть принцип "выбрать что дешевле - не нарушать, или нарушить и заплатить штраф".
Т.е. если вдруг, в обнаружите, что некая "большая корпорация", да еще находящаяся в иной от вас юрисдикции, неожиданно нарушила вашу лицензию "не использовать без согласия автора", то что? Вот что вы будет делать?
Второй момент- поддержка. Лично я занимаюсь разработкой того, что в значительной степени является missio critical для компании. И тут любое изменение кода влечет за собой полный ретест, включая нагрузочные и интеграционные тесты. А любой баг в работающем продукте оформляется как "дефект промсреды" и имеет наивысший приоритет. Т.е. все бросить и кинуться исправлять.
И что будет, если тут использовать опенсорс? Если вышло обновление - заниматься ретестами каждый раз? Если обнаружен баг - отправлять разработчику багрепорт и ждать от него что он все бросит и кинется его исправлять?
Т.е. если вдруг, в обнаружите, что некая "большая корпорация", да еще находящаяся в иной от вас юрисдикции, неожиданно нарушила вашу лицензию "не использовать без согласия автора", то что? Вот что вы будет делать?
В большинстве юрисдикций есть юридические конторы, промышляющие такими делами и получающие вознаграждение после суда. Чем больше корпорация, тем охотней за это дело возьмутся.
Есть реальный опыт?
А теперь в реальной ситуации. Вы В РФ. И вдруг обнаруживаете что в США IBM (который полностью ушел из РФ) что-то ваше использует без вашего ведома. Ваши действия?
У IBM тоже юридический отдел неслабый...
Есть реальный опыт в плане защиты авторских прав на использование фотографий в той же стране, и вообще, в судебных делах
Это не так страшно, как кажется
У "IBM" кроме неслабого юротдела есть еще и драгоценная репутация, на которую можно давить
Вот здесь не стоит обольщаться. На самом деле это достаточно трудно. Особенно в современном обществе, где большинство организаций поддерживающих открытый код контролируются спонсорами, которые либо корпорации либо близки к ним. Успешная травля Столмана тому примером.
И один из результатов такого спонсорского контроля мне видится в том, что "настоящих буйных мало, вот и нету вожаков". Это плохо.
И что будет, если тут использовать опенсорс?
А что поменяется, если это будет не опенсорс?
Если вышло обновление - заниматься ретестами каждый раз?
А при чём тут опенсорс? Ретест для mission critical штук нужен при любом изменении, нет?
Если обнаружен баг - отправлять разработчику багрепорт и ждать от него что он все бросит и кинется его исправлять?
Это как раз ситуация с вендорским решением. Если код открыт, то у тебя -всегда- как правило есть возможность залезть в исходники, поправить и даже отправить фикс в апстрим.
А что поменяется, если это будет не опенсорс?
Вы можете купить платное решение у крупного производителя, заключить с ним договор на премиальную поддержку (да, это будет стоить немало) и тогда по каждому вашему чиху там будут суетится.
При этом возможности тестирования релизов у крупных производителей несоизмеримо выше, чем у одинокого разработчика, который всем этим занимается в свободное от всего остального время.
Разница прежде все в том, что или над продуктом работает 50 человек и это их оплачиваемая работа, или это один человек и для него это хобби. Просто разные возможности.
Ретест для mission critical штук нужен при любом изменении, нет?
Да. Но когда это наш код, мы всегда знаем что никто кроме нас в него не залезет и ничего не поменяет. Никто не добавит туда никаких фич, никто его не отрефакторит. Только мы и только когда это нам реально необходимо.
Здесь такое возможно только если мы в какой-то момент форкнулись к себе и теперь сами с этим кодом работаем. Чтобы не вышло как в линуксе - каждый день по 3-5 каких-то обновлений прилетает. При том, что реально там нового ну самую чуть.
А есть пример таких конкретных производителей и договоров, что конкретно они делают по вашему чиху? Вышла новая версия, у вас упала инфраструеюктура, и что они вам прям обещают SLA на багфиксы по времени? Прям что-то не верится. Ну а откат на старую версию пока чинится новая вроде одинаково простым или сложным будет независимо от лицензии ?♂️❓
Оракл. Бегал, суетиться, присылал приватные патчи
Вот именно поэтому у нас практически не используется опенсорсное ПО. На критических участках разработка ведется собственными силами или вендорами где приемка производится на уровне исходников в нашем гите и исправление дефектов входит в условия договора.
Если говорить о системном ПО от IBM, то пока все было хорошо, мы были премиальными клиентами и имели своего представителя в IBM. Со всеми вытекающими.
Что-то автор статьи элегантно обогнул одну из, как мне кажется, самых больших проблем open source в современной культуре. Я имею в виду ситуацию, когда человека, гробящего тратящего своё время и силы на поддержку своего проекта, со всех сторон хейтят "потребители" этого проекта за то, что ошибки устраняются недостаточно быстро, новые прикольные фичи, про которые они просили уже целую неделю назад, ещё не добавлены, а логотип вообще недостаточно отражает современные тенденции всеобщей гендерной равноправности.
И даже если автор проекта достаточно уравновешен чтобы не плакать по ночам в подушку, а с той или иной степенью вежливости указывать таким персонажам дорогу в сад, давление на психику всё равно оказывается и какое-то влияние неизбежно.
Ну вот очень известный в экосистеме Vue.js человек написал недавно об этом
Mental Health in Open Source
Я имею в виду ситуацию, когда человека,
гробящеготратящего своё время и силы на поддержку своего проекта, со всех сторон хейтят "потребители" этого проекта за то, что ошибки устраняются недостаточно быстро
Это достаточно серьезный фактор.
Гипотетическая ситуация. Некий крупный банк стал использовать некую опенсорсную библиотеку в коде ядра своей АБС. И в один прекрасный момент в библиотеке обнаружился крайне редко проявляющийся баг, в результате которого десятки миллионов денег крупных корпоративных клиентов уходят непойми куда. Это дикий удар по банку - и финансовый и репутационный ущерб, а еще лишние проверки и потенциальные санкции от регулятора.
Как быстро и чьими силами будет закрыт этот баг? Готов автор библиотеки все бросить и кинуться грудью на амбразуру ради интересов потребителей своего продукта? Или скажет - "вы за это не платили, чего вы от меня хотите - будет время, поправлю".
Это тот фактор, который ограничивает распространение опенсорсного ПО среди крупных потребителей - отсутствие гарантированной поддержки. Т.е. могут взять за основу, а потом уже поддерживать и развивать своими силами, исключительно внутри себя и без оглядки на автора исходного продукта.
Значит, кто-то в банке садится и исправляет ошибку в библиотеке, а потом засылает PR в upstream. Open source работает так. В этом смысле ситуация намного лучше, чем с закрытой библиотекой.
Вопрос в том - кому-то в банке этот PR засылать куда-то нужно?
Тут и так неслабая нагрузка по чисто проектным задачам. И если взяли к себе что-то опенсорсное, то его просто перетащат в свой репозиторий и будут с ним работать тут. Это уже политика - все исходники хранятся у себя.
У нас так с исходниками нашей АБС - они выкуплены, размещены в наших репозиториях и в случае дорабатываются без согласования с разработчиками оригинала.
С опенсорсом будет точно также - если и возьмут, то поддерживать будут сами и никаких PR никто никуда отправлять не будет. Потому что дефект надо закрыть в кратчайшее время, а ждать пока согласуют PR времени ждать нет. А если не согласуют, то откатывать назад никто тут не станет и начнется расхождение в версиях.
Да, можно форкнуть проект и самим его мейнтейнить, но тогда чем дальше, тем сильнее форк будет отличаться от главной ветки, в него не будут попадать фиксы и новые фичи из апстрима. То есть вы просто добавите себе работы. Не говоря уж о том, что это неэтичное поведение - если вы используете что-то общественное, то надо также и отдавать что-то обществу.
С опенсорсом будет точно также - если и возьмут, то поддерживать будут
сами и никаких PR никто никуда отправлять не будет. Потому что дефект
надо закрыть в кратчайшее время, а ждать пока согласуют PR времени ждать нет. А если не согласуют, то откатывать назад никто тут не станет и
начнется расхождение в версиях.
Не надо натягивать сову. Зачем ждать, когда примут PR? Исправили - установили фикс у себя, когда его примут в апстрим, тогда примут. Если это нормальный фикс, то наверняка его примут, почему нет? Мейнтейнер рад, когда исправляют баги.
Да, можно форкнуть проект и самим его мейнтейнить, но тогда чем дальше, тем сильнее форк будет отличаться от главной ветки, в него не будут попадать фиксы и новые фичи из апстрима. То есть вы просто добавите себе работы. Не говоря уж о том, что это неэтичное поведение - если вы используете что-то общественное, то надо также и отдавать что-то обществу.
Именно так.
И да. Каждая новая фича (нужна она именно нам или не нужна) перед внедрением должна пройти длинную процедуру ретеста. И что делать, если новая фича ломает нашу интеграцию или не проходит нагрузочное тестирование? Опять править самим или не внедрять что опять приведет к расхождению...
Не надо натягивать сову. Зачем ждать, когда примут PR? Исправили - установили фикс у себя, когда его примут в апстрим, тогда примут. Если это нормальный фикс, то наверняка его примут, почему нет? Мейнтейнер рад, когда исправляют баги.
А если не примут? А если у мейнтейнера какое-то свое видение как надо этот баг исправлять?
В том и дело что тут очень много потенциальных проблем.
Я не против опенсорса (очень даже за если речь идет, скажем, о домашнем компе), но практика показывает что далеко не везде он хорошо "заходит". Есть области где его стараются не использовать. И отнюдь не в силу каких-то лицензионных соображений.
У нас официальные TR (technology refresh) от IBM и те сразу на прод не ставятся. Сначала месяцами на тестовых серверах обкатываются. А там TR выходит в свет после длительного и тщательного тестирования - у опенсорсников просто нет таких ресурсов.
У нас так с исходниками нашей АБС - они выкуплены, размещены в наших репозиториях и в случае дорабатываются без согласования с разработчиками оригинала.
С опенсорсом будет точно также - если и возьмут, то поддерживать будут сами и никаких PR никто никуда отправлять не будет.
Вот для того чтобы такое было возможно и необходимо прописывать механизмы покупки корпоративной лицензии, которая не предполагает открытости кода. Потому что обычные свободные лицензии они липкие, и требуют открытия производного кода. Не хотите открывать код - платите.
В большинстве случаев (пожалуй, только кроме AGPL) код надо раскрывать только при РАСПРОСТРАНЕНИИ производного продукта. И нет такого понятия "липкая лицензия", есть понятие "вирусная" - https://ru.wikipedia.org/wiki/Вирусная_лицензия
есть понятие "вирусная"
Как говорит баба Вика:
Такое название использовалось противниками копилефта (в частности, из корпорации Microsoft) для GNU General Public License по аналогии с вирусами. Они использовали этот и подобные термины «вирусная лицензия», чтобы подчеркнуть нежелательность использования или распространения кода под такой лицензией вместе с каким-либо другим кодом
AGPL и была создана в ответ на вызовы, когда вместо распространения программ стали предоставлять SaaS. Это и говорит о том, что лицензии должны меняться отвечая вызовам времени.
Так готовы платить. Но за это требуется премиальная поддержка по первому писку и глубокое тестирование каждого релиза силами производителя.
И тут мы упираемся во вторую проблему, которую я описал - отсутствие структуры централизованно осуществляющей поддержку открытого кода. Со своим прайсом на услуги. И с отчислением автору исходного кода небольших процентов. При этом код остается открытым, а оплачиваются именно дополнительные работы по коду. И по прежнему любой может скачать и использовать код "как есть" - без поддержки.
Интересно, также, что пока вроде такое ни разу не произошло ☝️. Hartbleed, наверное, потянет на пример такой совсем суровой уязвимости, распространение библиотеки тут тоже вопросов не возникает, но чтобы это привело прям к жёстким финансовым потерям? Такое вообще бывало хоть?
Потом, всп то же самое будет и в случае проприетарного софта в аналогичной ситуации. Не знаю ни одной EULA проприетарной, где они обязуется аозмещать убытки. У них там наоборот - указан отказ от ответственности обычно, разве нет?
Это проблема всех, кто пытается поделиться с широкой публикой плодами своей работы. Просто, в качестве примера. Кто-то искал решение своей проблемы (конечно, технической) в интернете, но готовое не нашел. Решил, как мог. Подумал, что раз не нашёл "рецепт" сам, то такого нет и почему бы не написать статью? По сути, мог просто выложить код решения в публичном доступе, но решил оформить в виде именно статьи на специализированном ресурсе. Написал. Нахватал минусов за недостаточно эффективно решение, за изобретение велосипеда, за попытку "отгавкаться" от нравоучений и "указать дорогу в сад". Плакать в подушку автор не станет, но в следующий раз он просто оставит все при себе.
Я такие статьи вижу 1- 2 раза в неделю. С высокой долей вероятности, можно сказать, что очередной open source "проект" благополучно прибивается в зародыше.
Нахватал минусов за недостаточно эффективно решение, за изобретение велосипеда, за попытку "отгавкаться" от нравоучений и "указать дорогу в сад".
Вот это меня удивляет больше всего в комьюнити Хабра. Казалось бы, айти - это сфера, где всегда есть место новаторству и нестандартным подходам, которые вполне могут выстрелить в нестандартных условиях.
Но при этом стоит какому-нибудь автору хоть что-нибудь реализовать нестандартно, не так, "как заведено у всех", то комментаторы его просто заплюют всей толпой. Даже если именно в кейсе, описанном автором, такое решение действительно будет хорошим, а то и одним из лучшим.
Вера в идеальность уже существующих инструментов и библиотек доведена до абсурда. Подключать, например, библиотеку ради функции в одну строку для них норма, а вот написать своё - это сразу "вон из профессии". И даже история с left-pad их ничему не научила.
Поневоле вспоминается мем про "американские и русские форумы". В котором на американском тебе подробно ответят на вопрос и пожелают удачи, а на русском - подробно объяснят, почему ты идиот и не лечишься. Блин, это мем из нулевых, а с тех пор ничего не изменилось...
Начало вроде бы логичное, когда автор начинает с оценки своих эмоций от цитаты в Твиттере.
Потом же сам пишет, что термин Open Source очень многогранен и под одним и тем же термином каждый понимает (может понимать), что-то свое, важное только конкретно для него. Кому-то статус или слава, кому-то банальные деньги, а кому-то бизнес или предложение о работе.
Из-за этого и "здоровый баланс" одного человека не обязательно будет равен "здоровому балансу" другого. Если честно, то я так ничего и не понял, что хотел сказать автор.
Темная сторона Open Source