document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-19 22:51:41 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #4554 from Chao-zhi/patch-1

Browse Source 
翻译完成
This commit is contained in:
VicYu 2016-10-17 18:34:07 +08:00 committed by GitHub
commit 93aabafdfa
2 changed files with 50 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
sources/tech/20160913 4 big ways companies benefit from having open source program offices.md
View File

@ -1,52 +0,0 @@
translating by Chao-zhi
4 big ways companies benefit from having open source program offices
====
![](https://opensource.com/sites/default/files/styles/image-full-size/public/images/business/BUSINESS_creativity.png?itok=x2HTRKVW)
In the first article in my series on open source program offices, I took a deep dive into [what an open source program office is and why your company might need one][1]. Next I looked at [how Google created a new kind of open source program office][2]. In this article, I'll explain a few benefits of having an open source program office.
At first glance, one big reason why a company not in the business of software development might more enthusiastically embrace an open source program office is because they have less to lose. After all, they're not gambling with software products that are directly tied to revenue. Facebook, for example, can easily unleash a distributed key-value datastore as an open source project because they don't sell a product called "enterprise key-value datastore." That answers the question of risk, but it still doesn't answer the question of what they gain from contributing to the open source ecosystem. Let's look at a few potential reasons and then tackle each. You'll notice a lot of overlap with vendor open source program offices, but some of the motivations are slightly different.
### Recruiting
Recruiting is perhaps the easiest way to sell an open source program office to upper management. Show them the costs associated with recruiting, as well as the return on investment, and then explain how developing relationships with talented engineers results in a pipeline of talented developers who are actually familiar with your technology and excited to help work on it. We don't really need to go in more depth here—it's self-explanatory, right?
### Technology influence
Once upon a time, companies that didn't specialize in selling software were powerless to influence development cycles of their software vendors directly, especially if they were not a large customer. Open source completely changed that dynamic and brought users onto a more level playing field with vendors. With the rise of open source development, anyone could push technology into a chosen direction, assuming they were willing to invest the time and resources. But these companies learned that simply investing in developer time, although fruitful, could be even more useful if tied to an overarching strategic effort&mdash. Think bug fixes vs. software architects—lots of companies push bug fixes to upstream open source projects, but some of these same companies began to learn that coordinating a sustained effort with a deeper commitment paid off with faster feature development, which could be good for business. With the open source program office model, companies have staffers who can sniff out strategically important open source communities in which they then invest developer resources.
With rapidly growing companies such as Google and Facebook, providing leadership in existing open source projects still proved insufficient for their expanding businesses. Facing the challenges of intense growth and building out hyperscale systems, many of the largest companies had built highly customized stacks of software for internal use only. What if they could convince others to collaborate on some of these infrastructure projects? Thus, while they maintained investments in areas such as the Linux kernel, Apache, and other existing projects, they also began to release their own large projects. Facebook released Cassandra, Twitter created Mesos, and eventually Google created the Kubernetes project. These projects have become major platforms for industry innovation, proving to be spectacular successes for the companies involved. (Note that Facebook stopped using Cassandra internally after it needed to create a new software project to solve the problem at a larger scale. However, by that time Cassandra had already become popular and DataStax had formed to take on development). Each of these projects have spawned entire ecosystems of developers, related projects, and end users that serve to accelerate growth and development.
This would not have been possible without coordination between an open source program office and strategic company initiatives. Without that effort, each of the companies mentioned would still be trying to solve these problems individually—and more slowly. Not only have these projects helped solve business problems internally, they also helped establish the companies that created them as industry heavyweights. Sure, Google has been an industry titan for a few years now, but the growth of Kubernetes ensures both better software, and a direct say in the future direction of container technologies, even more than it already had. These companies are still known for their hyperscale infrastructure and for simply being large Silicon Valley stalwarts. Lesser known, but possibly even more important, is their new relevance as technology producers. Open source program offices guide these efforts and maximize their impact, through technology recommendations and relationships with influential developers, not to mention deep expertise in community governance and people management.
### Marketing power
Going hand-in-hand with technology influence is how each company talks about its open source efforts. By honing the messages around these projects and communities, an open source program office is able to deliver maximum impact through targeted marketing campaigns. Marketing has long been a dirty word in open source circles, because everyone has had a bad experience with corporate marketing. In the case of open source communities, marketing takes on a vastly different form from a traditional approach and involves amplifying what is already happening in the communities of strategic importance. Thus, an open source program office probably won't create whiz-bang slides about a project that hasn't even released any code yet, but they'll talk about the software they've created and other initiatives they've participated in. Basically, no vaporware here.
Think of the first efforts made by Google's open source program office. They didn't simply contribute code to the Linux kernel and other projects—they talked about it a lot, often in keynotes at open source conferences. They didn't just give money to students who write open source code—they created a global program, the Google Summer of Code, that became a cultural touchstone of open source development. This marketing effort cemented Google's status as a major open source developer long before Kubernetes was even developed. As a result, Google wielded major influence during the creation of the GPLv3 license, and company speakers and open source program office representatives became staples at tech events. The open source program office is the entity best situated to coordinate these efforts and deliver real value for the parent company.
### Improve internal processes
Improving internal processes may not sound like a big benefit, but overcoming chaotic internal processes is a challenge for every open source program office, whether software vendor or company-driven. Whereas a software vendor must make sure that their processes don't step on products they release (for example, unintentionally open sourcing proprietary software), a user is more concerned with infringement of intellectual property (IP) law: patents, copyrights, and trademarks. No one wants to get sued simply for releasing software. Without an active open source program office to manage and coordinate licensing and other legal questions, large companies face great difficulty in arriving at a consensus around open source processes and governance. Why is this important? If different groups release software under incompatible licenses, not only will this prove to be an embarrassment, it also will provide a significant obstacle to achieving one of the most basic goals—improved collaboration.
Combined with the fact that many of these companies are still growing incredibly quickly, an inability to establish basic rules around process will prove unwieldy sooner than expected. I've seen large spreadsheets with a matrix of approved and unapproved licenses as well as guidelines for how to (and how not to) create open source communities while complying with legal restrictions. The key is to have something that developers can refer to when they need to make decisions, without incurring the legal overhead of a massive, work-slowing IP review every time a developer wants to contribute to an open source community.
Having an active open source program office that maintains rules over license compliance and source contribution, as well as establishing training programs for engineers, helps to avoid potential legal pitfalls and costly lawsuits. After all, what good is better collaboration on open source projects if the company loses real money because someone didn't read the license? The good news is that companies have less to worry about with respect to proprietary IP when compared to software vendors. The bad news is that their legal questions are no less complex, especially when they run directly into the legal headwinds of a software vendor.
How has your organization benefited from having an open source program office? Let me know about it in the comments.
--------------------------------------------------------------------------------
via: https://opensource.com/business/16/9/4-big-ways-companies-benefit-having-open-source-program-offices
作者：[John Mark Walker][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者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

50
translated/tech/20160913 4 big ways companies benefit from having open source program offices.md Normal file
View File

@ -0,0 +1,50 @@
拥有开源项目部门的公司可以从四个方面获益
====
![](https://opensource.com/sites/default/files/styles/image-full-size/public/images/business/BUSINESS_creativity.png?itok=x2HTRKVW)
在我的第一篇关于开源项目部门的系列文章中，我深入剖析了[什么是开源项目部门，为什么你的公司需要一个开源项目部门][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