Итак, у opsmop — та же проблема с графиком принятия и вовлечения, что и у vespene_io, и я также не вижу смысла продолжать. Я упорно верю в саму идею, но думаю, что целый мир IT с открытыми исходниками выгорел, а я устал пытаться заинтересовать людей.
Тем, кто скажет, что это было непопадание продукта в рынок, или что мне следовало подождать подольше — при всём уважении, вы неправы. Я знаю об этой сфере намного больше любого, кроме пяти людей в мире :-) Причины этого интересны…
По сути (1) agile-график означает, что на работе ни у кого нет времени, (2) DevOps не смог сработать так, как задумывалось. И тому, и тому понадобилось время для постепенного проявления, и причинения вреда. Честно говоря, около 12 лет.
DevOps [-подход — прим.перев.] должен был стать похожим на гибрид разработки и администрирования [development/operations — прим.перев.], но вместо этого люди делают обыденные инструменты, а разработчики делают массу того, к чему привычны администраторы. А администраторы становятся *ещё более* системными администраторами, чем были хотя бы в середине этого срока [в 12 лет — прим.перев.]
Ключ к успеху открытых исходников — когда аудитории пользователей и разработчиков (те, кто могут вносить свой вклад) сильно пересекаются, а также вовлечены и вдохновлены.
В нашем же случае множество обсуждений указывает на то, что все заняты, ни у кого нет времени, а ещё… вcё больше и больше заинтересованы в решениях типа «мало кода/нет кода». Это не касается открытых исходников в целом, а только сегмента IT-администрирования.
Оглядываясь назад, на обсуждения лицензирования (Mongo, Redis, Confluent) — они были правы, защищаясь от «облачных» злоупотреблений, но это говорит и ещё о чём-то: чтобы начать это делать, им пришлось встретиться с уменьшающейся ценностью взаимодействия с сообществом.
Верно, не все предлагаемые улучшения всегда хороши, но взаимодействие и опыт работы с людьми — большой позитив. Но они, кажется, тормозятся везде. Вы бы, наверное, подумали, что если кто-то написал одну из тех штук на GitHub, что получают наибольшее количество запросов на улучшение, то люди захотели бы попробовать его новые штуки и поделиться идеями, но на моём форуме — только 60 участников, и только 10 из них заходили за последнюю неделю. Каждый проект клонируется всего лишь дважды в день, и то, скорее всего — автоматически.
Я вижу сильное движение в других областях, типа экосистемы JavaScript. У меня масса энтузиазма касательно открытых исходников и обмена идеями. Я много говорил с людьми, у которых серьёзные проблемы с управлением конфигурацией. Но, в конце концов, взаимодействия не получается.
Программы с открытыми исходниками подпитывают взаимодействие. И, в основном, вот мой диагноз — широкомасштабное выгорание. Оно наступало медленно, и мы его не заметили. Agile и DevOps — выгорание. На мой взгляд, в некоторых областях мы технологически беднее, чем были шесть лет назад. Почему?
Мы устали, и просто позволяем всему идти, как идёт. Мы используем то же, что и другие. Мы запускаем облака поверх наших грёбаных облаков безо всяких причин, и мы намного больше заинтересованы в технической моде, чем в том, что делает нас производительными. Мы терпим софт с тысячами багов.
Мы в основном позволили нашему управляющему софту стать шуткой. Вместо того, чтобы настаивать на мастерстве ракетно-космического уровня, мы просто прикручиваем сверху ещё больше слоёв. И ни у кого нет сил сказать «нет». IT-софт ушёл слишком далеко от любого подобия инженерного дела.
Я хочу помочь с этим бороться, но, в конце концов, вовлечённость и мозговые штурмы — моё топливо. Если вовлечённости нет, и я не могу эту вовлечённость починить — я ничего с этого не получу. Вот я и оказался той самой канарейкой — в большей или меньшей степени.
Я до сих пор люблю писать софт, но я собираюсь попробовать создать проекты, которые интересны лично мне, и довольно заметно обернуться спиной к услуживающему лидерству. Это означает штуки типа моего проекта музыкального секвенсера. Потому что я полагаю, что людям не плевать на хобби…
Я надеюсь, здесь вовлечённость будет выражаться большими числами. Ну а если нет — его всё равно можно использовать, чтобы напилить клёвые мелодии. Возможно, я погружусь в некоторые интересные штуки по анализу данных, потому что они также интересуют меня.
Как же мы можем починить открытые исходники для IT в общем и в целом? Взгляните, кем должен быть DevOps… он должен быть настолько же разработчиком, настолько же и администратором. Боритесь с agile'ом, который пожирает ваше расписание. Пробуйте новые штуки, придумывайте, изучайте варианты и не пытайтесь быть кем-то ещё.
Блокируйте в Твиттере «адвокатов разработчиков». Мы любим говорить о представленности, но подумайте о том, что для технологий может означать «покупай местное». Поддерживайте мелкие проекты и ISV [независимые производители ПО — прим.перев.]. Взаимодействуйте. Большинство нас питается взаимодействием более, чем всем остальным.
Будущее, в которым мы просто потребляем софт, выпущенный одним из четырёх брендов, кажется мне довольно унылым, особенно если в этом будущем мало кода. Чтобы пережить это объединение, нам нужно разнообразие. И, чтобы к нему прийти, мы должны отвергнуть окостенение практик.
Очень немногие вещи мы делаем наилучшим способом, в основном же — тем способом, которым делают все. Большинство софта, который все хотят использовать — отстой. Ну и какой в этом прикол, ну серьёзно? Откажитесь от посредственности и делайте так, как сочтёте нужным.
Касательно той штуки насчёт депрессии/выгорания — берегите своё мастерство. Наслаждайтесь производительностью. Создавайте пуленепробиваемые вещи. Делитесь написанными скриптами. Ведите блоги. Что угодно. Общайтесь и делитесь ещё больше. Возможно, мало-помалу мы сможем это изменить.
Но в следующий раз, когда разговор зайдёт о смене парадигмы типа «agile» или «devops», начатый кем-то, кто ни написал, ни построил ничего значительного, будьте вежливыми, но не ведитесь на то, что они пытаются вам впарить.
Мы должны ценить инженерную работу — то, что мы создаём, особые актуальные штуки, а не дерьмовые высказывания или повторяющиеся мантры о процессах. Именно первые — показатель нашей ценности и того, насколько мы всё улучшаем.
Мы допустили движения, сделавшие это с нами, и допускаем до сих пор. Принятие окостенения [практик — прим.перев.] и наплевательство на качество софта, которые мы все поддерживаем, просто должны прекратиться. IT — инженерное дело, так что относитесь к ним соответственно.
Если это сложно для меня — представьте, каково оно кому-либо без платформы. Для меня OSS было отличным способом познакомиться с массой людей, и кучей радости, и… если я не могу сделать это сегодня — ой…
Все виды крутой помощи, касавшиеся движения OSS, которыми мы наслаждались в RedHat в 2006 — то, во что я уже просто не верю сегодня. Движение не было ошибочным, просто что-то сдвинулось в культуре, и убило его.
Я не могу удержаться от мысли о том, что не потому ли Red Hat была продана не ради дистрибутива, но (согласно объявлению IBM) ради дистрибутива Kubernetes и OpenStack. Они тоже столкнулись с этим? Что каждая большая компания с OSS-проектом думает о вовлечённости, но не может сказать?
Конечно, они бы, скорее всего, сказали что-то другое, но мне интересно, что они думают. А я думаю, что они все думают, что фримиум — хорошая модель загрузок, но настоящий код и сотрудничество больше ничего не значат, потому что люди не вовлекаются.
(всем, кто поставит «плюс» за это, хм… спасибо?)
Комментарии (44)
janvarev
01.11.2019 19:59Хотелось бы в опросе вариант ответа
«Пишу исходники, и свободно в них ориентируюсь» :)
akardapolov
01.11.2019 21:19+1А мне бы был полезен другой опрос, про вовлеченность и как ее починить, коллега (:)
tnt4brain Автор
01.11.2019 22:24+1Лично я вполне согласен с рецептами починки от Майкла — собственно, поэтому и сделал перевод, ибо зацепило.
akardapolov
02.11.2019 10:00А какие это рецепты?
tnt4brain Автор
02.11.2019 20:08Так вот же:
Касательно той штуки насчёт депрессии/выгорания — берегите своё мастерство. Наслаждайтесь производительностью. Создавайте пуленепробиваемые вещи. Делитесь написанными скриптами. Ведите блоги. Что угодно. Общайтесь и делитесь ещё больше.
akardapolov
02.11.2019 20:39Как я понял, автор не знает что делать с повсеместным падением уровня вовлеченности в open source проектах
взаимодействие и опыт работы с людьми — большой позитив. Но они, кажется, тормозятся везде.
Симптомом которого было внедрение Agile практик и DevOps. И он не знает, что с этим делать.Я хочу помочь с этим бороться, но, в конце концов, вовлечённость и мозговые штурмы — моё топливо. Если вовлечённости нет, и я не могу эту вовлечённость починить — я ничего с этого не получу.
tnt4brain Автор
02.11.2019 21:14+1Всё же, на мой взгляд, внедрение agile и DevOps — пара причин, которые привели к текущей ситуации.
Говоря прямо, инструменты, требующие определённого уровня квалификации, пошли в широкие массы. Результат печален: если условный спец умеет/успевает только использовать инструмент, но никак не разбираться в нём детально, то, конечно, никакой вовлечённости этот инструмент в нём не разожжёт, и никаких MR/PR никто от этого спеца не увидит. В лучшем случае — те самые унылые issues, потому что «доку не читай @ в чаты пиши».
gecube
02.11.2019 21:37Поэтому инструменты должны иметь некий заградительный уровень, порог входа. Тогда идиоты будут отсеиваться на входе. С другой стороны, именно поэтому появятся альтернативные инструменты, которые будут с виду простыми, буду обещать легкое решение проблем, но потом для более сложных задач и конфигураций они не будут подходить и тот, кто их взял, начнет изобретать костыли и велосипеды для решения своей задачи.
tnt4brain Автор
02.11.2019 23:56Вот прям повеяло простыми нажатиями кнопки «сделать хорошо» :-)
К сожалению, одинаково универсальных инструментов нет, и те, кто это не понимает, всегда будут огорчены тем, что «X не умеет Y, а Z — умеет, но при этом стоит денег». Остаётся только пожимать плечами и вчитываться в исходники очередного инструмента :-)
creker
02.11.2019 18:24Действительно, где тут рецепты? Что в переводе, что в оригинале — мало связный поток сознания непонятно о чем.
puyol_dev2
01.11.2019 22:42+4Я думаю проблема ещё заключается в том, что спецы, работающие в компаниях, берут исходники из открытого проекта, дорабатывают его под себя или исправляют ошибки, но обратно в открытый доступ этот код уже не попадает
dominigato
03.11.2019 00:13Ну это часто нарушает лицензию, да и трудно представить причину не выкладывать фикс если он уже готов. Неужели так трудно оформить PR?
playnet
04.11.2019 09:54+1если используется только внутри компании где было сделано то вообще-то не нарушает, распространять закрытый код без выкладки кода при этом запрещено.
Выложить по ошибкам PR проще, чтобы меньше патчить код на новых версиях, но зачастую реализовано то что большинству не нужно, оформлено не как нужно, код надо рефакторить, иногда ломает например работу на arm итд.
amarao
01.11.2019 23:17+3Автор ансибла недоволен софтом с багами? Удивительно.
wsdx
02.11.2019 20:09Вот прям с языка снял. Настолько слабодокументированной и баг-на-баге-багом-погоняет системы — еще поискать! Настолько, что под свои задачи хочется сесть и написать свой ансибл…
tnt4brain Автор
02.11.2019 20:16А кто же мешает? Напишите! Возможно, ваши задачи окажутся близки кому-то ещё, и мы станем свидетелями рождения нового замечательного инструмента управления конфигурацией — проявится то самое взаимодействие, о котором пишет Майкл.
dominigato
04.11.2019 16:00Репутация это конечно то, что легко потерять и трудно набрать, но должен сказать что последние версии ансибла гораздо лучше чем все было раньше.
С последней 2.9 вообще ничего не сломалось, что никогда не бывало раньше :) А с 2.8 совсем немного проблем было. Наверное к 3.0 будет уже нормальным зрелым продуктом.
tnt4brain Автор
02.11.2019 20:17Часто issue создают люди, которые не понимают, как работает та или иная часть/функция/модуль, да ещё и с комментариями — «хочу, чтобы работало вот так».
gecube
02.11.2019 21:39+1Любой ишью имеет ценность. Даже если он именно в ключе "хочу, чтобы работало вот так", но был реджекнут — это уже информация для будущих поколений, что так работать не будет.
Другой вопрос, что очень многие ишью дублируют другие (трекер не читай @ ишью создавай) или описаны очень… поверхностно (HELP! HELP! волки!). Или ответ на них есть в доке. И с помощью Ишью легко сделать DOS атаку на представителей разработки конкретного софта. Заведи 100 ненужных ишью — пускай разработчики их разгребают ((((((
amarao
04.11.2019 10:55+1Вся катастрофа ансибла — в том, что НИКТО не знает, как оно работает. Как написано — так и работает. Отношения между переменными, import'ами и include'ами — мистика совершеннейшая. Я недавно описывал совершеннейший WTF с import_role, который переопределяет переменные для таски, в которой import, но только вне scope остальных import'ов. Попытка разобраться с этим — это изучение карты минного поля.
А главная проблема ansible — глобальный массив переменных, который иногда притворяется локальными переменными.
tnt4brain Автор
04.11.2019 11:24+1В контексте статьи хочу заметить, что исходники Ансибла при этом открыты, то есть всегда есть возможность прочитать и понять, _как именно_ работает. Ну и, конечно же, обсудить с сообществом.
А если этого не хочется по каким-то причинам — всегда можно взять и написать свою систему, которая будет:
- легковесной,
- простой в использовании,
- не будет содержать багов,
- и будет абсолютно бесплатной в использовании.
P.S. Лично я проблем с глобальными переменными не встречаю вовсе — и так уже пять лет!.. По моим ощущениям, чаще источники подобных проблем кроются в непонимании объектной модели Ansible (как говорится, «не о присутствующих», сугубо по опыту чата @pro_ansible).amarao
04.11.2019 12:48Можно сколько угодно читать исходники Ансибла, если они неконсистенты с заявленной моделью в голове, то "переписать" единственный вариант. Потому что это архитектурная проблема, которая не решается патчкой патчей.
У нас на работе множество людей, которые ни разу не сталкивались с неконсистеностью модели Асибла. Например, все бухгалтеры ни разу не сталкивались с проблемами при написании плейбук ансибла. Повар тоже не сталкивался. А вот операторы и программисты сталкиваются постоянно.
Если вы так уверены в консистености ансибла, то объясните вот это:
https://habr.com/en/company/southbridge/blog/471896/#comment_20769540tnt4brain Автор
05.11.2019 01:50Что-то я не вижу, чтобы где-то озвучивал подобную уверенность:
Если вы так уверены в консистености ансибла
Во-вторых, если посмотреть на плейбук по ссылке, то вы изменяете глобальные переменные внутри отдельных вызовов ролей и удивляетесь результату. С чем именно консистентен подход с изменением глобальных переменных в отдельных вызовах?
vdshat
02.11.2019 16:34У JBoss'a всегда была модель бизнеса: в open source максимум бета, остальное — за деньги. Как говорится: «Не сотвори себе кумира». Кто сказал, что OS — это бесплатно? За все бесплатное кто-то обязательно платит. Это относится в равной степени ко всем модным штучкам, т.к. их чаще всего и делают для привлечения денег. Создали Аджайл — получили целую индустрию коучеров и последователей, назвали одмина DevOps'ом, нет кодить он как не умел, так и не умеет, как плел жгуты так и плетет, но теперь за него можно взять полтийник в час, а не четвертной.
Andrey_Rogovsky
02.11.2019 18:35Ну допустим, я — девопс. Начинал кодить еще с ассемблера.
Но у девопса минимальная магнитуда влияния на разработчиков и методологию.
Всем заправляют ПМы.
Kanut
02.11.2019 20:02Всем заправляют ПМы.
Даже если они есть, то они не обязательно всем заправляют. А ведь иногда их и нет вообще :)
tnt4brain Автор
02.11.2019 20:21Всем заправляют ПМы.
Это — та реальность, в которой живёте вы, но у кого-то другого ситуация может отличаться: его мнение имеет значение. И только вы можете либо соглашаться со своей ситуацией, либо как-то её менять.
virtual_hack2root
03.11.2019 21:13спасибо, отличная статья, хороший перевод
tnt4brain Автор
04.11.2019 09:01+1Благодарю!
Исходная ссылка где-то в профильных чатах мелькнула, увидел автора — решил прочитать. Понял, что это — «ОГО!», потому что симптомы, описанные в статье, действительно ощущаются: на конференциях и митапах в лучшем случае — делимся своими удачными практиками, а в худшем — просто перенимаем чужие.
При этом есть несколько решений, которые в своих… ну не областях, наверное, а нишах сегмента администрирования стали именно что неписанным стандартом, и ничего принципиально нового не появляется пару-тройку лет точно. Ну правда, а что свежего в сегменте можно вспомнить хотя бы за последний год? Разве ту же VictoriaMetrics, но и всё, пожалуй… Ну а если я ошибаюсь — что ж, с удовольствием не только прочту названия новых продуктов в комментариях, но и попробую хотя бы их потестировать.
gecube
DevOps и эджайл сделали с индустрией ПО то, что происходило годами и десятилетиями в других сферах. Слава Богу профессионализм ещё в почете. И крутые специалисты найдут себе работу… Но как побочный эффект — опенсурц умер.
tnt4brain Автор
Боюсь, да: open-source умер в контексте «почитать-код-подумать-внести-свой-вклад-чтобы-стало-лучше». Средней руки спец возьмёт то, что есть, и будет долго ныть в issues, не читая документацию, вместо того, чтобы создать PR/MR.
vasyan
можно подумать кому-то этот PR/MR нужен. Там с той стороны сидят ребята на поддуве у facebook, microsoft или какой-другой компании и у них свой план. А на MR скорее ответят, что его как-то не так оформили или ещё как-то докопаются до мелочей.
gecube
И соглашусь, и нет. С одной стороны, есть многие проекты, которые с радостью примут правильный PR/MR, т.к. разработчиков всегда не хватает.
С другой стороны, опен сурс это тоже способ коммерции. И подсадить сообщество на свой продукт и потом продавать его коммерческую версию. И собирать хорошие идеи у сообщества, ничего не давая взамен. И ещё много чего.
tnt4brain Автор
Здесь бы великолепно смотрелась ссылка на пример такого MR.
humbug
Да легко:
https://github.com/async-rs/async-std/pull/122
https://github.com/withoutboats/romio/pull/106
Первый ультимативно закрыли из-за смены политики в отношении зависимостей, без предложения отребейзить или поправить код. После чего открыли свой ишью и втроем думают, как же решить проблему, решенную в моем PR. До сих пор не придумали.
Второй хотят закрыть с аргументом "это троллинг, это спам", потому что это мешает им пиарить свой собственный проект.
Ребята сидят на поддуве у Ferrous Systems, если что. Вчитываемся в PR, делаем выводы, голосуем/отписываемся.
fougasse
Как-то звучит как обида с вашей стороны.
vasyan
Когда не принимают PR это всегда обидно.
Особенно, когда у твоего PR есть «пальцы вверх».
creker
Второй выглядит конечно странно, но у меня, как человека со стороны, нет ниодной причины подозревать в чем-то кого-то. С чего вдруг дело в пиаре? Неадекватность — это тут видно вполне.
По первому, выглядит как типичная ситуация, когда PR сделан без согласования с ментейнерами. Вместо того, чтобы копошиться в нем, править коммиты, можно закрыть его, открыть баг для обсуждения, а уже потом писать решение в новом PR. Никакого криминала. Вам обидно — это другой вопрос. Участвуйте в обсуждении, может придете к компромиссу.
humbug
Первый PR был открыт за полмесяца до смены парадигмы.
creker
И? Это ничего не меняет.
SirEdvin
Open Source в таком контексте никогда и не жил массово. Да и технически никогда не мог так жить.
Очень мало, даже опытных специалистов, может взять и написать к условному проекту код, который бы придерижвался стиля разработки в проекте (в том числе и не описанного), а еще что бы решение совпадало с тем, как его видит автор проекта .
Опять же, вы понимаете, что такой софт качественный в значительной мере потому, что он простой с точки зрения бизнес логики? Там безумно мало вещей, которые делают программы сложными. Никакой параметризации, ничего такого.
dominigato
Есть разные проекты: в некоторых огородились и туда нереально что-то пропихнуть, даже компаниям, не только индивидуальным разработчикам.
А некоторые с радостью примут вашу помощь.
По моим наблюдениям чем старше, больше и сложнее проект, тем меньше шансов на принятие сторонних PR.
playnet
> Средней руки спец возьмёт то, что есть, и будет долго ныть в issues,
А что делать… Правда тут есть момент в том, имеет ли место проблема или это «не чтение документации». Если второе то такое быстро закрывается, а первое часто висит годами.
> вместо того, чтобы создать PR/MR.
Чтобы сделать PR, нужно разобраться в коде, сделать фикс который ничего не сломает, вероятно написать/дописать автотесты, причём в стиле фирмы и ещё много работы. А потом ещё передать права на свою работу, часто без этого не берут PR, типа левый программер, надо поменять лицензию например — обходи потом по всем, собирай разрешения, удаляй их код если они не одобрили.
И если не провёл много сотен часов в коде этой утилиты, то часто сделать этот PR это работа даже не на неделю а может быть и больше, тогда как сотруднику — пол дня на всё. С другой стороны, я бы воздержался использовать софт, у которого нужно ориентироваться как в своём чтобы всё работало.
Ещё позиция многих людей — это опенсорц, тут никто ничего никому не обязан. И я сам с этим столкнулся, когда видел проблемы, но авторы вместо того чтобы их править, слали пачками письма «купите подписку всего за 3 килобакса в месяц и мы будем решать ваши issue». А сообщество такое «ну и что, имеют право». То есть находишь баг, репортишь, а в ответ «гони бабла». Именно такая позиция и убивает опенсорс. И вызывает желание критические ошибки не разработчикам сдавать, а продавать куда-то как 0day. Или и то и другое сразу.
Я конечно понимаю, что работы может быть и так много, а ещё семья-друзья ждут, а ещё — что гораздо приятнее пилить новые фишки чем ловить баги и править старый код, но это противоречие убийственно для опенсорса.
Хотя тема вообще-то про devops.
gecube
На самом деле опенсурс и девопс идут рука об руку.
Потому что бизнес требует результат вчера, денег на покупку коробочного решения не дает (попробуй обоснуй! к тому же, у "коробок" своих болячек полно), приходится выкручиваться как можешь.