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

#1 楼

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

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


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


提交补丁程序怎么样？

好吧，这并不容易。为此：


您必须了解开源项目中使用的语言。
您必须能够从版本控件中加载源代码，以便能够能够对其进行修改。
您必须安装所有构建依赖项的所有正确版本（包括运行时库和构建工具）。
您必须能够编译此源代码，这不是很明显在某些情况下。尤其是，当一个大型项目需要花费几个小时来编译并显示482个错误和成千上万的警告时，您可能会很勇敢地寻找这些错误的来源。
您应该非常了解该项目的完成方式，使用的编码风格是什么（如果有的话），如何运行单元测试等。如果项目没有像样的文档（对于开放源代码项目通常如此），这可能真的很难。
您必须使自己适应该项目以及积极参与该项目的开发人员的习惯。例如，如果您每天使用.NET Framework 4，但是该项目使用.NET Framework 2.0，则不能使用LINQ，代码契约或该框架最新版本的其他成千上万的新功能。
必须接受您的补丁程序（除非您仅自己进行更改，而无意与社区共享）。

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

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

#2 楼

规范的反驳是提交补丁。

#3 楼

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

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

自己反复提出请求，“取补丁”可能是比较礼貌的方式，而不是一些不太礼貌的选择...

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

如果您曾经与很多用户一起维护过一个开源项目，您就会知道请求数量是维护人员无法达到的100倍，其中许多请求对于请求者很重要，但将非常困难，或者会破坏许多其他用户，或者存在一些其他缺陷，这些缺陷只有在全球范围内才能理解项目和代码库。有时甚至只是判断性呼吁，而且要花很多时间来反复争论每个人。

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

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

也许这不是代码，但是可能可以进行很多分析和记录用户场景。当我维护GNOME窗口管理器时，很多时候人们去考虑所有用户的全局分析问题，并真正写下问题的优缺点以及从全局的角度来看应该发生什么，这对人们很有帮助。 />
（相反，通常的做法是开始大肆宣传，好像他们是唯一重要的用户一样，没有权衡取舍。尽管这很棒，而且是一个数据点，但我常常保持礼貌甚至最终解决他们的问题...燃烧不会使任何事情更快地发生，只会使情绪混乱，并浪费每个人的时间。

#4 楼

收到此回复的原因不是维护者是混蛋，而是您没有充分说服他们他们为您的功能工作的价值主张。

最好的回应是开始有关您的功能对整个社区的价值的对话，以查看您是否可以说服他们改变主意。也许他们是对的，他们比您更了解自己的社区需求-但是，也许再也没有。

如果该功能仅对您有价值，而对您却毫无价值在社区中，我发现金钱是一种很好的动力，而抱怨他们的态度却并非如此。

#5 楼

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


没有合理的反驳可能会有所不同。试图说服志愿者去做一些他们无意做的事情会浪费您的时间，甚至更糟。

您可以选择的方法是：


做出回应所建议的；即实施该功能并将其作为补丁提交。这就是所谓的“回馈”。
找到愿意为您实现真钱的功能的人。可能是项目本身（例如，作为赞助的回报），与该项目相关的人员，或者是一些随机的“出租编码员”。
找到替代产品。


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


我参与了一个长期运行的开源OS项目，最烦人的事情之一是坐在“花生画廊”中的人们，并向您提供了一些“做得更好”的建议。 ”，即：


是不完整，难以理解或彻头彻尾的荒谬，
是未成功的想法，客观上成功的机会很少，
需要付出大量的努力才能实施和/或
与项目的既定目标背道而驰。

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

当然，对这类人的另一种反应是根本不作出反应，或者完全不理them他们。

#6 楼

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

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

“没有办法可以像您一样快速和出色地做到这一点可以，这就是为什么我要您首先帮我的原因。拜托！“

我相信说“哦，是的，这件事我花了一个时间长了，而且真的很擅长，它是如此简单，以至于任何人都可以从街上走出来，尽我所能做好工作。”

#7 楼

规范的反驳是分叉项目。

#8 楼

“提交补丁”的规范答案是：


“我没有技能，经验
或所需的时间，所以您可以
告诉我
啤酒箱要运到哪里给我做的人”

#9 楼

提交全面的测试用例。

#10 楼

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

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

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

#11 楼

“感谢您的回应。”

原因：


在零价格下，需求（对功能的请求）超过了供应（可用编码器实现上述功能）。
免费提供的免费食物缺乏IMHO等级。
这是FOSS的全部重点：人们自带蔬菜和肉类以补充石汤营养。如果我什么都做不了，那我应该很感谢我能吃得饱，而不要抱怨自己的饮食没有改善。

#12 楼

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

最后，您所说的没有如果他们不想的话，将说服开发人员为您工作。

#13 楼

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

#14 楼

我个人希望得到“这是一个已知问题，但不幸的是，这不是一个很快就能解决的问题。开发人员正在研究其他问题。目前没有ETA。”

“提交补丁”响应非常粗鲁，因为它假定了很多情况：


该程序的所有用户都是程序员或所有错误报告者是程序员。
所有程序员都知道程序所使用的语言。
所有程序员都知道任何程序可能遇到的各种问题。
所有程序员都可以自由工作开源项目。

即使我们假设“提交补丁”响应的制作者都知道以上所有内容，这简直只是使该声明听起来像“我的X个小时所花的价值超过数量级”您会花费更多的时间来加快速度并解决问题”。

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

#15 楼

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

以下内容基于Jeremias Maerki（Apache FOP的名声）的帖子：


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


这是开源的：您可以自己进行修复。
如果无法自己进行修复，则可以等到有人有空闲时间并认为实施起来很有趣。
如果这样做不可行碰巧，您可以找到或雇用某人为您做这件事。



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

#16 楼

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

（请注意，我并不是说您看到的第一个错误报告您运行这种响应。您必须查看总体趋势。如果大多数错误报告都以这种响应结尾，那么请遵循此建议。如果仅是少数几个，则最有可能是不适合的功能请求a项目目标或非常特定于用途的项目）

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

#17 楼

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

我开玩笑地说（我在一家使用很多OSS），但我认为这是个事实-如果您想要商业级别的支持，那么您需要使用具有适当支持协议的商业软件，或者找到一个可以提供该级别支持的开源软件解决方案（通常通过有报酬提供它的人，但有可能是通过您的组织雇用或分配开发资源来工作的。）

“提交补丁”确实令人发指，但它突显了有关OSS的某些内容，也许应该提醒一下OSS在每种情况下都不适合每个人，至少在没有确保您有一个可靠的支持框架（内部，付费或通过社区）的情况下如此。

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

#18 楼

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

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

#19 楼

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

#20 楼

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

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

#21 楼

有几种方法可以完成。


功能提案和投票。但这需要时间。
被需要补丁的公司雇用。显然，这是最好的解决方案，但准备与要升级开源软件的人合作。
找出为什么不首先实现此功能也很重要。通常，该功能不属于软件项目的范围：团队不希望使用此功能，觉得自己没有必要，或者他们只是认为这不是做某事的好方法。在这种情况下，您应该只创建项目并自己创建。
请使用能够满足您需要的专有软件。
请记住，OOP软件通常可以简化集成功能的过程。
irc或论坛上的邮件列表只会激怒程序员，并给OSS支持者带来弹药。

#22 楼

您无话可说会让他做到这一点。毕竟，他为什么要这么做？因为一个用户的愿望？不够充分的原因。
但是，如果您可以收集合理数量的用户并给出合理的原因（“我想要它”不是合理的原因。）为什么该功能可能有用，一般而言，对于您和其他一些人，他可能会改变主意。

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

评论

---

另外，开发人员有足够的功能要求，以使他在本世纪余下的时间中忙于工作，想包括您的开发人员，但并不希望很快得到解决。

– David Thornley
2011年4月19日在17:14

---

@David Thornley-也是。

–浏览
2011年4月19日在18:34

---

#23 楼

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

是的，其中之一公开开源背后的想法是任何人和每个人都有权利和责任做出自己的贡献。

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

#24 楼

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

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

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

#25 楼

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

如果它很小，并且确实对项目的预期用户有用，那么只需提交错误报告，清楚地​​描述问题，给出重现步骤，表明您使用的是当前的每晚版本，然后将其保留。

看起来像是一个微小的简单更改，可以帮助大量的用户，实际上可能是一个巨大的变化痛苦的屁股，没有人会用你。这是“提交补丁”的最佳案例。

您还可能遇到了一个臭名昭著的glibc维护者之类的案例，他似乎一心一意地认为自己的系统就是宇宙，他对规格的解释是上帝的话，而这就是全部，而不论有多少人愿意这样做。

#26 楼

我建议创建一个用于在RentACoder / ELance / etc等网站上实现该功能的项目，并将其发布在原始开源项目的论坛上。现在，开放源代码项目中的任何程序员（包括作者）都有经济动机考虑您的请求。

#27 楼

我实际上只是注册来回答这个问题。
是否需要反驳？
当开发人员知道该问题但认为它不那么重要时，通常会使用此响应。 >我将给您一个生动的例子。 ubuntu放弃了对系统托盘的支持（但可以通过白色列出一个应用程序来解决），并添加了新的应用程序指示器。诸如jupiter之类的某些应用程序依靠系统托盘支持，因此开发人员向工作人员介绍了workaournd而不是添加应用程序指示器支持，因此我要求开发人员添加应用程序指示器支持，回复为“向我们发送补丁”。在询问他们选择不执行这个原因时。就是这样

我没有兴趣花费我的时间建立对我永远不会使用的库的支持，仅仅因为有很多钱的人通过将我的应用程序功能列入他的Linux才能将其列入黑名单分发仅仅是因为他可以。
如果这是一个真正的技术问题，我可能会采取行动，但这纯粹是政治手段，所以不，我不这么认为。
不，我只是将其列入白名单

足够公平。开发人员有理由不实施功能，但愿意接受补丁。
底线：规范的反驳是提交补丁，但如果您不能反驳的话，

#28 楼

开始悬赏您想要的功能。

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

#29 楼

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

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

您可以尝试提供（咳嗽）“捐款”以解决您的问题，但我担心，如果这样的做法普遍存在，将会导致严重损害了行业的完整性，因为无论是“免费”还是商业软件，错误修复都决不能赚钱。