「軟體」，直到一九五九年才真正被視為一個單獨的個體，而不是硬體的附屬品。當時實際上並沒有什麼「軟體協同開發」的觀念，就在不久之前的一九五六年，第 一個程式語言 FORTRAN （指的是公式翻譯器： FORmula TRANslator）才剛被設計出來。稍微看一下那時候的程式設計大環境： 編輯大人給的題目中談到了要說些歷史淵源，我們就先從遠古時代談起吧。

一、程式設計觀念仍然深受一九五一年，由劍橋大學所出版的《電子數位電腦專用程式的準備》（The Preparation of Programs for an Electronic Digital Computer） [1] 這當時唯一的一本程式設計教科書的影響。其中最重要的概念就是：發展「副程式庫」，這是當時他們認為可以減少程式發生錯誤的最佳方式。 二、所使用的儲存媒介是打孔卡片。
三、電腦系統是體積要佔上一個設備良好的大房間的大型主機，像是 IBM 的「七零四」電腦。
我們可以說，那時候唯一可以稱得上是軟體協同開發的動作，大概只存在於討論程式設計時的紙上作業吧！也就是「程式員彼此之間，所定義妥當的副程式的介面」。

從五零年代末期到六零年代中期，「軟體」從盛極而衰敗，陷入了第一次的軟體危機。主要的原因在於當時的硬體系統雖然在效能上提昇了一百倍，但是軟體技術的 進展幾乎停頓下來。這個趨勢一直到現在都還持續地存在著，不過當時軟、硬體之間發展的極度不對稱，讓電腦看起來活像是一部頭殼壞去的機器。順道一提，這也 表示了軟體的改進，實際上可以使「舊」的機器發揮出更多的效能，而不是「跑不動耶…」。因此好好愛惜舊機器，不想用的時候捐給中、小學，或是捐給山上、偏 遠地區的部落都很好。

到了一九六八年，終於出現以軟體工程作為主題的會議，逐步地將程式設計從藝術，帶入工程訓練與科學研究的範疇，並且提出了「結構化設計方法學」。一九七零 年代，在這個將程式進一步文本化的潮流下，讓我們可以在比較小的設計單元上進行分工。同時也由於硬體的進步，讓我們可以使用更多記憶體和計算資源，來輔助 程式員開發軟體的工作。從這裡開始，我們才有了具有現代意義的軟體協同開發的工具，並且真正地實際運用到開發過程中。

用來支援軟體協同開發的工具中，最重要的一環，一般稱之為修訂控制（Revision Control）或者是版本控制系統（Version Control System）。這些系統一開始就是設計用來管理軟體開發計畫的源碼，可以說是針對下面問題的直接回應：

軟體開發計畫可能有成百上千個檔案，程式員的數目則從幾個到數十個不等。在軟體開發的過程中，我們要如何將所有程式員的工作，做一個適當的協調整合呢？怎 樣才能避免其中一個人的工作，不會因為其他人的編輯動作而損失呢？如果有兩個人同時編輯一個源碼檔案，設若其中一位作了修改，那麼另一位要如何知道目前 「最新」的版本為何呢？要怎樣保證這兩個人所做的改變都能夠正確地反應到源碼檔案中呢？可不可以看出每一次的修訂，是變動到哪些地方呢？是由誰所做出的 呢？有沒有辦法知道，我們之前所做的某一次修訂實際上是錯誤的呢？有沒有辦法僅僅改正那一個錯誤，而不影響到它以後的任何修訂結果呢？

所有這些問題的答案，都指出我們需要一個設計良好的版本控制系統，這是所有軟體協同開發的關鍵所在。隨著歷史發展的腳步，從一九七零年代以降，版本控制系統也逐步而確實地回答了上面胡謅一通的問題。

第一個著名的版本控制系統稱為 SCCS （源碼控制系統： Source Code Control System），是在一九七零年代隨著 UNIX 而來的一套系統軟體。可以在 GNU 計畫中取得它的一個仿製品（clone），稱之為 CSSC （相容的笨拙源碼控制： Compatibly Stupid Source Control） [2] ，這些傢伙還真是把為程式命名當成一種樂趣啊！事實上，命名是程式設計一半的樂趣。這套系統適合用來作為，同一個文字檔案不同版本間的管理。

到了一九八零年代，我們有了 RCS （修訂控制系統： Revision Control System） [3] 。 RCS 主要也是在 UNIX 系統下運行，不過目前在 OS/2 、 DOS 、 Windows 95 、 Windows NT 等平台下也已經可以取得。 RCS 允許一個軟體計畫可以在大量的源碼檔案以及任意數量程式員的狀況下，進行協同開發的工作。不過它的問題在於：當某個檔案在編輯時，它就不能被另一個人編 輯。

因此我們有了 CVS （同時版本系統： Concurrent Versions System） [4] ，它所使用的資料結構和 RCS 是相同的，唯一不同的地方在於：它允許了任意數量的程式員，「同時」編輯「一個」檔案，並且任何人都可以隨時將她的變動反應到檔案中。如果大家的變動彼此 間沒有衝突，那麼一切都好，源碼可以被整合成一個共同的修訂版本；但是如果有了衝突， CVS 就會說明在哪裡發生的，並且給程式員自己決定要如何處理。這樣子的解決方案形成了一個理想的版本控制系統。由於 CVS 的出現，使得我們可以組織起一個，程式員的組成可能跨越全部二十四個時區的全球性軟體開發團隊，這真可以說是電腦與網路在應用上的極致表現了。

如果讀者對於這樣的軟體開發模式還存有一點點的懷疑的話，建議不妨試著簽出（check out） GNU/Emacs 計畫的源碼看看，經驗上是幾乎隨時（以 cron 最小的單位：分鐘，來算的話）都會有人在做修訂的動作。即使保守一點來看，我們也可以說每個小時都有人在改進這套軟體，這樣子的開發型態，實際上在大部份 的私權軟體中是無法辦到的。由於世界各地無私自願者的「好意」所表現出來的，人類互助合作的本質，我們卻在自由軟體上面辦到了。

除了上面所介紹的三種之外，現存可用的版本控制系統至少還有數十種可供選擇。它們之間的差別並不大，有些是私權的，有些則是自由軟體。為了公平起見，我們在這裡再額外地列出一些常見的版本控制系統：

一、開發 Linux 內核所使用的 BitKeeper [5] ，但本身卻是私權軟體。
二、 IBM 的 Rational ClearCase [6] 。
三、使用電子郵件來達成同步的點對點（peer-to-peer） Code Co-op [7] 。
四、在大型商業應用上蠻成功的 Perforce [8] 。
五、學習 ClearCase ，有點像是介於 CVS 和 NFS 之間的應用的 Katie [9] 。
六、想要取代 CVS 的 Subversion [10] 。
七、微軟的 Visual SourceSafe [11] 。

這裡所列出的私權軟體我們並不建議使用，不過如果發現了什麼有用的功能，而自由軟體沒有的話，請幫忙將這個資訊寄送到相關的自由軟體計畫，以使他們可以儘 快地實作出仿製品。目前來說， CVS 的使用率顯然是最高的，短期之內應該也不會有什麼變化。解決了協同開發問題之後，自由軟體就這樣一天二十四小時、一週七天，給自己 撐起了一片天，成了現代版的日不落帝國，並在軟體協同開發的歷史寫下了精彩的一章。

相關網址/文章：
[1] Wilkes MV, Wheeler DJ and Gill S, The Preparation of Programs for an Electronic Digital Computer, Addison Wesley Press Inc., 1951, 167 pp.
[2] GNU CSSC
https://cssc.sourceforge.net/
[3] Official RCS Homepage
https://www.cs.purdue.edu/homes/trinkle/RCS/
[4] Concurrent Versions System
https://www.cvshome.org/
[5] BitKeeper - The Scalable Distributed Software
Configuration Management System
https://www.bitkeeper.com/
[6] Rational ClearCase
https://www-306.ibm.com/software/awdtools/clearcase/
[7] Code Co-op: Peer-to-Peer Version Control
https://www.relisoft.com/
[8] Perforce Software - The Fast Software Configuration Management System
https://www.perforce.com/
[9] Katie
https://www.netcraft.com.au/geoffrey/katie/
[10] Subversion
https://subversion.tigris.org/
[11] Visual SourceSafe
https://msdn.microsoft.com/ssafe/