Software Cinema

百萬企鵝是一個嘗試由網路使用者共寫的小說撰寫計畫, 概念顯然地是基於 Wikipedia, 當初看到這個新聞 (Knews) 時, 除了覺得很有趣之外, 其實還對新聞中的一段敘述感到有意思與不解 :

企鵝出版集團強調，這項計畫並非在發掘新作家，所以每位「作者」以 250 字為限，他們呼籲網友要有雅量，尊重別人的國籍、文化及性別，因為每個人的創作都可能會被改動，受不了自己的文章被隨意刪改的人也許不參加為妙。(引用自 Knews )

這是被討論很久的問題, 特別是當初 Wikipedia 計畫開始推廣後, 相對的問題就不曾停止過, 例如 中文 Wikipedia 上針對中華民國的 頁面, 因為爭議太多, 持相異意見的會彼此胡亂刪減修改對方內容, 一直以來都是處於 Semi-Protection 模式下, 幾乎沒辦法對內容做修改, 只能等待討論區有共識之後再說, 換而言之, 在 Wikipedia 上針對此問題的解決是利用 Locking. 真跟上面百萬企鵝新聞稿中的敘述其實很像.

然而, 百萬企鵝何苦要遵循此種模式 ?

回到百萬企鵝計畫的目的, 在他們的 About 中, 首先出現的是粗體字的

Crowdsourcing. The Wisdom of the crowds. Social networking. Collaborative enterprise.

可見百萬企鵝與 Wikipedia 的共同特點, 但是他們決定性的不同卻在於企望達到的目標上. 再參考 About 內的另一段話 :

But what about the novel? Can a collective create a believable fictional voice? How does a plot find any sort of coherent trajectory when different people have a different idea about how a story should end – or even begin? And, perhaps most importantly, can writers really leave their egos at the door?

小 說往往並非事實, 它是 fictional voice 的, 不若 Wikipedia 是以共同建構知識庫為目標. 在 Wikipedia 中, 因為有事實存在, 因此難以容許參雜個人觀感推斷的敘述在內, 然而許多事實卻無法被證明, 只能靠著佐證的史料進行推斷, 由此矛盾就生. 這是短時間內不可能解的問題, 除非我們再度回到過去的獨裁帝制. 百萬企鵝卻不是這樣, 它的計畫要產出的成果是小說, 小說是不是跟事實相關其實根本不重要, 甚至許多地方的邏輯不通其實也不甚重要, 如果我們不期待名家大作, 那麼能有條有理, 有頭有尾地說完一個故事, 其實才是最重要的.

同時, 我覺得這段話裡重新說明了一個重要的事實 : 不同的人本來就會有不同的想法, 只要說的通, 要怎麼想是每個人的自由. 或許小說作者有他想要表達的意念在他的作品中, 但是究竟閱讀者會怎樣解讀, 那其實不是作者能夠控制的事情, 某個角度來說, 作者也只是一個讀者而已. 過去受限於人類所能做到的能力, 小說都是關起門來寫的. 百萬企鵝如果成功, 象徵的其實是打破這個藩籬, 並可以進一步尋求有效 ( efficient ) 的 process 出現. 類似的現象已經在 software domain 出現過了, Eric S. Raymond 著名的 The Cathedral and the Bazaar 十分清楚地說明了此一現象的轉移, 而現在, OSS community 已經在尋找與嘗試 efficient development process 了 ( 但這將會是條非常漫長的路 ) .

百萬企鵝其實應該回到最基本想證明的問題上, 在這樣的環境下, 幾百萬人是不是能夠合作共寫出一部小說其實並不是一個真正需要被解決的問題. 幾百萬人如何能夠合作共同寫出幾萬部小說才是真正應該要被解決的問題. 而百萬企鵝最後產出的那部小說, 其實就是這幾萬部小說中, 最受所有人喜愛的那一本.

雖 然我還不知道這個問題要怎樣解( 要是知道就去寫 paper 開公司了 XD ), 但是可以想見的或許把 content 跟 logic 分開會是必要的, 同時不同版本的 content, logic 是可以同時存在的. 以下圖來說明, 一部小說的內容可以分成數段的 content piece, 靠著 logic 將其連結起來. 如此一來, 每個人可以貢獻自己的想法, 撰寫其中一個 content piece 就好, 不必寫出一整部, 或是較大的區段, 同時結合自己的, 別人的 content pieces, 可以用自己特定的 logic 將其串起來, 但不需要串起全部的 content pieces, 只需要串起說的通的就可以. 從而網路貢獻者又可以分為 context piece contributor 以及 logic contributor 兩類.



同時 content piece 在一定的授權下是可以進一步被拿去修改擴充的, 因此不必有所謂修改刪除別人的文章之情形出現, 而是多重版本可以同時存在, 例如下圖中的 context piece B'' 就是由 content piece B' 修改來, 而 content piece B' 又是由 content piece B 而來. 另外 logic 本身也可以是被重新利用修改的, 例如 Logic One' 就是由 Logic One 修改而來, 替換了最前面的兩個 context piece 連結.


而 logic 與 context pieces 間的關係, 藉由 logic 與 content piece 的分離, 他們之間的關係是 flexible 的, 這樣的想法主要來自於 In-Code Modeling .


如 此一來就不會有百萬企鵝或是 Wikipedia 中, 因為彼此不滿意內容而刪減, 造成爭執的情況出現, 而且各種可能的串聯邏輯可以出現, context pieces 以及 logic 可以很方便地被 reuse / re-use, 整體的 productivity 因而可以提升, 多線劇情小說 (例如 MLNR, 此計劃似乎停擺很久了 ) 的想法也將可以被實現, 這基本上也是 component-based software development (CBSD) 的理想. 當然, 適當的配套措施是要有的, 例如怎樣比對相似的內容, 減少 context pieces 的數量, 避免因為大量的 content pieces 造成 logic contributor 反而需要花費大量時間閱讀可用的 content piece material. 或是適當的 search mechanism 可以被支援, 自動依照 logic contributor 提供的一些線索, 找出適用的 content pieces. 這其實都相似於 CBSE 對於 component 的處理.

或許我之前那邊 Paper Writing Process 也可以朝此方向去解決.