導入開放原始碼有何效益？

作者: 劉龍龍

開放原始碼來勢洶洶，尤其是Linux，幾乎所有的市場預測資訊都顯示未來數年Linux伺服器市場佔有率會大幅成長；而屆時Linux相關的軟硬體及服務市場總值也達數百億美元。

這些數字當然都是很吸引人的，姑且不去討論市場專家們是如何估算，也不去計較美國市場應佔全球市場多少百分比才恰當等專業知識；在這個看來充滿商機的市場上，資訊相關廠商理當是會賺錢的一方，而付錢(也就是被尊稱為「客戶」)的另一方，為什麼會主動隨著音樂就開始跳起舞來呢？我想嘗試從「企業」類型客戶的角度來談談。

大多數企業類型的客戶都只是資訊產品的使用者，一般都會注重產品功能、是否好用、是否安全等等切身的考慮因素，但是不太會去關心產品內部是如何設計等的技術細節。比較有規模的企業雖然設有MIS部門，通常也都會為了要維持各項資訊通信設備每天的正常運作而忙得不可開交。

因此，我認為，一般企業對開放原始碼的接觸，是很明確地僅止於「應用」的界限。企業不會、也沒有能力像網路上的個人高手(即駭客)一樣去下載、查閱、改寫、維護任何開放原始碼，企業會在某些有利條件下採用內含開放原始碼的應用解決方案，而這些解決方案都是由專業資訊公司提供。

企業資訊化的目的當然是為了提昇競爭力。但是，資訊化必須要有成本；而成本當然是希望越低越好。企業應用開放原始碼會降低成本嗎？開放原始碼支持者說會，微軟說不會，用了反而會增加成本。不管怎樣，因為他們都不是真正的當事(要付錢的)人，考慮因素可能不完全，所以兩邊說的都未必定能採信，自己算算比較踏實，錯了也不要怪別人亂說。

我對開放原始碼應用成本效益比較的看法，可以先拿在西餐廳點餐為例來比喻：到底是要點大廚規劃的建議套餐比較好，還是單點幾項來組合比較好呢？這個問題的答案可能還是要看點餐的人肚子到底有多餓、想吃牛肉還是海鮮、當天菜單內容如何、甚至服務生是否能清楚介紹等等因素的描述之後再判斷，才比較會正確，而且點餐人點完後如果吃得不滿意卻硬要說很好，別人也不便再更正他。

我認為目前企業的開放原始碼應用，就像中國人開始學吃西餐，並不清楚西餐文化及點餐細節，也許需要去嘗試一些錯誤之後或是產生西餐西吃變成西餐中吃的方式，那就正常了。簡言之，成本效益似乎不一定是開放原始碼的主要正面議題，也不必非在數字上評估。

那麼，開放原始碼能帶給企業什麼樣的效益呢？事實上，我已經觀察到幾個不易量化的效益反而是非常明顯，但是好像都被企業主管忽略掉：

合乎時代潮流的效益

開放原始碼是一股潮流，誰都擋不住，年輕同仁更是樂於參與；它並不一定要非是好或非是壞，它就是它，只要與它同在就行。我會建議那些老總級的朋友們，你也不需要叫資訊長寫充滿了技術名詞但又看不太懂的資訊設備擴充計畫，也不見得要財務長準備各種短中長期財務分析報表，只要簡單地吐出「我決定導入開放原始碼」這十個字；我保證「老板英明」的耳語馬上就會在你的企業中迅速流傳開來。

當然，如何導入開放原始碼這件事還是要資訊長去頭大，但是同仁那種「我們已與時代走在一起」的感覺會反應在工作氣氛及實質產出上。或者，把這個訴求放在招募新進人員的廣告文宣上試試看。

平衡供給主動優勢效益
企業一旦開始導入開放原始碼，負責提供資訊服務的廠商們馬上就會產生地殼擠壓效應。最主要的是原有廠商們在過去多年之間所建立牢不可破的組合必須重新整理，因為現在可能有第二建議解決方案，可供選擇了。如果原有廠商願意合理提供更佳的技術、服務、及保障，那繼續採用無妨；如果不願或不能(如產品代理權限不足)合理提供應有的項目以滿足基本需求，那就可以考慮改由有技術能力的廠商以開放原始碼方案取代？，以免越陷越深。我的瞭解是現在市場競爭激烈，供應商除非是客戶趁機獅子大開口，要求的太離譜，做下去真的不敷成本；否則都是將本求利，儘量滿足客戶需求。如此，買方或許就因此能迅速重振 (廠商不一定非是降價以求，而是將原來套牢的繩索打開)主動優勢效益。

分散風險效益

這個效益很容易被接受，因為任何企業都擔心如果把所有的雞蛋都放在一個籃子裡，萬一有差錯其後果是不可彌補的。開放原始碼很自然地會成為第一選擇。我常常跟企業界的朋友們建議，在導入開放原始碼的計畫裡，除了新開發的應用之外，不妨考慮把現有重要系統的備援系統也列進去。

雖然目前企業對開放原始碼的應用模式還不熟悉，經驗觀摩等等資訊也還不足；但是就上述的幾個效益來看，現在開始考慮導入開放原始碼，至少不會使貴公司輸在起跑線上。

Job Training? 教育訓練 for 職能建置與評估?

專案的成功與否常因公司的管理文化與特性而受影響，故HR時先全盤思考以下幾點：

1.職能建置的目的
建置職能大致可以分類為三種目的：

a. 未來力：實現願景策略, 培育能因應願景策略需求的人才
b. 優質力：傳承擴散內部成功典範
c. 競爭力：優勢競爭力是必需要掌握的。

2. 風險

a. 高階缺乏對未來目標與策略的共識
b. 組織的分工與層級不明確
c. 公司內部缺乏優秀典範或典範不被認同
d. 主管們對職能評鑑有抗拒或不配合
e. 找不到適合職能發展的訓練課程
f. 缺乏資源來建構訓練藍圖

Build in .net 1.1 using Visual Studio 2005?

To target VS 2005 using the older .net framework, try Jomo's work around - http://blogs.msdn.com/jomo_fisher/archive/2005/04/22/410903.aspx

Also check out Robert's workaround, although it's not working for me:
http://www.longhornblogs.com/robert/archive/2005/06/03/14156.aspx
http://www.hanselman.com/blog/BuildingNET11ProjectsUsingVisualStudio2005.aspx

The MS supported version is coming soon:
http://blogs.msdn.com/msbuild/archive/2005/11/09/490817.aspx
http://blogs.msdn.com/clichten/default.aspx

郭台銘語錄

http://www.visa.org.cn/blog/more.asp?id=307

一、如果
（1）妳只是接電話，告訴客戶不知道、沒辦法。
（2）妳只是開訂單，不連絡、不追蹤，有問題不回報、不處理。
（3）妳只是打報表，不確定數字正確性。
（4）妳只是接電話，從未希望客戶有滿意的感覺、從未希望客戶多訂一些貨。
（5）妳只是認為自己是助理，從未想過自己一言一行代表業務、主管、老闆、公司。那麼，妳不夠格做一個稱職的助理，妳的工作，任何人都可以取代 。

二、如果
（1）你從未將部門業績目標時時刻刻放在心中。
（2）你從未想過個人目標攸關部門目標達成。
（3）送樣後，從未想過結果如何，為什麼沒消息。
（4）報價後，從未追蹤為什麼沒有訂單，差多少可以成交。
（5）訂單多了，從未去想怎麼回事，隨波逐流、隨客戶起舞。
（6）訂單少了，不去追查什麼原因，毫無感覺、毫無動作。
（7）你從未想過在客戶面前更專業、更守信。
（8）工作不規劃、時間不管理、成本不控制、客戶不教育。
（9）你認為開發新客戶、新市場是麻煩的、痛苦的。那麼，你不夠格做一個稱職的業務人員，你在，是我們大家的負擔。

三、如果
（1）你不把客戶需求當作是非常的重要。
（2）你不把客戶抱怨當作優先解決的事項，主動追查檢 討。
（3）你時常不準時送貨，當作客戶永遠都會等你。
（4）業務反應客戶的問題，你嫌他煩。
（5）客戶反應品質的問題，你嫌他挑剔，視他為爛客戶。
（6）你經常把〝很麻煩〞、〝有困難〞、〝不想做〞、〝不可能〞掛在嘴邊。
（7）你每天上班當作例行工作，不主動尋找問題、改善品質。那麼，你不夠格做一個稱職的生產部主管，與你共事，我很疲勞。

每日我們在外努力，沒有良好的品質，沒有良好的服務做後盾，
一切效果會打折扣，對客戶的承諾都會跳票，我們便成口才一流、
品質二流、服務三流的公司。

四、如果
（1）有罵沒有稱讚、有懲罰沒有獎勵。
（2）對企業有利的，不立刻行動。
（3）經常把"再看看"、"再研究"掛在嘴邊。
那麼，我也只能偷偷的說，你不是一個稱職的老闆。我不能多說，畢竟你還是我的老闆。

C# 編碼原則 (C# Coding Guidelines)

誰都會寫程式碼！幾個月的編程經驗可以讓你寫出「可運行的應用程式」。但在開發團隊的運行模式下，以最有效率的方式編碼、能被小組成員順暢承接的程式碼就必需要下更多的功夫！

要知道，大多數程式設計師在寫「可運行程式碼」，而不是「高效率程式碼」。寫高效程式碼是一項藝術，必須靠紀律及學習來實踐。建立一個高效率、有默契的開發團隊更需有一定的規範及標準流程。

想要讓開發出來的程式碼穩固且容易維護，除了有必要適當地採用設計模式 (Design Patterns) 之外，也有必要採用編碼原則 (Coding Guidelines)，做為寫程式時依循的準則。設計模式是在設計階段進行的，主要由系統設計者 (System Designer)負責，所以和程式員的關係比較不是那麼密切。至於編碼方針，就和程式員的關係相當密切了。

程式碼命名及格式規範的目的為建立開發團隊的默契以及效率。檢視一篇與自己撰寫風格相同的程式碼不但能減少無謂的猜測，也能快速暸解程式碼，立即進入程式撰寫的狀況。

輔助工具
在Google搜尋keyword :: "Code formatter, code beautifier"，你可找到一票自動化的輔助工具。對C#來說，最重要的編程方針是美國微軟MSDN網站上的Design Guidelines for Class Library Developers。reSharper則是目前我們使用的自動化工具。

編碼原則
Ascertaint C# Coding Standard

相關文章
迅速提升.NET程式設計技巧 - 75個訣竅幫助你減少程式中潛在的問題

管理強人郭台銘經營解秘 --- 細節‧拆解‧簡化‧貫徹‧紀律

《數位時代雙週》第98期【封面故事】‧撰文／何飛鵬

創辦《商業周刊》也擔任過創刊總編輯的何飛鵬，對「管理」情有獨鍾，因此於去年12月創辦《經理人》月刊，並重出江湖擔任總編輯。在他的觀察中，鴻海郭台銘的紮根於作業現場的管理，最是樸實無華，也最有力量，在看完139條語錄後，他特別為《數位時代雙週》讀者撰文，提出台灣企業最應看重的郭台銘管理精髓。

將近三十年的財經新聞採訪經驗，讓我有機會接觸無數的台灣企業名人，近距離觀察體會他們的言行、經營奧秘。但是唯獨現在的台灣首富郭台銘，因為他竄出檯面太晚，我已經退居幕後，一直沒有機會一見。

也因為如此，許多的疑問，一直在我心中繚繞，鴻海的擴張動力及速度，為何如此巨大且快速？遠看像個獨裁者，而獨裁者又何以能有效統治龐大的鴻海帝國？這是個以速度取勝的公司；而他內部快速膨脹的團隊，又何以能手眼協調，有效運作？郭台銘應該是個高效益的經營管理者，而他的經營奧秘何在？

有亞歷山大大帝般的企圖心

這一連串的疑惑，隨著一個偶然的機會而解開，鴻海內部流傳的一百餘則「總裁語錄」，道盡了一切，我確定了一件事：郭台銘是台灣五十年來僅見的經營奇才，魄力與能力都是我淺薄的識見中的第一人。

先談魄力，魄力解釋了鴻海的快速成長、永不停息。語錄第一二八則：「成長來自什麼∣胸懷千萬里」；語錄第一三○則：「心胸有多大、舞台就有多大」；語錄第二十二則：「真正的英雄，是戰死在沙場的人，而不是來領勳章的人」；語錄第一一五則：「除非太陽不再升起，否則不能不達到目標」。

從這些話，我看到古代亞歷山大大帝的身影，郭台銘用想像構築了他的企業舞台，台灣只是起點，他的隊伍要到達他所能想像的地方，而且一定可達成、要達成，否則絕不終止。

大多數的台灣企業家，以台灣做舞台，也以台灣為限制，但郭台銘心中無懼，以意志為方向，他的舞台是世界！

能力來自於細節的累積

看起來戰鬥也是他的樂趣，崇拜馬革裹屍的英雄，這說明了「鴻海再大，仍太小」是郭台銘心中沒說出來的話。或許在最近的電視訪問中，他提出「鴻海上兆，我就要走」的退休預言，是他可以接受的目標。

「魄力」與「想像力」只是起點，「能力」則是郭台銘帶領鴻海走到今天的關鍵。

語錄第一二八則：「心思細如絲」，是郭台銘能力的原點，一切從細節出發，把細節做好。語錄第十八則：「關鍵（KPI）：魔鬼都藏在細節裡」；語錄第一三四則－「對事情的觀察：望遠鏡／放大鏡／顯微鏡」。在整個郭台銘經營語錄中，我們處處看到他從細節著墨，也仔細研究細節，親力親為帶領鴻海團隊追根究底每一個細節的痕跡。

不論是企業經營四大管制：工管、品管、生管、經營到生意型態，到PC產業技術問題，到HR人資管理，他都有他獨到的觀察和洞見，我們不能想像以他這樣規模的老闆，竟然能如此清楚每一個作業流程的細節，唯一的解釋是：鴻海成長太快，他脫離黑手老闆的時間很短，親力親為每一項細節的經驗猶新。

拆解經營問題中的十面埋伏

一旦老闆知道每一個細節，組織裏就沒有任何模糊的空間，工作者更沒有打混的空間。這就是鴻海讓外界感覺一切上緊發條的原因。

追根究底問細節，只是郭台銘的態度，其方法則是「拆解」與「簡化」。他把每一件事、每一個流程都予以拆解。例如，語錄第六十則：解決問題九大步驟。第十三則：系統七分類。第六十一則：生管系統七階層次。第六十六則：主管每天要做的四件事。第十九則：「桌子的顏色」，更清楚看到郭台銘的拆解事物的邏輯，他認為：桌子的表面是我們看到的顏色，但要真正瞭解，只有把桌子拆解才知道。

問題、流程經過拆解之後要再簡化。語錄第五十五則：簡化的對象包括：客戶、料號、流程、管理策略與組織架構，簡化的方法則是簡單化、合理化、標準化……任何事情經過簡化後，就變成響亮的口號。例如：第一二○則：成功的途徑：○抄、○研究、○創造、○發明。再如：第一三二則：三對—選對的公司、選對的人、做對的事。

仔細想想這不就是尋找Best Practice（最佳實務）的過程嗎？鴻海不只在流程上如此，在觀念、思考、方法上也都要有共識，這或許是「總裁語錄」的最大功用吧！

獨裁，卻害怕成功！

郭台銘用「細節、拆解、簡化」最後建構標準化的制度，而落實制度的基本精神則是紀律。第九十五則：工廠管理的理念∣走出實驗室，沒有高科技，只有執行的紀律。第一一五則任何事都要誓死達成任務。至於郭台銘本人，則像是政治學上的獨裁者－「哲君」。第一一七則：領導者須有獨裁為公的決斷勇氣。郭台銘的指令，貫穿鴻海的每一個角落。每天主管向郭台銘的報報，被稱做「面聖」、「上朝」，而這個哲君，則帶領鴻海一再創造奇蹟，攀登高峰。

不過在語錄中，我們也看到郭台銘的害怕：他害怕成功。第一三九則：成功是很差勁的導師，它給你無知與智慧，成功是失敗的媽媽，輕而易舉的成功則是事業大忌。這說明郭台銘居高思危的態度。

郭台銘也考慮到接班的問題，第二十四則：接班人三要件：品德、責任心肯做事、太聰明者則婉拒。但是鴻海的接班布局似乎只在「條件說」，但真命「太子」尚未出現。

這或許是鴻海最值得觀察的未來。如果郭台銘真的退休，沒有哲君的帝國會如何？郭台銘的語錄提供了過去與現在的解答，但未來，要時間來解答。

RSS的缺點也正是其優點

http://taiwan.cnet.com/enterprise/technology/0,2000062852,20095473,00.htm

David Berlind‧唐慧文　　2005/01/07

全球資訊網上的聯合供稿(Web syndication)技術種類繁多。一如諺語所述的情況：標準最棒的地方在於標準太多了。

若真要把RSS 1.0、RSS 2.0(其實接續的不是RSS 1.0版，而是0.94版)、Atom和其他林林總總沾得上邊的網際網路聯合供稿技術理出個頭緒，恐怕需要做碩士論文級的研究。如果在規格的層次上就有問題、而且沒辦法解決的話(依我之見有些衝突是被新聞界誇大了)，那麼我們怎能指望第一線的應用會變得容易上手？本文將討論使用者設法把現有技術湊合著用的情形。

我碰到的一個RSS 2.0問題是，網路出版者通常使用不同的慣例，來刊登以RSS(真簡單聯合供稿)系統傳送的資訊。雖然這種彈性正是RSS 2.0最棒的優點之一，但如此一來，把多重RSS feeds標準化以便匯整呈現的負擔，就轉移到閱聽者這一端。儘管終端使用者應用程式(包括RSS閱讀器在內)通常內含人工智慧，可補救所處理檔案格式紊亂不一的問題(這也意味處理RSS的應用軟體前景相當不錯)，但我懷疑RSS會不會也證明軟體商要兌現諾言極為困難 -- 他們承諾提供為平常人開發的軟體，讓技術生手只用游標和滑鼠點選和拖曳，也能打造出複雜的、交易性(transactional)、伺服器端的應用。

畢竟，RSS是當今最能展現可延伸標示語言(XML)對普羅大眾有何用處的範例，也象徵大多數人與XML最接近的接觸。基於RSS的人氣日盛，大有可能演變成所有資料(不論結構嚴謹或鬆散)賴以採集的主要方式 -- 不論用途僅為瀏覽最新的網誌(Weblog)更新內容、檢索電子郵件(嘿，那不就終結垃圾郵件了嗎？)，或是透過複雜的工作流程傳遞交易資料。就此而論，RSS也可能被當作「點選式程式設計」(point-and-click programming)的一大試金石。

為了鼓勵透過ZDNet網誌領域進行線上協同作業，我們已建立一個內部的Wiki。日後或許內容會更豐富，但目前我們的Wiki首頁比較像是共享的書籤陳列室。我倒是建了一個次級網頁，展現出多重使用者系統的威力：在上面可把我所屬工作群組必須追蹤的網誌一覽無遺。我用Twiki標題外掛程式把以RSS為基礎的聯合發稿內容匯整到同一網頁，基本上該網頁相當於在網誌領域的一個角落設立入口網站，以便我們觀察我認為不該遺漏的網誌。我稱之為我們的雷達。

我加入擷取自Robert Scoble、Jonathan Schwartz、Tim Bray、Bob Frankston、Slashdot、Groklaw等網誌的內容，不久之後，ZDNet.com副總裁Stephen Howard-Sarin又在這個網頁添加了一些，取自於Dan Bricklin、Jon Udell、Dan Gillmor、Phil Windley、Doc Searls等人的網誌。儘管這還稱不上是「點選式伺服器端程式設計」，我認為已十分接近。

但我不滿意這個外掛程式預設的內容擷取格式，以及在網頁上呈現的方式。所以，為牽就我們的需要，我在外掛程式之外添加了一些選擇參數(optional parameters)，以確定最後顯示出來的網頁是純文字(為了效能起見)，而且只從各種內容來源擷取最新的五則標題。以圖示來呈現這類選擇參數、自動產生編碼，並且把程式碼嵌入網頁，這些正是我期待「點選式程式設計」能夠為我代勞的事，而不是凡事都得用硬碼(hard-coding)方式來做(我目前的作法)。

在Wiki普遍成為政治正確的作法之際，Howard-Sarin也在添加網誌內容時仿效我採用的格式。由於欠缺更簡單易用的工具，他只用剪貼方式把程式碼拷貝過來，然後提供不可或缺的替代品。對一群非專業程式設計者來說，能做到這種地步已經很不錯了吧？短短幾個鐘頭，我們兩人同心協力製作了一個入口網站，提供有意義的資訊，而且會隨每次網頁重新整理更新內容。現在，就等其他ZDNet使用者共襄盛舉，把他們喜愛的、不重複的網路內容丟進這個網頁即可。

可是，還有個問題。有些內容無法正常顯示，害得我耗費比原訂計畫更多的時間。比方說，Jonathan Schwartz網誌裡的每一篇內容，都以異於他人的方式呈現 -- 在他以XML為格式的內容中，每一篇不重複的網誌內容(稱為一個item) 都省略連結欄(link field)。大多數的內容，例如擷取自ZDNet的本文，都用連結欄來儲存通用資源識別碼(URI)，以直接連上個別的item(就本文為例，指的是一篇新聞報導，而不是網誌裡的一則日誌)。省略掉連結欄，Schwartz依賴GUID (全域唯一性識別碼，讀音「gwid」) 欄附帶的選項(稱為「permalink」)，來儲存常駐的連結，以連上個別的網誌文章。這麼做是有道理的，因為要跨越整個網際網路連上某則特定的內容，使用專屬的連結是你所能找到、最獨一無二的方法。或許你能想出別的辦法，但何必花這個腦筋呢？基於此理，幾乎人人都把導向自己每則內容的直接連結存在GUID裡。對許多人來說，這意味在GUID裡找到的資料，與在連結欄(若他們採用的話)裡尋得的資料，是一模一樣的。

這些很重要嗎？嗯，就我而言，我覺得很重要，因為我試著想出一種可輕易重複使用的外掛程式參數組合(用「點選式程式設計」術語會稱之為「物件」，但我要等到親眼目睹才會信以為真) ，來建置我們的入口網頁，而那套組合要能夠用同一方式對待本網頁所觀測的各個內容來源。如果某物件在「普通人用的點選式程式設計」現實世界裡只是偶爾才管用，那麼沒多久，一般人就會棄滑鼠投降。

參照TWiki文件編寫採用連結欄的範例，我開始嘗試用它來提供入口網站使用者一個可回歸原始內容出處的連結。這很合理，不是嗎？然而，一旦連結欄被省略，如同Schwartz網誌的情況，即便我在入口網頁上一一附上連結，也不過是死的連結。為了研究這個問題，我進一步探討RSS的弱點 -- 我不認為其他只為體驗網路聯合供稿威力的使用者必須探究得這麼深入。我發現，如果Schwartz的網誌把每則內容專屬的URI存進GUID的話(他是這麼做的)，那麼我就可以倚賴GUID的目錄把使用者導回內容的原始出處。就可重複利用的能力而論，我考慮把這種作法全面套用在我們監看的所有內容上。

以下這一段是RSS 2.0的規格範例，由此可說明連結與GUID未必相同，也證明我傾向採取的解決辦法是對的：

「有關<guid>s的一個常見的問題是與<link>s該怎麼區分，不就是同樣的東西嗎？沒錯，在內容系統裡是如此，但在其他的系統就不見得。在某些系統，<link>s是連上網誌篇章的permalink。但在別的系統，每一個<item>是全文的摘要，<link>s指向該文，而<guid>s則是連上該則網誌內容的permalink。不論在什麼情況下，都建議你提供guid，並儘可能讓它以permalink呈現。這麼做可避免匯整器重複擷取相同的item，儘管這些item可能因為有修改過而有所不同。」

以上是專家建議的最佳範例，無疑是大勢所趨，也隱約暴露出許多內容供應系統依循不同慣例的問題。這正是我遭遇的問題。現在，可重複利用性已被判出局，而我甚至還沒開始嘗試用滑鼠作「點選式程式設計」咧。就每一個我加進入口網頁的內容來源而言，現在我會先研究它的XML，再決定該用哪一套參數。

但GUID相對於link的問題，並不是我們面對的唯一挑戰。

有些內容供應feeds，像是Dave Winer的Scripting News，也丟出一個變化球。Winer的網誌文章不附標題。這是個麻煩，因為要建置含20多個出處、一目瞭然的入口網站，我們決定最簡單的作法便是只顯示item的標題，然後附上導向全文的連結(使用前文提到的item連結或GUID，視哪一種比較適用而定)。但是，就Winer的XML來說，能擷取的東西有限。沒標題可選，只能擷取其他三種 -- GUID、item的發表日期(pubDate)、或是item(敘述)的全文。但item的全文長度從寥寥數字到堂堂數段不等，沒道理拿它來當作超文字連結(hyperlink)。

如同Schwartz的網誌，Winer的GUID也是連上全文的URI。換言之，能供我們用來當連結的文字只剩下發表日期。顯然Mozilla.org對無標題item的感受和我們一樣。Firefox瀏覽器採用一種稱為Live Bookmarks的功能，用來追蹤RSS feeds；該瀏覽器在碰上無標題item時，為了產生可點選的內容連結選單，也提供發表日期作為連上原文的線索。事實上，在處理規格不一的RSS應用方面，Firefox的表現一級棒，就連碰上在同一網誌裡有的item附標題、有的又不附標題的John Robb頻道時，也能機動應變。把Robb的網誌加入Firefox的Live Bookmark後，產生的選單即顯示出Firefox從每一item就地選材，有的擷取發表日期，有的擷取標題。這印證前文所言，就網路聯合供稿而論，供應端所做的選擇，其衍生的後果一概由閱聽者這端承擔。換句話說，控制權從供應者這方轉移到內容出版者這方。值得注意的是，此現象似乎與全球資訊網的走向背道而馳。(基於Internet Explorer使用者眾多，和許多網站用Firefox無法正常顯示，以後見之明來看，即可驗證供應端總是會順應需求端來作調整。)

同理，再度驗證通常軟體會代使用者做複雜的決定和演算法，Dave Winer的網站內容匯整器也作了令人讚許的貢獻，就是把各式各樣的內容慣例標準化，形成單一介面，再透過該介面把源自不同頻道的文章攙雜在一起，按照匯整器擷取的時間倒序排列。比方說12點15分時，某頻道可能顯示出五則，但其中最早刊出的一則也許不比排在它前面、出自另一頻道的文章來得新。不過，不論是哪一則，都是根據終端使用者所在地的時區來顯示發表時間。網路匯整器可不可能自動判知終端使用者的時區，我不清楚；但就Firefox和Newsgator這類美國境內執行的RSS匯整器而言，是辦得到的。看出未來的成長空間了嗎？

起初，我暗地咒罵Winer竟然不附標題。但一旦開始追蹤Winer的網誌後，我就領悟到這種抉擇自有道理。他的網誌只是意識流似的日誌。人在思考時，會先下標題嗎？不會吧。Winer不會，也無此必要。他和別人的網誌之所以可讀性高，與附標題的新聞報導與眾不同，就是因為網誌就像日記一般。這些網誌有許多篇章是想到什麼就援筆立就，若是作者必須停下來先為每一篇定個標題，可能就跟不上奔馳的思緒。這些是特例。另一人氣鼎盛的網誌，作者是微軟的Robert Scoble，就不管每則篇幅多短，都一律冠上標題。以最近談微軟執行長Steve Ballmer評論蘋果iPod的那一則為例，標題幾乎與全文等長。如果他給網誌文章下的標題少一些，或根本不定標題，或許我們更能深入了解Scoble腦子裡的想法。

為了建置一套可重複利用的參數(以便別人只需剪剪貼貼即可)，我不得不緊盯著Winer的內容，我愈是瞪著它瞧，就愈發現自己掙扎於兩種選擇之間的取捨：該用發表日期作為我們TWiki架構入口網站的連結文字呢，還是乾脆把他的全文(儲存在各個item的敘述欄內)下載並顯示在我們的入口網頁呢？畢竟，我們內容顯示的程度僅止於最新的五則，而Winer每天定期刊出五則以上，所以若是列出一串發表日期，除了告知每一則何時刊出以外，提供的資訊聊勝於無。我們真正需要的訊息，是全文的內容為何。碰到Winer這種不附標題的內容，我們唯一的選擇，就是擷取全文(端視外掛程式允許的容量而定)。

事實上，一口氣完整的擷取(包括GUID、敘述、發表日期和某來源提供的其餘材料)，逐漸看來是最適合我們入口網站的通用方法。就這麼搞定。我總算可以回頭做我日常的工作了吧？哎，還不行。

誠如Winer告訴我的，那種作法可能也行不通，因為和許多網誌不同，新聞網站通常在每篇報導的敘述欄裡提供摘要，而不是完整的全文。更糟的是，就算也把敘述抓過來，我發現TWiki的標題外掛程式無法處理超文字標示語言（HTML）格式，而網路新聞幾乎清一色都用這種格式編寫。

這個實驗計畫就像舊時卡通裡會漏水的水壩。就在你以為所有的漏洞都堵好了的時候，另一處漏水又泉湧而出。最後我只好許願，但求聰明人發明只要點選一下就可解決問題的辦法，就像軟體開發業者向來承諾的那般。只是，就現在的進步速度來看，我懷疑那可能要再苦等數年。

但本文仍算是一篇談論RSS優點的報導 -- 也附帶闡述RSS特有的彈性為什麼會讓企圖在亂中求序的人士(比方說軟體開發者)日子難過。畢竟，混亂本是網際網路的常態。