Open source 向开源项目成员支付bug修复和特性费用

我有一个问题要解决，我想需要4天时间，但如果我有一个功能请求排序和快照发布，那么我想我可以在一个时间内完成。从表面上看，这创造了一个3倍于我的每日费率的预算，以实现功能请求

所以我的问题是，你有没有付钱给O/S项目成员帮你修理东西？结果怎么样？你是如何向你的经理/同事推销这个想法的？资金来自哪里

最重要的是，你是如何友好地问的？这些东西有礼节吗？项目负责人可能会接受这个想法吗

---

若有关系的话，那个么缺少功能的软件是一个JBoss项目——专业开源的家园——我可以报销费用，因为我是一个承包商。

在工作中，我们很幸运地雇佣了开源维护人员来增强我们使用的库

以下是我们过去做过的一些项目：

我们需要将Quake 2与wxWidgets集成。我们雇佣了瓦迪姆·泽特林，他是wxWidgets的主要贡献者。在不到4天的时间里，他通过修改Windows版本的Quake 2构建了一个wxQuake2小部件

后来，我们需要对原始位图进行便携式访问。因此，我们再次雇用了瓦迪姆，并与他合作开发了一个新的原始位图API。这涉及到大量的设计工作，但我们非常喜欢由此产生的API，并且一直使用到今天

稍后，我们聘请了另一位核心贡献者来改进wxWidgets可访问性支持。事实证明，由于各种技术原因，我们最终没有立即使用此代码。但从那以后，其他人一直在增强这段代码，我们希望有一天能使用它

换句话说，雇佣开源维护人员与雇佣其他类型的承包商非常相似。但有些事情也有点不同。根据我们的经验，以下是一些建议：

如果您希望增强现有项目并将更改作为开放源代码发布，那么您将非常幸运

通常，您希望雇用核心团队的成员。他们有最好的业绩记录，他们是最有生产力的，他们有最好的机会让你的变化上游合并

您希望将更改合并到上游。如果你不这样做，你将维持当地的叉子，这是一个头痛的问题

在招聘之前，做一些调查。谁负责您关心的功能？他们是你喜欢与之共事的人吗？阅读邮件列表并浏览版本控制历史记录，然后挑选几个人进行联系

在设计阶段，可能会有一些取舍。开发人员关注的是项目的整体健康状况，而您关注的是特定业务的需求。这有时会使谈判对我们来说更为复杂，但最终结果通常是一个比我们自己选择的更好的设计

最重要的是，不要害羞。在任何一个足够大的开源项目中，核心团队的几个成员都已经在经营咨询业务。在较小的开放源码项目中，您通常会发现一些想要经营咨询业务的贡献者

如果你仍然不愿接近某人，你可以问：“你知道有谁对在$FEATURE上工作有兴趣获得报酬吗？”如果他们不感兴趣，你就没有把他们放在现场，他们可能会告诉你该问谁

---

总的来说，开源维护人员的专业精神和工作效率给我们留下了深刻的印象，我向其他人推荐这条路线。

这是一个相当令人困惑的问题。你是否有合同要修理某件东西，并想把它转包出去？或者你只是发现了一个你认为其他人更有资格处理的问题？我有一个问题可以通过多种方式解决。一种方法是实现该特性，但我没有资格这样做，也不想分叉代码。分包是可以的，建议我的客户和公开巫师直接签订合同也是可以的。“公开巫师”~魔术师，巫师。。。很酷的拼写错误，我还想雇佣一个巫师：-）谢谢你的回答，采取这条路线的大部分动机都是为了避免代码分叉，但是你如何确保修复-或者足够类似的修复-包括在内？如果你的更改是相当明显的bug修复，你应该不会有任何问题。如果您的更改是新功能，那么最好与具有提交权限的主要贡献者讨论，并征求他们的建议。