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

從 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” 。

文章導覽

   

共有 13 則迴響

  1. Compiere Taiwan Support Team
    From Compiere Beyond Compiere
    =============================
    Compiere GodFather Ph.D.Albert
    albert_a_chen@yahoo.com
    =============================
    Skype DrAlbert
    =============================
    歡迎你加入

  2. Good Point of View

    Hello, Kenming,
    原本只是受朋友所託, 想了解與廠商一起開發程式,應該要如何洽談.
    第一次造訪這類網站, 沒想到竟發現Developers相當有見地 (是我自己太無知). 敬佩!敬佩!

    best regards

  3. Hello White:

    yes, 國內有幾家公司已在 “包裝” 比較具知名度的 open-souce 了。 🙂

    不過,這個門檻比較不是那麼高,反而是比較專注於領域知識與行銷上。

    我個人所構思的,是另外一種 Model,是可以把個別 open-source 的產品當作一個個的 “元件”,可以動態因應客戶的需求而來完成系統的客製化整合。

    不過,很感謝 White 所提供的資訊,幫助多多~ ^_^

  4. HI~各位大大~
    http://www.compiere-tw.com/
    (不知道是不是)
    http://www.songfuli.com/zh/erp/index.html

    上面那兩個網址~就可以說是將Open Source軟體~包裝了~

    看了大大的文章~我想了想~將Open Source 包裝~感覺滿有前景的

    便宜又客製化~應該可以擄獲中小企業老闆的心~^^

    (尤其是台灣中小企業~企業家普遍為節儉)

    LINUX~就是很好的Open Source 包裝範例吧~

    OSC~最近也很紅~很適合網路SOLO族~

    看的大大們的文章真是受益良多~

  5. 社福團體的電子商務
    公司最近想把網路義賣流程進行 E 化(現在是傳真訂購單訂購, 後續所有動作都 “自在人心”), 我當然要想想該怎麼做囉! 最先想到的是制定規格然後外包: 但, 少不了要花個二, 三十萬. 對一個花䶮..

  6. 我今天到重慶南路逛逛, 一進書局, 就突然 “通” 了!

    我看到有關 osCommerce 架設電子商務的書… 剛好就前幾天, 我們公司還在討論要把網站上義賣商品的流程進行 E 化(目前是用傳真訂購單的方式), 我還在想, 定規格, 找外包… 一個完整的購物機制, 免不了又要花個十幾二十萬的…

    osCommerce 就是 Open Source, 如果我們同仁可以接受它預設的作業流程, 那我們的建制成本可以說是非常低廉(就是買些參考書的錢罷了). 如果不滿意, 我們就找個高手(公司)來改, 那我想也花不到幾萬元吧?

  7. hi 阿德, hi Kenming,
    這個破報的 inertia 寫的文章你們或許也會有興趣!
    Allen Gunn::跨越鴻溝的培力模式;將自由軟體帶給非營利組織
    http://heterotopias.org/AllenGunn#comment-827

    阿德,就環境教育/保護界而言同樣也有如此的困擾,我個人在環教所才發現,懂得電腦的人就少的可憐,更不用說來去碰觸open source領域的東西了…inertia 所寫的文章是一個很值得參考的方式。

  8. 哈! 讓你一說, 我倒覺得, 是我自己的角色有點不定, 有時後忍不住會想自己搞一下 “客製化”(大概還以為我還在資訊界吧!), 而無法把自己當成一個 “客戶”.

    國內可有這種廠商? 如果您知道的話, 不妨介紹我幾家, 我們最近有些需求想要找廠商…

  9. Hello Jimmy:
    介紹的兩個網站我看過了,蠻不錯的,謝謝你。 🙂
    與我之前看過的幾個以 opensource 為 solution 的 service-oriented 公司挺接近的。
    你所說的有一位 powerful 的 projet leader 來帶領整個長期性的規劃,我很認同。這個角色,我是定位由 “Architect” 來整體規劃的。

    Hello 阿德:
    可能你誤會我的意思,本來就不可能由客戶來作客製化的工作。
    open-source 的產品,把它看成是半成品比較恰當,所以會有如 Jimmy 所介紹上述兩個網站以 “open-source” 的 total solution 來當作賣點,這與我的想法是非常接近的。
    另,open-source 沒有所謂高來高去的。倒不如說,是低來低去~ ^_~
    前述提及,因為簡單的設計(甚至設計沒有傳承設計圖),主要溝通的機制是以低階程式碼做溝通。所以當然只有少數幾個核心 Developer 知道如何開發。

    總之,要能將 open-source 產品推至企業,仍必須經過 “包裝”。這個 “包裝”的工作,並非由客戶負責。客戶只要看到完整、符合他們所需,或者 ISV 可以協助客製化成他們所需的。
    甚至,連所謂 “open-source” 根本就不要提,沒有必要!
    客戶只要知道,不需要購買 “License”,軟體便宜到不可思議的地步,這就夠了!

  10. Open Source 或許是我們這種社福團體在資訊應用上的一條出路…

    最大的誘因是費用少, 可是最大的問題是沒人懂呀! 公司沒辦法請一,兩個人來整天搞客製化或 UI (就算遇到真懂的人, 社福團體恐怕是請不起!)…

    所以, 如果有公司可以利用 Open Source, 收合理的客製化費用, 然後產出合用的系統, 社福團體何樂不為? (因為沒人知道 Open Source! )

    但我個人膚淺的 “感覺”(不代表事實) 而言! Open Source 這詞給我一種高來高去的感覺, 寫下來的詞(比如規格書), 說出來的話, 都好像火星話; 如 Blog, Wiki, jBPM, J2EE… 對 LKK 的企業主而言: “依勢共夏?”, 這或許是 Business 的一種障礙吧!

  11. 我研究了幾個 “OpenSource” 的開發,發現到,幾乎都是屬於 “functional-based” 的開發 — 以功能為主,不特別強調設計;反而比較是以 “Task” ,也就是以系統功能為主要的規範。
    傳統的專案開發絕大部分也是以 “功能導向式” 的開發 — 不重視軟體系統內部的結構。這種開發的模式最大的問題在於無法快速應付使用者的需求變更。
    我個人並不主張 “功能式” 的開發模式,覺得那是 “Quick-and-Dirty”。
    只是,沒想到,”Open Source” 走這樣的模式,仍造就了許多頂尖的應用系統(例如 jBoss),足以擔任商用系統的使用。

    其實看到那些很突出的open source軟體,並不盡然是因為興趣而開發的,有些team or com認為這是一個商機,於是開始投入open source的領域,來擴展他們的可見度和知名度。他們裡面一樣有個powerful 的project leader,甚至對整個軟體有長遠的規劃,因此才不致流於都是你說的functional-based開發,不過許多著名的個人用普及軟體倒是比較偏向functional based的模式。

    有興趣可以看看兩個project, 不知道對你是否有用

    Compiere ERP & CRM
    http://www.compiere.org/services/index.html
    SugarCRM他販賣的support pack
    http://www.sugarcrm.com/home/component/option,com_phpshop/page,shop.browse/category_id,7831937ba02916cce53ebcfc27a82e57/

  12. Open source 專案成功的要素
    前陣子參加了「國際開放源碼」的研討會,聽了一場Patric McGovern(Director, wiki(SourceForge,SourceForge.net))的演講,今天終於有時間整理出來。
    全球最大wiki(open_source,open source)開發網站的主持人,他不…

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。