对“开源，提交补丁”的典型反驳是什么？[关闭]

在产品（特别是开源产品）上建议某些功能的危险是，您会得到响应，“为什么不这样做？”。

这是有效的，而且您可以自己进行更改很酷。但是，我们实际上知道，随着程序员倾听用户的声音，即使这些用户是其他程序员，产品也确实会不断进步。而且，进行这些更改的有效方法可以包括已经在项目中工作并接受并实现该想法的人员。

有一些常用术语用来指代软件开发问题。例如Bikeshedding。是否有一个通用术语基本上可以回答：“是的，我知道我可以改变世界上的几乎任何东西，甚至是封闭源代码。我都可以被雇用，然后去编写该代码。但是在这种情况下，我只是在做实际上对于另一位已经非常适合轻松进行更改的编码人员有用的观察，或者只是在讨论各种可能性。”

[ps（几天后）-我应该指出，“提交补丁”通常会用幽默的语气来表达，我正在寻求适当的机智回应。]

这很困难：由于用户不直接或间接购买产品，因此她无法要求实现功能。这并不是说您是订购产品的利益相关者或直接客户，甚至不是商业产品的最终用户。

也就是说，“提交补丁”不是有效的答案。这不是礼貌。不对 即使是开源产品。“提交补丁”是以下内容的简称：

“我们不在乎您是否喜欢我们的产品。如果需要，可以对其进行修改，但不要打扰我们满足客户的要求。”

提交补丁怎么办？

好吧，这不是那么容易。去做吧：

• 您必须知道开源项目中使用的语言。

• 您必须能够从版本控件中加载源代码，才能对其进行修改。

• 您必须安装所有构建依赖项的所有正确版本（包括运行时库和构建工具）。

• 您必须能够编译此源代码，在某些情况下，它不是很明显。尤其是，当一个大型项目需要几个小时来编译并显示482个错误和成千上万的警告时，您可能会很勇敢地寻找这些错误的来源。

• 您应该非常了解项目的完成方式，使用的编码风格（如果有的话），如何运行单元测试等。如果项目没有完善的文档（开放源代码项目通常就是这种情况） ），这可能真的很难。

• 您必须使自己适应项目以及积极参与该项目的开发人员的习惯。例如，如果您每天使用.NET Framework 4，但项目使用.NET Framework 2.0，则不能使用LINQ，代码契约或该框架最新版本的其他数千个新功能。

• 必须接受您的补丁程序（除非您仅自己进行更改，而无意与社区共享）。

如果您打算积极参与该项目，那么您可以做所有这些事情并为之投入时间。另一方面，如果只剩下一个烦人的小错误或一个简单的功能，花了数天，数周或数月的时间研究该项目，那么几分钟之内完成工作本身就是不合理的，除非您喜欢它。

那么，是否存在对“它是开源的，提交补丁程序”的规范反驳？我不这么认为。您要么向那个人解释她不礼貌，要么就停止跟她说话。

规范的反驳是提交补丁。

当开发人员认为他们不会在任何合理的时间范围内做某事时，这是标准答案，但它已经被反复提起。

反复提起它是最不公平的，但是最近提到的人并不知道，只是马上得到“我们正在为此修补”。在这种情况下，维护人员已经厌倦了讨论，但用户认为这是一个新主题。无论如何，最有可能的是，如果您立即获得“获取补丁”，则您不应该亲自处理它，而可能想通读档案和错误跟踪器以获取有关此问题的更多详细信息。

如果您自己反复提出请求，那么“获取补丁”可能是相对礼貌的轻描淡写，而不是一些不太礼貌的选择。

然后，当然会有一些粗鲁的维护者会说“打补丁”，而对任何人都没有任何解释，但是我会说这是少数。

如果您曾经维护过一个拥有大量用户的开源项目，那么您就会知道，与维护者相比，请求数量是维护者的100倍以上，其中许多请求对请求者来说很重要，但将非常困难，或会破坏许多其他用户，或者存在一些其他缺陷，这些缺陷只有对项目和代码库有全局了解才能看到。有时甚至只是判断调用，而要花很多时间来反复地争论每个人。

大多数非开源公司根本不会给您访问开发人员的权限，您只会从客户支持中获得无声的对待或礼貌而虚假的故事。因此，在开放源代码中，至少您可以有一些选择（付钱给某人编写功能代码等），尽管开发人员可能很粗鲁，但至少他们给出了直接的答案。我宁愿“不”，也不是通常的“它在我们的路线图上……[两年后]……它仍然在我们的路线图上”，我从许多供应商那里得到的东西……

所以我认为没有反驳。也许开源维护者真的很忙，也许是一个混蛋，但是无论哪种方式，他们都可能工作艰巨，进入“谁有生死话”的辩论也无济于事。您能做的最好的就是以某种方式做出贡献，并努力做到富有建设性。

也许这不是代码，但是可能有很多分析和文档记录您可以做的用户场景。当我维护GNOME窗口管理器时，很多时候对人们来说，考虑所有用户来分析问题，并真正写下问题的优缺点以及从全局的角度来看应该发生什么，对人们很有帮助。

（相反，通常的做法是开始大肆宣扬，好像他们是唯一重要的用户，并且没有权衡取舍。虽然这很好，而且是一个数据点，但我经常设法保持礼貌甚至最终解决他们的问题。燃烧不会使任何事情更快地发生，只会使情绪混乱，并浪费每个人的时间。

您收到此响应的原因不在于维护者抽搐，那就是你没有充分相信他们的价值主张的他们对工作的功能，为你。

最好的应对方法是就您的功能对整个社区的价值进行对话，以查看您是否可以说服他们改变主意。也许他们是对的，他们比您更了解自己的社区需求-但是，再一次，也许不是。

如果该功能仅对您有价值，而对社区却几乎没有价值，那么我会发现金钱是一种很好的动力，而抱怨他们的态度却不是。

对“开源，提交补丁”的典型反驳是什么？

没有合理的曲解可能会有所不同。试图说服志愿者做他们无意做的事情，这是在浪费您的时间，甚至更糟。

您的选择是：

• 做出回应所建议的；即实现该功能并将其作为补丁提交。这就是所谓的“回馈”。

• 寻找愿意为您实现真钱的人。可能是项目本身（例如，作为赞助的回报），与项目相关联的人员，或者是一些随机的“聘用编码员”。

• 寻找替代产品。

如果您在提出“有帮助的”建议时收到此回复，请考虑如果您穿着他的鞋子，您可能会如何回答。例如，如果您认为该建议不值得/考虑周全/可理解/等，但没有时间或耐心进行旷日持久的辩论，您将如何回应？

我参与了一个长期运行的开源OS项目，最令人讨厌的事情之一是坐在“花生画廊”中的人们，并向您推荐了一些有关“更好”的事情的建议：

• 不完整，无法理解或彻头彻尾的荒谬，
• 是没有成功机会的客观想法，
• 实施需要大量的精力，并且/或者
• 与项目既定目标背道而驰。

最好的应对方法通常是针对性地挑战该人以参与该项目……并希望他们能暗示……“举起或闭嘴”。不幸的是，最烦人的人甚至没有暗示。

当然，对这些人的另一个反应是根本不回应，或者完全不理them他们。

如果您和所讨论的程序员是平等的，并且对代码库和语言以及与您所指出的与此特定事物相关的所有其他事物都了解的差不多，那么响应将是合理的。

您不是平等的（或者您可能只是做到了），所以我建议适当的反驳是：

“我不可能尽你所能尽快做到这一点，这就是为什么我首先要求你帮助我的原因。拜托！”

我认为说“哦，是的，这是我花了很长时间并且非常擅长的事情，它是如此简单，以至于任何人都可以从街上走来做得很好，我可以。”

规范的反驳是分叉项目。

提交补丁的标准答案是：

“我没有所需的技能，经验或时间，所以请您告诉我将啤酒盒运送到可以为我做的那家伙那里”

提交全面的测试案例。

“如果您这样做，我将包括在内”比“不”要好得多。

如果您由于某种原因而无法执行该工作，请私下向项目维护者解释这种情况。

如果您不愿意以某种方式为您想使用的开源项目做出贡献，那么您应该寻找商业支持或其他商业产品。

“谢谢您的回应。”

因为：

• 在零价格下，需求（对功能的请求）超过供应（可用编码器实现所述功能）。
• 强加于免费提供的任何东西都缺少IMHO类。
• 这是FOSS的全部要点：人们自带蔬菜和肉类以增加石汤的营养。如果我什么都不能做，那我应该感谢我能吃得饱，而不要抱怨我的饮食没有改善。

你不用说什么 开发人员已做出响应的事实足以表明他们已经知道问题存在，并且这（至少对某些）用户造成了痛苦。

归根结底，如果您不想让开发人员为您工作，那么您所说的话不会说服他们。

一个好的开源项目将具有一个错误/功能请求系统，用户可以在其中提交错误/功能，其他人可以对其进行投票，以便维护人员可以确定对整个社区重要的内容。但是，使功能就位的最快方法是为其提交补丁。时间段...无法解决。

就我个人而言，我会回答“这是一个已知问题，但不幸的是，这不是一个很快就能解决的问题。开发人员正在研究其他问题。目前尚无ETA。”

“提交补丁”响应非常不礼貌，因为它假定了许多情况：

1. 程序的所有用户都是程序员，或者所有的错误报告者都是程序员。
2. 所有程序员都知道程序所使用的语言。
3. 所有程序员都知道任何程序可能遇到的每一种问题。
4. 所有程序员都有空闲时间来从事开源项目。

即使我们假设“提交补丁”的响应者已经知道了以上所有内容，这仅会使语句听起来像“我X个小时的时间比您要起床的时间多几个数量级。加快并解决问题”。

通常，当我询问开发人员遇到的问题或提交错误时，如果得到开发人员的粗鲁回应，我将停止使用该程序。例如，我不再使用uTorrent（不是开源的，但重点仍然是），因为我在其“支持”论坛上得到的答复是如此粗鲁。我提交了我在Bug报告论坛中遇到的问题。该线程立即被链接到另一个线程的链接所锁定，该链接与某个线程中的相似但不同的问题有关（当然也被锁定了）。同时，我在一般讨论论坛上打开了一个线程，询问是否有人找到解决该问题的方法。在保存该线程并返回来查看我的第一个线程已被花费的时间中，我的常规线程已被锁定，并且我的论坛帐户因破坏性行为而被禁止。我卸载了uTorrent，此后再也没有回来。

仅仅回答“提交补丁”是IMO的粗鲁做法，但是...如果您将开放源代码软件用于任何严重的事情，则必须准备好在有需要时对其进行照顾。

以下内容基于Apache FOP的Jeremias Maerki 的帖子：

如果某些方法对您不起作用，则有几种选择：

• 这是开源的：您可以自己修复。
• 如果您自己无法解决问题，则可以等到有人有空闲时间并认为实施起来很有趣。
• 如果那没有发生，您可以找到或雇用某人为您做。

我认为这是“提交补丁”答案的非常有效的完整版本。

每次看到此内容，我都会立即开始寻找替代产品。对我来说，这是一个危险的信号，表明维护人员要么不在乎他们的用户（如果您的项目在任何地方都被使用，那就不好了），要么对项目失去兴趣。这两种情况通常都意味着该项目很快就会死掉，或者由于开发商拒绝推进该项目而陷入停滞状态

（请注意，我并不是说您在运行此类响应时看到的第一个错误报告。您必须查看总体趋势。如果大多数错误报告都以这种响应结尾，请遵循以下建议。只是少数几个，然后这些是最有可能不符合项目目标的功能请求，或者是非常特定于使用的）

正如@MainMa所说，开始为一个全新的项目做出贡献非常困难。大多数开发人员不理解这一点，因为他们已经在该项目上工作了几个月/几年，这对他们来说很有意义。有时这可能是一个诚实的错误。

我偶尔开玩笑说，免费软件可以像啤酒一样免费，可以像言论一样免费，也可以像得到付款一样免费。

虽然我开玩笑地说（我在一家使用大量OSS的公司工作），但我认为那里是一个事实-如果您想要商业级别的支持，那么您需要使用具有适当支持协议的商业软件，或者找到一个开源软件解决方案，可以为您提供这种级别的支持（通常是通过向某人​​付款来提供支持，但有可能通过您的组织使用或分配开发资源来进行支持）。

“提交补丁”真是令人气愤，但它强调了有关OSS的某些内容，也许应该提醒人们，OSS在每种情况下都不适合每个人，至少在没有确保您有一个坚实的支持框架的情况下（在内部，通过社区付费或通过社区付费）。

我们经常想到的软件在啤酒中是免费的，但在语音中却是免费的（即非开放式免费软件）。也许是在这种情况下，我们应该像语音软件一样免费地考虑软件，而不是啤酒。

切换到维护良好的替代方案。

根据我在维护良好的开源项目中的经验，如果您创建定义良好的错误报告或功能请求，那么实现它的可能性就很高。

“我一次只能处理一件事情，但是我可以一次抱怨很多事情。我认为这两个功能都很有用。” - 关于ycombinator的akka​​rtik。

我认为，当一个人从事一个项目，提供发行和支持时，开发人员和用户之间就形成了一种默契的，隐含的支持合同。开发人员承担了为用户支持代码库的隐含责任，包括根据要求添加功能。

我认为，“提交补丁”基本上是在向用户伸出援手。这是上下文相关的-有时实施起来会花费太多的精力，有时会破坏现有项目或导致费用过高的肌炎，或许多其他原因。但是，最终，它说的是“拧紧您，不要这样做”。在我看来，这在某种程度上是违反了这份潜规则。

有几种方法可以完成。

• 专题提案和投票。但这需要时间。

• 被需要修补程序的公司雇用。显然，这是最好的解决方案，但请准备与制作要升级的开源软件的人合作。

• 找出为什么不首先实现该功能也很重要。通常，该功能不属于软件项目的范围：团队不希望使用此功能，觉得自己没有必要，或者他们只是认为这不是做某事的好方法。在这种情况下，您应该只是分叉项目并自己进行。

• 使用可满足您需求的专有软件。

• 请记住，OOP软件通常会简化集成功能的过程。

• 在邮件列表，irc或论坛上发牢骚只会激怒程序员，并会给OSS支持者带来弹药。

您无话可说会让他做到这一点。毕竟，他为什么要这么做？因为一个用户的愿望？原因还不够好。

但是，如果您可以收集合理数量的用户并给出合理的理由（“我想要它”不是合理的理由。）为什么该功能可能有用，通常对于您和其他许多人，他可能会改变主意。

虽然，还有一个特殊情况必须考虑。一个开发者。厌倦了开发应用程序，慢慢地希望放弃它（还有其他事情要做），因此他慢慢地放弃了功能要求。除了frm试图说服他发布代码外，在这种情况下，即使对于上述情况，您实际上也无能为力。

尤其是开源项目，即使新功能并未出现在官方发行版中，也很容易获得奖金或为特定功能的开发提供资金。

另外，是的，发布开源背后的想法之一是，任何人和所有人都有权利和责任做出自己的贡献。

使用封闭源时，最好的资源是从用户群中收集具有统计意义的重要组，这些组需要像您想要的解决方案。

以我的经验，如果用户请求不符合项目目标，通常会给出此响应。当人们认为您将实现他们向您提出的所有建议，甚至更多的事情时，就会发生这种情况-免费，开源和美好而美好的未来。

“提交补丁”是一个相对不礼貌的响应（当然应该避免。特别是在这种简洁明了的形式中。有很多方式可以表达大致相同的消息-例如“邀请”用户提供帮助，因为您没有时间自己实施）。但实际上，这是一个明显的“不要浪费我的时间”的指标。因此，您对此无能为力，也没有“规范”的回应。

我能想到的最好的应对方法是实际展示一个补丁。假设您的补丁程序有效，您至少已经证明了这个想法并非完全不切实际。通常，这意味着项目负责人将重新考虑该提案。

对于不符合项目目标的想法，“提交补丁”是合法的。从长远来看，最好只是告诉您想法很糟糕，或者您试图将项目用于超出预期范围的事情，但是，“嘿，如果您认为您的要求如此琐碎，为什么不这样做？” “您尝试将其适合我们现有的代码库”有时是合适的。

如果这是次要的并且确实对项目的预期用户有用，则只需提交错误报告，清楚地​​描述问题，给出重现步骤，指示您使用的是当前的每晚版本，然后就此保留。

看起来可能是一个小的简单更改，可以帮助大量的用户，但实际上，这是一个巨大的痛苦，除了您之外，没人会使用。这是“提交补丁”的最佳情况。

也有可能您遇到了一个臭名昭著的glibc维护者这样的案例，他似乎一心一意地认为他的系统是宇宙，他对规范的解释是神的话，而这一切就是它，无论有多少人会选择其他方式。

我建议创建一个用于在RentACoder / ELance / etc等网站上实现该功能的项目，并将其发布在原始开源项目的论坛上。开源项目中的任何程序员，包括作者，现在都可以从财务上考虑到您的请求。

我实际上报名只是为了回答这个问题。

是否需要蒸煮？当开发人员知道该问题但认为不重要时，通常使用此响应。

我会给你一个活生生的例子。ubuntu放弃了对系统托盘的支持（但是可以通过白色列出一个应用程序来解决），并添加了新的应用程序指示器。诸如jupiter之类的某些应用程序依靠系统托盘支持，因此开发人员向工作人员介绍了workaournd而不是添加应用程序指示器支持，因此我要求开发人员添加应用程序指示器支持，回复为“向我们发送补丁”。在询问他们选择不执行这个原因的时候。有这个

我没有兴趣花时间建立对我永远不会使用的库的支持，这仅仅是因为有很多钱的人通过将我的应用程序功能列入他的Linux发行版而将其列入黑名单，只是因为他可以。

如果这是一个真正的技术问题，我可能会采取行动，但这纯粹是政治手段，所以不，我不这么认为。

不，我将其列入白名单

很公平。开发人员有理由不实施功能，但愿意接受补丁。这并不是很粗鲁和冒犯性的，因此不需要反驳。

底线：规范的反驳将是提交补丁，但如果不能，则无需反驳

为您想要的功能启动赏金。

或者，当发现市场营销与您的期望不符时，出去购买声称能完全满足您要求的产品，并滥用他们的支持人员。

我能想到的最好的是“你很烂”。

抱歉，这显然不是很有帮助，但是我认为这只是用户完全被搞砸的不幸情况之一。对开发人员的良心残酷诚实的呼吁是最后的努力。

您可以尝试提供（咳嗽）“捐赠”来解决您的问题，但是我担心，这种习惯如果普遍存在，将会导致行业中真正的诚信严重受损，因为错误修复永远都不会使您获利。 “免费”或商业软件。