mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-29 21:41:00 +08:00
51 lines
8.4 KiB
Markdown
51 lines
8.4 KiB
Markdown
|
拥有开源项目部门的公司可以从四个方面获益
|
|||
|
|
====
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
在我的第一篇关于开源项目部门的系列文章中，我深入剖析了[什么是开源项目部门，为什么你的公司需要一个开源项目部门][1]。接着我又说到了[谷歌是如何创建一个新的开源项目部门的][2]。而这篇文章，我将阐述拥有一个开源项目部门的好处。
|
|||
|
|
|
|||
|
|
乍一看，非软件开发公司会更加热情的去拥抱开源项目部门的一个重要原因是他们并没有什么损失。毕竟，他们并不需要依靠这些软件产品来获得收益。比如，Facebook 可以很轻易的释放出一个 “分布式键值数据存储” 作为开源项目，是因为他们并没有售卖一个叫做 “分布式键值数据存储” 的产品。这回答了关于风险的问题，但是并没有回答他们如何通过向开源生态共献代码而获益的问题。让我们逐个来推测和探讨其中可能的原因。你会发现开源项目供应商的许多动机都是相同的，但是也有些许不同。
|
|||
|
|
|
|||
|
|
### 招聘
|
|||
|
|
|
|||
|
|
招聘可能是一个最容易的方法将一个开源项目售卖给上层管理部门。向他们展示与招聘相关的成本，以及投资回报率，然后解释如何与天才工程师发展关系，从而与那些对这些项目感兴趣并且十分乐意在其中工作的天才开发者们建立联系。不需要我多说了，你懂的！
|
|||
|
|
|
|||
|
|
### 技术影响
|
|||
|
|
|
|||
|
|
曾几何时，那些没有专门从事软件销售的公司难以直接影响他们软件供应商的开发周期，尤其是他们并不是一个大客户时。开源完全改变了这一点，它将用户与供应商放在了一个更公平的竞争环境中。随着开源开发的兴起，任何人，假如他们愿意投入时间和资源的话，都可以将技术推向一个选定的方向。但是这些公司发现，虽然将投资用于开发上会带来丰硕的成果，但是总体战略的努力却更加有效——试想 bug 的修复 VS 软件的构建——大多数公司都将 bug 的修复推给上游的开源部门，但是一些公司开始认识到通过更深层次的回报承诺和更快的功能开发来协调持久的工作，将会更有利于业务。通过一个开源项目部门的模型，公司的职员能够从开源社区中准确嗅出战略重心，然后投入开发资源。
|
|||
|
|
|
|||
|
|
对于快速增长的公司，如 Google 和 Facebook，其对现有的开源项目提供的领导力仍然不足以满足业务的膨胀。面对激烈的增长和建立超大规模系统所带来的挑战，许多大型企业开始为软件构建仅供内部使用的高度定制的栈。除非他们能说服别人在一些基础设施项目上达成合作？因此，虽然他们保持在诸如 Linux 内核，Apache 和其他现有项目领域的投资，他们也开始推出自己的大型项目。Facebook 发布了 Cassandra，Twitter 创造了 Mesos，并且甚至谷歌也创建了 Kubernetes 项目。这些项目已成为行业创新的主要平台，证实该举措是相关公司引人注目的成功。（请注意，Facebook 内部停止使用 Cassandra 后，它需要创造一个新软件项目来解决更大规模的问题，但是，这时 Cassandra 已经变得流行，而 DataStax 已经开始承担开发任务）。所有这些项目已经促使了开发商、相关的项目、以及最终用户来供应加速的增长和发展的整个生态。
|
|||
|
|
|
|||
|
|
开源项目部门和公司战略举措是不可能不协调的。没有这种努力，每个所提到的公司依然在试图单独地和更慢解决这些问题。不仅拥有这些项目可以帮助解决内部业务问题，它们也帮助这些公司逐渐成为行业巨头。当然，谷歌当了好多年行业巨头，但是 Kubernetes 的发展确保了软件的质量，并且在容器技术未来的发展方向上有着直接的话语权，并且远超之前就有的话语权。这些公司目前还是闻名于他们超大规模的基础设施和硅谷的中坚份子。鲜为人知，但是更为重要的是它们与技术生产人员的亲密度。开源项目办公室凭借技术建议和与有影响力的开发者的关系，再加上在社区治理和人员管理方面深厚的专业知识来引领这些工作，并最大限度地发挥其影响力，
|
|||
|
|
|
|||
|
|
### 市场营销能力
|
|||
|
|
|
|||
|
|
与技术的影响齐头并进的是每个公司谈论如何开源的努力。通过推敲这些项目和社区周围的消息，一个开源项目部门能够通过有针对性的营销活动来提供最大的影响。营销在开放源码领域一直是一个肮脏的词汇，因为每个人都有一个由企业营销造成的糟糕的经历。在开源社区中，营销呈现出一种与传统方法截然不同的形式，他会更注重于我们的社区已经在战略方向上做了什么。因此，一个开源项目部门不可能去宣传一些根本还没有发布任何代码的项目，但是他们会讨论他们创造什么软件和参与了其他什么举措。基本上，不会有“雾件”。
|
|||
|
|
|
|||
|
|
想想谷歌的开源项目办公室作出的第一份工作。他们不只是简单的贡献代码给 Linux 内核或其他项目，他们更多的是谈论它，并经常在开源会议主题演讲。他们不仅仅是把钱给写开源的代码的学生，他们还创建了一个全球计划——“Google Summer of Code”，现在已经成为一种开源发展的文化试金石。这些市场营销的作用在 Kubernetes 开发完成之前就奠定了谷歌在开源世界巨头的地位。最终使得，谷歌在创建 GPLv3 授权协议期间拥有重要影响力，并且在科技活动中公司的发言人和开源项目部门代表人成为主要人物。开源项目部门是协调这些工作的最好的实体，并可以为母公司提供真正的价值。
|
|||
|
|
|
|||
|
|
###改善内部流程
|
|||
|
|
|
|||
|
|
改善内部流程听起来不像一个大好处，但克服混乱的内部流程对于每一个开源项目部门都是一个挑战，不论是软件开发商还是驱动开发公司。而软件供应商必须确保他们的流程不与他们发布的产品重叠（例如，不小心开源了他们的专业软件），用户更关心的是侵犯了知识产权（IP）法：专利、版权和商标。没有人想只是因为释放软件而被起诉。没有一个活跃的开源项目部门去管理和协调这些许可和其他法律问题，大公司在开源流程和管理上面临着巨大的困难。为什么这个很重要呢？如果不同的组释放的软件是在不兼容的许可证下，那么这不仅是一个坑爹的尴尬，它还将对实现最基本的目标改良协作产生巨大的障碍。
|
|||
|
|
|
|||
|
|
考虑到还有许多这样的公司仍在飞快的增长，如果无法建立基本流程规则的话，将可以预见到它们将会遇到阻力。我见过一个巨大的电子表格罗列着批准、未经批准的许可证，以及指导如何（或如何不）创建开源社区而遵守法律限制。关键是当开发者需要做出决定时要有一个可以依据的东西，并且每次当开发人员想要为一个开源社区贡献代码时，可以不产生大量的法律开销，和效率低下的知识产权检查。
|
|||
|
|
|
|||
|
|
有一个活跃的开放源码项目部门，负责维护许可规则和源的贡献，以及建立培训项目工程师，有助于避免潜在的法律缺陷和昂贵的诉讼。毕竟，良好的开源项目合作可以减少由于某人没有看许可证而导致公司赔钱这样的事件。好消息是，公司已经不用担心关于专有的知识产权与软件供应商冲突的事。坏消息是，它们的法律问题不够复杂，尤其是当他们直接需要软件供应商提供法律阻力时。
|
|||
|
|
|
|||
|
|
你的组织是如何受益于拥有一个开源项目部门的？可以在评论中与我们分享。
|
|||
|
|
|
|||
|
|
--------------------------------------------------------------------------------
|
|||
|
|
|
|||
|
|
via: https://opensource.com/business/16/9/4-big-ways-companies-benefit-having-open-source-program-offices
|
|||
|
|
|
|||
|
|
作者：[John Mark Walker][a]
|
|||
|
|
译者：[chao-zhi](https://github.com/chao-zhi)
|
|||
|
|
校对：[校对者ID](https://github.com/校对者ID)
|
|||
|
|
|
|||
|
|
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
|||
|
|
|
|||
|
|
[a]: https://opensource.com/users/johnmark
|
|||
|
|
[1]: https://opensource.com/business/16/5/whats-open-source-program-office
|
|||
|
|
[2]: https://opensource.com/business/16/8/google-open-source-program-office
|