Что такое каноническая реплика на «это открытый исходный код, отправьте патч»? [закрыто]

215

Опасность когда-либо предлагать какую-либо функцию для продукта, особенно с открытым исходным кодом, заключается в том, что вы получите ответ: «Почему бы вам не сделать это?».

Это действительно так, и это здорово, что вы можете внести изменения самостоятельно. Но мы практически знаем, что продукты часто улучшаются, поскольку программисты прислушиваются к голосу пользователей - даже если эти пользователи являются другими программистами. И эффективный способ внести эти изменения может включать кого-то, кто уже работает над проектом, взяв идею и осуществив ее.

Есть некоторые общие термины, используемые для обозначения проблем разработки программного обеспечения. например, велосипедная прогулка . Используется ли общий термин, который по существу отвечает: «Да, я знаю, что могу изменить практически все в мире - даже с закрытым исходным кодом. Я мог бы быть нанят и пойти написать этот код. Но в этом случае я просто делаю наблюдение, которое на самом деле может быть полезным для другого кодировщика, уже хорошо приспособленного для того, чтобы легко внести это изменение - или просто для общего обсуждения возможностей ».

[ps (несколько дней спустя) - я должен был указать, что «представить патч» часто говорят с кривым юмором, и я ищу подходящий остроумный ответ.]

Винсент Шейб
источник
16
Хотелось бы, чтобы я проголосовал за это не раз! (И это исходит от кого - то , кто имеет . Представленный заплаты кучки различных проектов и получил их принято считать , что отношение вы описать это просто раздражает!)
Мейсон Wheeler
62
Я предполагаю, "Как я выгляжу, безработная обезьяна кода? У меня есть жизнь!" неприемлемая реплика ;-)
Стивен А. Лоу
12
По моему опыту, ответ «отправить патч» обычно приходит после того, как разработчик уже объяснил, почему добавление этой функции нецелесообразно.
user16764
7
@ Стивен, зависит от того, хочешь ли ты оскорбить или заставить их делать то, что тебе нужно. Я считаю, что это не оптимальная стратегия, если вы хотите последнюю.
12
@orokusaki: Или D) Они считают эту функцию менее ценной, чем другие функции, над которыми они могли бы работать, и у них ограниченные ресурсы.
Дэвид Торнли

Ответы:

115

Это сложный момент: так как пользователь не платит прямо или косвенно за продукт, он не может просить о реализации функции. Это не так, как если бы вы были заинтересованным лицом или прямым клиентом, который заказал продукт, и даже не являлись конечным пользователем коммерческого продукта.

При этом «отправить патч» не является правильным ответом. Это не вежливо. Это не правильно. Даже для продукта с открытым исходным кодом. «Отправить патч» - это короткая версия:

«нам все равно, нравится вам наш продукт или нет. Идите и измените его, если хотите, но не беспокойте нас своими запросами клиентов».

Как насчет отправки патча?

Ну, это не так просто. Сделать это:

  • Вы должны знать язык (и), используемые в проекте с открытым исходным кодом.

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

  • У вас должны быть установлены все правильные версии любых зависимостей сборки (включая библиотеки времени выполнения и инструменты сборки).

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

  • Вы должны очень хорошо понимать, как выполняется проект , какой стиль кодирования использовать, если таковой имеется, как выполнять модульные тесты и т. Д. Если у проекта нет достойной документации (что часто имеет место для проектов с открытым исходным кодом) ), это может быть действительно сложно.

  • Вы должны адаптироваться к проекту и к привычкам разработчиков, которые активно участвуют в проекте. Например, если вы используете .NET Framework 4 ежедневно, но в проекте используется .NET Framework 2.0, вы не можете использовать ни LINQ, ни Code Contracts, ни другие тысячи новых функций последних версий Framework.

  • Ваш патч должен быть принят (если вы не вносите изменения только для себя, без намерения поделиться им с сообществом).

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

Так есть ли каноническая реплика на «это открытый исходный код, отправьте патч»? Я так не думаю. Либо вы объясняете человеку, что она невежливая, либо просто перестаете с ней разговаривать.

MainMa
источник
9
Это звучит так, как будто он написан кем-то, у кого нет опыта в поддержке проекта с открытым исходным кодом.
Рейн Хенрикс
46
@Rein: Поддержка проекта с открытым исходным кодом ничем не отличается от поддержки любого другого проекта. У вас есть клиенты. Если вы игнорируете этих клиентов, они перестанут давать вам ценные отзывы, и они пойдут куда-то еще за своими решениями. Может быть, это нормально для людей с открытым исходным кодом, но я бы точно хотел знать, буду ли я полностью ответственным за исправление ошибок в программном обеспечении с открытым исходным кодом, потому что это заставит меня дважды подумать об его использовании.
Роберт Харви
17
@ Rein: Ну, до сих пор я слышал, как ты дважды говорил, что мы не знаем, о чем говорим. Может быть, вы можете просветить нас, а?
Роберт Харви
8
@ Рейн Хенрикс: Ваши первые два комментария - это атаки "ad hominem". Если между ними есть различия, скажите, кто они, а не говорите, что другие люди ничего не знают.
Эндрю Гримм
13
Я подозреваю, что целью было «Поддержание проекта с открытым исходным кодом ничем не отличается от поддержки любого другого проекта в отношении прослушивания отзывов клиентов и сохранения их доброй воли». Если это так, я полностью готов отказаться от него, но, как человек, который поддерживал несколько проектов FOSS, от нескольких до сотен участников, я нахожу первоначальное общее утверждение «неправильным».
Рейн Хенрикс
79

Каноническая реторта должна представить патч.

wnoise
источник
47
Или, еще лучше, сказать: «Я уже сделал это шесть месяцев назад. Когда вы, ребята, собираетесь приступить к рассмотрению и принятию решения?»
Боб Мерфи
14
Обычно мне не нравятся короткие ответы, но это серьезно - единственный способ ответить, который гарантированно закончится тем результатом, который вы ищете. Они четко заявили о наилучшем способе достижения вашей цели. Зачем дурачиться с каким-то меньшим решением?
19
-1 открытый мудак ответ. Не полезно. (Извините.) Канонической «реторты» нет. Лучший ответ (при условии, что OP не может просто отправить патч, что, на мой взгляд, является разумным допущением в этом случае), это один из следующих вариантов: (1) «У меня нет возможностей или ресурсов для генерации патча [и, возможно, я ссылка на этот самый вопрос] ", (2) круг глаз, отсутствие ответа, использование инструмента в его текущем состоянии или (3) поиск лучшего инструмента.
JohnL4
1
Это не обязательно должен быть патч. Предоставление подробных и уточненных отзывов также имеет значение. Все это говорит о том, что не ожидайте, что я потрачу свое время на покрытие ваших конкретных потребностей, если вам нечего предложить взамен.
Эван Плейс
67

Это стандартный ответ, когда разработчики не думают, что им удастся что-то сделать в любое разумное время, но это неоднократно выдвигалось.

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

Если вы неоднократно выдвигаете запрос самостоятельно, «принятие патчей» потенциально может быть относительно вежливым, по сравнению с некоторыми менее вежливыми альтернативами ...

И, конечно же, есть грубые сопровождающие, которые скажут «брать патчи» без объяснения причин, но я бы сказал, что это меньшинство.

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

Большинство компаний с открытым исходным кодом вообще не предоставляют вам доступ к разработчикам, и вы просто получите молчаливое обращение или вежливую, но поддельную историю от службы поддержки. Таким образом, в открытом исходном коде, по крайней мере, у вас есть несколько вариантов (платите кому-то за кодирование функции и т. Д.), И хотя разработчики могут быть грубыми, по крайней мере, они дают прямые ответы. Я предпочел бы иметь "нет", чем обычно ", это в нашей дорожной карте ... [2 года спустя] ... это все еще в нашей дорожной карте" вещь, которую я получил от ряда поставщиков ...

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

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

(Вместо этого обычно начинали разгореться, как будто они были единственным пользователем, который имел значение, и не было никаких компромиссов. И хотя это было здорово, это было назначение данных, и часто мне удавалось оставаться вежливым или даже в конечном итоге решить их проблему ...) Пламя не заставляет что-либо происходить быстрее, оно просто смешивает эмоции с проблемой и тратит время каждого.)

Havoc P
источник
4
@Aaronaught Я принимал участие в сотнях проектов с открытым исходным кодом и не заметил DIY как ответ по умолчанию. Это ответ на определенный вкус запроса.
Havoc P
2
Все, что я говорю, я думаю, чаще всего, есть причина, по которой сопровождающий, по крайней мере, немного устал от темы (или человека), прежде чем он скажет «исправления», и может быть стоит выяснить, почему вы получил этот ответ. Это мой опыт, fwiw. Если здесь речь идет о случаях, когда нет причин болеть за тему или человека, то, конечно, «принятие исправлений», вероятно, не является хорошей вещью для сопровождающего. Люди делают ошибки. Я все еще говорю, я сомневаюсь, что реплика (или мета-обсуждение, как это) поможет, но иногда может быть конструктивным.
Havoc P
5
Кроме того, хотя это можно сформулировать более или менее вежливо, если у сопровождающего есть в запасе отставание в работе, у него, вероятно, есть одна вещь, которую он может получить для себя, на каждые 100 вещей, для которых он бы взял патч, потому что он хотел бы характерная черта; и затем есть еще одна категория изменений, которые они отклонят, даже если кто-то другой сделает эту работу. Так что должен быть какой-то способ сообщить: «Я бы принял это изменение, но у меня нет планов делать это самому». Некоторые люди здесь, кажется, считают, что «Конечно, подходит» - единственный приемлемый ответ. Но «исправления» - это настоящая категория.
Havoc P
2
@ Ага, это звучит как хорошие фразы. Я думаю, что часто «обида / грубость» не подразумевается, «мы бы взяли за это патч», но программисты, как правило, не являются наиболее эмоционально чувствительными типами, они могут спешить по электронной почте, а тон не очень хорошо передается по тексту, так что легко встретить как краткий.
Havoc P
2
На самом деле, «мы бы заплатили за это» отличается двумя тонкими, но важными способами: (1) он не возлагает ответственность непосредственно на пользователя , и (2) он признает, что запрос был серьезно рассмотрен, несмотря на то, что он не был реализованы. Хотя итоговый результат по сути тот же, это гораздо более гуманный ответ. (Тем не менее, не помешало бы явно добавить подразумеваемое ... но у нас нет ресурсов, чтобы завершить это непосредственно сейчас. )
Aaronaught
43

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

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

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

Рейн Хенрикс
источник
15
Конечно, возможно они придурки. Этот ответ сам по себе не очень точный индикатор, так как он также используется не-рывками, когда спрашивающий является рывком.
Рейн Хенрикс
4
Я также хотел бы добавить, что в отсутствие денег вы часто можете обменять натурой на какую-то работу: помогите сортировать занятую очередь вопросов, зависать на IRC-канале и оказывать поддержку, тестировать исправления или писать документацию. Проекты с открытым исходным кодом имеют ограниченные ресурсы и должны максимально использовать их. Добавление функции жизнеспособно, если это важно для достаточного количества людей или важно для людей, которые делают / дают достаточно. Если ваш случай не первый, сделайте его вторым.
HedgeMage
2
Честно говоря, лучший способ убедить разработчика - показать ему, сколько из его пользовательской базы хочет эту функцию. Багтрекеры с голосованием, темами форумов и т. Д. Очень хороши для этого и используются во многих проектах с открытым исходным кодом.
ProdigySim
4
Точно так же, когда люди получают RTFM или DAFS в качестве ответа или -1 на SE, это происходит потому, что спрашивающий не убедил адекватно ответчика в ценностном предложении ответить на его вопрос для них . Я уверен, что многие из вас могут относиться к этому чувству.
Рейн Хенрикс
1
@Walter Да, именно поэтому я предложил убедить человека в «ценности вашей функции для его сообщества в целом».
Рейн Хенрикс
31

Что такое каноническая реплика на «это открытый исходный код, отправьте патч»?

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

Ваши варианты:

  • Делайте то, что предлагает ответ; т.е. реализовать функцию и представить его в виде патча. Это называется «отдать что-то обратно».

  • Найдите человека, который хотел бы реализовать эту функцию для вас за реальные деньги. Это может быть сам проект (например, в обмен на спонсорство), кто-то, связанный с проектом, или какой-то случайный «кодер по найму».

  • Найдите альтернативный продукт.


Если вы получили этот ответ, когда сделали «полезное» предложение, подумайте, как бы вы ответили, если бы были на его месте. Например, как бы вы ответили, если бы думали, что это предложение не имеет смысла / хорошо продумано / понятно / и т.д., но у вас нет времени или терпения, чтобы участвовать в затяжных дебатах?


Я принимал участие в длительном проекте ОС с открытым исходным кодом, и одна из самых раздражающих вещей - это люди, которые сидят в «арахисовой галерее» и предлагают вам множество советов о том, как сделать «лучше», что:

  • являются неполными, неразборчивыми или совершенно бессмысленными,
  • неопробованные идеи с объективно низким шансом на успех,
  • потребует огромных усилий для реализации и / или
  • противоречат заявленным целям проекта.

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

Конечно, другой ответ таким людям - вообще не отвечать или полностью игнорировать их.

Стивен С
источник
7
«Как бы вы ответили, если бы думали, что это предложение не стоит / хорошо продумано / понятно / и т. Д.» - именно так реагирует любой другой профессионал. «Не могли бы вы объяснить / привести несколько примеров того, что вы просите?» или "Не могли бы вы рассказать, почему вы думаете, что вам нужна эта функция?" или "Что если бы мы вместо этого сделали это, сработало бы это для вас?" или как насчет «Спасибо за ваше предложение, мы рассмотрим его в будущем выпуске». Это базовые навыки межличностного общения, а не ракетостроение.
Aaronaught
12
@Aaronaught - Извините, но вы не поняли. Типичный разработчик открытого исходного кода не имеет времени участвовать в вежливых, но в конечном счете бессмысленных дискуссиях, направленных на то, чтобы поразить эго его «клиентов»; то есть притворяется заботливым, когда полуинтеллектуальный человек может понять, что все это фасад. И, честно говоря, я нахожу, что такая вежливая вежливость эго покровительствует ... и более оскорбительна, чем прямое объяснение, что у них нет шансов внедрить XYZ.
Стивен С.
6
@kurige - на самом деле, если бы люди, о которых идет речь, отправляли патчи, они ОБЯЗАТЕЛЬНО были бы рассмотрены. Проблема в том, что люди, о которых идет речь, «все устали»; то есть не заинтересованы в том, чтобы приложить какие-либо усилия
Стивен С.
10
Потому что у типичного разработчика с открытым исходным кодом уже есть работа, и они занимаются разработкой с открытым исходным кодом для развлечения. Делать то, что другие люди хотят, чтобы вы делали, это работа. Делать то, что ты хочешь делать - это весело.
ProdigySim
8
@Aaronaught: нужно ли уважительно относиться к большому количеству рывков? На государственной службе будут люди, которые предъявляют необоснованные требования, часто в оскорбительной форме. Работа с невежливыми дураками может быть настоящей болью. Требование быть уважительным по отношению к ним вынудит многих людей отказаться от бизнеса F / OS, и это будет потеря для всех.
Дэвид Торнли
20

Ответ был бы разумным, если бы вы и рассматриваемый программист были равны и знали примерно то же самое о базе кода и языке, а также обо всех других вещах, имеющих отношение к этой конкретной вещи, на которую вы указываете.

Вы не равны (или вы, вероятно, просто сделали бы это), поэтому я бы предложил правильную реплику:

«Я никак не могу сделать это так быстро и хорошо, как ты можешь, поэтому я попросил тебя помочь мне в первую очередь. Пожалуйста!»

Я полагаю, что это противоречит фундаментальной человеческой природе: «О да, эта вещь, на которой я потратил много времени и в которой я действительно хорош, настолько проста, что любой может прийти с улицы и сделать такую ​​же хорошую работу, как и я». Я могу ".

оборота user1249
источник
За исключением того, что на самом деле они не говорят. Они говорят: «Это то, что вы хотите, это не то, чего хочет сообщество, поэтому нам не очень интересно работать над этим. Мы можем принять патч, если вы захотите поработать над этим». Подразумевается, что «мы также можем изменить свое мнение, если сообщество этого захочет». Помните, что «Я хочу, чтобы вы мне помогли » идет вразрез с фундаментальной природой проектов с открытым исходным кодом , где (чтобы вынести всю силу моих невзгод из Звездного пути), благо многих всегда перевешивает благо немногих.
Рейн Хенрикс
Ну, если эти немногие имеют много денег, исторически говоря.
Рейн Хенрикс
2
@ Рейн, нет, они говорят, что ОНИ не хотят этого делать. Все это "сообщество хочет" - просто соломенный человек. Все дело в том, что один из сообщества требует его.
1
«Чрезвычайно невежливо предлагать написать патч, если вы не знаете заранее, что - если он выйдет - вы бы рассмотрели его для своего продукта». Согласовано. Как я уже сказал, именно поэтому я не использую этот ответ. Я могу сочувствовать этому, хотя. «Если вы искренне подразумеваете, что« отправить исправление »предназначено для того, чтобы замолчать людей вместо делегирования работы, то вы соглашаетесь с тем, что об этом попросил член сообщества, а не разработчик». Я не совсем уверен, что ты здесь говоришь, извини.
Рейн Хенрикс
1
@ Торбьерн Ах, да. Ну, на самом деле мейнтейнеры с открытым исходным кодом, с которыми я знаком, конечно, так не считают. На самом деле, мы изо всех сил стараемся предоставить руководящие указания для разработчиков и документацию, чтобы помочь людям изучить проект и условные обозначения для его вклада именно потому, что мы знаем о недостатке навыков. Например, rubini.us/doc/en/contributing
Рейн Хенрикс
16

Каноническая реторта должна раскошелиться на проект.

user16764
источник
8
или отправьте патч
Kamil Szot
2
Что хорошего принесет вам разветвление?
1
@Thorbjorn: каждый может использовать хорошую вилку время от времени. Даже жалкая вилка.
user18014
15

Канонический ответ «отправить патч»:

«У меня нет необходимых навыков, опыта или времени, поэтому не могли бы вы сказать мне, куда доставить ящики с пивом парню, который может сделать это для меня»

gbjbaanb
источник
13

Представьте комплексный контрольный пример .

alecco
источник
1
Мне нравится этот, однако, это часто занимает больше времени, чем отправка самого патча! Здесь константа - это время для ознакомления с базой кода и, скорее всего, самая большая часть либо создания теста, либо написания патча напрямую!
Newtopian
1
Мне нравится этот ответ для ошибок. Даже если вы недостаточно разбираетесь в структуре, чтобы представить исправление, это сэкономит огромное количество времени тому, кто это делает. Нет ничего менее вероятного, чтобы заставить меня исправить проблему, чем неопределенная и невоспроизводимая «ошибка», которая может быть просто неправильно настроенной системой. Нет ничего, что заставило бы меня перейти к проблеме быстрее, чем простой тестовый пример, поэтому я могу быстро попробовать различные исправления.
BobMcGee
11

«Если вы сделаете это, я включу это» гораздо лучше, чем «нет».

Если вы не можете выполнить работу по той или иной причине, объясните это обстоятельство лично руководителю проекта.

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

yfeldblum
источник
5
Таким образом, только те, кто вносит непосредственный вклад, имеют право жаловаться на ошибку или отсутствующую функцию? Хорошо, я думаю, но это также означает, что ни участники, ни пользователи не имеют права жаловаться на отсутствие усыновления.
Aaronaught
@Aaronaught Нет, они имеют право жаловаться, но есть ограничение на количество неоплачиваемого времени, которое разработчик может инвестировать в проект, и пользователям важно это понимать. В своей собственной работе я оставляю за собой «я бы приветствовал запрос исправления / извлечения» для функций, которые имеют паршивые предложения в отношении усилий / сообщества. Или там, где пользователь настаивает на том, что он получает функцию ПРЯМО СЕЙЧАС и не уважает чужое время или другие обязательства по проекту.
BobMcGee
10

"Спасибо за ответ."

Потому что:

  • При нулевой цене спрос (запросы на функции) превышает предложение (доступные кодеры для реализации указанных функций).
  • Тряпки по всему, что предоставляется бесплатно, не хватает класса ИМХО.
  • В этом вся суть FOSS: люди, приносящие овощи и мясо, чтобы добавить пищу в каменный суп. Если я не могу что-то внести, я должен быть благодарен, что я могу есть вообще, и не жаловаться, что я не ем лучше.
Джон
источник
9

Вам не нужно ничего говорить. Тот факт, что разработчики ответили, является достаточным свидетельством того, что они уже знают, что проблема существует, и это причиняет боль (по крайней мере, некоторым) пользователям.

В конце концов, ничего, что вы скажете, не убедит разработчика работать на вас, если он этого не хочет.

Дин Хардинг
источник
9

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

Майкл Браун
источник
8

Лично я предпочел бы получить ответ: «Это известная проблема, но, к сожалению, эта проблема не решается в ближайшее время. Разработчики работают над другими проблемами. В настоящее время ETA отсутствует».

Ответ «отправить патч» очень грубый, так как предполагает несколько вещей:

  1. Все пользователи программы являются программистами или все репортеры ошибок являются программистами.
  2. Все программисты знают язык, на котором написана программа.
  3. Все программисты знают о любой проблеме, которая может возникнуть у любой программы.
  4. У всех программистов есть свободное время для работы над проектом с открытым исходным кодом.

Даже если мы предположим, что создатель ответа «представить патч» знает все вышеперечисленное, это просто звучит так: «Х часов моего времени стоит больше, чем на порядки часов вашего времени, которые вы должны были бы поднять» чтобы ускорить и решить проблему ".

Обычно, когда я получаю грубый ответ от разработчика, когда я спрашиваю о проблеме, которую я имею, или отправляю ошибку, я прекращаю использовать эту программу, Я больше не использую uTorrent (не с открытым исходным кодом, но суть остается), например, потому что ответы, которые я получил на их форуме «поддержки», были настолько грубыми. Я отправил сообщение о проблеме на форуме об ошибках. Поток был немедленно заблокирован ссылкой на другой поток о похожей, но другой проблеме в потоке (который также был заблокирован, конечно). Тем временем я открыл ветку на форуме общих дискуссий с вопросом, нашел ли кто-нибудь обходной путь для решения проблемы. За то время, которое потребовалось, чтобы сохранить эту тему и вернуться и увидеть, что моя первая тема была заблокирована, моя тема в общем заблокирована, а моя учетная запись на форуме заблокирована за нарушение работы. Я удалил uTorrent и с тех пор не вернулся.

Бекон Биты
источник
Вы имеете в виду «я бы предпочел получить ответ», а не «я бы не получил»?
Эндрю Гримм
Спасибо за первый абзац в частности. Удивительно, как такая базовая форма профессиональной вежливости может быть чужда многим людям. Независимо от того, получаете вы деньги или нет, соответствующий ответ - подтвердить проблему и объяснить ее статус (даже если статус «отложенный»).
Aaronaught
8

Просто ответить «отправить патч» - это грубо для ИМО, но все же ... если вы используете программное обеспечение с открытым исходным кодом для чего-то серьезного, вы должны быть готовы позаботиться об этом в случае необходимости.

Следующее основано на посте Джеремиаса Маерки (известности Apache FOP):

Если что-то не работает для вас, у вас есть несколько вариантов:

  • Это открытый исходный код: вы можете исправить это самостоятельно.
  • Если вы не можете это исправить самостоятельно, вы можете подождать, пока у кого-то не появится свободное время, и он подумает, что это интересно реализовать.
  • Если этого не произойдет, вы можете найти или нанять кого-нибудь, кто сделает это за вас.

Я думаю, что это очень верная полная версия ответа «отправить патч».

Bertrand Delacretaz
источник
6

Каждый раз, когда я вижу это, я сразу начинаю искать альтернативный продукт. Для меня это опасный признак того, что сопровождающие либо не заботятся о своих пользователях (плохо, если ваш проект используется повсеместно), либо потеряли интерес к проекту. Оба из них обычно означают, что проект скоро умрет или будет страдать от стагнации, так как разработчики отказываются продвигать проект вперед

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

Как сказал @MainMa, начать вносить вклад в совершенно новый проект очень сложно. Большинство разработчиков не понимают этого, так как они работают над проектом месяцами / годами, и для них это имеет смысл. Иногда это может быть честной ошибкой.

TheLQ
источник
3

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

Хотя я говорю это в шутку (я работаю в компании, которая часто использует OSS), но я думаю, что в этом есть доля правды - если вам нужна поддержка на коммерческом уровне, вам нужно либо использовать коммерческое программное обеспечение с подходящей поддержкой, либо найти программное обеспечение с открытым исходным кодом, которое обеспечивает вам такой уровень поддержки (обычно через кого-то, которому платят за его предоставление, но, возможно, через вашу организацию, использующую или назначающую ресурс разработки для работы над ним).

«Отправить патч» приводит в бешенство, но в нем подчеркивается кое-что о OSS, и, возможно, это должно быть напоминанием о том, что OSS не подходит для всех в любой ситуации, по крайней мере, не убедившись, что у вас есть надежная структура поддержки (или внутри, оплачивается или через сообщество).

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

Джон Хопкинс
источник
2

Переключитесь на ухоженную альтернативу.

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

vartec
источник
2
Отчеты об ошибках и запросы функций часто недостаточно четко определены. Мой опыт показывает, что компетентность и уважение работают хорошо. Кроме того, в лучшем случае будет рассмотрен четко определенный запрос. Это может считаться низким приоритетом, или это может быть то, что группа проекта явно не хочет делать (есть хорошие примеры в FAQ по PuTTY, и хороший список запросов функций, сгруппированных по категориям).
Дэвид Торнли
1

«Я могу работать только над одной вещью за раз, но я могу жаловаться на многие вещи одновременно. Я думаю, что обе функции полезны». - аккартик на йкомбинатор .

Винсент Шейб
источник
1

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

По моему мнению, «Отправить патч» - это, по сути, указание пользователям. Это контекстно - иногда это просто слишком много усилий для реализации, иногда это может привести к разрушению существующего проекта или возникновению острого креатурита, или по любой другой причине. Но, в конечном счете, он говорит: «Винт, не делай этого». Что, на мой взгляд, на каком-то уровне является нарушением этого невысказанного контракта.

Пол Натан
источник
Это не договор, если обе стороны не получат что-то. Проекту обычно нужны хорошо выполненные отчеты об ошибках и часто хорошо выполненные запросы функций, а не все, что приходит в соответствие с этой целью неявного контракта.
Дэвид Торнли
1
@Aaronaught: они предоставляют бесплатное тестирование, только если они представляют отчеты об ошибках, достаточно подробные для работы. Я видел свою долю плохих отчетов об ошибках. Они могут или не могут обеспечить хорошую рекламу. Большинство людей, которые используют F / OSS, не дают ничего полезного, что хорошо, но это, конечно, не одна сторона контракта.
Дэвид Торнли
1
@ Дэвид: Не могли бы вы перестать пытаться ограничить разговор только самыми трудными / непродуктивными пользователями? Если мы собираемся обобщать, то это обобщение должно быть для всей базы пользователей и участников как коллектива; выпуская публику, вы получаете всех этих людей. В обмен на благо, которое вы получаете от многих из них, вы получаете некоторые проблемы от многих других. Это жизнь.
Aaronaught
1
@Aaronaught: Если мы собираемся обобщать, мы должны убедиться, что мы обобщаем правильно. Я не пытаюсь ограничить разговор худшими пользователями, просто указываю, что они там. Большая часть разговоров, кажется, предполагает, что все пользователи являются участниками в некотором роде, и это просто не соответствует действительности. Если мы будем говорить только о пользователях, которые полезны для проекта, то будет справедливо говорить только о членах команды проекта, которые обычно вежливы.
Дэвид Торнли
2
@ Дэвид: Очевидно, что есть некоторые пользователи и сторонние участники, которые помогают, а также некоторые, которые вызывают проблемы. Очевидно, что есть некоторые разработчики, которые вежливы и профессиональны в той мере, в которой это позволяют здравый смысл и хорошие навыки управления временем, а также есть разработчики, которые являются грубыми и непрофессиональными по привычке. Это был вопрос о том, как бороться с последней группой разработчиков. Существование «проблемных пользователей» не оспаривается, но это красная селедка, которая не служит никакой цели, кроме как сорвать обсуждение, создавая состязательную ситуацию - поэтому давайте оставим это в покое.
Aaronaught
1

Есть несколько способов сделать это.

  • Особенность предложения и голосования. но это требует времени.

  • Получить работу в компании, которая нуждается в этом, чтобы сделать патч. Очевидно, что это лучшее решение, но будьте готовы сотрудничать с парнем, который делает программное обеспечение с открытым исходным кодом, которое вы хотите обновить.

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

  • Используйте проприетарное программное обеспечение, которое делает то, что вы хотите.

  • Помните, что программное обеспечение ООП часто облегчает процесс интеграции функции.

  • Скулящий на список рассылки, на irc или на форуме просто разозлит программистов и даст боеприпасы сторонникам OSS.

jokoon
источник
0

Вы не можете сказать ничего такого, что заставит его сделать это. В конце концов, почему он должен? Из-за пожеланий одного пользователя? Это не достаточно хорошая причина.

Но если вы можете собрать разумное количество пользователей и привести рациональные причины («Я хочу это» - не рациональная причина.), Почему эта функция может быть полезна, в целом, и вам, и ряду других, он просто может передумать ,

Хотя есть и особый случай, который нужно рассмотреть. Это разработчик устал от разработки приложения, медленно желает отказаться от него (есть другие дела), и поэтому он медленно отказывается от запросов функций. Помимо попыток убедить его выпустить код, в этом случае вы практически ничего не можете сделать, даже в отношении вышеизложенного.

ладья
источник
В качестве альтернативы, у разработчика достаточно запросов функций, чтобы занять его до конца века, он хотел бы включить свой, но не предвидит, что получит его в ближайшее время.
Дэвид Торнли
@ Дэвид Торнли - Это тоже.
Ладья
0

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

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

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

апалала
источник
2
Право вносить, да, но последний раз , когда я прочитал GPL это ничего о не говоря ответственности за конечные пользователи , чтобы сделать свой вклад. Это немного надумано, не правда ли?
Aaronaught
0

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

«Отправить патч» - это довольно грубый ответ (и его, конечно, следует избегать. Особенно в этой краткой и четкой форме. Есть много способов выразить примерно одно и то же сообщение - например, «пригласить» пользователей помочь, потому что вы нет времени, чтобы реализовать это самостоятельно). Но как есть, это четкий индикатор «Хватит тратить мое время». Таким образом, вы ничего не можете с этим поделать, и нет «канонического» ответа.

Лучший ответ, который я могу придумать, - это представить патч . Предполагая, что ваш патч работает, вы по крайней мере доказали, что идея не является полностью нереальной. Обычно это означает, что люди, отвечающие за проект, пересмотрят предложение.

Александр Гесслер
источник
1
Я не думаю, что какой-либо разработчик должен ответить «отправить патч» относительно запроса, который не соответствует цели проекта. Это более нечестно, чем грубо. Либо программное обеспечение становится раздутым, и разработчик ненавидит вас за это, либо он не принимает патч и эффективно тратит ваше время. Последнее более вероятно. Разработчик должен честно сказать: «Мы не хотим это менять, потому что ____» и покончить с этим.
Рей Миясака
@ Rei Miyasaka: Лично я был бы в ярости, если бы получил «отправить патч», выполнил работу, чтобы сделать патч хорошего качества, а затем мне сказали, что они все равно не хотят использовать эту функцию.
Дэвид Торнли
@ Дэвид Да, а? Я бы бросил стул или два.
Рей Миясака
0

«Отправить патч» - это законная стрижка идей, которые не вписываются в цели проекта. Возможно, в конечном итоге лучше просто сказать вам, что идея - отстой, или вы пытаетесь использовать проект для чего-то далеко за пределами его предполагаемой области, но «эй, если вы думаете, что вы спрашиваете, настолько тривиально, почему бы и нет? вы пытаетесь вписать его в нашу существующую кодовую базу "иногда уместно.

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

То, что может показаться незначительным простым изменением, которое могло бы помочь многим пользователям, на самом деле может быть огромной болью в заднице, которую никто не использовал бы, кроме вас. Это лучший случай для «представить патч».

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

Кевин Петерсон
источник
Я не думаю, что кто-то решил бы задать этот вопрос, если бы знал, что изменение будет огромной болью в заднице, используемой только одним человеком. Поэтому вместо «представить патч», почему бы не вежливо и кратко объяснить, почему это так важно и не может быть сделано немедленно.
Мистер Шикаданс
2
«Отправить патч» делает паршивое мошенничество, так как возможно, что кто-то отправит патч. Он должен быть зарезервирован для низкоприоритетных товаров.
Дэвид Торнли
0

Я бы предложил создать проект для реализации этой функции на таких сайтах, как RentACoder / ELance / и т. Д., И опубликовать ее на форуме проекта с открытым исходным кодом. Любой из программистов в проектах с открытым исходным кодом, включая автора, теперь имеет финансовый стимул для рассмотрения вашего запроса.

Ренджи Паникер
источник
-1

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

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

Я дам вам живой пример. Ubuntu прекратил поддержку systray (но обойтись можно, если добавить приложение в белый список) и добавил новые индикаторы приложений. некоторые приложения, такие как jupiter, полагались на поддержку systray, поэтому разработчик рассказал о рабочем ресурсе, а не о добавлении поддержки индикаторов приложений, поэтому я попросил разработчика добавить индикатор приложений, добавив, что ответ «Пришлите нам исправления». на вопрос о причине, по которой они решили не реализовывать это. было это

Я не заинтересован в том, чтобы тратить свое время на создание поддержки для библиотеки, которую я никогда не буду использовать только потому, что кто-то, у кого много денег, требует этого, помещая в черный список мои приложения для правильной работы в своем дистрибутиве Linux просто потому, что он может.

Если бы это была настоящая техническая проблема, я бы, вероятно, принял меры, но это чисто политический маневр, так что нет, я так не думаю.

Нет, я просто внесу это в белый список

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

Итог: каноническая реторта должна была бы представить патч, но если вы не можете, нет необходимости в реторте

Lincity
источник
-1

Начните щедрость за функцию, которую вы хотите.

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

CyberFonic
источник
-2

Лучшее, что я могу придумать, это «ты сосешь».

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

Вы могли бы попытаться предложить ( кашлять ) «пожертвования», чтобы решить вашу проблему, но я боюсь, что такая практика, если она станет распространенной, приведет к серьезной потере целостности в отрасли, поскольку исправление ошибок никогда не должно приносить прибыль, либо для «Бесплатное» или коммерческое программное обеспечение.

Рей Миясака
источник