![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Open source software enables entrepreneurs and technologists to bring innovative solutions to market. This article discusses why we adopted and how we used open source software when creating our startup that sold for US$36.5 million.
We created StudioNow to be the premier globally distributed video production platform. It connects videographers, editors, graphic artists, voice-over actors, and other creative types to produce content for customers such as Yellow Pages, Citysearch®, and music labels. Through StudioNow's website and cloud-based delivery and transcoding platform, video production at scale is achieved, driving down the cost for individual videos.
Early on at StudioNow, my colleagues and I had to decide what technology to use and determine the best way to ramp up and learn a new set of skills. We also had to adapt to scaling challenges and make informed architectural decisions. During this experience, we learned how using these technologies can provide tremendous advantages in building a business. Your results may vary, but if you are considering open source for your project, I suggest that you:
- Make technology choices based on community strength and depth.
- Get involved in the communities around the software you adopt.
- Consider the cloud for scaling (although technically not open source, there is a lot of open source involvement around this approach to infrastructure).
- Avoid the General Public License (GPL).
Choosing a platform: Ruby or Python?
Building a solution on a new technology stack is difficult, but building an entire company around said technology takes it to a new level entirely. The choice of which platform to adopt was an early strategic decision. The wrong choice could have made the difference between success and failure. A poor choice could preclude acquisition if the technology were too esoteric. In addition, would we be able to learn fast enough if the community were weak or nonexistent? What would yield more out of the box so that we could focus on building core functionality rather than scaffolding?
Coming from backgrounds primarily in enterprise software, which meant Microsoft® .NET and C#, as well as Oracle and Java™ technology, it was obvious that we needed to choose something different. No one wanted to spend money on licensing and managing compliance to licensing, so the final decision was between Ruby with Ruby on Rails or Python with Django. It came down to these two, as they were generally well-respected open source choices for building web applications.
In early 2006, I was moonlighting for StudioNow when our co-founder and CTO, Adam Solesby, was evaluating and making the decision between the two platforms. He chose Django because of two key factors. For starters, the Python language just seemed more aesthetically pleasing. More importantly, however, the Python and Django documentation and communities were strong. It was easy to find examples and read documentation that explained things with clarity. That was a critical factor in determining the technology adoption. Between the online Dive into Python book, the #django Internet Relay Chat (IRC) channel on Freenode, and the documentation for both Python and Django (see Resources), ramping up was easy.
Each open source project — and to some degree, the community around that project — has a certain set of rules, either explicit or understood. To be successful when going the open source route, the following considerations are important:
- Approach the community with an attitude of contributing back.
- Understand that the people in the community are volunteers and don't owe you a thing.
- Attempt to find answers yourself. If something is unclear and takes you a long time to figure out, contribute your knowledge back to the community in the form of blog posts, documentation, FAQ writing, and so on, to save the next person the same effort.
- Seek to determine the social norms early on and assimilate them instead of being a maverick. Does the community communicate more in email lists or IRC channels? It may be both, and each might have a different tone.
- Be positive.
In the early days of StudioNow, we didn't know much about transcoding video. We were still learning and exporting video to the Sorenson FLV format for playback on our website for review process. To drive down cost and convince editors it was worth their while to undertake our projects that paid lower than if they sourced the jobs themselves, we had to take on more of the burden of doing the non-creative repetitive work that the editors didn't want to do. A selling point was customers not having to worry about target formats.
This model was sustainable early on, before we had significant volume. We had a number of workstations and full-time staff to manually perform the exports. In addition, there were some ad hoc scripts to help semi-automate the process of downloading the raw upload from the editor to the office, doing the transcodes, and then uploading them back to the project page for client and customer review.
It was obvious from the start that this process was not going to scale, and we needed to solve the problem while preserving as much capital as possible. There is always uncertainty in raising the next round of funding, and we didn't want to spend the money foolishly.
In mid-2006, Amazon Web Services (AWS) was still relatively new. Initially, we were attracted to Amazon Simple Storage Service (Amazon S3) for inexpensive and unlimited storage that we would pay for as we grew. After all, we were hosting the entire site (website and video file hosting) on two relatively old servers that were co-located. We knew we had to scale the transcoding, but it was of primary importance that we not have to worry about filling up the meager hard disks on our web servers.
We decided to hook up our in-office transcode solution to store transcodes on Amazon S3 and record the location through an API call to our website. This solution bought us some time to figure out the transcode scaling issue.
I started working to interface with the Amazon S3 API by writing my own Python interface. However, I quickly found the boto project by Mitch Garnaat (see Resources). With Mitch's direct help, we had a tremendous boost in productivity. Although the library itself was a big win in saving StudioNow time and effort, the community of boto users and developers was a tremendous help in figuring out this new form of architecting technical solutions. In a sense, involvement in the boto project was less about open source software and more about open architecture.
This cooperative experience led me to successfully transform our in-house, limited approach to producing a single-codec rendition of video to a massively scalable encoding platform using Amazon Elastic Compute Cloud (Amazon EC2). This platform is now capable of literally transcoding tens of thousands of videos of different sizes and codecs for different target devices and platforms in the same amount of time it takes to encode a single rendition for a single video.
Looking back, we considered (at the suggestion of our COO) using a Java-based closed-source solution. It was a proven technology that provided these same transcoding services to post-production houses. It was a smart and conservative recommendation, but it would have required significant capital investment to buy hardware, build or rent data center space, license the software, and hire additional staff to manage the hardware. However, it was a solution that we knew we could at least scale in the short term.
Before investing the capital in this black-box solution, we decided to
pursue the cloud-based solution, given our experience with the boto
community and the promise of "paying for what we use as we use it."
Although there were few examples of other people doing similar things at
the time, enough pieces were in place. The boto library had interfaces for
launching nodes on demand. Amazon had a compute resource priced right for
what we needed (on demand and horizontal computing resources instead of
always-running machines that would sit idle a large chunk of the time).
Mitch had even written an article that showed how he used
FFmpeg to transcode a video to play on an Apple
iPod.
This meant that I needed to build a prototype that booted an image, took
input of what video file to transcode, hit the API we'd already built,
stored the results on Amazon S3, and shut itself down. After I completed
it in a matter of weeks it gave us the confidence to build a solution
based on AWS and open source software. It also allowed us much more
control over the platform. We could focus on learning technologies that
were core to our business, like FFmpeg and the
transcoding of video. It also meant that we were not beholden to a vendor
of a software product or constrained to physical hardware or budgets. We
would know precise costs per project of computing and storage resources
and could factor them into pricing.
A crucial part of building this platform was learning about video
transcoding and our primary tool for getting things done:
FFmpeg. I found this project to be a lot more
technical and confusing than a pure Python library like boto. Video codecs
were a strange and foreign dialect to me so at times, and I wasn't sure if
it was a problem understanding the tool, a library that the tool used, or
video specifications in general.
I started hanging out in the Freenode IRC channel #ffmpeg, reading
documents, and even attempting to study the source code, which is written
in C. I found great help in the IRC channel,
but it was much less forgiving to those asking questions that they could
have answered on their own by doing research or reading the documentation.
This was intimidating at first, but after a while I determined it was
more a conservation of effort rather than rudeness. The social norm
in this community seemed to be first to seek answers in the FAQ and
documentation, and then, when asking a question in the channel, doing so
with relevant and useful information or context. After I learned these
social norms, I was successful in getting answers to questions.
Being acquired: License considerations
The day came that everyone involved in early startups wants to see come, someone was interested in buying us. After the initial excitement wore off, there was a series check for due diligence. One check was verification licensing of the software we were using and had used to build StudioNow. AOL lawyers were most particular about there being any trace of GPL-related code in use. The GPL has stipulations stating that derivative works of any GPL code must also carry the GPL as well as distribute the source code. Furthermore, there is a lot of ambiguity about whether linking to GPL-licensed libraries (static or dynamic linking) is cause for this "viral" nature of the license to be enforced.
For the most part, we were fine. However, we were using
FFmpeg with linked libraries, which meant that
the GPL was in force instead of the Lesser General Public License (LGPL).
Although we were not redistributing or modifying the source code —
just using the compiled binary to transcode video — we needed to
figure out a way around this issue. Fortunately, we were not using the
bits requiring GPL in our transcode service, so we just recompiled a new
FFmpeg binary with different compile flags.
Being successful in bringing solutions to market using open source software goes beyond just using the free source code. Open source software is an ecosystem and a community. You can gain a lot by becoming an engaged and active member in the different communities of interest. Moreover, by the very nature of using the software, you have much to contribute back to the project. Finally, be careful and pay attention to the licenses of the different open source software you use, they could be very important later.
Enjoy the freedom and fun of building your next venture on open source software!
Learn
-
Dive into Python: Read Mark
Pilgrim's book for a good introduction to the language.
- Discover Python (developerWorks 2006): Explore this series of
articles that discuss topics for beginning Python programmers, including
variables, container objects, and compound statements.
- Safari bookstore: Visit the e-reference library to find specific
technical resources.
- Events of interest: Check out upcoming conferences, trade shows,
and webcasts that are of interest to IBM open source
developers.
- developerWorks
Open source zone: Find extensive how-to information, tools, and
project updates to help you develop with open source technologies and use
them with IBM's products.
Get products and technologies
- FFmpeg: Learn more about this
cross-platform solution for recording, converting, and streaming audio and
video.
- Boto: Check out the main
source code repository for this Python package that provides interfaces to
Amazon Web Services.
- Django: Learn more about this
high-level Python Web framework.
- Pinax: Find information about this
platform that is built on top of Django.
- IBM trial
software: Innovate your next open source development project using
trial software, available for download or on DVD.
Discuss
- developerWorks
community: Connect with other developerWorks users while exploring
the developer-driven blogs, forums, groups, and wikis.
- Real world open source: Help build this developerWorks community group that focuses on
open source.
Patrick Altman is a core developer on Pinax and has created and contributes to many other open source projects. He is currently VP of Engineering at Eldarion. Previously, he was the Principal Software Engineer at StudioNow, which was later sold to AOL. He currently resides in Nashville, Tennessee, with his wife and three children.
