{Draft} Open Source 的 “Business Model” 思考

2005/01/05| 閱覽人次：17,146| 13 則留言

從 Jimmy 網站一文：「專案成功的要素」

才知道，原來 Jimmy 參加了「國際開放源碼」的研討會，聽了一場Patric McGovern(Director, SourceForge.net)的演講。

最重要的是， Jimmy 節錄了 “Open Source 成功的關鍵” (感謝！對我實在太有幫助了) ^^”

全球最大open source開發網站的主持人，他不但用Apple的Keynote製作了超炫的3D轉場投影片，還提到了一個有趣的觀察；他認為一個成功的開放原碼專案通常有這些關鍵：[全文:]

1. 要有趣！讓人覺得有吸引力
2. 可與其他的軟體相互結合(e.g. blog + photo album + wiki + forum + …)
3. 傾聽使用者的回應
4. 提供良好的vision給使用者參考
5. release early, release often

這一年來，我個人也一直在觀察思考 “Open Source” 這個 “社群”。
前四點，我大概都有想到，但第五點，完全沒有想到！！
哇哈哈 ~ 讓我在對 “Open Source Business Model” 研究的思考上提供了太大太大的幫助了。

這股有史以來可以說是顛覆 「知識有價」 的傳統觀念，開發者最主要的目的不是取得實質的 “回饋”，而是 “Just for Fun” ~ 沒有實質的收穫，看來 Developers 動力的主要來源在於 “樂趣” 及 “成就感”。

基於樂趣所開發的專案甚至產品，在傳統的軟體開發公司來看，簡直是不可思議。為什麼呢？重要的原因是，沒有約束力。沒有約束力就代表無法確保時程及品質。傳統的經營模式是始自於最原始的交易觀念：
我 “付錢” 請你來 “做事” ，所以我有權力可以要求你需要做什麼樣的事；若是你對事情的內容或報酬覺得不合理、無法忍受，那麼，你可以自由離開。

這種模式是屬於 “Tight Coupling (緊密連結)”，在 自由軟體、OpenSource 這股風尚尚未普及時，普遍資本主義的商業行為基本不脫離這樣的模式。
“Tight Coupling” 的組織層級觀念是很重要的，最典型的，即在於軍隊，不如此，無法有效命令統御士兵。

而 “Open Source”，則完全相反，它是屬於 “Loose Coupling (寬鬆式的連結)”。
組織非常地鬆散，開發者可以來去自如，沒有階層的管理，也沒有所謂專案時程的壓力。

我研究了幾個 “OpenSource” 的開發，發現到，幾乎都是屬於 “functional-based” 的開發 — 以功能為主，不特別強調設計；反而比較是以 “Task” ，也就是以系統功能為主要的規範。
傳統的專案開發絕大部分也是以 “功能導向式” 的開發 — 不重視軟體系統內部的結構。這種開發的模式最大的問題在於無法快速應付使用者的需求變更。

我個人並不主張 “功能式” 的開發模式，覺得那是 “Quick-and-Dirty”。
只是，沒想到，”Open Source” 走這樣的模式，仍造就了許多頂尖的應用系統(例如 jBoss)，足以擔任商用系統的使用。

看來主要的關鍵原因可能就是上述的第五點：release early, release often。
但，此種模式，拉回到小型、區域式的專案開發，因為資源限制(人)，並不容易達成第五點這樣的要求。

我主要所思考的是，有沒有機會把 “Open Source” 當作是可以來開拓的 “Business Model” ？

因為企業的 e化，需要許多應用系統的服務，例如人事、財會、採(訂)購，或泛稱 ERP 系統．．．等。
許多中小企業，也很需要這些應用系統的服務，但，卻沒有足夠的預算來負擔這些商用的系統的花費。買現成的套件(Package)？根本無法應付 “客製化” 的需求。

“Open Source” 的一些模組，看來很有機會可以應用在中小企業的應用系統服務上。

舉一個例子，電X 廣告公司需要一套可以做電子簽核的 Workflow 系統。若購買商用的 Workflow 系統，兩個最主要的問題：

  • 以 200 人的規模，導入 Workflow 系統的 Liense 起碼要 50 萬以上。
  • 需要與現成的人事系統整合。

因為需要系統整合，同時一個問題，誰來整合？ 當然 Workflow 系統廠商又想要來收這一筆系統整合的費用。並且最好就是我的 Workflow 系統來整合你們的人事、ERP 等系統，然後，永遠都不要換掉我的 Workflow 系統。

那麼，若是，這家廠商的 Workflow 系統倒了或改版或原來所整合的系統升級了而不相容，該怎麼辦？
這種問題永遠糾纏不清。

而若是，所導入的是 “OpenSource” Solution，就不會有第一個 License 的問題。再則，因為可以完全交付所有的文件與原始碼，對於未來維護及客製化等，均是很大的幫助。

我經常所主張的：協助你導入某某系統，就是鼓勵你隨時都可以把它給抽換掉！(整合的設計觀念問題)，所以，有更好的 “open source” solution，換掉原來的，根本不足惜！ 因為本來就不用錢。 😉

那麼，系統廠商賺什麼錢？
最主要的獲利來源有兩種：客製化 and 系統整合。

例如，jBPM (Business Process Management) 這個 Open Source，核心部分算是開發得很完整了。不過，在 Web UI 及中文化等尚有許多調整及修正的地方。
不需要從無到有開發一個 Workflow 系統，可以基於商業客戶需求的考量下來 “客製化” 一些功能或門面(UI)的修飾。

難不難？這可比開發一個產品容易得太多了～

再來，”客製化” 要不要花時間及功夫呢？而且，考量的可能不僅是幾套 “Open Source” Solution，若同時對數十個的產品有意來開拓經營時，是否需要請 “Developer” 來客製化呢？

說真的，我認為這就是關鍵之處！！

以我們團隊為例，我們的專長在於整體架構設計與整合，但沒有人力來完成 “Hard-Coding” 的客製化，不是不會，是真的沒有多餘的人力。我們很容易看得出來許多 open source 的結構，也知道該如何切入，但，確實是要花時間去克服解決(例如，要讓 jBPM 順暢地跑中文及移轉至 MySQL，要花上一個星期才能解決)。

需不需要請 “Employee” 來負責這些問題？ I don’t think so…
許多軟體公司就是因為擔負太多太多的人事成本，根本無法賺錢。

軟體設計公司走的路線就是 “菁英團隊” ~ 極少數的菁英負責軟體架構、整合及設計，再與擅長程式開發的軟體工廠互補。

我是覺得，偏底層技術面(ex. J2EE)的高級人才仍散居在各地，可以透過 Internet 社群(如，Java World)與之聯繫對話。
若是，能吸引這些人才的高度興趣(首要考量)，並且，在基於興趣來共同參與客製化的設計與開發下，未來若能獲得一些 “實質” 的報酬(第二個考量)，我相信這些高級玩家的參與意願會來得更有興趣、更積極些。

當然，有很多細節，我仍未想清楚，待一些細節性的問題獲得滿意的答案後，我想，這應該會是可以成為一個不錯的 “Business Model” 。