Джедай-разработка. Джедай — это в первую очередь человек, который может в одиночку изменить судьбу вселенной (не подпадающий под принцип «один в поле не воин»). И некоторые open source фреймворки позволяют решать сложные технические проблемы простым деплоиментом готовых решений. Теоретически можно написать свой map-reduce, свою распределенную файловую систему и даже свою supertable realtime database. Но это займет много времени и будет по качеству хуже существующих решений.
А вот свой Spark за пределами долины уже не написать — просто слишком сложная система, требующая слишком много очень высококвалифицированных разработчиков. Но зачем все это писать, если весь big data стек организации можно поднять на 2 дня. Террабайты логов? Cassandra + Spark + Zeppelin. Из готовых docker контейнеров опытный человек может поставить все и за один день.
— Apache Spark релизится раз в 3 месяца с мажорными фичами. Это радикальное увеличение стабильности, появление новых инструментов (SparkSQl, Dataframe, GraphX), увеличение количества реализованных алгоритмов (Gradient boosting в MLLib). Solr за пару лет научился шардироваться и посему работать с большими данными. Hadoop переродился в Yarn. Эти фреймворки обзаводятся новой полезной функциональностью без приложения моих усилий. А значит, я могу более эффективно решать поставленные перед мной задачи. В проприетарном продукте жизнь становилось бы легче только тогда, когда я бы сильно вкладывался в то, чтобы сделать ее легче.
Хорошая документация. Очень мало top level apache проектов с плохой документацией. В apache incubator плохую документацию можно встретить чаще. Но даже в этом случаи — в силу открытости проекта у него есть пользователи, которые оставляют следы своих изысканий на StackOverflow. То что в проприетарном проекте обычно первый шаг — обратится непосредственно к автору кода, является самым крайним шагом в open source. За 2 года своего самого тесного общения со spark мне пришлось писать на dev mailing list всего дважды.
Сложившееся коммьюнити. В open source у меня всегда есть чувство плеча и принадлежности к какому то кругу, который всегда поможет в корректно поставленном техническом вопросе. Появляется ощущение, что у тебя замечательные коллеги по всему земному шару. И они останутся, если ты даже сменишь фирму, но не сменишь фреймворк.
Работа на себя. Работая с open source вы увеличиваете свою экспертизу в нем и быстро растете в зарплатно-профессиональном плане. Действительно, если понадобиться сменить работу — на рынке есть 5 контор, технологический стек которых вы уже примерно знаете и можете приносить пользу с первого дня. Вам не нужно по полгода входить в контекст переходя с одного проприетарного стека на другой. И фирмам тоже проще — можно нанять сотрудников, которых практически не надо обучать.
Все это является плюсом для сотрудников и работодателей в России. И для того, чтобы воспользоваться этими преимуществами, не надо быть committer. Достаточно быть contributor. Для тех, кто не знает, кратко расскажу, чем они отличаются. Сontributor — это человек, который предложил патч к проекту и его committer вмержил в мастер. Committer — это человек, который имеет право (и обязанность) регулярно коммитить и вмерживать патчи в мастер.
Contributor, таким образом, идеальный сотрудник в российских реалиях. Он хорошо знает проект, раз пользовался им достаточно, чтобы понять, где его можно улучшить. Он смог его улучшить. Он может собирать проект из сорсов и править сорсы, а значит, всегда сможет залезть в код и кастомизировать, если понадобится.
Контрибьютером быть классно — тебе не надо сдавать Spark Certification за 300 баксов, при этом никто не поставит под сомнение твою компетентность в этом фреймворке.
Committer обладает большей экспертизой в проекте, но куда важнее — большей властью.
Он может «протащить» в проект патч, выгодный его работодателю. Он может забанить патч, если он не выгоден. Он может определять пути развития проекта. Но власть идет не бесплатно. Он реально должен работать над формированием и поддержанием своего авторитета — читать бесконечные, бесполезные патчи, писать архитектурные гугло-доки, отвечать на вопросы. Делать это в свободное время почти нереально — это громадный труд. Поэтому коммитер делает это за счет работодателя. А что работодателю с этого? Посмотрим на список коммитеров в Spark:
| Aaron Davidson | Databricks |
| Andrew Or | Databricks |
| Andrew Xia | Alibaba |
| Andy Konwinski | Databricks |
| Ankur Dave | UC Berkeley |
| Charles Reiss | UC Berkeley |
| Cheng Lian | Databricks |
| Davies Liu | Databricks |
| Haoyuan Li | UC Berkeley |
| Imran Rashid | Cloudera |
| Jason Dai | Intel |
| Joseph Bradley | Databricks |
| Joseph Gonzalez | UC Berkeley |
| Josh Rosen | Databricks |
| Kay Ousterhout | UC Berkeley |
| Mark Hamstra | ClearStory Data |
| Matei Zaharia | Databricks, MIT |
| Michael Armbrust | Databricks |
| Mosharaf Chowdhury | UC Berkeley |
| Mridul Muralidharam | Yahoo! |
| Nick Pentreath | Mxit |
| Patrick Wendell | Databricks |
| Prashant Sharma | Imaginea, Pramati, Databricks |
| Ram Sriharsha | Hortonworks |
| Reynold Xin | Databricks |
| Robert Evans | Yahoo! |
| Ryan LeCompte | Quantifind |
| Sandy Ryza | Cloudera |
| Sean McNamara | Webtrends |
| Sean Owen | Cloudera |
| Shane Huang | National University of Singapore |
| Shivaram Venkataraman | UC Berkeley |
| Stephen Haberman | Bizo |
| Tathagata Das | Databricks |
| Thomas Dudziak | Groupon |
| Thomas Graves | Yahoo! |
| Xiangrui Meng | Databricks |
| Yin Huai | Databricks |
Spark зарождался в UC Berkley, поэтому вычтем всех из Berkley. Databricks — компания, которую образовали основатели Spark, зарабатывает на Databricks Cloud — analytic tool поверх Спарка. Spark является по факту их главным продуктом, поэтому они должны в него вкладываться. Yahoo всегда строила свою инфраструктуру на отрытых решениях — сначала это был Hadoop, теперь Spark. Компаниям такого рода нужны коммитеры по следующим причинам:
- В инфраструктуру на этом фреймворке у них вложены по крайне мере десятки миллионов долларов (кластеры по тысячи машин в Yahoo). Контроля такого рода вложений не бывает слишком много. Нельзя допускать изменений в проекте, которые не позволят перейти на более новую версию в силу обратно несовместимых изменений или архитектурных решений, которые не укладываются в видение компании;
- В любой большой компании обычно приходится делать локальные патчи в open source, чтобы заставить работать для специфических условий или требований. Если эти патчи будут большими и серьезным, это создаст проблемы при переходе на новую версию. Поэтому такие патчи надо стараться вмерживать в upstream. Протащить большой патч в большой проект, без того, чтобы какой либо коммитер был в этом заинтересован практически невозможно;
- Компания видит свои приоритеты и коммитер старается транслировать эти приоритеты в комьюнити.
Я не знаю наверняка, но думаю, что Alibaba имеет не меньше инвестиций в инфраструктуру, чем Yahoo. Groupon меньше, но все же. Для ClearData Spark — основной движок.
Intel нужно точно знать, что Spark хорошо совместим с Intel. Cloudera, Hortonworks — являются вендорами хадупа (а значит и Спарка). Они должны транслировать не только свои интересы, но и интересы заказчика. Компании, для которых Big Data и IT — основной бизнес, куда сильнее заинтересованы в committers. MapR, SAP, Oracle, IBM — сейчас активно ищут коммитеров Cпарка (хотя я не понимаю, как можно активно искать всего 30 людей, которых все поименно знают). И они готовы платить хорошие деньги. Стать комитером Спарка в долине — гарантировано поднять свою зарплату в 2 раза, если она была уже высока.
Компании, которые готовы платить большие деньги за коммитеров, в России отсутствуют. IT-интеграторы не имеют размах IBM и SAP не только в плане оборота, но и в плане амбиций определять развитие отрасли. Они следуют тенденциям, формируемым в долине. Committer просто не сможет принести им пользы.
Продуктовые же компании в России либо малы, либо сидят на проприетарном технологическом стеке. Yandex пытается развиваться по модели Google, где вся разработка in house. Как я понимаю, это позиция основана на идеи, что разработка внутри быстрее и эффективнее любого open source, когда компания в состоянии создать критическую массу опытных специалистов. С деталями инфраструктуры ВКонтакте не знаком, но она тоже проприетарная. Одноклассники точно пользуются Spark, почему их не видно в коммьюнити — не могу сказать.
Таким образом, будучи committer, выиграть по деньгам или возможностям в России на фоне простого contributor считаю очень сложным.
Отсутствие компаний в России, которые хотели бы держать committers (которым было бы выгодно), считаю основной проблемой низкого количества committers.
Комментарии (48)
egorsmkv
05.06.2015 20:06Open Source для меня — это модель разработки ПО, которая не основана на личных интересах определенной группы людей или компаний. Проект открытый потому, что улучшить его может любой человек, а власть коммитера только в том, что он может одобрить хороший патч и отклонить плохой.
Если в проект вступает интерес работодателя, то это не Open Source. Хорошо, что есть кпопка «форк».
epahomov Автор
05.06.2015 20:21-1Есть open source проекты в которых не участвуют интересы никаких компаний. Они на мой вкус позорят звание top level apache проекта. Например Oozie без нормальной документации архитектуры и поддержки спарка до недавнего времени, или big top который отстает от контейнерной революции, спарка, ambari, и вообще всего на свете.
Как мне кажется это связано с тем, что никто их не коммерциализирует или не завязан на них в своей архитектуре настолько, чтобы вкладывать силы в развитие.egorsmkv
05.06.2015 21:02+2Коммерциализация проекта ни при чём. Меня смутили эти строки в тексте:
Он может «протащить» в проект патч, выгодный его работодателю. Он может забанить патч, если он не выгоден. Он может определять пути развития проекта.
questor
06.06.2015 16:30+2В словах «крупный опенсорсный проект» автор основной упор ставит на слово «крупный» (а вы — на «опенсорсный»), отсюда и вся разница в подходах.
В крупном проекте сталкиваются не два-три человека — а миллионы людей, поэтому уместно говорить в терминах «политика», когда приходится согласовывать разные мнения.
Вам не нравится слово «протащить свой патч», коробит от того, что есть люди, которые могут определять пути развития проекта?
Полагаю, что напрямую «забанить» патч — редкая ситуация. Можно мягко откладывать (давая своей компании время подготовиться), можно согласовывать разные варианты. Не надо демонизировать власть коммитера: в опесорс всегда можно форкнуть проект и попытаться доказать, что твоё видение, твой фреймворк — лучше, чем у фреймворка, который пользуется миллионной популярностью и который поддерживают гранды.egorsmkv
08.06.2015 16:55В крупном проекте сталкиваются не два-три человека — а миллионы людей, поэтому уместно говорить в терминах «политика», когда приходится согласовывать разные мнения.
Миллионы, наверно, используют этот крупный проект, а модернизирует (присылает патчи, багрепорты) значительно меньшее количество людей.
Вам не нравится слово «протащить свой патч», коробит от того, что есть люди, которые могут определять пути развития проекта?
Да, меня это коробит. С такой политикой управления os-проектом можно было просто-напросто держать его в компании и нанимать других программистов, чтобы они исправляли найденные ошибки.
Не понимаю, зачем откладывать улучшение, если в продакшене можно использовать старую версию, а через время переписать код под новую?questor
08.06.2015 17:14+1Миллионы, наверно, используют этот крупный проект
Допустим, для 70% из этих миллионов без разницы, что за фичи в проекте и, увы, вообще даже не обновляются по актуальной версии. Но ведь есть же некоторое количество людей, которое не просто использует этот проект, а ждёт реализации очередной фичи.
Поэтому интересы есть есть у всех — и у активного меньшинства и у пассивного большинства, которое промолчит, но в случае чего проголосует ногами и уйдёт на другой проект через некоторое время.
Давайте конкретный пример для наглядности. Есть opensource-бразуер Firefox. Была альтернатива: поддержать стандарт от гугл, но не встраивать проприетарный кодек H.264, либо поддержать проприетарный кодек, на котором уже много весьма завязано в мире (не в самом firefox). Microsoft и Cisco предлагают одно решение, гугл — третье. Попробуйте сказать, что бы вы сами выбрали бы на месте Mozilla Foundation? Вы бы наверное не поддержали бы ни одного из крупных вендоров, а купили бы программистов, чтобы они реализовали свой собственный кодек, с блэкджеком и всем-чем-полагается.
kirichenko
06.06.2015 13:11Какой-то непонятный фанатизм от спарка. И контейнеры ради контейнеров и какой-то революции — тоже не понятно.
LastDragon
06.06.2015 10:25+11> Open Source для меня — это модель разработки ПО, которая не основана на личных интересах определенной группы людей или компаний.
Точно так же основана, а баги вообще могут десятилетиями висеть просто потому что неинтересны разработчикам. Далеко не все так радужно.
grossws
06.06.2015 12:42+3Open Source для меня — это модель разработки ПО, которая не основана на личных интересах определенной группы людей или компаний.
Основана, так или иначе. Просто она обычно представляет интересы большей группы людей и компаний. Бывают исключения: например, проекты экосистемы jboss'а, там всё печально, несмотря на open source.
Если в проект вступает интерес работодателя, то это не Open Source.
Если исходники открыты — то это open source, по определению. Хотя и не FOSS. Но и в FOSS могут преследоваться интересы работодателя (начиная от увеличения качества и стабильности продукта), что не является чем-то страшным или необычным.
vaniaPooh
05.06.2015 20:47+3Про Яндекс — неправда. Довольно много выкладывается в Opensource.
epahomov Автор
05.06.2015 20:57+12На мой вкус это 2 разные истории — когда компания просто выкладывает свой код в опен сорс, и когда она делает свой продукт реально опен сорсным. Второе подразумевает — внутри перейти на опен сорс версию, развивать и работать с коммунити, формировать набор комитеров за пределами своей компании, и для некоторых проектов может — пойти под «зонтик» того же Apache для следования стандартам индустрии(традиции версионирования, мейлинг листы, стандарты CI)
В яндексе настолько вкладываются как мне кажется только в BEM(и в него вкладываются довольно профессионально на мой вкус). Я не знаю, но представляю каким интересам компании это может соответствовать — стандартизировать верстку, чтобы иметь возможность легче потом все интегрировать в свои поисковые снипеты, или верстать проще(?) Опять же плохо знаю этот фреймворк. Но в нем наверно я вижу черты нужды в committers про которые я говорил.
Gorthauer87
05.06.2015 21:12+1Вот вот, я вряд ли смогу набиться в коммитеры кокаина, для этого нужно будет устроиться в Яндекс работать, а я может уже в другом месте работаю, но использую кокаин и хочу его улучшать не только исправлениями багов.
epahomov Автор
05.06.2015 21:09-3Но опять же — тот же cocaine и BEM не стандарт индустрии как тот hadoop или cassandra. А хочется играть со всем ребятами, а не в своей песочнице.
JIghtuse
06.06.2015 10:50+7По-моему, вас заклинило на Apache Software Foundation. Есть другой открытый код, под другими лицензиями, с другими целями. Полно разработчиков из России, участвующих в разработке отрытого и свободного ПО.
z3apa3a
05.06.2015 21:15+7Не согласен с таким подходом: взять один проект, да еще выросший из внутренней разработки Berkley. Почему бы не посмотреть статистику? Россия на 8м месте по числу коммитов в Github, что весьма неплохо.
P.S. А вы, уважаемый автор, куда коммитите, если не секрет?epahomov Автор
05.06.2015 21:26Можете пояснить — это карта коммитев или коммитеров? Потому что я писал о коммитерах, а не коммитах. Здесь мне кажется не учитывается размер проектов, что на мой вкус важно. Я полтора года назад вконтрибутил немного кода в главный класс спарка — RDD — и это было сравнительно просто. Сейчас даже тесты в MLLib не вмерживают из-за того, что есть коммитерами одобреная гуглодока стратегии развития этого куска кода и мой код туда не вписывается. Надо писать обоснование, получать одобрение на интерфейсы… Проект стал большой. Теперь контрибутить нетревиальные вещи — большой труд. И эти виды коммитов как мне кажется надо разделять.
P.S. насчет статистики. Я верю что это аккуратные цифры и они репрезнтуют что-то. Но есть исследование StackOverflow которое дает иную картину — stackoverflow.com/research/developer-survey-2015. Я не буду спорить на уровне больших цифр — я не компетентен. Я могу только сказать про проекты в которых я копал откуда растут эти фичи и что оттуда еще должно вырасти.
Я контрибьючу немного в Спарк, немного раньше в Zeppelin. Делал патчи в Solr но их (правильно на мой вкус) не приняли.z3apa3a
05.06.2015 21:45+6Там вся легенда прописана — это именно карта по числу пользователей, при этом в России число коммитов на пользователя почти вдвое больше, чем в среднем по гитхабу, так что по коммитам все еще «краснее». Статистика по коммитам и по пользователям идет по краю карты.
Я наблюдаю совсем другую картину — наши люди коммитят в ядра Linux и FreeBSD, создают nginx и продукты конкурирующие с теми, что вы используете. Или посмотрите, например, кто коммитит в MySQL.epahomov Автор
05.06.2015 22:06-2Еще раз. Они туда коммитят или являются коммитерами? Я в своей статье пытался показать, что это разные вещи.
Очень может быть что наши картины различаются ибо мы смотрим на разные проекты. Из-за этого не совпадают ощущения. но прежде чем делать такой вывод посмотрите являются ли Ваши соотечественники коммитерами и работают ли они в Российских компаниях
BaRoN
07.06.2015 01:01+3А как связано количество спрашивающих и отвечающих на StackOverflow с числом коммитов или коммиттеров в OpenSource?
Stas911
06.06.2015 05:21-3Интересная статья, спасибо! За ссылки на докерконтейнеры тоже!
Zeppelin пробовал недавно — показался пока сыроватым (судя по отзывам — не мне одному), хоть и виден хороший потенциал.
AmdY
06.06.2015 05:45+18rambler — nginx
badoo — memcache и много чего для php
sphinx — аксёнова
percona — mysql и его стек
mailru — tarantool
jetbrains — kotlin
yandex — cocaine
vk — kPHP
Энвижен крупно вложился в postgre
…
VBart
06.06.2015 13:19+11На всякий случай поясню, поскольку похоже есть еще люди, кто не в курсе дел.
Rambler отношения к NGINX не имеет. Игорь в Рамблере не работал программистом, а с 2011 и вовсе там не работает. NGINX это уже 4-ый год как NGINX, Inc.
dezconnect
06.06.2015 13:30+1Энвижен круто вложившийся в постгре… так бы и писали Postgresql Professional
grossws
06.06.2015 12:27+1То что в проприетарном проекте обычно первый шаг — обратится непосредственно к автору кода, является самым крайним шагом в open source.
Не соглашусь. Часто смотрят и на всякий SO, и пишут в user@, что не очень далеко от обращения к разработчику.
amarao
06.06.2015 14:15+6Наблюдения в общем и целом интересные, но слишком много апачевского гадю… зоопарка. Наверное, это свой волшебный мир, но со стороны оно выглядит очень душераздирающе.
Что же касается opensource — да, именно так. Добавим ещё то, что айтишников в России не так уж и много (в абсолютных числах). Математика простая: 300кк население США, 700кк — население Европы. В РФ — всего 130кк. Очевидно, что при одинаковой концентрации айтишников, на 10 европейских будет приходиться один русский. При этом концентрация сильно разбавляется синдромом «всё или ничего» (то есть большая компания или фрилансеры), т.к. в РФ очень мало средних успешных контор.
А на одних мажорах много опенсорса не вытянешь — самих мажоров по пальцам пересчитать.questor
06.06.2015 16:48+3Статья в целом интересная, хоть и очень неоднозначная. Автор в некоторых комментариях хапнул минусов совершенно заслуженно, однако знаете — в целом дал повод ещё раз задуматься над некоторыми вопросами, я всё же иногда за то, чтобы услышать и альтернативные мнения, которые в чём-то неверные — но побуждают размышления.
Досталось в основном за однобокость собственного опыта, вернее описание собственного опыта всегда приветствовалось на хабре, а минуса — за то, что была сделана экстраполяция на все остальные области. И за то, что экстраполяция неверная — за это и получил обоснованную критику.
Alexins
07.06.2015 01:03+1Проблема не в том, быть ответственным лицом в проекте, чтобы вносить изменения, или предлагать эти изменения.
Скажу по себе. Многие мои идеи вошли в Apache Camel, правда идей было не так много. Тем не менее, личного кода там почти нет. И меня это совсем не смущает.
Кто чаще всего является ответственным за код? Я думаю, далеко не автор идеи, а тот, кто чаще отвечает на вопросы. А это люди уже с большим стажем работы.
Возьмем для примера закрытый проект в компании. Проект использует Git и корпоративный сайт GitLab. Вы выполняете работу и вносите свои изменения в ветку с номером вашего задания. Рядом может сидеть ваш товарищ по несчастью, который принимает решение о слиянии вашей ветки в основную ветку проекта. Вы хотите сами принимать решение о внесении десятка веток в основную ветку? Я скажу, как тот, кто сливает ветки в одном из проектов, я был бы рад передать часть этих забот на другого.
Это одна из причин, почему таких людей мало. Причина — скучная работа.
Вторая причина для мира OpenSource, это преподавательский навык на иностранном языке. Если вы будете предлагать хороший код, но не сможете объяснить свою цель, вас банально не поймут.
Простая ситуация. В одном из Open Source проектов, я предложил очень хорошую идею. Руководители проекта заинтересовались. Я предоставил код. Меня попросили предоставить тесты. Я написал тесты и даже кое что написал в JavaDoc. Следующий шаг — документация. Вот тут то я и скис. Описать на русском языке одно, а на английском, совсем другое.
ingumsky
08.06.2015 19:13+1Просите о помощи коллег, которые лучше знают английский. Это же open source, неплохие шансы, что помогут.
impwx
Почему фраза «релизится с мажорными фичами» вас не смущает, но committer(s) — исключительно по-английски? :)
epahomov Автор
Да на самом деле, если уж по совести делать, то все эти части должны быть на английском. Но тогда русскими останутся только союзы. Но тогда уже надо весь текст писать на английском. Но зачем, если только русско-язычной публике это интересно? Поэтому я выбрал что-то посередине.
SerafimArts
По-моему, «коммитер» и «контрибьютор» — это нынче такие же отечественные жаргонизмы\латинизмы, как и «фича», «деплой», «прод» и т.д. Лично мне «committer» безумно глаза режет.
epahomov Автор
Быть может и все же Вы написали «коммитер» с одной «т», а хабр опубликовал заметку с двумя «т». Так что не такой уж и устоявшийся латинизм
epahomov Автор
Намек понят, в следующий раз буду писать с латинизмами.
MacIn
И с «экспертизой» получилась полная ерунда. В русском языке «экспертиза» употребляется в контексте «была проведена баллистическая экспертиза». Английское expertise переводится в данном случае иначе:
expertise Прослушать
[??ksp???ti?z]
Существительное
специальные знания; компетентность; эрудиция (в какой-л. области)
человеческий опыт, знание дела
квалификация; компетенция
искусство, мастерство, умение; сноровка
Синоним: skill
— Переводится и как «экспертиза», но именно в значении, о котором я писал выше.
Schaman
Экспертность
MacIn
Зачем? Это искусственное, при том корявое словообразование. Не вижу этого слова в толковых словарях вообще.
Вот выше указаны хорошие варианты: «повысить уровень своей компетенции», «обладает бОльшим мастерством/более высокой квалификацией/более компетентен».
«вы увеличиваете свою экспертизу в нем» — «повышаете свой уровень компетенции в нем»
«обладает большей экспертизой в проекте» — «более компетентен в рамках данного проекта»
Сравните с «обладает большей экспертностью».
alexeibs
В слове committer второе t только для того, чтобы оно читалось, как «комитер», а не «комайтер». В русском языке такой необходимости нет
stepanp
Открываю коменты к очередной статье на «техническом» ресурсе, коим почему-то до сих пор считается хабр, и что я вижу? Правильно, срач на тему правописания.
fr33z3
Меня всегда жутко удивляло, что в статьях подобного рода, люди первым делом начинают обращать внимание на стилистику, нежели на саму суть написанной статьи. И это при всем при том, что не раз уже оговаривалось, что стилистические и грамматические замечания обычно отправляются автору в личку.
impwx
Чем сложнее читать, тем меньше шансов донести суть статьи.
fr33z3
Я согласен, но мне кажется для этого вполне сгодилась бы личка. Может быть я и не прав конечно.
MacIn
Просто таких моментов полно, в каждой второй статье. Каждый раз в личку не напишешь, а так всем видно. Ничего обидного в этих обсуждениях для авторов нет, в конце концов, это просто делает материалы на данном сайте лучше.