Планирование членов проекта с открытым исходным кодом для исправления ошибок и функций

У меня есть проблема с решением, которое, как я думаю, займет 4 дня, но если бы у меня был отсортированный запрос функции и был выпущен снимок, я бы подумал, что мог бы сделать это в одном. Поверхностно это создает бюджет в 3 раза по моей ежедневной ставке, чтобы заставить его выполнить запрос функции.

Итак, мои вопросы: вы когда-нибудь платили участнику проекта O/S, чтобы что-то исправить? Это нормально? Как вы продали идею своему менеджеру/коллегам и откуда пришли деньги?

Самое главное, как вы поступили хорошо? Есть ли этикет для этих вещей? Возможно ли, что руководители проекта воспримут эту идею?

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

Ответ 1

На работе у нас была удача нанимать разработчиков с открытым исходным кодом для расширения библиотек, которые мы используем.

Вот несколько проектов, которые мы делали в прошлом:

Нам нужно было интегрировать Quake 2 с wxWidgets. Мы наняли Вадима Зейтлина, главного вкладчика в wxWidgets. Менее чем за 4 дня он построил виджет wxQuake2, адаптировав версию Quake 2 для Windows.
Позже нам понадобился переносимый доступ к сырым растровым изображениям. Поэтому мы снова наняли Вадима и вместе с ним работали над созданием нового raw bitmap API. Это связано с существенной конструкторской работой, но нам очень понравился полученный API, и мы используем его по сей день.
Позднее мы наняли еще одного из основных участников для улучшения поддержки доступности wxWidgets. Как оказалось, мы не сразу использовали этот код по различным техническим причинам. Но с тех пор другие люди улучшают этот код, и мы надеемся однажды его использовать.

Другими словами, найм разработчиков с открытым исходным кодом во многом напоминает наем любого другого подрядчика. Но некоторые вещи немного разные. Вот несколько советов, основанных на нашем опыте:

У вас будет больше всего удачи, если вы хотите улучшить существующий проект и опубликовать изменения как открытый.
В общем, вы хотите нанять членов основной команды. У них лучшие записи о треках, они самые производительные, и у них есть все шансы, что ваши изменения будут объединены вверх по течению.
Вы хотите, чтобы ваши изменения были объединены вверх по течению. Если вы этого не сделаете, вы будете поддерживать локальную вилку, которая является головной болью.
Перед наймом, сделайте некоторые исследования. Кто работает над функциями, которые вас интересуют? Это кому-то, с кем вам понравится работать? Прочитайте списки рассылки и взгляните на историю управления версиями и выберите несколько человек, чтобы приблизиться.
На этапе проектирования может быть немного отдачи. Разработчики смотрят на большее здоровье проекта, и вы смотрите на потребности конкретного бизнеса. Это иногда делало переговоры для нас более сложными, но конечный результат, как правило, был лучшим дизайном, чем мы бы выбрали сами.

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

И если вы все еще не решаетесь подойти к кому-то, вы всегда можете спросить: "Вы знаете кого-нибудь, кто был бы заинтересован в том, чтобы платить за работу над $FEATURE?" Если они не заинтересованы, вы не поставили их на месте, и они могут сказать вам, кто спросить.

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