最新的隨身版 OpenOffice.org (Portable OpenOffice.org) 讓用戶將 2.0.1 版的 OpenOffice 放在隨身碟裡帶著四處走，不過分析師認為 144 MB 的大小對於隨身這兩個字，好像不是那麼名付其實。

Portable OpenOffice.org 是完整的 OpenOffice.org 辦公室套件，包括了文字處理器、試算表、簡報和繪圖工具，以及資料庫。這些軟體全被包裝成可攜式應用軟體，便於儲存在隨身碟，可供隨處使用。

Portable OpenOffice.org 2.0.1 佔用 144 MB 的儲存空間，而完整的 OpenOffice.org 則需 300 MB。Portable OpenOffice.org 的開發者 John Haller 表示，這套軟體可在出外旅行時取代攜帶筆記型電腦的麻煩。

Ovum 的研究主管 Gary Barnett 可不這麼認為。他覺得 144 MB 實在太大了點，有些隨身碟只能儲存 256 MB。Barnett 表示 Portable OpenOffice.org 並不真的那麼的「隨身」。的確要用 40 MB 包起整個 OpenOffice 是有所困難，但用戶其實不太需要所有的功能，只需提供基本編輯與閱覽文件的功能即可。

Barnett 提到他個人比較想看到線上的 OpenOffice.org 版本，如網路文字編輯器 Writely。Writely 是一套著名的 Web 2.0 網路應用軟體，可供用戶在線上編輯、分享 Word 與 OpenOffice 文件。

Barnett 說，如此一來，只要他人在可以接上網路的地方，他就可以存取線上的 OpenOffice 文件與應用軟體。

相關網址：
1.Portable OpenOffice.org
2.OpenOffice.org 隨身版面世

AJAX 是非同步 JavaScript 與 XML（Asynchronous JavaScript and XML）的縮寫字，是用來建置網路應用軟體的一種方式。從程式設計的角度，AJAX 並不新的技術，而是應用 JavaScript、CSS 與 DOM 等 DHTML 技術的新方式。

這種方式允許網路應用軟體以客戶端動態呈現與操作，來和用戶產生互動。一方面，減低了向伺服器端重覆提出連線要求的需要，另一方面帶來了更順暢的使用者經驗，讓網路應用軟體更像是桌面軟體。

比起過去傳統作法由伺服器端一手包辦企業邏輯與介面構成，AJAX 打破了這個模式，客戶端如今也扮演起更為積極的角色。Google Maps 就是一個典型的 AJAX 網路應用軟體。

正因為如此，AJAX 專案團隊運作上也受到影響。"AJAX in Action" 共同作者 Dave Crane 表示，設計師必須了解介面自動產生的方式，JavaScript 開發者必須與設計師更緊密合作。Tapestry、Wicket 等框架（framework）已經開始著手 AJAX 化，此外，Java 也會在網路服務與整個 SOA 架構下更為活躍。

從整體架構的觀點，由於 AJAX 取得過去展示層（presentation tier）部份的使用者流程控制權，必須對伺服器端運作進行重新思考，帶來了許多挑戰。

目前並沒有單一完整的 AJAX IDE 可供使用。Crane 表示他看過開發者採用 Eclipse 甚至是 Dreamweaver 開發 AJAX 應用軟體。除錯器方面，Mozilla 下有 Venkman，IE 則可選擇 Microsoft Script Debugger 或 Script Editor。

對於雨後春筍般出現的 AJAX 框架，在客戶端框架上，Crane 偏好 prototype.js、Dojo 或 MochiKit。伺服器端框架 Ruby on Rails 有著不錯的 AJAX 支援，Java 與 .Net 陣營則在積極追趕。Crane 表示 2006 將可見到引人 注目的發展。

相關網址：
1.AJAX & Java: "AJAX in Action" 共同作者 Dave Crane 專訪
2.AJAX 探討

LGPL 的英文全文是 "GNU Lesser General Public License"，中譯有許多版本，維基百科全書譯為「GNU 寬通用公共許可證」、或一般比較常見的有「GNU 較寬鬆公用許可證」，筆者則取用「GNU 較寬鬆公用授權條款」一詞，以其較符合國內譯文的語法。那麼顧名思義，LGPL 就是較為寬鬆的「GNU 公用授權條款 (GNU General Public License，GPL)」，所以其基本架構和要求都與 GPL 如出一轍，例如 Copyleft 的機制，不得向被散布者收取授權金，以及拘束衍生作品選用授權條款的自由，不過、既然取名「寬鬆」，那必然也有得以獨立出來的不同之處。

最大的特點就是，LGPL 是針對函式庫（註一）所特別設計的授權條款，它稍微弱化了 GPL 追求絕對的軟體自由的實踐，GPL 向來有一項被戲稱「感染性」的特點，那就是取用了 GPL 程式的部分原始碼後再編寫出來的衍生作品，無可避免的受到 GPL 的拘束而一定得以 GPL 作為這個衍生作品的授權條款。在這方面，LGPL 取而代之是一種更為切合現實的推廣態度，在某些特殊的使用環境下，它提供了較之 GPL 更有利的分享方式。

如果照 GPL 原本的預設，程式的編寫者在設立與此使用 GPL 授權條款函式庫的連結時，就可能被定義為取用，因而被迫受到 GPL 的拘束，程式的編寫者反而可能因此怯步。但考慮到函式庫使用上的壯大在於各方的連結交互作用，一旦因為此等感染性的疑慮而削減了自由軟體類型的函式庫的被使用率，則亦不為研議 GPL 的自由軟體基金會所樂見。所以，LGPL 就在這個思考立基點上脫穎而出，LGPL 定位在於提升自由軟體函式庫的市場佔有率，擴大其使用對象、引介更多使用者接觸了解自由軟體，藉此達到推廣自由軟體的目標，像 GNU C 函式庫及 GNU/LINUX 都是成功的例子。

是以，LGPL 條文的重點其實就在於訂立規則界定「基於函式庫」與「使用函式庫」行為的分野。所謂「基於函式庫」指稱與 LGPL 函式庫連結的他函式庫基礎乃衍生自 LGPL 函式庫的一部分，因而承襲 GPL 的感染性特點，會拘束此一連結函式庫也須以 LGPL 做它的授權條款；而「使用函式庫」則意指對於 LGPL 函式庫的單純利用關係，或者是微量取用（註二）亦可不受拘束。以上僅是原則性的解釋，詳細的分辨標準仍得進一步視個案而定。

LGPL 當然還有其他的特色，像是修改 LGPL 函式庫所產生的衍生作品，衍生作品本身仍然得是函式庫才能續用 LGPL 授權條款，若其為獨立的軟體程式，則只能轉而受到 GPL 授權條款的拘束；此外、使用 LGPL 授權條款的函式庫被允許在任何時候轉而使用 GPL 為其授權條款，但此轉換行為並不可逆轉。由此可看出來 LGPL 與 GPL 之間既合作又競爭的共生關係，而 LGPL 就前段所說其為一種與現實折衝妥協的過渡帶，論到自由軟體基金會的原意還是希望更多人使用 GPL 授權條款來保障軟體的自由性持續散布。從 LGPL 的生成可以看到自由軟體授權模式由理想到與現實切合的調合觀點，從遠一點的角度來觀察，這種稍微折衷的調和模式有擴大其規模的可能性與未來性，值得日後持續的追蹤與觀察。

註一：函式庫 (Library) 在資訊科學裡的定義，是某些元件的集合，這個元件負責不同的流程和功能，而可以利用這些元件間的相互運作，運用在研發軟體程式上。
註二：所謂的微量取用像是目的碼僅用了數字參數、資料結構層級、小巨集及一些內嵌功能（十行以內），雖然定義上符合衍生作品的範疇，但被認為微乎其微，所以不至於非得受到 LGPL 授權條款的選用拘束。