㈠ 以大數據時代為題寫一篇年終總結
可參考下文
9個關鍵字 寫寫大數據行業2015年年終總結
2015年，大數據市場的發展迅猛，放眼國際，總體市場規模持續增加，隨著人工智慧、物聯網的發展，幾乎所有人將目光瞄準了「數據」產生的價值。行業廠商 Cloudera、DataStax 以及 DataGravity 等大數據公司已經投入大量資金研發相關技術，Hadoop 供應商 Hortonworks 與數據分析公司 New Relic 甚至已經上市。而國內，國家也將大數據納入國策。
我們邀請數夢工場的專家妹子和你來聊聊 2015 年大數據行業九大關鍵詞，管窺這一年行業內的發展。
戰略：國家政策
今年中國政府對於大數據發展不斷發文並推進，這標志著大數據已被國家政府納入創新戰略層面，成為國家戰略計劃的核心任務之一：
2015年9月，國務院發布《促進大數據發展行動綱要》，大力促進中國數據技術的發展，數據將被作為戰略性資源加以重視;
2015年10月26日，在國家「十三五」規劃中具體提到實施國家大數據戰略。
挑戰：BI(商業智能)
2015年對於商業智能(BI)分析市場來說，正由傳統的商業智能分析快速進入到敏捷型商業智能時代。以 QlikView、Tableau和 SpotView 為代表的敏捷商業智能產品正在挑戰傳統的 IBM Cognos、SAP Business Objects 等以 IT 為中心的 BI 分析平台。敏捷商業智能產品也正在進一步細化功能以達到更敏捷、更方便、適用范圍更廣的目的。
崛起：深度學習/機器學習
人工智慧如今已變得異常火熱，作為機器學習中最接近 AI(人工智慧)的一個領域，深度學習在2015年不再高高在上，很多創新企業已經將其實用化：Facebook 開源深度學習工具「Torch」、PayPal 使用深度學習監測並對抗詐騙、亞馬遜啟動機器學習平台、蘋果收購機器學習公司 Perceptio ……同時在國內，網路、阿里，科大訊飛也在迅速布局和發展深度學習領域的技術。
共存：Spark/Hadoop
Spark 近幾年來越來越受人關注，2015年6月15日，IBM 宣布投入超過3500名研究和開發人員在全球十餘個實驗室開展與 Spark 相關的項目。
與 Hadoop 相比，Spark 具有速度方面的優勢，但是它本身沒有一個分布式存儲系統，因此越來越多的企業選擇 Hadoop 做大數據平台，而 Spark 是運行於 Hadoop 頂層的內存處理方案。Hadoop 最大的用戶(包括 eBay 和雅虎)都在 Hadoop 集群中運行著 Spark。Cloudera 和 Hortonworks 將 Spark 列為他們 Hadoop 發行的一部分。Spark 對於 Hadoop 來說不是挑戰和取代相反，Hadoop 是 Spark 成長發展的基礎。
火爆：DBaaS
隨著 Oracle 12c R2 的推出，甲骨文以全新的多租戶架構開啟了 DBaaS (資料庫即服務Database-as-a-Service)新時代，新的資料庫讓企業可以在單一實體機器中部署多個資料庫。在2015年，除了趨勢火爆，12c 多租戶也在運營商、電信等行業投入生產應用。
據分析機構 Gartner 預測，2012年至2016年公有資料庫雲的年復合增長率將高達86%，而到2019年資料庫雲市場規模將達到140億美元。與傳統資料庫相比，DBaaS 能提供低成本、高敏捷性和高可擴展性等雲計算特有的優點。
㈡ 有關ubuntu下安裝Cloudera Manager的問題
你看錯誤提示「using password：YES」，你創建hadoop用戶的時候應該是沒有指定密碼。刪掉hadoop用戶，建立一個用戶名和密碼都是hadoop的用戶，配置時密碼也輸入hadoop即可。
㈢ hadoop流api具有什麼特性使得它支持多種語言
1. Apache Mesos
代碼託管地址： Apache SVN
Mesos提供了高效、跨分布式應用程序和框架的資源隔離和共享，支持Hadoop、 MPI、Hypertable、Spark等。
Mesos是Apache孵化器中的一個開源項目，使用ZooKeeper實現容錯復制，使用Linux Containers來隔離任務，支持多種資源計劃分配（內存和CPU）。提供Java、Python和C++ APIs來開發新的並行應用程序，提供基於Web的用戶界面來提查看集群狀態。
2. Hadoop YARN
代碼託管地址： Apache SVN
YARN又被稱為MapRece 2.0，借鑒Mesos，YARN提出了資源隔離解決方案Container，但是目前尚未成熟，僅僅提供 Java 虛擬機內存的隔離。
對比MapRece 1.x，YARN架構在客戶端上並未做太大的改變，在調用 API 及介面上還保持大部分的兼容，然而在YARN中，開發人員使用 ResourceManager、ApplicationMaster 與 NodeManager代替了原框架中核心的 JobTracker 和 TaskTracker。其中 ResourceManager 是一個中心的服務，負責調度、啟動每一個 Job 所屬的 ApplicationMaster，另外還監控 ApplicationMaster 的存在情況；NodeManager負責 Container 狀態的維護，並向 RM 保持心跳。ApplicationMaster 負責一個 Job 生命周期內的所有工作，類似老的框架中 JobTracker。
Hadoop上的實時解決方案
前面我們有說過，在互聯網公司中基於業務邏輯需求，企業往往會採用多種計算框架，比如從事搜索業務的公司：網頁索引建立用MapRece，自然語言處理用Spark等。本節為大家分享的則是Storm、Impala、Spark三個框架：
3. Cloudera Impala
代碼託管地址： GitHub
Impala是由Cloudera開發，一個開源的Massively Parallel Processing（MPP）查詢引擎 。與Hive相同的元數據、SQL語法、ODBC驅動程序和用戶介面(Hue Beeswax)，可以直接在HDFS或HBase上提供快速、互動式SQL查詢。Impala是在Dremel的啟發下開發的，第一個版本發布於2012年末。
Impala不再使用緩慢的Hive+MapRece批處理，而是通過與商用並行關系資料庫中類似的分布式查詢引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分組成），可以直接從HDFS或者HBase中用SELECT、JOIN和統計函數查詢數據，從而大大降低了延遲。
㈣ 做大數據分析系統Hadoop需要用哪些軟體
1、ApacheMesos
代碼託管地址：ApacheSVN
Mesos提供了高效、跨分布式應用程序和框架的資源隔離和共享，支持Hadoop、MPI、Hypertable、Spark等。
Mesos是Apache孵化器中的一個開源項目，使用ZooKeeper實現容錯復制，使用LinuxContainers來隔離任務，支持多種資源計劃分配(內存和CPU)。提供Java、Python和C++APIs來開發新的並行應用程序，提供基於Web的用戶界面來提查看集群狀態。
2、HadoopYARN
代碼託管地址：ApacheSVN
YARN又被稱為MapRece2.0，借鑒Mesos，YARN提出了資源隔離解決方案Container，但是目前尚未成熟，僅僅提供Java虛擬機內存的隔離。
對比MapRece1.x，YARN架構在客戶端上並未做太大的改變，在調用API及介面上還保持大部分的兼容，然而在YARN中，開發人員使用ResourceManager、ApplicationMaster與NodeManager代替了原框架中核心的JobTracker和TaskTracker。其中ResourceManager是一個中心的服務，負責調度、啟動每一個Job所屬的ApplicationMaster，另外還監控ApplicationMaster的存在情況;NodeManager負責Container狀態的維護，並向RM保持心跳。ApplicationMaster負責一個Job生命周期內的所有工作，類似老的框架中JobTracker。
Hadoop上的實時解決方案
前面我們有說過，在互聯網公司中基於業務邏輯需求，企業往往會採用多種計算框架，比如從事搜索業務的公司：網頁索引建立用MapRece，自然語言處理用Spark等。
3、ClouderaImpala
代碼託管地址：GitHub
Impala是由Cloudera開發，一個開源的MassivelyParallelProcessing(MPP)查詢引擎。與Hive相同的元數據、SQL語法、ODBC驅動程序和用戶介面(HueBeeswax)，可以直接在HDFS或HBase上提供快速、互動式SQL查詢。Impala是在Dremel的啟發下開發的，第一個版本發布於2012年末。
Impala不再使用緩慢的Hive+MapRece批處理，而是通過與商用並行關系資料庫中類似的分布式查詢引擎(由QueryPlanner、QueryCoordinator和QueryExecEngine三部分組成)，可以直接從HDFS或者HBase中用SELECT、JOIN和統計函數查詢數據，從而大大降低了延遲。
4、Spark
代碼託管地址：Apache
Spark是個開源的數據分析集群計算框架，最初由加州大學伯克利分校AMPLab開發，建立於HDFS之上。Spark與Hadoop一樣，用於構建大規模、低延時的數據分析應用。Spark採用Scala語言實現，使用Scala作為應用框架。
Spark採用基於內存的分布式數據集，優化了迭代式的工作負載以及互動式查詢。與Hadoop不同的是，Spark和Scala緊密集成，Scala像管理本地collective對象那樣管理分布式數據集。Spark支持分布式數據集上的迭代式任務，實際上可以在Hadoop文件系統上與Hadoop一起運行(通過YARN、Mesos等實現)。
5、Storm
代碼託管地址：GitHub
Storm是一個分布式的、容錯的實時計算系統，由BackType開發，後被Twitter捕獲。Storm屬於流處理平台，多用於實時計算並更新資料庫。Storm也可被用於「連續計算」(continuouscomputation)，對數據流做連續查詢，在計算時就將結果以流的形式輸出給用戶。它還可被用於「分布式RPC」，以並行的方式運行昂貴的運算。
Hadoop上的其它解決方案
就像前文說，基於業務對實時的需求，各個實驗室發明了Storm、Impala、Spark、Samza等流實時處理工具。而本節我們將分享的是實驗室基於性能、兼容性、數據類型研究的開源解決方案，其中包括Shark、Phoenix、ApacheAccumulo、ApacheDrill、ApacheGiraph、ApacheHama、ApacheTez、ApacheAmbari。
6、Shark
代碼託管地址：GitHub
Shark，代表了「HiveonSpark」，一個專為Spark打造的大規模數據倉庫系統，兼容ApacheHive。無需修改現有的數據或者查詢，就可以用100倍的速度執行HiveQL。
Shark支持Hive查詢語言、元存儲、序列化格式及自定義函數，與現有Hive部署無縫集成，是一個更快、更強大的替代方案。
7、Phoenix
代碼託管地址：GitHub
Phoenix是構建在ApacheHBase之上的一個SQL中間層，完全使用Java編寫，提供了一個客戶端可嵌入的JDBC驅動。Phoenix查詢引擎會將SQL查詢轉換為一個或多個HBasescan，並編排執行以生成標準的JDBC結果集。直接使用HBaseAPI、協同處理器與自定義過濾器，對於簡單查詢來說，其性能量級是毫秒，對於百萬級別的行數來說，其性能量級是秒。Phoenix完全託管在GitHub之上。
Phoenix值得關注的特性包括：1，嵌入式的JDBC驅動，實現了大部分的java.sql介面，包括元數據API;2，可以通過多個行鍵或是鍵/值單元對列進行建模;3，DDL支持;4，版本化的模式倉庫;5，DML支持;5，通過客戶端的批處理實現的有限的事務支持;6，緊跟ANSISQL標准。
8、ApacheAccumulo
代碼託管地址：ApacheSVN
ApacheAccumulo是一個可靠的、可伸縮的、高性能、排序分布式的鍵值存儲解決方案，基於單元訪問控制以及可定製的伺服器端處理。使用GoogleBigTable設計思路，基於ApacheHadoop、Zookeeper和Thrift構建。Accumulo最早由NSA開發，後被捐獻給了Apache基金會。
對比GoogleBigTable，Accumulo主要提升在基於單元的訪問及伺服器端的編程機制，後一處修改讓Accumulo可以在數據處理過程中任意點修改鍵值對。
9、ApacheDrill
代碼託管地址：GitHub
本質上，ApacheDrill是GoogleDremel的開源實現，本質是一個分布式的mpp查詢層，支持SQL及一些用於NoSQL和Hadoop數據存儲系統上的語言，將有助於Hadoop用戶實現更快查詢海量數據集的目的。當下Drill還只能算上一個框架，只包含了Drill願景中的初始功能。
Drill的目的在於支持更廣泛的數據源、數據格式及查詢語言，可以通過對PB位元組數據的快速掃描(大約幾秒內)完成相關分析，將是一個專為互動分析大型數據集的分布式系統。
10、ApacheGiraph
代碼託管地址：GitHub
ApacheGiraph是一個可伸縮的分布式迭代圖處理系統，靈感來自BSP(bulksynchronousparallel)和Google的Pregel，與它們區別於則是是開源、基於Hadoop的架構等。
Giraph處理平台適用於運行大規模的邏輯計算，比如頁面排行、共享鏈接、基於個性化排行等。Giraph專注於社交圖計算，被Facebook作為其OpenGraph工具的核心，幾分鍾內處理數萬億次用戶及其行為之間的連接。
11、ApacheHama
代碼託管地址：GitHub
ApacheHama是一個建立在Hadoop上基於BSP(BulkSynchronousParallel)的計算框架，模仿了Google的Pregel。用來處理大規模的科學計算，特別是矩陣和圖計算。集群環境中的系統架構由BSPMaster/GroomServer(ComputationEngine)、Zookeeper(DistributedLocking)、HDFS/HBase(StorageSystems)這3大塊組成。
12、ApacheTez
代碼託管地址：GitHub
ApacheTez是基於HadoopYarn之上的DAG(有向無環圖，DirectedAcyclicGraph)計算框架。它把Map/Rece過程拆分成若干個子過程，同時可以把多個Map/Rece任務組合成一個較大的DAG任務，減少了Map/Rece之間的文件存儲。同時合理組合其子過程，減少任務的運行時間。由Hortonworks開發並提供主要支持。
13、ApacheAmbari
代碼託管地址：ApacheSVN
ApacheAmbari是一個供應、管理和監視ApacheHadoop集群的開源框架，它提供一個直觀的操作工具和一個健壯的HadoopAPI,可以隱藏復雜的Hadoop操作，使集群操作大大簡化，首個版本發布於2012年6月。
ApacheAmbari現在是一個Apache的頂級項目，早在2011年8月，Hortonworks引進Ambari作為ApacheIncubator項目，制定了Hadoop集群極致簡單管理的願景。在兩年多的開發社區顯著成長，從一個小團隊，成長為Hortonworks各種組織的貢獻者。Ambari用戶群一直在穩步增長，許多機構依靠Ambari在其大型數據中心大規模部署和管理Hadoop集群。
目前ApacheAmbari支持的Hadoop組件包括：HDFS、MapRece、Hive、HCatalog、HBase、ZooKeeper、Oozie、Pig及Sqoop。
㈤ cloudera manager agent 啟動失敗
檢查一下 主機名 和域名配的是否正確
（1） cat /etc/hosts 注意順序
ip 域名 主機名
192.168.*.1 master.com master
（2）cat /etc/sysconfig/network
HOSTNAME = master.com //域名哦
這樣問題就解決了吧！
㈥ 根本就沒有什麼所謂的開源商業模式
在這里我首先要提醒大家的是，撰寫此文並非是要說明開源是「骯臟的商業主義」或「天下根本沒有利他主義」。我的主張是經濟學是關於行為而不是金錢，我是德魯克的追隨者（一家公司的存在是因為解決問題而創造了市場），我反對弗里德曼的觀點（一家公司就是為股東提供回報而存在）。我信奉慷慨的人，我深信拉帕波特的解決方案對於囚徒困境是有效的，即始終以最慷慨的選擇開始。我也堅信我們知道社區運行的意義，即如果你有一把篝火，是不介意我坐下來的。
我曾有幸觀看了BobYoung在「Allthingsopen」上的演講，BobYoung在演講中重申了一家成功的公司應是聚焦於其客戶的成功。我以為這就是紅帽創立之初所種下的DNA，直到今天紅帽仍然以客戶的成功為己任，不斷的前進。我相信分享好的軟體是使我們所有人成功的唯一途徑，就像我們可以作為一個部落一樣。我亦堅信軟體沒有規矩難成氣候。
這並非是利他的行為，而是工程經濟
開源的定義和出現已經有20多年的歷史了，紅帽在成立了22年之後成為了一家超過20億美元的公司，MySQL和JBoss被以不錯的價格所收購，Cloudera和Hortonworks正在成為下一個十億美元的軟體公司，但是我想要撰文表達的是，盡管上述這些公司取得了一定經濟上的成功，他們和開源商業模式沒有關系，根本就沒有什麼所謂的開源商業模式。
我堅定的相信自由許可下、協同開發的軟體的經濟價值，我們從一開始開發軟體就在分享著軟體，這要一直追溯到上世紀40年代末和50年代初，這是因為編寫好的軟體本質上是一項非常艱難的工作。經事實證明，軟體的代碼審核要比測試本身發現的缺陷更有效，所以構建軟體開發的代碼審查文化來創建更加優秀的軟體。在軟體工程和編程系統中很多的發明來自於代碼的重用，或者是精簡已有的代碼以生產更好的軟體。軟體若是沒有在如何構建和部署方面擁有嚴謹的規則，就不可能得到發展，軟體本質上是動態的，而互聯網所連接的世界讓此動態更加的清晰。運行良好、規則清晰、自由許可的協同社區能夠解決軟體的這些屬性，而且相比其它的開發方式能夠開發、演進、維護更優秀的軟體。而這點就是開源軟體背後的工程經濟原理。
案例——Interix
我要講的這個使用開源的案例，真實的反映了沒有開源商業模式這樣一個事實。
Interix是上世紀90年代後期的一款產品，旨在提供在WindowsNT環境下運行Unix程序。其涵蓋了約300多個軟體包，許可證涉及到25個，以及微軟POSIX子系統的衍生開發，當然了還有Interix自身開發的代碼。這些都是在開源軟體定義之前的內容。開始的時候使用的是4.4BSD-Lite分發的，因為AT&T/USL的律師們建議這么做。這其中gcc編譯器套件為我們的工具鏈提供關鍵支持，相當於一個SDK的作用，gcc保證了客戶可以將他們的UNIX應用程序移植到WindowsNT中。
此項目關於GCC移植到Interix環境中就讓一位高級編譯器工程師花了6～8個月的時間，然後在算上測試、集成等，項目則達到了10萬美元，當時的gcc套件大約有75萬行代碼，COCOMO的計算結果表明，價值在1000萬到2000萬美元之間，這個取決於工程師們具體的賺取。也正由於此，我們最終的選擇不是去自行編寫一套編譯器套件，這個成本的節約可是兩個數量級。gcc是一款維護良好、健壯、穩定的編譯器套件，即使憑空從零開始編寫一個新的，未必有它優秀。而這就是使用開源的益處所在。我們同樣可以看到紅帽為Linux內核作貢獻，然後交付Fedoar和RHEL的年凈收益達到10%。Interix當然也是基於開源上游項目，但是它現在自己搞了一個分支，這也就意味著Interix無法獲得gcc主幹上的新功能和新的bug修復。
經實踐評估，gcc每更新一次大版本，我們需要6個月的時間重新集成，但是如果我們始終將自己的修復和提交在主幹上進行的話，僅僅需要一個月的時間來測試和集成。所以成本是從10萬美元，降到了1萬～2萬美元，這就是上面提到的節省數量級的證據。我們也嘗試和Cygnus接觸過，根據他們的解決方案，他們擁有主要的gcc的工程團隊，即多個gcc的貢獻者，但是他們要的價格也貴點，需要12萬美元，但是要知道其它團隊接手這個項目，大約需要14個月才能開工。另外AdaCore技術公司則承諾僅需要4萬美元，而且聲稱第二月就可以開工。看起來這是一個十分明顯的結果，決定是不言而喻的。（我們無法直接參與gcc項目下的五個子項目，盡管有些項目會非常尊重並接受我們的貢獻，但是有些項目卻對我們嗤之以鼻，只因為我們要往微軟的平台移植，這對於一些人是勉為其難的。）
這里並不是說往上游貢獻就是利他主義，這只是說這是一項工程經濟學。這是正確的行徑，而且增強了我們自己使用的編譯器。這也是開源項目能夠運轉良好的秘訣所在。我以為個人作出為社區貢獻的決定是明智的，因為在開源世界的關鍵貢獻里有你的名字，這在某種程度上是最好的廣告，這是最佳的簡歷：能夠勝任項目中的工作，可以有效的和他人協作，並展示出對於技術的理解，這對於面試是絕佳的優勢。當然了，它還非常的有意思。它不僅有趣而且很具挑戰性。如果讀者你是一名開發者的話，或者渴望改進自己的技能，那麼為什麼不去參與到上游社區？從而實現自己的價值並增強技能。
運轉良好的開源軟體社區對於技術是良性的促進。社區發展到一定的階段，就是成為產品、服務（支持、咨詢、培訓）、書籍以及其它周邊相關內容的生態系統。使用有機的模型的話，將開源比喻為一顆大樹的話，有人可以從中獲得木材，另外一些則可以取得其它如樹葉、樹枝、樹根，進而構建很多其它衍生產品。
案例——紅帽公司
紅帽是一家典型的基於開源的公司，可以說是一類公司的典型代表。當我深度觀察紅帽的時候，我發現的並非是單單的開源。我看到的是一家專注於客戶的軟體公司，在發展的過程中歷經三位不同的首席執行官，針對的是三個截然不同的市場環境，這三位首席執行官均在自己的任期內作出了最佳決策。
BobYoung以製作Linux發行版而創立了公司，他致力於亨氏番茄醬的品牌模式，試圖讓人們一提到Linux，就立馬想到紅帽。而此時紅帽初期的成長恰逢互聯網早期階段，也經歷了整個的互聯網泡沫階段，紅帽的策略幾乎都是品牌管理，紅帽成功的融到了資金，並在1999年公開上市。紅帽的股票一度飆升。
MattSzulick接棒的時候，可謂是臨危受命，沒過幾年互聯網的泡沫破碎了，紅帽的發行價從每股$140跌倒了每股$3.5，就這樣艱難的行進著，經過幾年不懈的努力，紅帽成功的將自己的定位轉型為服務，RHEL（紅帽企業版Linux）誕生了，不久之後，紅帽又推出了針對開發者的社區版本Fedora，讓活躍的用戶有施展才華，而紅帽則去專門維護企業級的版本RHEL，更加厲害的是紅帽在金融服務業中成功的跨越了摩爾鴻溝，然後，紅帽花了$350M收購了JBoss，並以此再提供企業級的中間件。正當其它家Linux發行版還處在安樂窩的時候，紅帽已經將自己定位於Unix的獨立軟體開發商上行列了，准備吃掉Unix的份額。
時間轉到2008年，JimWhitehurst開始掌舵，JimWhitehurst擁有航空公司的背景，經過大刀闊斧的變革之後，可謂是成功的將紅帽帶上了又一個頂端。JimWhitehurst深刻懂得如何培養和維護員工的士氣，且有著管理成本的背景，將競爭激烈的航空公司的理念帶給了紅帽：保證用戶滿意。要知道，Whitehurst執掌紅帽的時間是2008年，那是經濟衰退的一年，不過，事實證明JimWhitehurst完勝，自從那以後，紅帽的股價可謂是節節升高。
縱觀紅帽的整個歷史，紅帽始終致力於解決用戶的問題。哈佛經濟學家TheodoreLevitt曾經論說過：「客戶不想要一個四分之一英寸的鑽頭，他們想要的是一個四分之一英寸的洞。」絕大多數的Linux發行版公司都希望自己成為最好的Linux發行版，紅帽卻反其道而行之，並沒有去單純的追求成為最好的Linux發行版，而是注重企業級的質量，以更加廉價的方式替代運行在數據中心中的昂貴的SPARC機器上的Solaris。
毫無疑問，紅帽所構建的產品和服務是基於開源的技術，但是紅帽的商業模式既和DECUltrix不一樣，也和BSD世界的Sun公司的SunOS不同，沒有照搬DECUltrix和IBMAIX協同創建的OSF/1，也沒有像Sun對Solaris的發展是基於SystemV的許可，也沒有像微軟那樣為WindowsNT增加成千上萬的第三方許可協議（比如伯克利Socket技術）。
技術的粘性
當一家公司根據自己的產品和服務，對外提供源代碼時，並嘗試發展自己的協作社區，那麼這家公司就可以獲得很多的益處。其技術會對客戶以及未來潛在的客戶具有一定的粘性，他們會進一步增設佈道師和專家團隊，並圍繞技術更進一步的培養用戶的習慣，那麼技術就隨之穩固的在客戶中間流傳。取決於技術棧和產品的依賴關系，它們可以源源不斷的發展自己的業務。
工程經濟效應或許沒有直接從技術棧中選取那麼明顯，但是其開發者效應能夠以控制和擁有社區來彌補。這也是諸如IBM、Intel、微軟以及Oracle等公司為開發者網路狠下血本的原因，無論其與開源許可是否有關聯。它們在製造粘性。紅帽從其對Linux的工程投資中、其在Fedora社區的開發、以及收購Jboss的技術、專家和客戶中獲得了諸多的益處。