Отличная статья про участие в разработке OpenSource проекта.
У многих совершенно неверное представление о сообществе OpenSource и участии в разработке крупных проектов. Удивительно, как вышло, что OpenSource community без всякого PR (public relations) умудрились создать себе репутацию, которая рядом не лежала с реальностью. Для многих OpenSource — нечто белое и пушистое. На словах: "участвуйте в разработке открытых проектов, мы вам поможем, расскажем, покажем, направим, присылайте Push Request'ы, мы их отрецензируем и примем"...
Ага, щас. На деле в OpenSource ты нафиг никому не нужен. Почти везде тебе никто ничего не будет рассказывать (даже если спросишь) — разбирайся сам (9 из 10 разработчиков ответят, что у них нет времени или вообще не ответят). Твой PR никому не нужен, вместо рецензии на него ты легко можешь получить кучу пурги, не имеющей к нему никакого отношения (чувак тупо не разобрался, что делает твой PR, но к чему-то придрался, потому что PR расходится с его представлениями о прекрасном), когда ты поправишь PR кто-то другой докопается еще до чего-то (или предложит все вернуть обратно). Совсем забавно, когда эти двое начнут рассказывать, что PR в принципе можно принять, но все это они делают, чтобы "сэкономить твое время" (причем, на территории СНГ лицемерие еще только развивается, а на западе оно давно на грани полнейшей шизы, когда говорят одно, а делают ровно противоположное и это противоречие очевидно). Также, есть куча умников, которые воспринимают тезис "в OpenSource тебе никто ничего не должен" таким образом, что с тобой даже разговаривать по человечески не обязаны и могут просто послать на... потому что их подход "я в проекте царь и бох, поэтому творю, что хочу" (в коммерческой разработке против этого есть тормоза — тут бывает полный беспредел). В результате, чтобы добавить свой код в OpenSource проект (далеко не с первой попытки) придется потратить довольно много усилий и большую часть не на разработку.
Разумеется, все проекты разные и правила в них разные, но обычно проще поддерживать свой форк, чем пытаться передать код в OpenSource проект (и чем крупнее проект, тем больше бюрократии). При этом у крупного бизнеса с этим никаких сложностей. У них либо ведущие разработчики на зарплате, либо они найдут к ним подход и могут, даже, добавить в проект не работающий код (а в это время твой PR в соседней ветке будут "критиковать" по любому поводу, а повод всегда найдется).
В общем, мой посыл:
OpenSource далеко не такой белый и пушистый, как многим кажется, и нужно воспринимать его более реалистично.
Участие в разработке OpenSource проектов полезно, как для повышения технических навыков, так и для мировоззрения (в смысле более реалистично начинаешь смотреть на вещи, различаешь слова и реальность).
как то подавался на одну вакансию родом из мск, а попой в сфба
у них продукт опенсорс
собеседование из двух слов
ну вот у нас на гитхабе полно открытых тикетов по продукту
вы с годик поопенсорсте наш продукт на дурняк(денег платить не будем)
а через годик мы вас может быть на полную ставку в компанию возьмем
Здравствуйте, Reset, Вы писали:
R>При этом у крупного бизнеса с этим никаких сложностей. У них либо ведущие разработчики на зарплате, либо они найдут к ним подход и могут, даже, добавить в проект не работающий код (а в это время твой PR в соседней ветке будут "критиковать" по любому поводу, а повод всегда найдется).
Главная и основная цель существования Open Source — это уничтожение малого бизнеса в айти (кто помнит watcom c compiler?), защита крупного бизнеса от опасности, что мелкий их потеснит, уничтожение самого рынка для малого бизнеса и снижение затрат для крупного бизнеса — так бы они были вынуждены поддерживать свои собственные компиляторы, платить специалистам по компиляторам, а не индусам за фронтенд, а сейчас у них есть общий gcc и специалистов нужно меньше.
Здравствуйте, Reset, Вы писали:
R>Отличная статья про участие в разработке OpenSource проекта.
И исходная статья, и этот топик однобоко рассматривают open source с точки зрения стороннего контрибьютора — но не со стороны мейнтейнера.
На последнюю тему могу предложить доклад Адама Ситника (там ближе к концу раздел «The bad part of being the maintainer»).
Opensource, как и всё что долго живёт, прошло и проходит несколько существенно разных этапов.
Первый — когда ранний FSF Столлмана делал gcc и комплекты юзерских утилит, он просто реализовывал открыто то, что реально стоило уже ничего, но никто пока не решился сделать открытую версию — но вместо этого фирмы, полные некомпетентных разработчиков, продавали дерьмовые продукты за тонны нефти. Один gcc убил десятки коммерческих компиляторов — просто потому, что они стали тупо бессмысленны, и выживали те, что реально начали превосходить по качеству.
Но бо́льшая часть продуктов спокойно могла быть сделана одним человеком без напряга, часто в свободное время, и делалась (примеров масса — gcc ранний, groff, почти весь софт Internet вроде почтовиков...) Для передовых продуктов это 80-е и часть 90-х.
(Реально можно ещё считать нулевой — когда не оформилась схема продажи софта, потому что он был неотъемлем от железа — но это было ad-hoc и без идеологии. Поэтому его пропустим.)
Второй — это когда поднялась сложность и началась потребность работать командами и вкладывать существенные деньги в развитие, для анализа подходов, сбора требований, оптимизации и повышения производительности. Примеры — Linux, FreeBSD, apache, nginx. Для флагманских продуктов это 90-е и 2000-е. Уже в начале этого пути собралась полноценная экосистема, которая спокойно бы выжила и была способна обслужить потребителей всех видов, если бы весь прочий софт мистически исчез — как минимум на 1995 это было бы тяжёлый вой, на 2000 просто вой, но ничего фатального для прогресса не случилось бы.
Третий — наблюдаем сейчас — когда у флагманских продуктов настолько высокая сложность, что требуются уже серьёзные усилия на организацию проектов и затраты на развитие. Как правило, играют бизнес-модели разного типа — кто-то на коммерческой поддержке, кто-то на параллельной более богатой версии, кто-то на требовании обратного вклада от кастомизаторов, которые зарабатывают на своих услугах; часто это комбинируется.
Проблемы, описанные вами, происходят из нескольких факторов:
1. Ниш, где бы подошёл подход первого этапа, уже нет (как обычно, любое обобщение считать правильным на 95-99%, включая это). Новые ниши могут быть открыты только коллективами. Старые все покрыты как проприетарщиной, так и opensource. Прорывы-исключения редки.
2. Человеческие коллективы страдают от общеизвестных человеческих проблем, но в отсутствие работающей регуляции усиливаются — а если у продукта координация страдает, то это становится очень хорошо видимым.
R>Ага, щас. На деле в OpenSource ты нафиг никому не нужен. Почти везде тебе никто ничего не будет рассказывать (даже если спросишь) — разбирайся сам (9 из 10 разработчиков ответят, что у них нет времени или вообще не ответят). Твой PR никому не нужен, вместо рецензии на него ты легко можешь получить кучу пурги, не имеющей к нему никакого отношения (чувак тупо не разобрался, что делает твой PR, но к чему-то придрался, потому что PR расходится с его представлениями о прекрасном), когда ты поправишь PR кто-то другой докопается еще до чего-то (или предложит все вернуть обратно). Совсем забавно, когда эти двое начнут рассказывать, что PR в принципе можно принять, но все это они делают, чтобы "сэкономить твое время" (причем, на территории СНГ лицемерие еще только развивается, а на западе оно давно на грани полнейшей шизы, когда говорят одно, а делают ровно противоположное и это противоречие очевидно). Также, есть куча умников, которые воспринимают тезис "в OpenSource тебе никто ничего не должен" таким образом, что с тобой даже разговаривать по человечески не обязаны и могут просто послать на... потому что их подход "я в проекте царь и бох, поэтому творю, что хочу" (в коммерческой разработке против этого есть тормоза — тут бывает полный беспредел). В результате, чтобы добавить свой код в OpenSource проект (далеко не с первой попытки) придется потратить довольно много усилий и большую часть не на разработку.
Про "в коммерческой разработке против этого есть тормоза" — рассказывайте тем, кто поверит в эти сказки. Многолетнее наплевательство на жалобы клиентов потому, что не смогли убедить пня в руководстве, или до верха просто не дошли плачи — это норма. Только в случае opensource вы можете хотя бы форкнуть. А с проприетарщиной и этой возможности нет.
Проблема в общем, конечно, есть — на того, кто работает не за деньги, а за собственный интерес, надо влиять не деньгами, а этически и морально — а интересы, этика и мораль у всех разные, в отличие от денег, которые универсальны. Но, повторюсь, открытость кода спасает. Случаи, когда тот, кому отказали в осмысленном пожелании, делал форк и перетягивал основную прежнюю команду — уже исчисляются десятками и сотнями.
R>Разумеется, все проекты разные и правила в них разные, но обычно проще поддерживать свой форк, чем пытаться передать код в OpenSource проект (и чем крупнее проект, тем больше бюрократии).
Бюрократия необходима для защиты от юридического хакерства захватчиков, а не сама по себе.
R> При этом у крупного бизнеса с этим никаких сложностей. У них либо ведущие разработчики на зарплате, либо они найдут к ним подход и могут, даже, добавить в проект не работающий код (а в это время твой PR в соседней ветке будут "критиковать" по любому поводу, а повод всегда найдется).
Агащазз. Если твоё предложение идёт вразрез с общим подходом — будет то же самое.
R>* OpenSource далеко не такой белый и пушистый, как многим кажется, и нужно воспринимать его более реалистично.
Реалистично надо воспринимать всегда. Но подход идёт миру в целом на пользу.
R> Участие в разработке OpenSource проектов полезно, как для повышения технических навыков, так и для мировоззрения (в смысле более реалистично начинаешь смотреть на вещи, различаешь слова и реальность).
Да. Это лучше, чем цинизм, которого наберёшься при работе на крупного частного диверсанта.
Здравствуйте, Reset, Вы писали:
GIV>>Офигеть, чел научился git merge делать.
R>Скорее rebase, rebase -i, cherry-pick и много чего другого (ты же в курсе, да, что merge conflicts бывают и в rebase тоже).
R>Это у коммерсантов многие даже лиды дальше merge не продвинулись.
Это только говорит о том, что процессы в компании работают как надо. А вот если на проекте все мастера черри-пика и разрешения конфликтов то тут как раз повод задуматься.
N>Про "в коммерческой разработке против этого есть тормоза" — рассказывайте тем, кто поверит в эти сказки. Многолетнее наплевательство на жалобы клиентов потому, что не смогли убедить пня в руководстве, или до верха просто не дошли плачи — это норма. Только в случае opensource вы можете хотя бы форкнуть.
Не понимаю, как люди говорят про одни сказки, и тут же начинают рассказывать другие. Причем прямо в тексте про сложность проектов и необходимости команд для работы над ними. Много ли мало-мальски сложных опенсорсов проектов действительно хоть кем-то форкнуты (и дальше развиваются). Доли процента.
Абсолютно стандартная ситуация: опенсорс так же забивает большой и толстый болт на любые чаяния кого бы то ни было. В случае с коммерческим софтом у тебя хоть есть возможность заплатить, чтобы тебе что-то сделали (на самом деле, это тоже в большой степени сказка).
Самый наглядный пример, от которого мы страдаем (на самом деле не страдаем) уже год — Google Dataflow, который построен на Apache Beam. Официально поддерживаемая версия — Java 8, поддержка которой закончилась год тому назад. Стоит ли говорить, что Java 11, которая LTS, выпущена в сентябре 2018, а поддержка ее — до сих пор находится на Roadmap'е и пока даже близко не видно, когда она будет реализована. Я вот прям вижу, как наша компания с 80 разработчиками все бросает, форкает этот проект и следующие два года пилит поддержку Java 11. А потом, видать, пытается свой форк протолкнуть в Гугл.
N>>Про "в коммерческой разработке против этого есть тормоза" — рассказывайте тем, кто поверит в эти сказки. Многолетнее наплевательство на жалобы клиентов потому, что не смогли убедить пня в руководстве, или до верха просто не дошли плачи — это норма. Только в случае opensource вы можете хотя бы форкнуть.
M>Не понимаю, как люди говорят про одни сказки, и тут же начинают рассказывать другие. Причем прямо в тексте про сложность проектов и необходимости команд для работы над ними. Много ли мало-мальски сложных опенсорсов проектов действительно хоть кем-то форкнуты (и дальше развиваются). Доли процента.
Одно дело форкнуть и развивать другое дело форкнуть и пофиксить баг. Я так делал (тоже апачевский проект). Параллельно отправил патч, когда его залили и срелизили (через год) я удалил форк.
Этот год мы жили с форком, я туда пару раз смержил обновления (CVE всякие в основном). Для фикса CVE тоже форкал бывало и затыкал, но там майнтейнеры сами нормальный фикс вскоре выпускали без моего участия.
Здравствуйте, Reset, Вы писали:
R>Ага, щас. На деле в OpenSource ты нафиг никому не нужен.
В данном хабре речь идёт о софте, который разрабатывается консорциумом компаний. Его пишут разработчики, которым платят зарплату и у которых есть сроки и планы. Так как там участвует куча компаний, то и появилась соответствующая бюрократия.
Здравствуйте, reversecode, Вы писали:
R>у ваткома была узкая ниша прибитая гвоздями к досу, который он сильно расширял по ресурсам R>дос умер и вместе с ним ватком
Здравствуйте, sergey2b, Вы писали:
S>Здравствуйте, reversecode, Вы писали:
R>>у ваткома была узкая ниша прибитая гвоздями к досу, который он сильно расширял по ресурсам R>>дос умер и вместе с ним ватком
S>что не так было с Borland C++
С ним было все не так
Под занавес (я именно про Borland C++, а не BCB), он превратился в лютый ужоснах.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
GIV> А вот если на проекте все мастера черри-пика и разрешения конфликтов то тут как раз повод задуматься.
В случае Open Source проекта — владение cherry-pick объективная необходимость (и я это утверждаю без какого-либо негатива). Когда ты один из основных разработчиков в Open Source проекте — у тебя нет сложностей добавить туда любой код (на самом деле у тебя одна сложность — недостаток времени, ибо такие люди впахивают по 160 часов в неделю и могут делать десятки коммитов в день). А если ты обычный контрибьютор — твой PR может пролежать пару месяцев пока до него дойдут проверяющие и тут либо ты проявишь чудеса rebase -i и cherry-pick (потому что HEAD ушел далеко вперед, а PR не rebase'ится на HEAD), либо твой PR не будут даже проверять (потому что он никому не нужен). У коммерсантов такие фокусы не нужны — там по-другому устроены процессы.
R>>Ага, щас. На деле в OpenSource ты нафиг никому не нужен. C>В данном хабре речь идёт о софте, который разрабатывается консорциумом компаний. Его пишут разработчики, которым платят зарплату и у которых есть сроки и планы. Так как там участвует куча компаний, то и появилась соответствующая бюрократия.
В данном проекте одни причины для бюрократии, в другом — другие, но в результате в сколько-нибудь крупном Open Source проекте бюрократия — скорее правило, чем исключение.
P.S. Для меня бюрократия — это неоправданные сложности. Если у админов/мейнтейнеров в Open Source проектах не хватает времени и тот же login для sso тебе создают неделю или требуют что-то подписать по понятной причине — это не имеет отношения к бюрократии. А вот когда чувак с синдромом вахтера начинает придираться и требовать от тебя чего-то неразумного — вот это напрягает и после очередной итерации вызывает вопрос: "А зачем мне все это нужно, если есть способы попроще?"
Здравствуйте, Reset, Вы писали:
GIV>> А вот если на проекте все мастера черри-пика и разрешения конфликтов то тут как раз повод задуматься.
R>В случае Open Source проекта — владение cherry-pick объективная необходимость (и я это утверждаю без какого-либо негатива). Когда ты один из основных разработчиков в Open Source проекте — у тебя нет сложностей добавить туда любой код (на самом деле у тебя одна сложность — недостаток времени, ибо такие люди впахивают по 160 часов в неделю и могут делать десятки коммитов в день). А если ты обычный контрибьютор — твой PR может пролежать пару месяцев пока до него дойдут проверяющие и тут либо ты проявишь чудеса rebase -i и cherry-pick (потому что HEAD ушел далеко вперед), либо твой PR не будут даже проверять (потому что он никому не нужен). У коммерсантов такие фокусы не нужны — там по-другому устроены процессы.
Именно это я и имел ввиду. Такое и у комерсов бывает если делать по бранчу на кастомера, пилить ему уникальные фичи и еще как-то что-то из baseline тащить.
M>>Не понимаю, как люди говорят про одни сказки, и тут же начинают рассказывать другие. Причем прямо в тексте про сложность проектов и необходимости команд для работы над ними. Много ли мало-мальски сложных опенсорсов проектов действительно хоть кем-то форкнуты (и дальше развиваются). Доли процента.
GIV>Одно дело форкнуть и развивать другое дело форкнуть и пофиксить баг.
Этим тоже занимаются доли процентов
GIV>Я так делал (тоже апачевский проект). Параллельно отправил патч, когда его залили и срелизили (через год) я удалил форк. GIV>Этот год мы жили с форком, я туда пару раз смержил обновления
Что бы ты делал, если бы патч замержили не через год, а через пять. Или не смерджили?
Вообще, почти в каждой компании находится какой-то код или обертка над кодом, которая «мы тут внутренне форкнули потому что нам надо то-то и то-то». Через год-два-пять обычно приходится тормозить работу одного-двух отделов, избавляться от внутреннего форка или обертки потому что никто ее не поддерживает, апстрим ускакал в неведомые дали, человек, который когда-то это сделал, уже уволился и никто не знает, как это поддерживать.
Здравствуйте, Mamut, Вы писали:
M>Не понимаю, как люди говорят про одни сказки, и тут же начинают рассказывать другие.
M>Абсолютно стандартная ситуация: опенсорс так же забивает большой и толстый болт на любые чаяния кого бы то ни было. В случае с коммерческим софтом у тебя хоть есть возможность заплатить, чтобы тебе что-то сделали (на самом деле, это тоже в большой степени сказка).
M>Самый наглядный пример, от которого мы страдаем (на самом деле не страдаем) уже год — Google Dataflow, который построен на Apache Beam. Официально поддерживаемая версия — Java 8, поддержка которой закончилась год тому назад. Стоит ли говорить, что Java 11, которая LTS, выпущена в сентябре 2018, а поддержка ее — до сих пор находится на Roadmap'е и пока даже близко не видно, когда она будет реализована. Я вот прям вижу, как наша компания с 80 разработчиками все бросает, форкает этот проект и следующие два года пилит поддержку Java 11. А потом, видать, пытается свой форк протолкнуть в Гугл.
Очаровательно. Я уж не вспоминаю, что в Java мире до сих пор половина энтерпрайза сидит на Java 6 или 7, а 8 для них это нечто новое и неожиданное; а вы тут про 11 говорите. Что там оракл говорит про потерю поддержки — вопрос десятый, от них эту поддержку всё равно как-то выбивают, или обеспечивают сами. Просто вот скажите — вы пробовали предложить им деньги за обновление, если считаете, что оно вам реально нужно? И зачем вам на самом деле Java 11? Может, это просто бессмысленная хотелка?
Здравствуйте, Mamut, Вы писали:
M>>>Не понимаю, как люди говорят про одни сказки, и тут же начинают рассказывать другие. Причем прямо в тексте про сложность проектов и необходимости команд для работы над ними. Много ли мало-мальски сложных опенсорсов проектов действительно хоть кем-то форкнуты (и дальше развиваются). Доли процента.
GIV>>Одно дело форкнуть и развивать другое дело форкнуть и пофиксить баг.
M>Этим тоже занимаются доли процентов
Доли процента от кого? От всех разрабов? Наверно, я нашей конторе только я этим занимался, остальные N штук использовали. В других проектах тоже видел патченые сборки, но уже я ими не занимался. Так что да, согласен, доли процента если от разрабов считать.
GIV>>Я так делал (тоже апачевский проект). Параллельно отправил патч, когда его залили и срелизили (через год) я удалил форк. GIV>>Этот год мы жили с форком, я туда пару раз смержил обновления
M>Что бы ты делал, если бы патч замержили не через год, а через пять. Или не смерджили?
Через пять контора сдохла и вопрос с форком решился бы сам собой
M>Вообще, почти в каждой компании находится какой-то код или обертка над кодом, которая «мы тут внутренне форкнули потому что нам надо то-то и то-то». Через год-два-пять обычно приходится тормозить работу одного-двух отделов, избавляться от внутреннего форка или обертки потому что никто ее не поддерживает, апстрим ускакал в неведомые дали, человек, который когда-то это сделал, уже уволился и никто не знает, как это поддерживать.
Вот я именно про то что почти в каждой компании такая хрень. А так ты прав, эти форки есть зло
Здравствуйте, Reset, Вы писали:
C>>В данном хабре речь идёт о софте, который разрабатывается консорциумом компаний. Его пишут разработчики, которым платят зарплату и у которых есть сроки и планы. Так как там участвует куча компаний, то и появилась соответствующая бюрократия. R>В данном проекте одни причины для бюрократии, в другом — другие, но в результате в сколько-нибудь крупном Open Source проекте бюрократия — скорее правило, чем исключение.
Потому, что без бюрократии получается хаос. Печально, но факт.
R>P.S. Для меня бюрократия — это неоправданные сложности. Если у админов/мейнтейнеров в Open Source проектах не хватает времени и тот же login для sso тебе создают неделю или требуют что-то подписать по понятной причине — это не имеет отношения к бюрократии.
Нынче почти все переползли на Github, так что эта проблема отпала.
R>А вот когда чувак с синдромом вахтера начинает придираться и требовать от тебя чего-то неразумного — вот это напрягает и после очередной итерации вызывает вопрос: "А зачем мне все это нужно, если есть способы попроще?"
Ну вот стань мэйнтейнером — тогда поймёшь.
M>Java 8, поддержка которой закончилась
Эмм... поддержка кем/чем?
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Mamut, Вы писали:
M> Самый наглядный пример, от которого мы страдаем (на самом деле не страдаем) уже год — Google Dataflow, который построен на Apache Beam.... Я вот прям вижу, как наша компания с 80 разработчиками все бросает,
Непонятно какое это всё имеет отношение собственно к opensource. Такая же ситуация хоть даже может быть в одной компании. Используете вы какую-нибудь библиотеку для построения отчётов, написанную 5 лет назад бангалорской командой, которая уже давно разбежалась, бюджет давно распилили, clearcase репозиторий с исходниками потеряли, а то что таки удалось наскрести из бэкапов даже не собирается и очень похоже, что исходник даже не соответствует версии релиза. Или вроде команда даже как бы есть, но занята Важными Задачами, а переход на 11 у них бюджета нет и митинг для обсуждения плана организации процесса исследования возможностей миграции в очередной раз уже второй раз перенесён на следующее полугодие.
Всё то же самое или даже хуже.
Здравствуйте, ·, Вы писали:
·>Непонятно какое это всё имеет отношение собственно к opensource. Такая же ситуация хоть даже может быть в одной компании.
Здравствуйте, Codealot, Вы писали:
C> ·>Непонятно какое это всё имеет отношение собственно к opensource. Такая же ситуация хоть даже может быть в одной компании. C> В компании тебе хотя бы платят за работу.
Ты по-моему не в тему. Напомню контекст "как наша компания с 80 разработчиками все бросает, форкает этот проект и следующие два года пилит поддержку Java 11!"
В любом случае, плата за работу тоже никакого отношения к опенсорс не имеет. К примеру, упомянутый тут выше Google Flow предполагаю написан разработчиками Google, которые вряд ли работают бесплатно.
Здравствуйте, ·, Вы писали:
·>Ты по-моему не в тему. Напомню контекст "как наша компания с 80 разработчиками все бросает, форкает этот проект и следующие два года пилит поддержку Java 11!"
Ты по моему уже сам забыл, что писал.
Если они хотят пилить на старой версии — ради Б-га, любой каприз за ваши деньги.
·>В любом случае, плата за работу тоже никакого отношения к опенсорс не имеет. К примеру, упомянутый тут выше Google Flow предполагаю написан разработчиками Google, которые вряд ли работают бесплатно.
Здравствуйте, Codealot, Вы писали:
C>·>Ты по-моему не в тему. Напомню контекст "как наша компания с 80 разработчиками все бросает, форкает этот проект и следующие два года пилит поддержку Java 11!" C>Ты по моему уже сам забыл, что писал.
Ты наверное не так понял мои слова. И я затрудняюсь сказать, что тебе непонятно, т.к. ты вопросы не задаёшь, а говоришь какие-то вещи не в тему.
C>Если они хотят пилить на старой версии — ради Б-га, любой каприз за ваши деньги.
Из текста Mamut у меня сложилось впечатление, что они взяли продукт забесплатно, поняли что он их немного не устраивает и возмущаются, что их хотелку волшебно делать нахаляву никто не собирается, все 80 разработчиков очень заняты, и виноват во всём конечно же сабж. Бывает.
Многие путают понятие "опенсорс" и "халява", вот я и попытался сделать ликбез.
C>·>В любом случае, плата за работу тоже никакого отношения к опенсорс не имеет. К примеру, упомянутый тут выше Google Flow предполагаю написан разработчиками Google, которые вряд ли работают бесплатно. C>Они — нет. Обычный средний красноглазик — да.
Какой такой средний красноглазик? Примеры в студию. Как раз большинство популярных опенсорсов пилят для работы, за которую получают деньги.
Бывают, конечно случаи "запилю себе штуку сам, т.к. платить $$$$ за ту хню не хочу" — это экономия денег. В крайнем случае работают на резюме или в надежде продаться стартапом.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Ты наверное не так понял мои слова. И я затрудняюсь сказать, что тебе непонятно, т.к. ты вопросы не задаёшь, а говоришь какие-то вещи не в тему.
Затрудняешься понять или просто не хочешь?
Я просто процитирую:
Используете вы какую-нибудь библиотеку для построения отчётов, написанную 5 лет назад бангалорской командой, которая уже давно разбежалась, бюджет давно распилили, clearcase репозиторий с исходниками потеряли, а то что таки удалось наскрести из бэкапов даже не собирается и очень похоже, что исходник даже не соответствует версии релиза. Или вроде команда даже как бы есть, но занята Важными Задачами, а переход на 11 у них бюджета нет и митинг для обсуждения плана организации процесса исследования возможностей миграции в очередной раз уже второй раз перенесён на следующее полугодие.
Всё то же самое или даже хуже.
Намекаю — делать всю ту же самую неприятную работу всё же менее неприятно, когда тебе за нее платят.
·>Как раз большинство популярных опенсорсов пилят для работы, за которую получают деньги.
большинство популярных опенсорсов, или большинство разработчиков в этих популярных опенсорсах?
Здравствуйте, Codealot, Вы писали:
C>·>Ты наверное не так понял мои слова. И я затрудняюсь сказать, что тебе непонятно, т.к. ты вопросы не задаёшь, а говоришь какие-то вещи не в тему. C>Намекаю — делать всю ту же самую неприятную работу всё же менее неприятно, когда тебе за нее платят.
Я не понимаю на что конкретно ты намекаешь. Как я понял, Mamut работает в компании, и я предположил, что ему за это платят. Кто кому не платит за работу в обсуждаемой ситуации? Ты можешь выражаться ясно, прямо, без хитровывернутых намёков?
C>·>Как раз большинство популярных опенсорсов пилят для работы, за которую получают деньги. C>большинство популярных опенсорсов, или большинство разработчиков в этих популярных опенсорсах?
Чё? Получать деньги могут только человеки, разработчикы т.е.
[Опенсорс] проекты — не люди, им деньги ни к чему.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
C>>Если они хотят пилить на старой версии — ради Б-га, любой каприз за ваши деньги. ·>Из текста Mamut у меня сложилось впечатление, что они взяли продукт забесплатно, поняли что он их немного не устраивает и возмущаются, что их хотелку волшебно делать нахаляву никто не собирается, все 80 разработчиков очень заняты, и виноват во всём конечно же сабж. Бывает.
Мы взяли проект, за который Гуглу платим золотой уровень поддержки. Бесплатный проект взяли Гугл и на нем построили один из своих сервисов. Но ни то ни другое не имеет отношение к сказкам про «в крайнем случае можно форкнуть». Предлагаю тебе взять и форкнуть Apache Beam. Что там, плевое же дело. Форкнул, переписал то, что нужно, так ведь?
Здравствуйте, Mamut, Вы писали:
M> ·>Из текста Mamut у меня сложилось впечатление, что они взяли продукт забесплатно, поняли что он их немного не устраивает и возмущаются, что их хотелку волшебно делать нахаляву никто не собирается, все 80 разработчиков очень заняты, и виноват во всём конечно же сабж. Бывает. M> Мы взяли проект, за который Гуглу платим золотой уровень поддержки. Бесплатный проект взяли Гугл и на нем построили один из своих сервисов. Но ни то ни другое не имеет отношение к сказкам про «в крайнем случае можно форкнуть». Предлагаю тебе взять и форкнуть Apache Beam. Что там, плевое же дело. Форкнул, переписал то, что нужно, так ведь?
Плёвое дело по сравнению с чем? Если бы вместо Apache Beam был бы какой-нибудь IBM SuperPuperFramework — было бы проще попросить IBM сделать это для вас нахаляву?
Впрочем, форкать даже необязательно, делайте контрибуцию в https://issues.apache.org/jira/browse/BEAM-2530 и счастье наступит быстрее.
Просто плевое дело.
·>Если бы вместо Apache Beam был бы какой-нибудь IBM SuperPuperFramework — было бы проще попросить IBM сделать это для вас нахаляву?
Удивительно, как ты за меня говоришь мои же аргументы.
·>Впрочем, форкать даже необязательно, делайте контрибуцию в https://issues.apache.org/jira/browse/BEAM-2530 и счастье наступит быстрее.
Угу. И мы будем делать контрибуцию туда ... как? У нас примерно ноль специалистов по Apache Beam'у. Ну и не забываем, что кроме Apache Beam'а есть еще вагон и маленькая тележка технологий, в которых существуют разнообразные проблемы. Согласно тебе и прочим сказочникам, ничего не стоит форкнуть или законтрибютить в каждый из них, так ведь? Остается нерешенным вопрос: а когда основную работу-то делать?
Здравствуйте, Mamut, Вы писали:
M>·>Плёвое дело по сравнению с чем? M>Просто плевое дело.
А смысл-то ты в это какой-нибудь вкладываешь? Или так, просто, фигура речи для экспрессии? В чём суть твоей речи, просто поворчать о кривости софта?
M>·>Впрочем, форкать даже необязательно, делайте контрибуцию в https://issues.apache.org/jira/browse/BEAM-2530 и счастье наступит быстрее. M>Угу. И мы будем делать контрибуцию туда ... как? У нас примерно ноль специалистов по Apache Beam'у. Ну и не забываем, что кроме Apache Beam'а есть еще вагон и маленькая тележка технологий, в которых существуют разнообразные проблемы.
Вот опять. Причём тут сабж-то?
M>Согласно тебе и прочим сказочникам, ничего не стоит форкнуть или законтрибютить в каждый из них, так ведь?
Про "ничего не стоит" это твои личные фантазии и вера в халяву.
M>Остается нерешенным вопрос: а когда основную работу-то делать?
Что значит "основную"? Выкиньте этот ужасный Beam и работайте свою работу. Кто мешает-то? Так ведь вам придётся в список основной работы включить создание аналога Beam или потратить кучу бабла чтобы купить готовое, и специалистов соответствующих обучить/нанять... А то что вам задёшево удалось быстро сфарганить работающее приложение на основе Beam, выйти на рынок и заработать — это вам просто все были должны!
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
M>>Просто плевое дело. ·>А смысл-то ты в это какой-нибудь вкладываешь?
Почему ты меня спрашиваешь? Это ты предлагаешь «просто законтрибьютить» ::xz
M>>·>Впрочем, форкать даже необязательно, делайте контрибуцию в https://issues.apache.org/jira/browse/BEAM-2530 и счастье наступит быстрее. M>>Угу. И мы будем делать контрибуцию туда ... как? У нас примерно ноль специалистов по Apache Beam'у. Ну и не забываем, что кроме Apache Beam'а есть еще вагон и маленькая тележка технологий, в которых существуют разнообразные проблемы. ·>Вот опять. Причём тут сабж-то?
Не удивительно, что ты не понимаешь.
M>>Остается нерешенным вопрос: а когда основную работу-то делать? ·>Что значит "основную"? Выкиньте этот ужасный Beam и работайте свою работу. Кто мешает-то? Так ведь вам придётся в список основной работы включить создание аналога Beam или потратить кучу бабла чтобы купить готовое, и специалистов соответствующих обучить/нанять... А то что вам задёшево удалось быстро сфарганить работающее приложение на основе Beam, выйти на рынок и заработать — это вам просто все были должны!
Я где-то пишу о том, что нам все должны? Нет. Я пишу ровно одно:
N> Только в случае opensource вы можете хотя бы форкнуть.
Не понимаю, как люди говорят про одни сказки, и тут же начинают рассказывать другие. Причем прямо в тексте про сложность проектов и необходимости команд для работы над ними. Много ли мало-мальски сложных опенсорсов проектов действительно хоть кем-то форкнуты (и дальше развиваются). Доли процента.
И твое «Впрочем, форкать даже необязательно, делайте контрибуцию в» — это такая же сказка.
Здравствуйте, Mamut, Вы писали:
M>>>Просто плевое дело. M>·>А смысл-то ты в это какой-нибудь вкладываешь? M>Почему ты меня спрашиваешь? Это ты предлагаешь «просто законтрибьютить» ::xz
Не сочиняй, "Просто" тут тебе никто не обещал, вроде, я уж точно не обещал. Про "плёвость" тут только ты говоришь.
M>·>Вот опять. Причём тут сабж-то? M>Не удивительно, что ты не понимаешь.
Так объясни.
M>>>Остается нерешенным вопрос: а когда основную работу-то делать? M>·>Что значит "основную"? Выкиньте этот ужасный Beam и работайте свою работу. Кто мешает-то? Так ведь вам придётся в список основной работы включить создание аналога Beam или потратить кучу бабла чтобы купить готовое, и специалистов соответствующих обучить/нанять... А то что вам задёшево удалось быстро сфарганить работающее приложение на основе Beam, выйти на рынок и заработать — это вам просто все были должны! M>Я где-то пишу о том, что нам все должны? Нет. Я пишу ровно одно:
N>> Только в случае opensource вы можете хотя бы форкнуть.
M>Не понимаю, как люди говорят про одни сказки, и тут же начинают рассказывать другие. Причем прямо в тексте про сложность проектов и необходимости команд для работы над ними. Много ли мало-мальски сложных опенсорсов проектов действительно хоть кем-то форкнуты (и дальше развиваются). Доли процента.
Я не вижу тут сути возражения, кроме ворчания, что не всегда находятся желающие за вас вашу работу работать забесплатно.
Если у вас есть определённое требование к Beam, то организуйте команду у себя, сабж только поможет.
M>И твое «Впрочем, форкать даже необязательно, делайте контрибуцию в» — это такая же сказка.
Почему сказка я так и не понял. А какова реальность? И какое влияние тут оказывает сабж? Тем, что даёт хотя бы возможность форков/контрибуции? И начинает подгорать, что возможность вроде как есть, но воспользоваться ею вам компания не хочет давать?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Mamut, Вы писали:
M>Мы взяли проект, за который Гуглу платим золотой уровень поддержки. Бесплатный проект взяли Гугл и на нем построили один из своих сервисов. Но ни то ни другое не имеет отношение к сказкам про «в крайнем случае можно форкнуть». Предлагаю тебе взять и форкнуть Apache Beam. Что там, плевое же дело. Форкнул, переписал то, что нужно, так ведь?
Ну я вот так именно так и делал для нескольких продуктов внутри Амазона. В этом конкретном случае, Apache Beam работает на JDK11, но требует JDK8 для сборки. Я что-то не вижу чего-то суперплохого.
Здравствуйте, Слава, Вы писали:
С>Главная и основная цель существования Open Source — это уничтожение малого бизнеса в айти (кто помнит watcom c compiler?), защита крупного бизнеса от опасности, что мелкий их потеснит, уничтожение самого рынка для малого бизнеса и снижение затрат для крупного бизнеса — так бы они были вынуждены поддерживать свои собственные компиляторы, платить специалистам по компиляторам, а не индусам за фронтенд, а сейчас у них есть общий gcc и специалистов нужно меньше.
Не согласен от начала и до конца.
Что касается опен сорс библиотек. Я, как представитель малого бизнеса в айти безумно рад, что я могу за бесплатно иметь доступ к миллионам библиотек с открытым кодом, пользоваться мощнейшими компиляторами и виртуальными машинами. Это всё делает вдох в айти не требующим никаких материальных затрат кроме покупки компьютера. Если бы мне нужно было платить за дельфи несколько тысяч долларов в год, если бы мне нужно было платить за библиотеки компонентов сотни долларов за каждую, да ещё и за новые версии приплачивать, совсем не факт, что я бы это вообще потянул.
Что касается опен сорс программ. Ну большинство из них ведь объективно плохи и пользуются ими только от бедности. Тот же WinRAR гораздо удобней и красивей 7-zip. Понятно, что если бы вариантов не было, люди бы вынуждены были покупать WinRAR (ну или воровать), но это всё равно нездоровая обстановка. А когда есть недоделанная открытая программа, да, нужно постараиться, но вполне можно сделать платную программу лучше. Gimp, Paint.NET не помешали появиться Pixelmator-у и я за последний заплатил с удовольствием. Я покупал не менее десятка мелких программок, которым есть открытые аналоги.
Watcom C Compiler сдох, потому, что он был хуже других компиляторов. Точно так же, как gcc имеет все шансы уйти в небытие, потому, что он хуже clang-а. Сделай компилятор C, который будет генерировать код на 10% быстрей существующих и у тебя его будут покупать за тысячи долларов. Не можешь? Ну извини.
А ещё Linux убил таких монстров, как HPUX, Solaris и подобных. Можно ли их называть малым бизнесом? Никак нет. И, опять же, он работает компонентой. А пользователям продают платный Android, в котором Linux сидит компонентой.
Здравствуйте, Mamut, Вы писали:
M>Самый наглядный пример, от которого мы страдаем (на самом деле не страдаем) уже год — Google Dataflow, который построен на Apache Beam. Официально поддерживаемая версия — Java 8, поддержка которой закончилась год тому назад.
Это неправда. Как минимум до 2030 года Java 8 поддерживается Azul-ом. Насколько я знаю, и RedHat и Amazon и Oracle и AdoptOpenJDK предлагают сходные сроки поддержки, сейчас искать лень. В общем выбирай-не хочу.
Не говоря уже о том, что вменяемый софт заработает хоть на Java 14 с абсолютно минимальными телодвижениями. Идеальная обратная совместимость это главный конёк Java.
M>Java 8, поддержка которой закончилась
Эмм... поддержка кем/чем?
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
M>Java 8, поддержка которой закончилась
Эмм... поддержка кем/чем?
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Аноним931, Вы писали:
А> M>Java 8, поддержка которой закончилась А> Эмм... поддержка кем/чем?
Не обращай внимания. Mamut осознал, что спорол фигню, отмалчивается, минусы расставляет.
Здравствуйте, vsb, Вы писали:
vsb>Watcom C Compiler сдох, потому, что он был хуже других компиляторов. Точно так же, как gcc имеет все шансы уйти в небытие, потому, что он хуже clang-а. Сделай компилятор C, который будет генерировать код на 10% быстрей существующих и у тебя его будут покупать за тысячи долларов. Не можешь? Ну извини.
Ватком был шустрым, не надо. Хуже он может стал, когда стал отставать в поддержке стандарта, да под досом застрял
Здравствуйте, vsb, Вы писали:
vsb>Что касается опен сорс программ. Ну большинство из них ведь объективно плохи и пользуются ими только от бедности. Тот же WinRAR гораздо удобней и красивей 7-zip.
Когда-то Сергей Выдров писал про различие таргетинга для "изиотов" и "приверед" — тут это более уместно, чем просто "удобней" и "красивей".
vsb>Watcom C Compiler сдох, потому, что он был хуже других компиляторов. Точно так же, как gcc имеет все шансы уйти в небытие, потому, что он хуже clang-а.
Ну пока что это слишком смелое заявление, мягко говоря. Пример, где gcc выгоднее на 30%, дальше есть ещё парочка таких. И новые ценные для всех развития в нём идут быстрее. Рано хоронить
Ну и, думаю, его будут поддерживать хотя бы потому, что альтернатива. Intel жмётся в своём углу "мы вылизываем под свои процессоры", Microsoft — под Windows, остальное их интересует постольку поскольку — и что, один универсальный компилятор на весь мир?
vsb>А ещё Linux убил таких монстров, как HPUX, Solaris и подобных. Можно ли их называть малым бизнесом? Никак нет. И, опять же, он работает компонентой. А пользователям продают платный Android, в котором Linux сидит компонентой.
Тут действует закон Спольского — активно развивают то opensource, которое развивающему инфраструктура, но не основа бизнеса.
Здравствуйте, netch80, Вы писали:
N>Ну пока что это слишком смелое заявление, мягко говоря. Пример, где gcc выгоднее на 30%, дальше есть ещё парочка таких. И новые ценные для всех развития в нём идут быстрее. Рано хоронить
Проблема в том, что все корпорации поддерживают LLVM, потому, что не хотят GPL. А на энтузиастах далеко не уедешь. Как мне кажется, GCC нужен только за счёт исторического наследия, во-первых код, который изначально писался под GCC и портировать его никому не хочется, во-вторых бэкэнды под всякие системы, которые тоже изначально писались для GCC (потому, что LLVM не так давно появился). Но это всё наследие.
N>Ну и, думаю, его будут поддерживать хотя бы потому, что альтернатива.
При наличии LLVM с адекватной для коммерческих компаний лицензией альтернатива просто не нужна. Нет в ней смысла. Если кому-то очень захочется не зависеть от разработчиком LLVM, куда проще просто форкнуть его, чем поддерживать абсолютно другой код.
N> Intel жмётся в своём углу "мы вылизываем под свои процессоры", Microsoft — под Windows, остальное их интересует постольку поскольку — и что, один универсальный компилятор на весь мир?
Да, один универсальный компилятор на весь мир. И Intel и Microsoft со временем выкинут свои компиляторы и перейдут на него. Точно так же, как все выкинули свои браузерные движки и перешли на Chromium.
Думаю, нужен некий финальный рывок, чтобы начать хоронить gcc. Например если RHEL перейдёт на llvm. Это будет таким громким звоночком, за которым все и потянутся.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, netch80, Вы писали:
N>>Ну пока что это слишком смелое заявление, мягко говоря. Пример, где gcc выгоднее на 30%, дальше есть ещё парочка таких. И новые ценные для всех развития в нём идут быстрее. Рано хоронить
vsb>Проблема в том, что все корпорации поддерживают LLVM, потому, что не хотят GPL.
ИМХО это слишком большое обобщение. Единственная компания которой была важна лицензия gcc
это Apple. Всем остальным пофиг. Они выбирают LLVM скорее из-за кодовой базы, она намного моложе
gcc и соответственно с ней проще работать.
А>> Эмм... поддержка кем/чем? ·>Не обращай внимания. Mamut осознал, что спорол фигню,
Спор пошел по кругу, зачем еще раз это размусоливать? Тем более, что ты гнешь свою линию, не пытаясь даже сделать вид, что ты слушаешь собеседника.
·>отмалчивается, минусы расставляет.
Минус я поставил только один и только тебе. Уж извини, что это задело твою тонкую натуру.
Здравствуйте, Mamut, Вы писали:
M> ·>Не обращай внимания. Mamut осознал, что спорол фигню, M> Спор пошел по кругу, зачем еще раз это размусоливать? Тем более, что ты гнешь свою линию,
Аноним931 это не я. Ты на его вопрос не ответил, моя линия тут побоку.
M>не пытаясь даже сделать вид, что ты слушаешь собеседника.
Кроме эмоций и фактических ошибок там нечего слушать.
M>Java 8, поддержка которой закончилась
Эмм... поддержка кем/чем?
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Marty, Вы писали:
S>>>что не так было с Borland C++
КД>>С ним было все не так
КД>>Под занавес (я именно про Borland C++, а не BCB), он превратился в лютый ужоснах.
M>Да ладно, BC4.5 вполне норм был, и OWL тоже ничего, но MFC его заборол
Я начинал с этого компилятора/IDE.
Но, поскольку это было яслях при детсаде C++, когда срался ходил под себя от любой ошибки компилятора, ничего толкового сказать про 4.5 не могу.
---
Где-то валяется CD с этим хламом
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, K13, Вы писали:
N>>Ну пока что это слишком смелое заявление, мягко говоря. Пример, где gcc выгоднее на 30%
K13>Прошел по ссылке, не нашел выигрыша в 30% у gcc перед clang на одинаковом железе. K13>Какая именно табличка, может, пропустил?
Himeno Benchmark v3.0 на 4й странице.
А C-Ray v1.1 на странице 5 так вообще двукратное преимущество.
Bullet Physics Engine v2.81, тоже на странице 5 — процентов 20-30.
N>>>Ну пока что это слишком смелое заявление, мягко говоря. Пример, где gcc выгоднее на 30%
K13>>Прошел по ссылке, не нашел выигрыша в 30% у gcc перед clang на одинаковом железе. K13>>Какая именно табличка, может, пропустил?
N>Himeno Benchmark v3.0 на 4й странице.
Himeno was another case of Clang 8 yielding a slightly faster binary than GCC 9 on the AMD Threadripper system.
На интеле -- да, gcc быстрее.
N>А C-Ray v1.1 на странице 5 так вообще двукратное преимущество. N>Bullet Physics Engine v2.81, тоже на странице 5 — процентов 20-30.
А если судить по MKL-DNN то clang иногда быстрее почти на порядок (8.14 миллисекунд против 70.99).
Интересно было бы посмотреть на результаты свежего clang, уже вышел 10.
