Como o GitHub usou o Caindo na Real para comprar uma briga, coçar sua própria coceira e se manter pequeno

Este texto é uma tradução do artigo escrito por Chris Wanstrath, onde ele explica os benefícios de aplicar os princípios do Getting Real na construção do GitHub.
Você pode encontar a versão original (em inglês) aqui. Decidi traduzir este artigo, porque considero o GitHub como um caso de sucesso e a forma como ele foi desenvolvido é inspiradora para todos aqueles que desejam “cair na real”. Bom proveito!

Getting Real desde o primeiro dia

Temos empregado o Getting Real (com grande sucesso) no GitHub desde o primeiro dia. Não porque quisemos, ou porque pensávamos que seria o única coisa certa a fazer. Fizemos isso porque não tivemos escolha.
Tom Preston-Werner e eu estávamos trabalhando em tempo integral em outras startups quando começamos o GitHub. Este era apenas um trabalho secundário. Compartilhar repositórios em Git era muito difícil. Os sites existentes exigiam que se configurasse tudo na mão, o que era uma dor de cabeça. Sem perceber, passamos a adotar o Getting Real – compramos uma briga (com os sites de Git existentes), coçamos nossa própria coceira (tínhamos repositórios Git que queríamos compartilhar), e nos mantemos pequenos (nós dois planejamos fazer tudo sozinhos).
Aplicar o Getting Real no GitHub, embora estivéssemos familiarizados com ele, nunca passou por nossas cabeças. A idéia principal era construir algo útil do qual nos sentiríamos bem de poder usar. A parte boa, é claro, é que outras pessoas também gostariam de usá-lo. Então, percebemos que poderíamos transformar o GitHub em um negócio de verdade. Claro que estávamos sempre planejado como ganhar algum dinheiro, mas ganhar dinheiro e gerir uma empresa são coisas bem diferentes.

Nenhum financiamento externo

Tivemos uma conversa e concordamos de imediato: sem financiamento externo. Queríamos manter toda a empresa conosco. Ter pouco dinheiro, pouco tempo, e muita paixão deixa poucas opções. Você tem que fazer o que Jason, David, e os garotos dizem. É a maneira mais inteligente para o sucesso.
Uma vez que evitamos financiamento, fizemos mais algumas decisões: nos manter pequenos, dar ao site uma atitude, sempre dizer não e definir o objetivo do site em uma única frase. Ah sim, e encontrar nosso terceiro mosqueteiro. Encontramos Hyett PJ, um experiente desenvolvedor empresarial, e então mão à obra.

Lançando para já

Nós literalmente lançamos o nosso “beta” assim que o código de autenticação foi finalizado. Tínhamos usuários de verdade e projetos concretos cadastrados, trazendo-nos um inestimável feedback. O que funcionou, o que não funcionou, coisas deste tipo. Sem testes de laboratório ou pesquisas. Acompanhávamos o que as pessoas faziam ao invés de ouvir o que elas queriam fazer (o que naturalmente nunca é necessário).
Não só não estávamos preocupados com escalonamento quando lançamos o nosso beta, como a nossa arquitetura local nos proibia disso. Lançamos nosso beta em um single box, e devido a arquitetura do Git e da nossa configuração, não podíamos simplesmente adicionar outro box se o trafego aumentasse. Teríamos de reescrever a coisa toda. Mas tudo bem. Conseguir usuários era mais importante.

Mantenha-se informado

Blogamos a respeito e acompanhávamos o Twitter (via Summize) com olhos de águia. Trabalhamos duro para construir um hype e celebrávamos toda vez que um blogueiro influente se cadastrava no GitHub ou escrevia alguma coisa boa a respeito. Ver o que as pessoas estavam dizendo, especialmente as coisas boas, nos turbinava. Em pouco menos de 3 meses tínhamos nosso sistema de faturamento finalizado e pronto para lançar.
Mas as coisas sempre dão errado em dias de lançamento. Se tudo sair perfeito, alguma coisa saiu errado. Nos recuperamos rapidamente, e no geral tivemos um bom dia. Até conseguimos liberar algumas novas funcionalidades como uma espécie de “obrigado” aos nossos beta testers. Mas não conseguimos lançar tudo.
Vários projetos web, no nosso ramo, possuíam muitas funcionalidades que não tínhamos. Bug tracking, chat, integração contínua e outras coisas assim. Sendo somente três pessoas, poderíamos gastar o resto de nossas vidas criando estes recursos, ou com muito menos esforço, abrir pontos de integração para deixar as pessoas usarem os sites que eles amavam em conjunto com o nosso.

Campfire

Somos grandes fãs do Campfire, então por que não dar às pessoas uma maneira de integrar os seus códigos no GitHub com o Campfire? Adoramos usar o Lighthouse para ticket tracking, então porque não adotá-lo? Ao invés de criar funcionalidades que outros já faziam fomos capazes de gastar nosso tempo com idéias como o network visualizer e os comentários em commits.

“As coisas têm sido surpreendentes”

Tivemos nosso lançamento há três meses e as coisas têm sido surpreendentes desde então. Um ótimo crescimento, muitos usuários maravilhosos, e acima de tudo um site do qual estamos orgulhosos e que usamos todos os dias. De fato, depois de apenas três meses já estamos pagando alguns salários. Tudo sem financiamento.
Realmente, não aceitar financiamento foi ótimo para nós. Quer pagar do seu bolso para ter a Funcionalidade X? Não? Então deixe de lado. Se eu não estou afim de uma funcionalidade, eu não vou gastar o meu tempo (e muito menos meu dinheiro) implementado-a.

Outros princípios inestimáveis

Enquanto idéias como “sem financiamento” e “mantenha-se pequeno” são os pilares, alguns outros princípios do Getting Real embora fáceis de se esquecer, são inestimáveis. O “tela em branco” é uma destas idéias. Basicamente, o que os seus usuários verão quando usarem pela primeira vez o seu aplicativo importa, e muito. Um bem respeitado desenvolvedor Ruby abordou PJ em uma conferência e mencionou especificamente o quanto ele gostou de sua primeira experiência com o news feed do GitHub. Ele não utilizou essas palavras, é claro. Em vez disso ele disse exatamente o que queria ouvir: “Depois de me cadastrar, a página de Boas Vindas me mostrou exatamente o que fazer em seguida”. Quando você cria um novo projeto no GitHub, você realmente pode copiar e colar o texto da caixa “What’s Next?” no seu console para configurar um repositório em seu computador. Isto facilita as coisas.
Para mim, a ‘atitude’ é um outro aspecto que normalmente é subestimado. Mas é a solução perfeita para muitos problemas. Tem uma grandes parada programada? Exiba vídeos do YouTube para seus usuários na página “Vamos estar de volta em breve” (nós fazemos isto – os visitantes assistem a uma coleção de vídeos pré-selecionados). Precisa mostrar uma mensagem de “carregando” enquanto executa algo em background? Torne isto engraçado. “Fork” (copiar) um repositório demora um pouco e a nossa mensagem “Hardcore Forking Action” tornou-se infame entre nossos usuários. Adicionar um pouco de tempero em coisas que normalmente são rotineiras e chatas é a melhor coisa a se fazer. Você não é o Banco do Brasil ou qualquer outra megacorporação – mostrar o seu lado criativo em lugares pouco ortodoxo é a melhor maneira de provar isto.
Eu mencionei anteriormente que chegamos a um acordo sobre uma única frase para definir o objetivo do site. Embora o GitHub continue brincando de integrar produtos de terceiros, aspectos de redes sociais, APIs e feeds, um visual interessante e outras características que nós amamos, ele foi criado para facilitar o compartilhamento de códigos. E isso é o que nós dizemos: “Hospedagem Git: deixou de ser um pé no saco”.
Até aqui, tudo bem.