用開源軟件來構建一項3650萬美元的業務
前言
開源軟件使得企業家和技術人員能夠把創新的解決方案帶給市場，本文討論了在創建我們的這一以3650萬美元售出的企業時，為什么我們會采用并且是如何使用開源軟件的。
我們把StudioNow創建成一個分布于全球的領先的視頻制作平臺，其連接了攝像師、編輯、圖形藝術家、配音演員和其他一些創造型的人員，他們主要為黃頁、Citysearch®和唱片公司等一類客戶生產內容。通過StudioNow的網站和基于云的交付和轉碼平臺，視頻的生產實現了規模化，降低了單個視頻的制作成本。
在StudioNow的早期時候，我的同事和我需要決定使用哪些技術，并且要確定提升和學習一些新技能的最佳途徑。我們還不得不接受伸縮性方面的挑戰，在架構選擇上做出明智的決定。在這一體驗過程中，我們學會了在構建業務時，如何使用這些技術才能帶來巨大的優勢。你要的結果可能有所不同，但如果你考慮在項目中使用開源軟件的話，我建議你：
1. 基于社區的強健程度和深度來選擇技術。
2. 參與圍繞你所采用的軟件而建的社區。
3. 考慮使用云來支持伸縮性(盡管技術上是不開源的，但是圍繞著這一基礎設施方法有許多相關的開源軟件)。
4. 避開公共許可協議(General Public License，GPL)。
選擇平臺：Ruby還是Python?
在一個新的技術棧上構建解決方案是很困難的，但是圍繞著所述技術來構建整個公司則是要把它完全提升到一個新的層面上。選擇采用哪種平臺是一種早期的戰略決策，錯誤的選擇可以帶來成功和失敗的兩種不同。如果技術過于深奧的話，糟糕的選擇可能會妨礙到被收購。此外，如果社區很薄弱或是根本不存在的話，我們的學習速度是否能夠做到足夠快?哪些技術有著更多開箱可用的東西，這樣我們就能夠把重點放在構建核心功能上而不是從頭開始搭建手腳架呢?
從以企業軟件為主要背景來看，這意味著 Microsoft®的.NET和C#，以及Oracle的Java™技術，顯然，我們需要選擇一些不同的東西。沒有人想要在遵從許可協議和管理協議的兼容性方面花錢，所以，最終的決定是在Ruby的Ruby on Rails和Python的Django之間選擇。之所以要回落到這兩種技術上，是因為它們通常是備受推崇的構建web應用的開源選擇。
早在2006年我兼職于StudioNow時，我們的共同創始人兼CTO，Adam Solesby就在這兩個平臺之間進行評估并作出了決定。因為兩個關鍵的因素，他選擇了Django。對于初學者來說，Python語言似乎更美觀一些。然而，更重要的是，Python和Django的文檔和社區都很強健，很容易就找到例子，文檔很容易閱讀，很清晰地解釋了事情。在決定技術的采用時，這是一個很關鍵的因素。從在線的Dive into Python一書，到Freenode上的#django Internet Relay Chat(IRC)頻道，再到Python和Django(參見參考資料)的文檔，有著很容易走的上升通道。
社區的強大作用
每個開源項目——就某種程度上來說，圍繞項目而建的社區——有著一些或是明示或是隱含既定的規則。要想成功地走出一條開源路線的話，下面的這些考慮很重要：
1. 要以一種回饋的態度來進入社區。
2. 要明白社區中的人都是志愿者，他們不欠你任何東西。
3. 嘗試著自己來找出問題的答案，如果有什么不清楚的并且是花費了你很長的時間來解決的問題的話，把你的知識貢獻回給社區，可以是以博客文章、文檔、書面FAQ等方式，這樣就能夠免得下一個人要付出同樣的努力。
4. 較早地明確社交規范并接受它們而不是做一個特立獨行的人，社區更多的是以郵件列表還是IRC頻道的方式來進行溝通呢?可能兩種都是，但每種的風格可能有所不同。
5. 要有積極的態度。
學會規模化
在StudioNow早期的那些日子中，我們不懂得轉換視頻，在我們的審查過程網站上，我們仍然在學習著把視頻導成Sorenson的FLV格式來播放。為了壓低成本以說服編輯們，采用我們的方案是值得的，相比于他們完全自己來完成這些工作，這些方案的花費會更少。因此我們不得不承擔了更多的非創造性的重復工作，這些工作是編輯們不想做的，一個賣點是客戶無需擔心目標格式。
在我們擁有大批量的數據之前，這種模式在早期是可持續的。我們有一些工作站和專職人員來手動地執行導出。此外，還有一些特定的腳本被用來幫助完成半自動化的下載過程，把編輯上傳的原始內容下載到辦公室，進行轉碼，然后把它們上傳回到項目頁面上，以讓客戶和顧客查看。
從一開始有一點就是顯然的，即這一過程不具備伸縮性，我們需要在節省盡可能多的資本的同時解決這一問題。下一輪資金的籌集總是有著不確定性，因此我們不想很愚蠢地把錢花掉。
向云進階
在2006年年中的時候，Amazon Web Services(SWS)相對來說還是一種較新的技術。最初，我們被Amazon Simple Storage Service(Amazon S3)吸引是因為它的廉價和無限的存儲空間，在成長的過程中，這是我們要支付的代價。畢竟，我們當時是把整個網站(網站和視頻文件托管)托管在兩臺相對較舊的本地協同的服務器上。我們知道我們必須要規模化轉碼過程，但最重要的是我們不必再擔心我們的web服務器上的微薄的硬盤會被擠爆了。
我們決定把我們的在辦公室完成的轉碼方案和在Amazon S3上存儲轉碼的做法掛接起來，通過到我們的網站的API調用來記錄位置。這一解決方案給我們帶來了一些解決轉碼規模化問題的時間。
我一開始是通過編寫自己的Python接口來與Amazon S3 API進行接口工作的，然而，我很快就發現了Mitch Garnaat的boto項目(參見參考資料)。在Mitch的直接幫助下，我們在生產效率方面有了巨大的推進。盡管在節省StudioNow的時間和精力方面，該庫本身就是一個極大的勝利，然而在研究出這一架構技術解決方案的新形式方面，boto用戶和開發者社區提供了巨大的幫助。從某種意義上說，boto項目所涉及的與其說是一個開源軟件還不如說是一個開源架構更恰當一些。
這一合作經歷讓我能夠成功地從作坊式的受限做法轉向給使用了Amazon Elastic Compute Cloud(Amazon EC2)的大型可擴展編碼平臺生產視頻的單個編解碼呈現。這一平臺現在能夠逐字的給數以萬計的不同規模的視頻和用于不同目標設備和平臺的編解碼器做轉碼，而所需的時間就和用來為單個視頻編碼單個呈現的時間一樣。
回看過去，我們曾(在我們的COO的建議下)考慮過使用一種基于Java的閉源解決方案，這是一種已經證明的技術，給后期制作公司提供同樣的轉碼服務。這是一種明智而穩健的建議，但它需要大量的資金投入來購買硬件，構建或是租賃數據中心的空間，購買軟件的使用許可，以及雇用額外的人員來管理硬件。不過，這是一種我們知道的至少可在短期內進行擴充的解決方案。
在把資本投入這一黑盒子解決方案之前，我們決定繼續采用基于云的解決方案，與boto社區交流我們的經驗，并承諾“為我們所會用到的付費”。盡管在當時做同類事情的其他人幾乎沒有幾個，但現有的一些東西已經足夠我們用來拼湊了。
boto庫有著按需啟動節點的接口，Amazon有我們所需價位的計算資源(是按需的和橫向的計算資源，而不是有著大量空置時間的總在運行的機器)，Mitch甚至寫了一篇文章來說明如何使用FFmpeg來轉碼視頻，以便能夠在Apple iPod上播放。
這意味著我需要構建一個這樣的原型，即啟動一個鏡像，導入要轉碼的視頻文件，運行我們構建好的API，把結果存儲在Amazon S3上，然后自行關閉。我在幾個星期之內完成了該原型，在完成原型之后，我們就有信心去構建一個基于AWS和開源軟件的解決方案了。這一做法還允許我們對平臺有更多的控制，我們可以把重點放在了解業務的核心技術上，比如說FFmpeg和視頻轉碼等。這還意味著我們不會依賴于軟件產品的供應商或是受限于物理硬件和預算，我們知道每個項目的的計算和存儲資源的精確成本，因此可以把它們納入定價中。
構建這一平臺的一個至關重要的部分是了解視頻轉碼和完成事情的主要工具：FFmpeg，我發現這一項目更加的技術化，比諸如boto一類的純Python庫更容易令人迷惑不解。在當時視頻的編解碼器對于我來說是陌生的，就像是外國的方言一樣，我不能確定在理解該工具和工具所用的庫方面，或是一般的視頻規范方面會不會有什么問題。
我開始在Freenode IRC的#ffmpeg頻道出入，閱讀文檔，甚至嘗試著去研究源代碼，代碼是用C寫的。我在IRC頻道得到了很大的幫助，但是對于那些提出問題的人，他們不夠寬容，因為他們認為可以通過研究和閱讀文檔來自己回答這些問題，一開始我覺得這蠻嚇人的，但過了一段時間之后，我覺得這更多的是一種對付出努力的保護而不是無禮。這一社區的社交規范似乎是首先要在FAQ和文檔中查找答案，然后，如果要在頻道中提出問題的話，要使用相關的或是有用的信息或是上下文來進行描述。在了解了這些社交規范之后，我就能夠成功地獲得問題的答案了。
被收購：對許可協議的考慮
早期參加公司創業的每個人都期望看到的那一天到來了，有人有興趣收購我們。在最初的興奮感褪去之后，我們需要做一系列的盡職檢查。其中一項檢查是驗證我們正在使用的和曾用來構建StudioNow的軟件的許可協議。AOL的律師最在乎的是是否有任何GPL相關代碼在用的痕跡，GPL規定，任何GPL代碼的衍生作品都必須要攜帶GPL并且分發源碼。此外，關于否是鏈接了GPL許可的庫(靜態的或是動態的鏈接)有許多含糊不清的說法也導致了協議被強制執行的這一“病毒”特質。
就大部分的情況來說，我們還不錯，然而，我們使用了FFmpeg的鏈接庫，這意味著生效的是GPL協議而不是寬松的通用公共許可(Lesser General Public License，LGPL)。盡管我們沒有重新分發或是修改源碼——只是使用了已編譯好的庫來對視頻進行轉碼——我們還是需要找出一種繞過這一問題的方法。幸運的是，我們在轉碼服務中沒有用到要求遵守GPL協議的代碼，因此我們只是使用了不同的編譯標志來重新編譯了新的FFmpeg二進制代碼。
結束語
若要使用開源軟件來為市場提供成功的解決方案的話，所要做的不僅是使用免費的開源代碼這么簡單。開源軟件是一個生態系統和一個社區，你可以通過參與并成為不同的興趣社區中的活躍成員來獲取大量的所需。而且，使用軟件的一件很自然的事情就是，你會有許多可以回饋給項目的東西。最后一點，注意你使用的的不同開源軟件的許可協議，保持一種謹慎的態度，在將來的某一天它們可能會變得非常重要。
去享受這種自由和樂趣吧，在開源軟件上搭建你的下一個創投事業!
英文：Building a $36.5 million business with open source software
原文：http://select.yeeyan.org/view/213582/214825
【編輯推薦】
