Introdução

O software livre possibilita que empresários e tecnólogos introduzam soluções inovadoras no mercado. Será discutida neste artigo a razão pela qual adotamos e como utilizamos o software livre ao criar a empresa inicial, que foi vendida por US$ 36,5 milhões.

Criamos a StudioNow para ser a principal plataforma de produção de vídeo distribuída mundialmente. Ela conecta produtores de vídeo, editores, artistas gráficos, atores de narração e outros profissionais criativos a fim de produzir conteúdo para clientes como Páginas Amarelas, Citysearch®e gravadoras. Através do website da StudioNow, da entrega em nuvem e da plataforma de transcodificação é possível atingir a produção de vídeo em escala, reduzindo o custo de vídeos individuais.

No início da StudioNow, meus colegas e eu precisávamos decidir qual tecnologia utilizar e determinar a melhor maneira de se aprimorar e aprender novas habilidades. Também tínhamos de nos adaptar aos crescentes desafios e tomar decisões arquiteturais embasadas em informações. Durante esta experiência, aprendemos como o uso dessas tecnologias pode proporcionar benefícios extraordinários ao desenvolvimento da empresa. Os resultados podem variar, mas se você está pensando em adotar software livre para seu projeto, sugiro que você:

• Faça escolhas de tecnologia com base no poder e na intensidade da comunidade.
• Participe das comunidades em torno do software adotado.
• Considere a nuvem para escala (embora tecnicamente não seja software livre, há muito envolvimento de software livre em torno da abordagem para infraestrutura).
• Evite a Licença Pública Geral (GPL).

Voltar para parte superior

Escolhendo a plataforma: Ruby ou Python?

Criar uma solução em uma nova pilha de tecnologia é difícil, mas criar uma empresa inteira em torno de tal tecnologia é completamente diferente. A escolha de qual plataforma adotar foi uma decisão inicial estratégica. A escolha errada poderia ter sido a diferença entre ter sucesso e fracassar. Uma escolha equivocada poderia impossibilitar a aquisição, caso a tecnologia fosse muito limitada. Além disso, será que conseguiríamos aprender rápido o suficiente se a comunidade fosse fraca ou inexistente? O que renderia mais de imediato de modo que pudéssemos nos concentrar na criação de funcionalidades essenciais em vez de andaimes?

Com experiência principalmente em empresas de software, que significava Microsoft® .NET e C#, além de tecnologia Oracle e Java,™ era óbvio que precisávamos escolher algo diferente. Ninguém queria gastar dinheiro com licenciamento e gerenciar conformidade para licenciamento, então a decisão final ficou entre Ruby com Ruby on Rails ou Python com Django. Tratava-se então dessas duas opções de software livre para a criação de aplicativos da web, pois, de modo geral, tinham boa reputação.

No início de 2006, eu estava fazendo um bico para a StudioNow quando nosso cofundador e CTO, Adam Solesby, estava avaliando e decidindo entre as duas plataformas. Ele escolheu a Django devido a dois fatores primordiais. Em primeiro lugar, a linguagem da Python parecia esteticamente mais agradável. Entretanto, o mais importante era a solidez da documentação e das comunidades da Python e da Django. Era fácil encontrar exemplos e ler documentos que explicassem as coisas com clareza. Isso foi um fator decisivo para determinar a tecnologia adotada. Aprofundando-se no guia online da Python , no Internet Relay Chat (IRC)#django no Freenode e na documentação para Python e Django (veja Recursos), foi fácil se aperfeiçoar.

Voltar para parte superior

O poder da comunidade

Cada projeto de software livre— e até certo ponto a comunidade em torno daquele projeto — tinha um determinado conjunto de regras, explícitas ou implícitas. Para ter êxito ao optar pelo software livre, os fatores a seguir são importantes:

• Aproxime-se da comunidade com uma atitude de contribuir em retorno.
• Entenda que as pessoas da comunidade são voluntárias e não lhe devem algo.
• Tente encontrar as respostas por conta própria. Se algo não estiver claro e levar um bom tempo até que você compreenda aquilo, compartilhe seu conhecimento com a comunidade através de publicações em blog, documentações, inclusão em FAQ, etc. para poupar outra pessoa do mesmo esforço.
• Procure determinar as normas sociais no início e assimilá-las em vez de se rebelar. A comunidade se comunica mais através de listas de e-mail ou canais IRC? Pode ser de ambas as formas e cada uma pode ter um tom diferente.
• Seja positivo.

Voltar para parte superior

Aprendendo a escalar

No início da StudioNow, não sabíamos muito sobre transcodificação de vídeo. Ainda estávamos aprendendo e exportando vídeo para o formato Sorenson FLV para reproduzir em nosso website e realizar o processo de revisão. Para reduzir custos e convencer os editores de que valia a pena realizar nossos projetos que pagavam menos do que se eles mesmos terceirizassem o trabalho, tivemos de assumir a responsabilidade de executar o trabalho repetitivo e sem criatividade que os editores não queriam fazer. Um aspecto que reforçava a estratégia de vendas era o fato de o cliente não precisar se preocupar com os formatos de destino.

Este modelo era inicialmente sustentável, antes de termos um volume significativo. Tínhamos várias estações de trabalho e uma equipe em tempo integral para realizar as exportações. Além disso, havia alguns scripts ad hoc para ajudar a automatizar parcialmente o processo de efetuar download do carregamento bruto do editor para o escritório, fazendo a transcodificação e depois carregando de volta para a página do projeto para análise do cliente.

Era óbvio desde o começo que este processo não ia escalar e precisávamos resolver o problema mantendo o máximo possível do capital. Sempre há incertezas para conseguir a próxima rodada de investimento, então não queríamos gastar dinheiro à toa.

Indo para a nuvem

Em meados de 2006, a Amazon Web Services (AWS) ainda era relativamente nova. No início, estávamos interessados no Amazon Simple Storage Service (Amazon S3) devido ao armazenamento ilimitado e barato que pagaríamos à medida que a empresa crescesse. Afinal, estávamos hospedando a página inteira (website e host de arquivo de vídeo) em dois servidores relativamente antigos que estavam juntos. Sabíamos que era necessário escalar a transcodificação, mas era crucial que não precisássemos nos preocupar com o fato de preencher os escassos discos rígidos de nossos servidores da web.

Decidimos conectar a nossa solução de transcodificação interna para armazenar as transcodificações no Amazon S3 e gravar o local através de uma chamada de API para o nosso website. Essa solução nos deu algum tempo para entender a questão de escala da transcodificação.

Comecei a realizar a interface com a API Amazon S3 escrevendo minha própria interface Python. Porém, eu logo encontrei o projeto boto de Mitch Garnaat (consulte Recursos). Com a ajuda imediata de Mitch, tivemos um tremendo impulso na produtividade. Embora a própria biblioteca fosse um enorme ganho em termos de poupar tempo e esforços da StudioNow, a comunidade de usuários e desenvolvedores do boto representou uma imensa ajuda para o entendimento desta nova forma de construir soluções técnicas. De certa forma, o envolvimento no projeto boto abordou muito mais arquitetura aberta que software livre.

Esta experiência de cooperação me levou a transformar com êxito o nosso método interno e limitado de produzir versão de codec único de vídeo em uma plataforma de codificação extremamente escalável através da Amazon Elastic Compute Cloud (Amazon EC2). Essa plataforma agora é capaz de literalmente transcodificar dezenas de milhares de vídeos de diferentes tamanhos e codecs para diferentes dispositivos e plataformas de destino no mesmo tempo que leva para codificar uma única versão de um único vídeo.

Recordando, nós pensamos na possibilidade de utilizar uma solução de código fechado baseada em Java (conforme sugerido por nosso COO). Era uma tecnologia de eficácia comprovada que oferecia os mesmos serviços de transcodificação para estabelecimentos de pós-produção. Tratava-se de uma recomendação inteligente e conservadora, mas exigiria um significativo investimento de capital para comprar hardware, construir ou alugar um espaço para a central de dados, licenciar o software e contratar mais pessoas para gerenciar o hardware. Porém, era uma solução que poderíamos escalar em curto prazo.

Antes de investir capital nesta solução caixa-preta, decidimos seguir a solução baseada em nuvem, considerando a nossa experiência com a comunidade do boto e a promessa de "pagar pelo que você usa à medida que usa." Embora houvesse poucos exemplos de outras pessoas fazendo coisas similares na época, tínhamos peças suficientes para montar o quebra-cabeça. A biblioteca do boto tinha interfaces para iniciar nós por comando. A Amazon tinha um recurso de computar com o preço ideal para o que precisávamos (recursos de computar sob encomenda e horizontais em vez de máquinas sempre em funcionamento que ficariam ociosas grande parte do tempo). Mitch até escreveu um artigo mostrando como ele utilizava FFmpeg para transcodificar um vídeo e reproduzi-lo em um iPod Apple.

Isso me dizia que eu precisava criar um protótipo que iniciasse uma imagem, recebesse informação sobre qual arquivo transcodificar, atingisse a API já construída, armazenasse os resultados no Amazon S3 e fechasse sozinho. Após concluí-lo em algumas semanas, nós nos sentimos seguros para criar uma solução baseada em AWS e software de código aberto. Também nos proporcionou muito mais controle sobre a plataforma. Podíamos nos concentrar em aprender tecnologias que eram essenciais para o nosso negócio, como FFmpeg e a transcodificação de vídeo. Isso também significava que não estávamos atrelados a um fornecedor de produto de software ou restritos a hardware físico ou orçamento. Saberíamos os custos exatos por projeto de computação e armazenamento de recursos e poderíamos contabilizá-los no preço.

Uma parte crucial da construção desta plataforma era aprender a transcodificação de vídeo e a ferramenta primordial para realizar as etapas: FFmpeg. Eu achei este projeto muito mais técnico e confuso do que uma biblioteca Python pura como o boto.Os codecs de vídeo eram um dialeto estranho e desconhecido para mim, então às vezes eu não sabia se o problema era entender a ferramenta, a biblioteca que a ferramenta utilizava ou as especificações gerais do vídeo.

Comecei visitando o canal Freenode IRC #ffmpeg, lendo documentos e até tentando estudar o código fonte, que era escrito em C. O canal IRC foi de grande ajuda, mas não era muito complacente com aqueles que perguntavam coisas que podiam ser esclarecidas por conta própria, pesquisando ou lendo a documentação. Isso era inicialmente intimidante, mas depois de um tempo eu concluí que era mais uma questão de poupar esforços do que ser rude. A regra social desta comunidade era procurar respostas primeiro na FAQ e na documentação e só depois perguntar no canal, levando informações úteis e relevantes ou contexto. Após aprender essas regras sociais, eu consegui obter respostas para as perguntas.

Voltar para parte superior

Aquisição: Considerações da Licença

Chegou o dia em que todos os envolvidos nas etapas iniciais queriam presenciar, alguém estava interessado em comprar nossa empresa. Após o entusiasmo inicial, havia uma série deverificações para a devida diligência.Um destes elementos era a verificação da licença do software que estávamos usando para criar a StudioNow. Os advogados da AOL estavam particularmente focados no caso de ter qualquer rastro de código relacionado à GPL em uso. A GPL possui especificações que determinam que trabalhos derivados de qualquer código GPL também devem carregar a GPL, assim como distribuir o código fonte. Além disso, há muita ambiguidade sobre se a vinculação às bibliotecas com licença GPL (vinculação estática ou dinâmica) é a causa para esta natureza "viral" da licença a ser aplicada.

Em geral, estava tudo bem. Porém, estávamos usando oFFmpeg com biblioteca vinculada, o que significava que a GPL estava em vigor, em vez da Lesser General Public License (LGPL). Embora não estivéssemos redistribuindo ou modificando o código fonte — apenas usando o binário compilado para transcodificar vídeo — nós precisávamos resolver esta questão. Felizmente, não estávamos usando bits que exigiam GPL em nosso serviço de transcodificação, então apenas recompilamos um novo FFmpeg binário com diferentes sinalizadores de compilação.

Voltar para parte superior

Conclusão

Conseguir oferecer soluções ao mercado utilizando software livre vai além de simplesmente usar o código aberto livre.O software livre é um ecossistema e uma comunidade. Você tem muito a ganhar tornando-se um membro ativo e engajado nas várias comunidades de interesse. Além disso, pelo simples fato de utilizar o software, você tem muito a contribuir para o projeto. Por último, seja cauteloso e preste atenção às licenças dos diversos softwares livres que você utiliza, pois elas podem ser muito importantes depois.

Desfrute da liberdade e da diversão de criar seu próximo empreendimento em software livre!

Recursos

Aprender

• Aprofunde-se no Python: Leia o livro de Mark Pilgrim para uma boa introdução à linguagem.
  
  
• Descubra o Python (developerWorks 2006): Explore esta série de artigos que abordam tópicos para programadores iniciantes do Python, incluindo variáveis, objetos do contêiner e instruções compostas.
  
  
• Livraria Safari: Visite a biblioteca de consulta eletrônica para encontrar fontes técnicas específicas.
  
  
• Eventos interessantes: confira futuras conferências, exposições e webcasts interessantes para desenvolvedores de software livre IBM.
  
  
• Zona de software livre do developerWorks: Encontre muitas instruções, ferramentas e atualizações de projeto para ajudar a desenvolver com tecnologias de software livre e usá-las com produtos IBM.
  
  

Obter produtos e tecnologias

• FFmpeg: Saiba mais sobre esta solução multiplataforma para gravar, converter e transmitir áudio e vídeo.
  
  
• Boto: Confira o repositório principal de software livre para este pacote Python que fornece interfaces para Amazon Web Services.
  
  
• Django: Saiba mais sobre esta estrutura Web de alto nível do Python.
  
  
• Pinax: Encontre informações sobre esta plataforma que é construída sobre o Django.
  
  
• Software de avaliação da IBM: inove o seu próximo projeto de desenvolvimento de software livre usando software para teste, disponível para download ou em DVD.
  
  

Discutir

• developerWorks : Conecte-se a outros usuários do developerWorks enquanto explora os blogs, fóruns, grupos e wikis voltados para desenvolvedores.
  
  
• Software livre do mundo real: Ajude a desenvolver este grupo da comunidade do developerWorks, focado em software livre.
  
  

Sobre o autor

Patrick Altman é um dos principais desenvolvedores do Pinax e criou e contribuiu para muitos outros projetos de software livre. Ele é o atual vice-presidente de engenharia da Eldarion. Anteriormente, atuou como engenheiro-chefe de software na StudioNow, a qual depois foi vendida para a AOL. Atualmente reside em Nashville, Tennessee, com sua esposa e três filhos.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Escolhendo a plataforma: Ruby ou Python?
• O poder da comunidade
• Aprendendo a escalar
• Aquisição: Considerações da Licença
• Conclusão
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais