引用
Aron Lindberg, Nicholas Berente, James Gaskin, Kalle Lyytinen. "Coordinating interdependencies in online communities: A study of an open source software project." Information Systems Research 27.4 (2016): 751-772.
摘要
網上社區通常是利用信息技術平臺和相關實踐提供的各種獨立的協調機制來管理工作上的相互依賴性。然而，“未解決的相互依賴關係”仍然存在，它們無法通過這種獨立的機制解決。例如，這些相互依賴關係反映了社區成員之間未識別的或正在出現的基於知識的依賴關係，或正在進行的社區任務之間的關係。與此同時，在線社區不能依靠諸如激勵或命令結構之類的分級協調機制來解決這種相互依賴關係。那麼，這種相互依賴關係應該如何管理呢?為了解決這個問題，論文進行了一個探索性的、理論生成的案例研究，包括對一個開源軟件社區（Rubinius）內的開發活動的定性和計算分析，分析了社區中正在進行的相互依賴關係的管理，並發現未解決的相互依賴關係與可選的結構化活動序列相關聯，將其定義為例程。論文觀察到兩類不同的相互依賴：開發和開發人員相互依賴，它們與例程變化的替代形式相關。論文確定了兩個通用的例程組件：直接實現和知識集成，它們解決了這兩種不同的未解決的相互依賴關係。特別的，“直接實現”處理了代碼中尚未通過模塊接口進行協調的開發相互依賴關係，而“知識集成”解決了開發人員之間無法解釋的相互依賴關係。最後，總結了網絡社區組織原則研究的意義，並注意到研究結果對組織研究中協調問題研究的重要性。
關鍵詞:網絡社區;開源軟件;例程;相互依賴關係;協調;活動變化;訂單變化;序列分析
介紹
傳統地，組織層次結構提供了支持複雜工作管理的協調機制，旨在處理任務和人員之間的相互依賴性，以實現組織目標，因此，協調機制長期以來一直是組織科學關注的中心問題。而在線社區沒有傳統組織層級結構，但是它們通常可以成功地完成複雜的、高度相互依賴的任務的協調。在本文中，我們研究了在沒有組織層級的情況下，在線社區如何有效協調工作，以完成複雜的任務。
目前對在線社區如何完成相互依賴任務的協調的解釋主要強調了信息技術(IT)平臺和相關實踐的獨立機制的存在。對於開源軟件(OSS)社區，IT 平臺提供的這些實踐包括軟件代碼的模塊化和通過增量貢獻層的協作。然而，這些獨立的協調機制並不能解決開發工作的所有相互依賴關係。在大多數開發環境中，一些“未解決的相互依賴”不可避免地以“開發”或“開發人員”相互依賴的形式存在。未解決的“開發“相互依賴關係是指軟件代碼中未處理的交互。產生這些相互依賴的原因是，軟件不可能完全模塊化，而是處於不斷變化的狀態，反映其環境的動態性。未解決的開發人員相互依賴關係是由開發人員之間的交互程度和方式導致的，這些交互方式是為了理解現有的功能，以及跨不同技術環境和用戶社區設想軟件的方向。因此，提出本文主要的研究問題：開源社區如何解決這種未解決的相互依賴關係（“開發”或“開發人員”相互依賴）?
為了解決這個問題，我們進行了一個關於 OSS 項目 Rubinius 的在線社區的探索性案例研究。Rubinius 是一個成功的虛擬機和 Ruby 編程語言的解釋器，它被廣泛用於開發交互式 Web 應用程序。Rubinius 是一個典型的在線社區，它起源於任何特定組織層次的邊界之外，但是需要協調一組相互依賴的開發任務。我們發現 Rubinius 開發人員通過參與各種類型的程序化活動來協調不同的相互依賴的類。首先,他們基於疊加原則的直接程序化任務分配的模塊化結構協調 “簡單”的相互依賴關係。其次，通過在程序化活動的結構中產生更大的變化，解決了未解決的開發和開發人員之間的依賴關係。開發的相互依賴性主要是通過增加正在執行的相關活動類型的變化來處理的。此外，隨著開發相互依賴的增加，更多的開發人員傾向於參與進來，從而增加了任務中開發人員相互依賴的程度。反過來，通過增加與開發任務相關的活動的順序的變化來解決開發人員的相互依賴關係。總的來說，我們發現與成功的開發任務相關聯的例程變化形式是以各種例程組件(例程中穩定的子模式)的集合出現的，其中每個組件都提供了一種專用的機制來協調不同類型的相互依賴關係。活動變化與我們標記為“直接實現”的常規組件相關，它提供了將代碼合併到代碼庫所需的活動的有效覆蓋。順序變化與我們標記為“知識集成”的常規組件相關，它使開發人員能夠迭代地集成分佈在整個社區的洞察力。通過總體開發例程中的這些組件，OSS 社區能夠解決各種未解決的相互依賴關係。相關概念的界定，見表 1
表 1 主要概念的界定
相互依賴與 OSS 例程變異的探索性研究
基於對網絡社區中未能解決的相互依賴（開發相互依賴和開發人員相互依賴）和作為調節機制的例程的介紹，以幫助我們分析在線社區如何處理未解決的相互依賴關係。本節我們對中型 OSS 社區 Rubinius 進行了探索性研究，以檢查 OSS 社區協調相互依賴任務的方式。
我們採用混合方法研究設計，包括定性和計算研究方法。我們選擇這個設計是因為它幫助我們在日常活動的結構中識別廣泛的、統計上派生的模式，並開發出驅動這些模式的潛在機制的豐富描述。這使我們能夠揭示程序化活動的一般結構，以及與這些活動相關的上下文意義和目的，因為它們涉及解決未解決的相互依賴關係。設計包括一個多步驟的過程，通過這個過程，我們試圖對多種形式的數據(主要是作為文本和變量的數字跟蹤)進行三角化，並進行多種步驟和形式的分析(定性編碼、變量的計算操作化、統計建模和可視化)。我們使用與數據語料庫的迭代交互和相關文獻提供的湧現理論，歸納地識別構造和構造之間的關係。
1、數據蒐集
數據的主要部分可以在 Rubinius 存儲庫中在線獲得。我們收集了 12 個月的數據(2012 年 1 月 6 日至 2013 年 1 月 6 日)，數據集包括在線開發平臺 GitHub (https:/ /github.com/)上記錄的所有活動的數字蹤跡，以及 Rubinius 開發的公共歸檔數據(公共訪談、博客文章、會議演講等)，我們還採訪了創始人、企業贊助商、核心開發者和外圍開發者。這為我們提供了訪問社區詳細的內部工作機制的豐富途徑(收集的數據信息見表 2)
表 2 數據統計信息
GitHub 平臺圍繞“pull requests”來組織開發工作，pull requests 是一個獨立的工作單元，它可能包含錯誤報告、討論和代碼等，即可以包含數量不定的活動。我們提取了包含 3704 個活動的 686 個拉請求的蹤跡。該過程遵循探索性數據分析的原則(Tukey 1977)，我們在可視化、統計建模和定性調查之間不斷迭代。GitHub 支持的原始活動及其在我們數據集中的頻率見表 3。相應的，GitHub 平臺實施了 OSS 開發的“fork-pull 請求程序”。
表 3 活動頻率
2、構念可操作化和數據分析
通過對數據的深入初步研究，我們確定了相互依賴和協調機制，並將其運作化。表 4 總結了研究中使用的構唸的定量操作化，包括重點構念突出方面的度量。接下來，我們描述了為引出結果而進行的具體分析。圖 1 呈現了有關分析過程的概述。
表 4 構唸的定量操作化
圖 1 數據分析流程
研究結果
我們提出了以下研究問題:OSS 社區如何處理這種未解決的相互依賴關係?為了解決這個問題，首先我們將詳細介紹帶有和不帶有未解決的相互依賴關係的 pull 請求之間的區別，然後我們將展示 Rubinius 社區如何解決未解決的開發和開發人員之間的相互依賴關係。在此之後，我們將詳細闡述直接實現和知識集成這兩個常規組件的性質，並分別展示它們是如何驅動活動變化和順序變化的。最後，我們將展示例程變化對代碼合併成功的影響。
我們展示了模塊化工作和非模塊化工作以及疊加工作和非疊加工作之間拉取請求的顯著特徵的均值差異及其統計意義，如表 5 所示。如表 5 所示，帶有未解決的開發相互依賴關係與沒有這種依賴關係的拉請求有很大的不同
表 5 未解決的相互依賴
解決未解決的開發相互依賴關係。圖 2(a)和 2(b)分別展示了開發相互依賴和活動變化以及次序變化之間的關係，圖 2(a))為楔形，圖 2 (b))不顯示任何可辨別的關係，這表明開發人員通過增加他們的活動變化來響應增加的開發相互依賴。圖 3 中所示的結果表明，隨著開發相互依賴性的增加，開發人員相互依賴性的程度也會增加。
圖 2 例程變化和開發相互依賴的關係
圖 3 開發相互依賴和開發者相互依賴的關係
解決未解決的開發人員相互依賴關係。我們發現未解決的開發人員相互依賴關係與活動變化和順序變化都是相關的(圖 4(a)和 4(b))。開發人員相互依賴關係與順序變化的關係可以通過擬合一個楔形關係來建立線性模型。
圖 4 例程變化和開發者相互依賴的關係
例程組件。通過研究相關例程組件的內容來揭示這些模式的本質。就所執行的活動的內容而言，例程變化的增加意味著什麼?通過定性分析，我們確定了兩個獨立的例程組件:直接實現和知識集成。由表 6，我們可以發現活動變化的增加與直接實現組件相關，此外，順序變化的增加與知識集成組件相關。
表 6 ANCOVA
合併代碼。正如我們在表 7 中所看到的，活動變化顯然與代碼合併相關，活動變化中一個標準偏差的增加了合併代碼的機會；順序變化與合併代碼的可能性呈負相關，因此，在順序變化中增加一個標準偏差將減少合併代碼的機會。
表 7 Logit 迴歸
總結
現有的許多關於協調的研究都以這樣一種觀點為前提，即明確規定的機制為協調相互依存的組織活動提供了必要的手段。這一假設在最近幾十年受到了質疑，因為在線社區已經蓬勃發展，並且成功地在沒有預先存在的組織層級的情況下完成了複雜的任務。OSS 社區形成了此類社區的一個特別成功的例子——它與其他類型的在線社區有相似之處，但具有獨特的特徵，如共同生產複雜的工件。OSS 社區協調複雜工件的設計和開發，儘管存在一些傳統上被視為與成功協調背道而馳的條件:地理和時間分佈、志願服務和虛擬通信。因此，許多研究人員認為 OSS 社區是下一代組織形式的先驅，能夠提供替代傳統組織協調的可行方案。在這篇論文中，我們使用了一種新穎的、探索性的方法來引出一種理論，即在這樣的在線社區中，例程及其伴隨的變化形式如何作為緊急協調機制，從而潛在地引導我們更好地理解未來的組織形式。
致謝
本文由南京大學工程管理學院 2019 級博士高尚翻譯轉述。
感謝國家重點研發計劃（2018YFB1403400）和國家自然科學基金（71732003，61772014）支持！
閱讀更多 慕測科技 的文章
