--- title: "我希望看到的開源社群" date: 2025-04-30T00:00:00+08:00 publishDate: 2025-04-30T00:00:00+08:00 lastmod: 2025-04-29T17:37:01+08:00 tags: ["社群","開源","人際"] toc: true permalink: "https://blog.aotoki.me/posts/2025/04/30/the-open-source-community-i-hope-to/" language: "zh-tw" --- 最近實際參與了[工研院開源事件](https://www.ithome.com.tw/news/168497)後被視為延伸的開源授權爭議。起因在初步處理後，有人詢問是否會有後續處理，我認同有後續處理，所以提出了調整用詞的建議，然而後續並未如我預期以更友善的方式繼續進行。 之所以會提出建議做出調整，是希望整個開源社群是朝向更正面、友善的風氣前進，而非無法容錯的方向。 ## 背景{#background} 簡單來說，甲（提出者）認為乙（專案作者）的專案中使用了跟甲的專案高度相似的程式碼，因此使用了工研院事件中的[議題](https://github.com/ITRI-BDL-D/CQL-Project-template/issues/9)（Issue）當作樣板，提出一篇帶語氣較為激烈的議題在乙的專案上。 後續乙認知到專案中相似的程式碼有很高的機率是在沒有標注來源的狀況下使用，因此盡快的補上來源資訊，以及簡單的回覆甲進行道歉。 基於上述雙方的處理，以爭議來說確實可以看作是有妥善處理。 然而，我在這件事情上看到兩個不同的問題需要處理。 1. 開源授權使用 2. 社群風氣影響 開源授權的使用在 Facebook 社團等地方，已經有不少有經驗的人分享他們對於此次爭議的看法，基本上只要對授權條款解讀不要有太大差異，當下的處置已經算是較理想的做法。 但是，要讓整件事情用更好的方式落幕，那麼就該處理原本採取「情緒化的表達」方式，讓他回到友善的表達，也是我為何提出將標題修正為較為中立用詞的原因。 > 我在提議時有揭露我是乙的朋友這一事實，也清楚會被當作護航和影響社群上的信用，至少這個朋友值得我這樣做，也盡力以淡化衝突為主進行建議。 ## 友善{#friendly} 我所期待的開源社群，是希望他能朝向一個友善和包容的方向前進。看到議題中表達情緒較激烈的情況，讓我擔心這類方式可能會成為為來解決爭議時的常態。 工研院事件的處理方式被帶入到另一個事件中，讓我意識到這個問題。 工研院先前接獲多次改進建議，然而回應未如預期，導致使用了較強硬的溝通手段。本次則是在雙方沒有溝通的狀況下，就直接以較為嚴格的標準處理，這可能造成未來許多人為了避免遭遇這種狀況，而遠離這個社群，走向閉源。 基於這樣的擔憂，我提出調整用詞以及在社群網站更新狀態來把事態降級的處理方式。在議題的回覆中，我也提出尊重、同理兩個面向處理情緒問題。 當我們在這類爭議事件中，發起方必然會先覺得不滿，帶有情緒是合理的。因此我們需要先同理對方會有這樣的情緒，同時許多指責可能是在帶有情緒的狀況提出，不一定完全合理或者有盲點，也需要尊重對方的觀點跟看法。 > 實際上在討論中，會不斷來回在某些論點上，也是因為每個人觀點差異，除非一方能提出非常完善的邏輯大多會持續僵持下去，各退一步大多會比較好，畢竟完善的邏輯大概要用論文的標準來回檢驗。 當發起方的情緒被接住後，我們也需要回過頭來看接受指責的人當下的情緒、觀點，因為雙方會有各自的觀點和情緒在，如果單方面的只看其中一方的情緒，很容易造成更多誤解跟評價上的不平衡。 這也是為什麼希望能朝友善的環境發展，我們從「指責」變成「提醒」把原本攻擊性消除掉，用善意的方式去看待其他人的行為，那麼整個社群就會友善很多，也能夠容納更多不同類型的人加入進來，持續壯大。 只有我們展現出包容的態度，允許其他人犯錯，即使犯錯也只會得到善意的提醒，才能建構出一個具有安全感的社群環境。 ## 雙贏{#win-win-deal} 若要討論「開源精神」我認為創造一個「雙贏」的局面是很重要的，即使是比較嚴格的 GPL 條款，最初也是因為閉源困擾而提出，進而創造各方都能受益的風氣。 這一次的案例，若是在更新授權引用的階段停止，對雙方來說在外界的印象可能會變成這樣。 * 甲（提出者）在情緒表達上值得關注 * 乙（專案作者）曾面臨抄襲質疑 若是未來在求職或者合作上，很有可能被關注到這件事情的公司對甲或乙進行排除，因為抄襲的指控很嚴重，而情緒處理也會被視為難以融入團隊的要素之一。 然而，當我們加入第二階段處理，整件事情就變得不太一樣 * 甲（提出者）雖然情緒表達上值得關注，但在後續積極進行友善且負責任的處理 * 乙（專案作者）面對抄襲質疑時，採取誠懇且積極修正的態度 我希望透過第二階段處理，讓雙方的「補充」被加入進來，這樣在職涯上的評價可能從負面調整到正面，只是當下若是由我去明講這件事情，效果可能不會那麼好，只能嘗試提示。 後續仍有在抄襲事實的來回討論，可能是我在揭露身份後嘗試讓其他人意識到這件事情時，被當作是護航的表現。 若我們要把抄襲的「事實（Fact）」釐清，需要相當大的成本，即使事實被確認也只是對雙方造成負面影響，甚至延伸到整個社群在看待未來活動上的方針。 若是我們能把這件事情用善意的方式處理，就可以從嚴重程度是抄襲降級成爲「誤會」或者「失誤」這樣的程度，只保留對雙方有益的「真相（Truth）」即可。 這樣一來，我們在許多開源社群上的衝突都能逐漸用理性、包容的方式處理，對許多剛接觸的人來說也更有安全感，更樂意分享自己的作品而不用擔心犯錯。 --- 討論中我有被問到如果是我被其他人抄程式碼，我會怎麼做？我會選擇不做額外處理，甚至歡迎大家藉此向我學習。 既然我的程式碼值得被抄，那表示我寫得非常好，沒有能改動的地方。另一方面，我的價值並不在於產出程式碼，這沒有對我造成損害，在 AI 時代來臨時我們也該正視這樣的問題。