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