從 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” 。
Compiere Taiwan Support Team
From Compiere Beyond Compiere
=============================
Compiere GodFather Ph.D.Albert
albert_a_chen@yahoo.com
=============================
Skype DrAlbert
=============================
歡迎你加入
Hello Gyata:
與廠商一起開發程式？ 不太瞭解您的意思。
不過，謝謝您的稱讚囉～ ^^
Good Point of View
Hello, Kenming,
原本只是受朋友所託, 想了解與廠商一起開發程式,應該要如何洽談.
第一次造訪這類網站, 沒想到竟發現Developers相當有見地 (是我自己太無知). 敬佩!敬佩!
best regards
Hello White:
yes, 國內有幾家公司已在 “包裝” 比較具知名度的 open-souce 了。 🙂
不過，這個門檻比較不是那麼高，反而是比較專注於領域知識與行銷上。
我個人所構思的，是另外一種 Model，是可以把個別 open-source 的產品當作一個個的 “元件”，可以動態因應客戶的需求而來完成系統的客製化整合。
不過，很感謝 White 所提供的資訊，幫助多多～ ^_^
ＨＩ～各位大大～
http://www.compiere-tw.com/
（不知道是不是）
http://www.songfuli.com/zh/erp/index.html
上面那兩個網址～就可以說是將Open Source軟體～包裝了～
看了大大的文章～我想了想～將Open Source 包裝～感覺滿有前景的
便宜又客製化～應該可以擄獲中小企業老闆的心～^^
（尤其是台灣中小企業～企業家普遍為節儉）
LINUX～就是很好的Open Source 包裝範例吧～
OSC～最近也很紅～很適合網路SOLO族～
看的大大們的文章真是受益良多～
社福團體的電子商務
公司最近想把網路義賣流程進行 E 化(現在是傳真訂購單訂購, 後續所有動作都 “自在人心”), 我當然要想想該怎麼做囉! 最先想到的是制定規格然後外包: 但, 少不了要花個二, 三十萬. 對一個花䶮..
我今天到重慶南路逛逛, 一進書局, 就突然 “通” 了!
我看到有關 osCommerce 架設電子商務的書… 剛好就前幾天, 我們公司還在討論要把網站上義賣商品的流程進行 E 化(目前是用傳真訂購單的方式), 我還在想, 定規格, 找外包… 一個完整的購物機制, 免不了又要花個十幾二十萬的…
osCommerce 就是 Open Source, 如果我們同仁可以接受它預設的作業流程, 那我們的建制成本可以說是非常低廉(就是買些參考書的錢罷了). 如果不滿意, 我們就找個高手(公司)來改, 那我想也花不到幾萬元吧?
hi 阿德, hi Kenming,
這個破報的 inertia 寫的文章你們或許也會有興趣！
Allen Gunn:：跨越鴻溝的培力模式；將自由軟體帶給非營利組織
http://heterotopias.org/AllenGunn#comment-827
阿德，就環境教育/保護界而言同樣也有如此的困擾，我個人在環教所才發現，懂得電腦的人就少的可憐，更不用說來去碰觸open source領域的東西了…inertia 所寫的文章是一個很值得參考的方式。
哈! 讓你一說, 我倒覺得, 是我自己的角色有點不定, 有時後忍不住會想自己搞一下 “客製化”(大概還以為我還在資訊界吧!), 而無法把自己當成一個 “客戶”.
國內可有這種廠商? 如果您知道的話, 不妨介紹我幾家, 我們最近有些需求想要找廠商…
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”，軟體便宜到不可思議的地步，這就夠了！
Open Source 或許是我們這種社福團體在資訊應用上的一條出路…
最大的誘因是費用少, 可是最大的問題是沒人懂呀! 公司沒辦法請一,兩個人來整天搞客製化或 UI (就算遇到真懂的人, 社福團體恐怕是請不起!)…
所以, 如果有公司可以利用 Open Source, 收合理的客製化費用, 然後產出合用的系統, 社福團體何樂不為? (因為沒人知道 Open Source! )
但我個人膚淺的 “感覺”(不代表事實) 而言! Open Source 這詞給我一種高來高去的感覺, 寫下來的詞(比如規格書), 說出來的話, 都好像火星話; 如 Blog, Wiki, jBPM, J2EE… 對 LKK 的企業主而言: “依勢共夏?”, 這或許是 Business 的一種障礙吧!
其實看到那些很突出的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/
Open source 專案成功的要素
前陣子參加了「國際開放源碼」的研討會，聽了一場Patric McGovern(Director, wiki(SourceForge,SourceForge.net))的演講，今天終於有時間整理出來。
全球最大wiki(open_source,open source)開發網站的主持人，他不…