與 objc.io 這期專題的其他團隊規模相比，Astsy 的移動團隊很小。儘管如此，我們卻因為我們在社群的影響力而被關注。我們的 iOS 開發團隊成員都參加過著名和大型的 Cocoa 社群開源專案。
Artsy 團隊內部充滿了我們稱之為預設開源的技術氛圍。我們不是絕無僅有的一個。開源一個專案有時候聽起來更像獲得了一個技術勳章，但是這個專案所影響到的東西可能會超出你的想象。開源不單單是建立一個 GitHub repository — 同時也是我們團隊成員的情感分享。
我們團隊都信奉開源。儘管我們每個人的動機各不相同 – 從堅信教育的力量到想要幫助其他人站在巨人的肩膀上看得更遠 – 我們都從開源中受益匪淺。
我們團隊的每個人相信，除非的確有一個理由需要你保密，否則你就應該把它開源。這種精神不單單對於程式碼。我們在 Google Hangouts On Air 定期舉辦交流會，邀請其他人蔘與進來和討論問題。我們的團隊也用一個開源的倉庫來組織活動。
我們這個小團隊為 Cocoa 開發者社群作出了顯著的貢獻。我們以這三種方式貢獻自己的力量：
1.我們經常會發布一些應用的元件，這些元件作為開源庫可能會幫助其他開發者。
2.在使用其他的庫的同時，我們傳送反饋，bug report 和 pull request。
3.我們鼓勵所有的團隊成員積極參加社群活動，包括演講，寫部落格或者出版書籍。
有幾個很好理解的原因可以解釋我們為什麼想要減少程式碼的規模和複雜度。我們通過編寫小而穩定的元件來提高應用整體的穩定性和完整性。另外，通過可重用的庫，我們在編寫多個應用時也減少了工作量。
Artsy 主要有三個 iOS 應用，同時還維護著一些小的專案，當有新的專案時，可以避免重複造輪子從而節省時間。對於為了一個應用而創造的庫來說，維護和修復漏洞是一件很值得分享的事。我們過去在程式碼重用的策略做得很好，但是仍然有很大提升的空間。
如果將我們的應用拆分成小而且可重用的幾部分的話，會有很多技術上的優點，但同時這些不同的元件也有明確的擁有者。當我們這樣做的時候，我們需要確保我們確實把知識分享給團隊成員，來保證團隊成員們對我們的程式碼儘可能的熟悉。這一點是非常重要的；當我們團隊裡的某一個成員突然被法院傳召三個月，我們不需要苦惱，因為他不是唯一的對特定部分程式碼熟悉的人。
除了團隊實際的管理外，鼓勵開發者去探索 iOS 開發的不同的方向，能幫助他們更專業，更全面。我們在 iOS 領域自然已經爐火純青，而與此同時學習其他程式語言能幫助我們保持頭腦清醒和情緒放鬆，並且可以發現新的思路來解決相似的問題。
我們遠端工作；我們的團隊到目前為止還沒有同時呆在一個屋子裡過。通過像一個開源社群來工作，團隊結構更加靈活和可伸縮，而不是像傳統的團隊一樣。
2015 年初，我們完成了 Artsy 的 iOS 應用 eigen 的開源工作。這是一個持續了很多個月的專案；我們慎重考慮過，並逐漸地證明，開源一個面向消費者的應用的確會有它的商業價值。這也反駁了那些質疑我們的聲音，讓他們看到了這一切是如何發生的。這對於公司來說並不是一個艱難的決定，因為分享知識已然是我們公司的每個人所信奉的核心價值。
開源 eigen 的第一步工作已經完成得差不多了；我們已經儘可能地從我們的應用中開原始碼。我們的大部分的準備工作都是在確保程式碼中敏感的細節不會通過 git 歷史記錄和 GitHub 的 issue 洩露出去。最後，我們決定用一個全新的 repository，還有完全空白的歷史記錄以及 issue。
在前面，我說過如果開源則意味著全部對外開放，除非確實有一個理由想讓它保密。我們所開源的那些程式碼並不是讓 Artsy 獨具一格或者更有價值的程式碼。Artsy 的有些程式碼是需要一直閉源的。其中的例子中包括一個商業許可用途的字型，還有 Art Genome Project所用到的推薦引擎等。
做完前期開源工作的準備後，接下來就是從基礎開始搭建一個完整的開源應用。這給了我們機會來審視要如何在開源環境下進行管理專案，處理開發的問題以及進行實際的開發。這種體驗與維護社群的開源專案非常類似。
在開發前期我們不會設定嚴格的的線路圖。這部分程度上歸咎於我們需要準時完成專案，另外在我們內部的 Slack 頻道里也已經有很多交流了。將來，我們會嘗試儘量多地將我們的交流放到公共的倉庫裡去。
開發並開源一個複雜的 iOS 應用這件事並沒有很多公司嘗試過。在開發工具方面，我們還有些欠缺，這也是必須努力的方向。最常見莫過於 API tokens 的保密。為了解決這個問題，我們創造了一個新的，更加安全的方法來儲存這些 keys。
Artsy 是一個設計驅動型的公司，我們的設計師在我們開發工作進行時經常參加進來。我們的設計師能夠很容易地參加到開源專案中。只需稍加援手，我們的設計師們就可以調整到開放的方式進行工作。他們已經對如何使用 GitHub 來反饋問題相當熟悉，所以他們參加到開源專案的貢獻中是一件再簡單不過的事了。他們都有著關於回饋設計社群的想法，和像我們對開發者社群的態度一樣。
我們上面說明了一些概念和理論上的東西，接下來說一下我們真實的日常工作。
開源工作與典型的軟體開發並沒有那麼大的差別。我們開啟 issue，提交 pull requests，並在 GitHub 上討論交流。當我們有機會創造一個新的開源庫的時候，負責這個庫的開發者會使用他自己的賬號來建立倉庫，而不是使用 Artsy 的賬號。
這是一種產品歸屬感。如果在六個月之後某個團隊成員對這個庫有什麼疑問的話，他可以很快地找到求助的人。同樣地，開發者也會有歸屬感，並且幫助我們營造令人滿足和愉悅的工作環境。最後，開發者們瞭解到這些由他們創造的程式碼是屬於他們的，這樣他們可以繼續使用這些程式碼，即使他們離開了 Artsy。
讓我們來看一個例子吧。
像很多可靠的開發者一樣，我們在儘可能地嘗試自動化我們的工作。這其中包括使用持續整合 (CI) 來減少新的 bugs 的產生以及回退。目前，我們使用 Travis 來持續整合，當然，也有很多其他解決方案。
我們很多的測試都是基於 Facebook 的 iOS 截圖測試庫來進行的。這個庫可以構造一個 view (或者 ViewController)，來模擬互動，然後將檢視層次結構截圖以作參考。之後，當我們測試時，我們進行相同的操作和截圖，從而與之前的參考截圖作對比。
我們所遇到的一個問題是關於 Travis 的使用。雖然截圖測試在本地能夠通過，但它會在 CI 環境下失敗。究其原因，是因為截圖測試是由 Kaleidoscope 對提供的參考和不通過的截圖進行比對，從而診斷出原因。但是，在 CI 環境下，我們沒有取得這些截圖的許可權，那我們應該怎麼辦呢？
在維也納的週末旅行中，Orta 和 Ash 一起討論了可能的解決辦法。最後我們決定構建一個叫 Second Curtain 的工具，它可以解析xcodebuild 的輸出。如果它檢測到任何測試失敗，那麼有關不通過的截圖和參考檔案截圖將會被上傳到一個 S3 bucket 上，並可以比較出不同的地方。這是 Ash 第一次用 Ruby 寫的比較重量級的工具，這給了開發者一個機會來改進我們的配置工具，並且擴充了知識。
經常有人會問我們為什麼把專案都開源。我們已經討論了我們的技術上的目的，以及它給予我們團體每個成員的感受，但坦白說，開源其實是一樁很聰明的交易。例如，我們正在編寫一個開源庫來處理使用我們的 API 時所需要進行的身份驗證。這項工作不單單會讓那些使用我們的 API 進行的開發工作更簡單，同時它也使每個人的開發更輕鬆。這真是太爽啦。
對於開發者，經常有特意避開第三方依賴庫的傾向，這種現象在 iOS 開發社群尤為明顯。他們經常受害於重複製造輪子，並浪費很多時間來除錯，而不是使用那些已經為他們解決了相似問題的庫。在我們的移動團隊，我們非常反感這種現象，反而，我們更欣賞那種 “自豪地到處搜刮” 的思想 (我們很贊同這個開發者說過的話)。
在我們的公司裡，我們都會認真評估員工的個人素質和技術水平；但是，這些指標不單單是 HR 手裡的表格上面的幾個選項這麼簡單。如果你確實很優秀，那麼這些東西會潛移默化地融入你的日常生活和工作中。而我們，正是由於待在這麼一個開源專案的團隊裡而身體力行。
通過將我們的軟體開源，龐大的開發者社群能夠對我們的工作提供反饋，讓我們有機會與全世界那些出色的開發者一起交流。與別人分享知識同時也幫助我們培養良好的工作氛圍 — 當我們出名以後 — 反過來會吸引那些好的開發者加入我們。畢竟，我們從來沒有得到如此多的尊敬和聲望。
我們經常整理那些從部落格或者會議演講中獲得的技術知識和技術筆記。它們不僅會幫助我們將見解和技術傳給公司外部的開發者，同時便利了那些加入我們團隊的新成員，讓他們更加迅速地瞭解到我們的工作，以及我們所使用的工具。我們甚至分享那些關於如何分享知識的經驗，這也是其中一件我們正努力去做的事。
開源工作不總是一帆風順的，但是我們遇到的困難仍然不值一提。一種普遍的關於開源的看法是，讓別人看到自己不完美的程式碼會很尷尬。但我們認為，提高水平最好的辦法就是讓別人看你的程式碼，讓別人評論你的程式碼。這不應該成為讓你尷尬的原因 — 同時，幾乎，所有開發者都明白，截止日期快要來的時候，專案裡那些迫不得已的 hacky 程式碼必定會缺乏可讀性和優雅性。
我們的一些競爭對手在使用我們的程式碼，因為他們反饋了一些改進給我們。我們也一樣。實際上，開源一個商業專案最大的挑戰在於管理。這種責任關係是處理人際關係最重要的部分，也是需要認真處理好的 — 特別是當一個專案得到了足夠多的好名聲。大部分的專案都沒有得到足夠的管理，這使它們最終舉步維艱。
釋出完程式碼，將專案拋之腦外，並忽視開發者的反饋是一件很常見的事情，但是我們卻樂於接受開源專案的責任，並努力繼續把專案開源。
那些需要額外花費我們時間來開發和維護的開源專案，經常能幫助從日常的任務中解放出來，而且，通過 GitHub 進行的交流也能夠幫到我們團隊中遠端工作的成員。
在一個擁抱開源的公司裡作為一個小的團隊而工作，可以讓那些由於開源而要承擔的各種風險微不足道。如果這種風險確實存在的話，技術好處，商業前景以及開源專案所帶來的樂趣要比它們大，並且大得多。
將一個庫開源和建立一個開源庫其實有著本質上的不同 – 這種不同和從技術上開源還是從精神上開源是一樣的。一句話來說，回答這個問題就可以總結兩者的差異：
你是為了自己的利益而開源呢，還是為了所有人的利益？