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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Потому что:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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