mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-02-28 01:01:09 +08:00
translated
This commit is contained in:
geekpi
parent
66714716da
commit
0e5068af0f
@ -1,74 +0,0 @@
|
||||
translating---geekpi
|
||||
|
||||
Most companies can't buy an open source community clue. Here's how to do it right
|
||||
============================================================
|
||||
|
||||
Red Hat has learned to fol e low open source communities and lead in monetizing them. You can, too.
|
||||
|
||||
One of the most powerful—yet most difficult—things in open source is community. "Where a robust community exists," declared Red Hat CEO Jim Whitehurst in a [recent interview][7] with Slashdot, "Open source always wins." But building that community is hard. Really, really hard. While it's somewhat straightforward to [predict the necessary components of a thriving open source community][8], it's immeasurably harder to predict when and where the confluence of those components will result in a community like Linux or Kubernetes.
|
||||
|
||||
Which is why the smart money seems to follow open source communities, rather than trying to create them.
|
||||
|
||||
### Lovable open source parasites
|
||||
|
||||
This thought struck me while reading Whitehurst's Slashdot interview. Though it tackles everything from the Linux desktop to systemd, Whitehurst's commentary on community proved the most potent for me:
|
||||
|
||||
> Building a new community is hard. We've started a few at Red Hat, but most of the time we look for existing ones that already have a robust community. Where a robust community exists, open source always wins.
|
||||
|
||||
### More about Open Source
|
||||
|
||||
* [Git: Everything the pros need to know][1]
|
||||
|
||||
* [Ditching Windows for Linux led to 'major difficulties' says open-source champion Munich][2]
|
||||
|
||||
* [Securing Linux policy (Tech Pro Research)][3]
|
||||
|
||||
* [Subscribe to our Open Source Weekly newsletter!][4]
|
||||
|
||||
While this approach—tacking on to existing, growing communities—could seem to be a cop-out, it's actually the wisest course of action. Early on, open source almost always seems fragmented, as different projects attempt to gain critical mass. At some point things start to coalesce around two or three winners (think KDE vs. Gnome, or Kubernetes vs. Docker Swarm vs. Apache Mesos). But eventually, it's simply too hard to maintain diverse community "standards," and everyone rallies around one winner (Kubernetes, for example).
|
||||
|
||||
**SEE: [Hybrid cloud and open source: Red Hat's recipe for digital transformation][5](Tech Pro Research)**
|
||||
|
||||
This isn't capitulation—it's a smarter way of shepherding resources and driving standardization. One reason that Linux has become such a powerful force, for example, is that it encourages operating system innovation in one place, even if there are disparate tributary communities feeding into it (and wildly different companies and individuals contributing the code). Red Hat has thrived in part because it made smart community choices early on, picking a winner (like Kubernetes) and helping to make it even more successful.
|
||||
|
||||
Which, in turn, powers its business model.
|
||||
|
||||
### Making money from community chaos
|
||||
|
||||
The great thing for Red Hat is the more community, the more successful the project. But "success" in open source doesn't necessarily mean that enterprises will embrace a project; it merely means that they _want_ to do so. Red Hat's early intuition, and one that keeps paying dividends, was understanding that dull, stodgy enterprises want the vibrancy of open source without, well, the vibrancy. They need it tamed and made dull and stodgy. Whitehurst captured this perfectly in his interview:
|
||||
|
||||
> Red Hat is successful because we obsess about finding ways to add value around the code for each of our products. We think of ourselves as helping make open source innovation easily consumable for enterprise customers.
|
||||
>
|
||||
> Just one example: For all of our products, we focus on life-cycle. Open source is a great development model, but its "release early, release often" style makes implementing it in production difficult. One important value we play in Linux is that we backport bug fixes and security updates in supported kernels for over a decade, all while never breaking API compatibility. That has huge value for enterprises running long-lived applications. We go through this type of process against all of the projects we chose to productize to determine how we add value beyond the source code.
|
||||
|
||||
For most companies that want to make a business with open source, the challenge is that they may recognize the value of community, but can't fathom how not to sell code. Selling software, after all, has been a fantastically profitable business model for decades, and has resulted in some of the most valuable companies on earth.
|
||||
|
||||
**SEE [How Red Hat aims to make Kubernetes boring...and successful][6]**
|
||||
|
||||
Open source, however, requires a different approach, as Whitehurst pointed out. "YOU CAN'T SELL FUNCTIONALITY because it is available for free," he asserted in the interview. Instead, you have to find other value, like making open source supportable over long periods of time. Boring work, but worth billions every year to Red Hat.
|
||||
|
||||
All of this starts with community. The more vibrant, the better for its ability to both market an open source product and also to monetize it. Why? Well, because more moving parts equal more value tied to making that free-wheeling project just a bit more staid for enterprise consumption. It's a winning formula, and plays to all the good in open source without shackling it to 20th-century business models.
|
||||
|
||||
 Image: iStockphoto/ipopba
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.techrepublic.com/article/most-companies-cant-buy-an-open-source-community-clue-heres-how-to-do-it-right/
|
||||
|
||||
作者：[Matt Asay ][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.techrepublic.com/meet-the-team/us/matt-asay/
|
||||
[1]:https://www.techrepublic.com/article/git-everything-the-pros-need-to-know/
|
||||
[2]:https://www.techrepublic.com/article/ditching-windows-for-linux-led-to-major-difficulties-says-open-source-champion-munich/
|
||||
[3]:http://www.techproresearch.com/downloads/securing-linux-policy/
|
||||
[4]:https://www.techrepublic.com/newsletters/
|
||||
[5]:http://www.techproresearch.com/article/hybrid-cloud-and-open-source-red-hats-recipe-for-digital-transformation/
|
||||
[6]:https://www.techrepublic.com/article/how-red-hat-aims-to-make-kubernetes-boring-and-successful/
|
||||
[7]:https://linux.slashdot.org/story/17/10/30/0237219/interviews-red-hat-ceo-jim-whitehurst-answers-your-questions
|
||||
[8]:http://asay.blogspot.com/2005/09/so-you-want-to-build-open-source.html
|
||||
[9]:https://www.techrepublic.com/meet-the-team/us/matt-asay/
|
||||
[10]:https://twitter.com/intent/user?screen_name=mjasay
|
||||
@ -0,0 +1,72 @@
|
||||
大多数公司不得开源社区要点。这是该怎么做
|
||||
============================================================
|
||||
|
||||
Red Hat 已经学会了跟随开源社区，并将其商业化。你也可以。
|
||||
|
||||
开源中最强大但最困难的事情之一就是社区。红帽首席执行官 Jim Whitehurst 在与 Slashdot 的[最近一次采访][7]中宣称：“有强大社区的存在，开源总是赢得胜利”。但是建设这个社区很难。真的，真的很难。尽管[预测开源社区蓬勃发展的必要组成部分][8]有些直接，但是预测这些部分在何时何地将会组成像 Linux 或 Kubernetes 这样的社区是难以估计的。
|
||||
|
||||
这就是为什么聪明的钱似乎跟随社区，而不是试图创建它们。
|
||||
|
||||
### 可爱的开源寄生虫
|
||||
|
||||
在阅读 Whitehurst 的 Slashdot 采访时，这个想法让我感到震惊。虽然它负责从 Linux 桌面到 systemd 的所有内容，但 Whitehurst 的社区评论对我来说是最有效的：
|
||||
|
||||
>建立一个新社区是困难的。我们在红帽进行一点，但大部分时间我们都在寻找已经拥有强大社区的现有项目。在强大的社区存在的情况下，开源始终是胜利的。
|
||||
|
||||
### 关于开源的更多信息
|
||||
|
||||
* [Git：专业人士需要知道的一切][1]
|
||||
|
||||
* [开源冠军慕尼黑说为 Linux 抛弃 Windows 遇到“重大困难”][2]
|
||||
|
||||
* [保护 Linux 政策（Tech Pro Research）][3]
|
||||
|
||||
* [订阅我们的开源每周通讯！][4]
|
||||
|
||||
虽然这种方法 - 加强现有的，不断发展的社区，似乎是一种逃避，它实际上是最明智的做法。早期, 开源几乎总是支离破碎的，因为不同的项目试图获得大量群众。在某些时候，开始聚集两到三名获胜者（例如 KDE vs. Gnome，或者 Kubernetes vs. Docker Swarm 与 Apache Mesos）。但最终，维持多元化的社区“标准”实在太难了，每个人都围绕着一个赢家（例如 Kubernetes）。
|
||||
|
||||
**见：[混合云和开源：红帽数字化转型的秘诀][5]（Tech Pro Research）**
|
||||
|
||||
这不是投降 - 这是培养资源和推动标准化的更好方式。例如，Linux 已经成为如此强大的力量的一个原因是，即使存在不同的分支社区（对于贡献代码的大量不同的公司和个人），也会促进操作系统创新。红帽的发展很快，部分原因是它在早期就做出了聪明的社区选择，选择了一个赢家（比如 Kubernetes），并帮助它取得更大的成功。
|
||||
|
||||
而这反过来又为其商业模式提供动力。
|
||||
|
||||
### 从社区混乱中赚钱
|
||||
|
||||
对红帽而言一件很好的事是社区越多，项目就越成功。但是，开源的“成功”并不一定意味着企业会拥抱一个项目，这仅仅意味着他们_愿意_这样做。红帽公司早期的直觉，其中一个是支付分红，就是理解那些枯燥，平庸的企业想要开源的活力，而不是，好吧，是活力。他们需要把它驯服，变得枯燥而又平庸。Whitehurst 在采访中完美地表达了这一点：
|
||||
|
||||
>红帽是成功的，因为我们沉迷于寻找方法来增加我们每个产品的代码价值。我们认为自己是帮助企业客户轻松消费开源创新的。
|
||||
>
|
||||
>仅举一例：对于我们所有的产品，我们关注生命周期。开源是一个伟大的发展模式，但其“发布早、发布频繁”的风格使其在生产中难以实施。我们在 Linux 中发挥的一个重要价值是，我们在受支持的内核中支持 bug 修复和安全更新十多年，同时从不破坏 API 兼容性。这对于运行长期应用程序的企业具有巨大的价值。我们通过这种类型的流程来应对我们选择进行产品化的所有项目，以确定我们如何增加源代码之外的价值。
|
||||
|
||||
对于大多数想要开源的公司来说，挑战在于他们可能认识到社区的价值，但是不知道怎么不出卖代码。毕竟，销售软件几十年来一直是一个非常有利可图的商业模式，并导致了一些地球上最有价值的公司。
|
||||
|
||||
**看[红帽如何使 Kubernetes 枯燥并且成功][6]**
|
||||
|
||||
然而, 正如 Whitehurst 指出的那样, 开源需要一种不同的方法。他在采访中断言:“你不能出售功能, 因为它是免费的”。相反, 你必须找到其他的价值, 比如在很长一段时间内让开源有支持。这是枯燥的工作, 但对红帽而言每年值数十亿美元。
|
||||
|
||||
所有这一切都从社区开始。社区更有活力，它能更好地市场化开源产品并且货币化。为什么？嗯，因为更多的发展部分等价于更大的价值，随之让自由发展的项目对企业消费而言更加稳定。这是一个成功的公式, 并发挥所有开源得好处, 而不受制它在二十世纪的商业模式。
|
||||
|
||||
 Image: iStockphoto/ipopba
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.techrepublic.com/article/most-companies-cant-buy-an-open-source-community-clue-heres-how-to-do-it-right/
|
||||
|
||||
作者：[Matt Asay ][a]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.techrepublic.com/meet-the-team/us/matt-asay/
|
||||
[1]:https://www.techrepublic.com/article/git-everything-the-pros-need-to-know/
|
||||
[2]:https://www.techrepublic.com/article/ditching-windows-for-linux-led-to-major-difficulties-says-open-source-champion-munich/
|
||||
[3]:http://www.techproresearch.com/downloads/securing-linux-policy/
|
||||
[4]:https://www.techrepublic.com/newsletters/
|
||||
[5]:http://www.techproresearch.com/article/hybrid-cloud-and-open-source-red-hats-recipe-for-digital-transformation/
|
||||
[6]:https://www.techrepublic.com/article/how-red-hat-aims-to-make-kubernetes-boring-and-successful/
|
||||
[7]:https://linux.slashdot.org/story/17/10/30/0237219/interviews-red-hat-ceo-jim-whitehurst-answers-your-questions
|
||||
[8]:http://asay.blogspot.com/2005/09/so-you-want-to-build-open-source.html
|
||||
[9]:https://www.techrepublic.com/meet-the-team/us/matt-asay/
|
||||
[10]:https://twitter.com/intent/user?screen_name=mjasay
|
||||
Loading…
Reference in New Issue
Block a user