mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-07 22:11:09 +08:00
20171113-5 选题
This commit is contained in:
parent
0af45335ba
commit
df80f7e8a8
@ -0,0 +1,72 @@
|
||||
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.
|
||||
|
||||
![istock-638090542.jpg](https://tr4.cbsistatic.com/hub/i/r/2017/11/06/ef2662be-6dfb-4c71-83ac-5e57fd82593a/resize/770x/3bc6a8e261d536e1992ff7ba2075bbc2/istock-638090542.jpg) 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
|
Loading…
Reference in New Issue
Block a user