使用开源软件来构建一项3650万美元的业务

译者 Elaine.Ye

前言

---

开源软件使得企业家和技术人员能够把创新的解决方案带给市场，本文讨论了在创建我们的这一以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二进制代码。

结束语

---

若要使用开源软件来为市场提供成功的解决方案的话，所要做的不仅是使用免费的开源代码这么简单。开源软件是一个生态系统和一个社区，你可以通过参与并成为不同的兴趣社区中的活跃成员来获取大量的所需。而且，使用软件的一件很自然的事情就是，你会有许多可以回馈给项目的东西。最后一点，注意你使用的的不同开源软件的许可协议，保持一种谨慎的态度，在将来的某一天它们可能会变得非常重要。

去享受这种自由和乐趣吧，在开源软件上搭建你的下一个创投事业！

参考资料

---

 学习资料

1. Dive into Python：通过阅读Mark Pilgrim的这本书来获得对该语言的一个很好的介绍。

2.  Discover Python （developerWorks 2006）：探索这一系列文章为初级Python程序员所讨论的主题，其中包括变量、容器对象和复合语句等。

3. Safari bookstore：访问这一电子资料库来查找一些特定的技术资源。

4. 感兴趣的活动：了解IBM开源开发者感兴趣的即将召开的会议、展览和webcast。

5. developerWorks Open source zone：查找涉猎广泛的技术信息、工具和项目更新来帮助你使用开源技术进行开发，以及在IBM产品中使用它们。

获取产品和技术

1. FFmpeg：了解更多关于这一用于录制、转换以及制作音频和视频流的跨平台解决方案的内容。

2. Boto：了解这一Python包的主要源代码库，其提供了到Amazon Web Services的接口。

3. Django：了解更多关于这一高层面的Python web 框架的内容。

4. Pinax：了解这一构建在Django之上的平台的一些信息。

5. IBM试用软件：使用提供了下载或是DVD的试用软件来创立你的下一个开源开发项目。

讨论

1. developerWorks社区：在浏览开发者驱动的博客、论坛、新闻组和wiki时与其他developerWorks用户建立联系。

2. Real world open source：帮助构建这一重点关注开源的developerWorks社区小组。

关于作者

---

  Patrick Altman是Pinax的一位核心开发者，其创建并为其他的许多开源项目贡献了自己的力量。现在是 Engineering at Eldarion的VP。在这之前，他是StudioNow的首席软件工程师（Principal Software Engineer），该公司后来被出售给了AOL。目前他和妻子及三个孩子居住在田纳西州的Nashville。

  

（译者注：标题配图来自http://www.studionow.com）