Pull to refresh

Comments 48

Почему фраза «релизится с мажорными фичами» вас не смущает, но committer(s) — исключительно по-английски? :)
Да на самом деле, если уж по совести делать, то все эти части должны быть на английском. Но тогда русскими останутся только союзы. Но тогда уже надо весь текст писать на английском. Но зачем, если только русско-язычной публике это интересно? Поэтому я выбрал что-то посередине.
По-моему, «коммитер» и «контрибьютор» — это нынче такие же отечественные жаргонизмы\латинизмы, как и «фича», «деплой», «прод» и т.д. Лично мне «committer» безумно глаза режет.
Быть может и все же Вы написали «коммитер» с одной «т», а хабр опубликовал заметку с двумя «т». Так что не такой уж и устоявшийся латинизм
Намек понят, в следующий раз буду писать с латинизмами.
И с «экспертизой» получилась полная ерунда. В русском языке «экспертиза» употребляется в контексте «была проведена баллистическая экспертиза». Английское expertise переводится в данном случае иначе:
expertise Прослушать
[ˌɛkspɜːˈtiːz]
Существительное

специальные знания; компетентность; эрудиция (в какой-л. области)

человеческий опыт, знание дела

квалификация; компетенция

искусство, мастерство, умение; сноровка
Синоним: skill

— Переводится и как «экспертиза», но именно в значении, о котором я писал выше.
Зачем? Это искусственное, при том корявое словообразование. Не вижу этого слова в толковых словарях вообще.

Вот выше указаны хорошие варианты: «повысить уровень своей компетенции», «обладает бОльшим мастерством/более высокой квалификацией/более компетентен».

«вы увеличиваете свою экспертизу в нем» — «повышаете свой уровень компетенции в нем»
«обладает большей экспертизой в проекте» — «более компетентен в рамках данного проекта»

Сравните с «обладает большей экспертностью».
В слове committer второе t только для того, чтобы оно читалось, как «комитер», а не «комайтер». В русском языке такой необходимости нет
Открываю коменты к очередной статье на «техническом» ресурсе, коим почему-то до сих пор считается хабр, и что я вижу? Правильно, срач на тему правописания.
Меня всегда жутко удивляло, что в статьях подобного рода, люди первым делом начинают обращать внимание на стилистику, нежели на саму суть написанной статьи. И это при всем при том, что не раз уже оговаривалось, что стилистические и грамматические замечания обычно отправляются автору в личку.
Чем сложнее читать, тем меньше шансов донести суть статьи.
Я согласен, но мне кажется для этого вполне сгодилась бы личка. Может быть я и не прав конечно.
Просто таких моментов полно, в каждой второй статье. Каждый раз в личку не напишешь, а так всем видно. Ничего обидного в этих обсуждениях для авторов нет, в конце концов, это просто делает материалы на данном сайте лучше.
Open Source для меня — это модель разработки ПО, которая не основана на личных интересах определенной группы людей или компаний. Проект открытый потому, что улучшить его может любой человек, а власть коммитера только в том, что он может одобрить хороший патч и отклонить плохой.

Если в проект вступает интерес работодателя, то это не Open Source. Хорошо, что есть кпопка «форк».
Есть open source проекты в которых не участвуют интересы никаких компаний. Они на мой вкус позорят звание top level apache проекта. Например Oozie без нормальной документации архитектуры и поддержки спарка до недавнего времени, или big top который отстает от контейнерной революции, спарка, ambari, и вообще всего на свете.

Как мне кажется это связано с тем, что никто их не коммерциализирует или не завязан на них в своей архитектуре настолько, чтобы вкладывать силы в развитие.
Коммерциализация проекта ни при чём. Меня смутили эти строки в тексте:
Он может «протащить» в проект патч, выгодный его работодателю. Он может забанить патч, если он не выгоден. Он может определять пути развития проекта.
В словах «крупный опенсорсный проект» автор основной упор ставит на слово «крупный» (а вы — на «опенсорсный»), отсюда и вся разница в подходах.
В крупном проекте сталкиваются не два-три человека — а миллионы людей, поэтому уместно говорить в терминах «политика», когда приходится согласовывать разные мнения.
Вам не нравится слово «протащить свой патч», коробит от того, что есть люди, которые могут определять пути развития проекта?
Полагаю, что напрямую «забанить» патч — редкая ситуация. Можно мягко откладывать (давая своей компании время подготовиться), можно согласовывать разные варианты. Не надо демонизировать власть коммитера: в опесорс всегда можно форкнуть проект и попытаться доказать, что твоё видение, твой фреймворк — лучше, чем у фреймворка, который пользуется миллионной популярностью и который поддерживают гранды.
В крупном проекте сталкиваются не два-три человека — а миллионы людей, поэтому уместно говорить в терминах «политика», когда приходится согласовывать разные мнения.
Миллионы, наверно, используют этот крупный проект, а модернизирует (присылает патчи, багрепорты) значительно меньшее количество людей.
Вам не нравится слово «протащить свой патч», коробит от того, что есть люди, которые могут определять пути развития проекта?
Да, меня это коробит. С такой политикой управления os-проектом можно было просто-напросто держать его в компании и нанимать других программистов, чтобы они исправляли найденные ошибки.

Не понимаю, зачем откладывать улучшение, если в продакшене можно использовать старую версию, а через время переписать код под новую?
Миллионы, наверно, используют этот крупный проект

Допустим, для 70% из этих миллионов без разницы, что за фичи в проекте и, увы, вообще даже не обновляются по актуальной версии. Но ведь есть же некоторое количество людей, которое не просто использует этот проект, а ждёт реализации очередной фичи.
Поэтому интересы есть есть у всех — и у активного меньшинства и у пассивного большинства, которое промолчит, но в случае чего проголосует ногами и уйдёт на другой проект через некоторое время.

Давайте конкретный пример для наглядности. Есть opensource-бразуер Firefox. Была альтернатива: поддержать стандарт от гугл, но не встраивать проприетарный кодек H.264, либо поддержать проприетарный кодек, на котором уже много весьма завязано в мире (не в самом firefox). Microsoft и Cisco предлагают одно решение, гугл — третье. Попробуйте сказать, что бы вы сами выбрали бы на месте Mozilla Foundation? Вы бы наверное не поддержали бы ни одного из крупных вендоров, а купили бы программистов, чтобы они реализовали свой собственный кодек, с блэкджеком и всем-чем-полагается.
Какой-то непонятный фанатизм от спарка. И контейнеры ради контейнеров и какой-то революции — тоже не понятно.
> Open Source для меня — это модель разработки ПО, которая не основана на личных интересах определенной группы людей или компаний.

Точно так же основана, а баги вообще могут десятилетиями висеть просто потому что неинтересны разработчикам. Далеко не все так радужно.
Open Source для меня — это модель разработки ПО, которая не основана на личных интересах определенной группы людей или компаний.
Основана, так или иначе. Просто она обычно представляет интересы большей группы людей и компаний. Бывают исключения: например, проекты экосистемы jboss'а, там всё печально, несмотря на open source.

Если в проект вступает интерес работодателя, то это не Open Source.
Если исходники открыты — то это open source, по определению. Хотя и не FOSS. Но и в FOSS могут преследоваться интересы работодателя (начиная от увеличения качества и стабильности продукта), что не является чем-то страшным или необычным.
На мой вкус это 2 разные истории — когда компания просто выкладывает свой код в опен сорс, и когда она делает свой продукт реально опен сорсным. Второе подразумевает — внутри перейти на опен сорс версию, развивать и работать с коммунити, формировать набор комитеров за пределами своей компании, и для некоторых проектов может — пойти под «зонтик» того же Apache для следования стандартам индустрии(традиции версионирования, мейлинг листы, стандарты CI)

В яндексе настолько вкладываются как мне кажется только в BEM(и в него вкладываются довольно профессионально на мой вкус). Я не знаю, но представляю каким интересам компании это может соответствовать — стандартизировать верстку, чтобы иметь возможность легче потом все интегрировать в свои поисковые снипеты, или верстать проще(?) Опять же плохо знаю этот фреймворк. Но в нем наверно я вижу черты нужды в committers про которые я говорил.
Вот вот, я вряд ли смогу набиться в коммитеры кокаина, для этого нужно будет устроиться в Яндекс работать, а я может уже в другом месте работаю, но использую кокаин и хочу его улучшать не только исправлениями багов.
А почему не получится стать коммиттером за пределом яндекса?
Но опять же — тот же cocaine и BEM не стандарт индустрии как тот hadoop или cassandra. А хочется играть со всем ребятами, а не в своей песочнице.
По-моему, вас заклинило на Apache Software Foundation. Есть другой открытый код, под другими лицензиями, с другими целями. Полно разработчиков из России, участвующих в разработке отрытого и свободного ПО.
Для мобильных разработчиков например можно сказать, что ничего нет :(
UFO just landed and posted this here
Не согласен с таким подходом: взять один проект, да еще выросший из внутренней разработки Berkley. Почему бы не посмотреть статистику? Россия на 8м месте по числу коммитов в Github, что весьма неплохо.

P.S. А вы, уважаемый автор, куда коммитите, если не секрет?
Можете пояснить — это карта коммитев или коммитеров? Потому что я писал о коммитерах, а не коммитах. Здесь мне кажется не учитывается размер проектов, что на мой вкус важно. Я полтора года назад вконтрибутил немного кода в главный класс спарка — RDD — и это было сравнительно просто. Сейчас даже тесты в MLLib не вмерживают из-за того, что есть коммитерами одобреная гуглодока стратегии развития этого куска кода и мой код туда не вписывается. Надо писать обоснование, получать одобрение на интерфейсы… Проект стал большой. Теперь контрибутить нетревиальные вещи — большой труд. И эти виды коммитов как мне кажется надо разделять.

P.S. насчет статистики. Я верю что это аккуратные цифры и они репрезнтуют что-то. Но есть исследование StackOverflow которое дает иную картину — stackoverflow.com/research/developer-survey-2015. Я не буду спорить на уровне больших цифр — я не компетентен. Я могу только сказать про проекты в которых я копал откуда растут эти фичи и что оттуда еще должно вырасти.

Я контрибьючу немного в Спарк, немного раньше в Zeppelin. Делал патчи в Solr но их (правильно на мой вкус) не приняли.
Там вся легенда прописана — это именно карта по числу пользователей, при этом в России число коммитов на пользователя почти вдвое больше, чем в среднем по гитхабу, так что по коммитам все еще «краснее». Статистика по коммитам и по пользователям идет по краю карты.

Я наблюдаю совсем другую картину — наши люди коммитят в ядра Linux и FreeBSD, создают nginx и продукты конкурирующие с теми, что вы используете. Или посмотрите, например, кто коммитит в MySQL.
Еще раз. Они туда коммитят или являются коммитерами? Я в своей статье пытался показать, что это разные вещи.

Очень может быть что наши картины различаются ибо мы смотрим на разные проекты. Из-за этого не совпадают ощущения. но прежде чем делать такой вывод посмотрите являются ли Ваши соотечественники коммитерами и работают ли они в Российских компаниях
Да, есть в том числе и коммитеры. И да, они работают в Российских компаниях.
Здорово. Значит просто зависит от проекта.
А как связано количество спрашивающих и отвечающих на StackOverflow с числом коммитов или коммиттеров в OpenSource?
Интересная статья, спасибо! За ссылки на докерконтейнеры тоже!

Zeppelin пробовал недавно — показался пока сыроватым (судя по отзывам — не мне одному), хоть и виден хороший потенциал.
rambler — nginx
badoo — memcache и много чего для php
sphinx — аксёнова
percona — mysql и его стек
mailru — tarantool
jetbrains — kotlin
yandex — cocaine
vk — kPHP
Энвижен крупно вложился в postgre

На всякий случай поясню, поскольку похоже есть еще люди, кто не в курсе дел.

Rambler отношения к NGINX не имеет. Игорь в Рамблере не работал программистом, а с 2011 и вовсе там не работает. NGINX это уже 4-ый год как NGINX, Inc.
Энвижен круто вложившийся в постгре… так бы и писали Postgresql Professional
То что в проприетарном проекте обычно первый шаг — обратится непосредственно к автору кода, является самым крайним шагом в open source.
Не соглашусь. Часто смотрят и на всякий SO, и пишут в user@, что не очень далеко от обращения к разработчику.
Наблюдения в общем и целом интересные, но слишком много апачевского гадю… зоопарка. Наверное, это свой волшебный мир, но со стороны оно выглядит очень душераздирающе.

Что же касается opensource — да, именно так. Добавим ещё то, что айтишников в России не так уж и много (в абсолютных числах). Математика простая: 300кк население США, 700кк — население Европы. В РФ — всего 130кк. Очевидно, что при одинаковой концентрации айтишников, на 10 европейских будет приходиться один русский. При этом концентрация сильно разбавляется синдромом «всё или ничего» (то есть большая компания или фрилансеры), т.к. в РФ очень мало средних успешных контор.

А на одних мажорах много опенсорса не вытянешь — самих мажоров по пальцам пересчитать.
Статья в целом интересная, хоть и очень неоднозначная. Автор в некоторых комментариях хапнул минусов совершенно заслуженно, однако знаете — в целом дал повод ещё раз задуматься над некоторыми вопросами, я всё же иногда за то, чтобы услышать и альтернативные мнения, которые в чём-то неверные — но побуждают размышления.
Досталось в основном за однобокость собственного опыта, вернее описание собственного опыта всегда приветствовалось на хабре, а минуса — за то, что была сделана экстраполяция на все остальные области. И за то, что экстраполяция неверная — за это и получил обоснованную критику.
Проблема не в том, быть ответственным лицом в проекте, чтобы вносить изменения, или предлагать эти изменения.
Скажу по себе. Многие мои идеи вошли в Apache Camel, правда идей было не так много. Тем не менее, личного кода там почти нет. И меня это совсем не смущает.
Кто чаще всего является ответственным за код? Я думаю, далеко не автор идеи, а тот, кто чаще отвечает на вопросы. А это люди уже с большим стажем работы.
Возьмем для примера закрытый проект в компании. Проект использует Git и корпоративный сайт GitLab. Вы выполняете работу и вносите свои изменения в ветку с номером вашего задания. Рядом может сидеть ваш товарищ по несчастью, который принимает решение о слиянии вашей ветки в основную ветку проекта. Вы хотите сами принимать решение о внесении десятка веток в основную ветку? Я скажу, как тот, кто сливает ветки в одном из проектов, я был бы рад передать часть этих забот на другого.
Это одна из причин, почему таких людей мало. Причина — скучная работа.
Вторая причина для мира OpenSource, это преподавательский навык на иностранном языке. Если вы будете предлагать хороший код, но не сможете объяснить свою цель, вас банально не поймут.
Простая ситуация. В одном из Open Source проектов, я предложил очень хорошую идею. Руководители проекта заинтересовались. Я предоставил код. Меня попросили предоставить тесты. Я написал тесты и даже кое что написал в JavaDoc. Следующий шаг — документация. Вот тут то я и скис. Описать на русском языке одно, а на английском, совсем другое.
Просите о помощи коллег, которые лучше знают английский. Это же open source, неплохие шансы, что помогут.
Sign up to leave a comment.

Articles