Pull to refresh

Comments 12

Получается, что развитие оперсорсного продукта с точки зрения бюрократии и скорости разработки ничем не отличается от коммереского продукта большой фирмы, а то ещё и более замедлено, так?
Я бы сказал, что «it depends». Вероятно, это сильно зависит от жизненного цикла продукта в продуктовой среде и от самого community. К примеру, для облачной платформы, которую без реальных стендов с железом, инфраструктурой, довольно проблемно протестировать (не все может быть сделано через unit-тесты и интеграционные тесты) развитие будет идти медленно. Если, вы делаете условный Minio, бежать можно быстрее.

В целом, сам процесс переноса фич в основное дерево может идти очень медленно, хотя бы в силу того, что дизайн фич делается одними людьми, а их валидация и подтверждение другими. Те фичи, которые, к примеру, делает ShapeBlue, которые проходят через их кухню, вполне вероятно, что пройдут в master быстрее, чем мои.

Короче, я не знаю как однозначно ответить на ваш вопрос)
Да ну нафиг это ваше программирование. Пойду на токаря учиться…

А что мотивирует Вас тратить своё время на это?
Я за открытые продукты и хочу развивать свой и мне не всегда понятно, что может двигать человеком, который сам захотел внести вклад в развитие продукта.
Что получает этот человек взамен?

Как я уже написал ранее, я сам использую Apache CloudStack в бизнесе, поэтому у меня есть непосредственный интерес в фичах и багфиксах. Я решил отправлять свои изменения в мэйнстрим, чтобы иметь к ним доступ в будущих релизах.

Если я не буду этого делать, значит, что я не смогу использовать новые релизы CloudStack, поскольку это потребует портировать все мои изменения в новые релизы, что будет весьма затруднительно.

Исправление ошибок, добавление новых фич, локализация.

В первую очередь мотивирует личное использование продукта, и как следствие необходимость в новых фичах и исправленных багах.
Кроме того, причиной может быть желание добавить дополнительную ценную строчку в резюме. Например, как мне кажется, наличие патчей в том-же ядре Linux может оказаться весьма ценной строчкой в резюме.

Иван, Помогите разобраться, кто является лидером в опен сорс проекте и кто принимает решения какие PR мержить и когда?

В каждом проекте свои правила игры, и зачастую ответ на этот вопрос не так уж тривиален. Мало того, внутренние войны между участниками, имеющими право на запись, тоже могут иметь место, как следствие, даже влитый код вполне может быть revert'нут другим человеком…

Здравствуйте. В широком смысле, кому владелец проекта дал права на запись, тот и может сливать изменения. Каждый проект имеет свою оргструктуру, например для Apache Software Foundation есть PMC: https://www.apache.org/dev/pmc.html


Состав PMC обновляется, PMC решает у каких контрибьюторов достаточно морального права и технического опыта для внесения изменений в репозиторий. Кто-то из них и сливает после двух авторизованных подтверждений.


Если у вас в проекте другая организация, то и процессы могут быть иными.

UPD: важно еще разделять типы OSS-проектов. На мой взгляд можно выделить как минимум:

— квази-OSS — компания открывает свой продукт, сообщество неактивное, состоит из постоянных разработчиков компании, плюс нескольких активистов со стороны;

— user-based OSS — типа CloudStack, компактная группа основных пользователей совместно разрабатывает продукт под свои нужны, спонсируя своих разработчиков;

— community-based OSS — большАя группа контрибьюторов как от компаний, так и от индивидуальных разработчиков;
Поддерживаю автора, участие в крупных OpenSource проектах чаще боль, чем розовые порхающие бабочки…
С другой стороны наличие у человека принятых патчей в крупный проект, лично я бы рассматривал как огромный плюс к квалификации этого самого человека, поскольку это показывает насколько грамотно человек может аргументировать свою позицию и насколько хорошо умеет разбираться с чужим кодом.
А уж если человек сумел продавить новую фичу (а не просто исправил баг), то это уже плюс с восклицательным знаком…
Sign up to leave a comment.

Articles