Obs: Esse post é além de inspirador, muito esclarecedor, faz com que coloquemos novamente nossos pés onde eles precisam estar, que é no chão. Mas mostra também que podemos conseguir diversas coisas legais tomando as decisões certas e fazendo a única ação benéfica e sustentável do mundo da programação que é de ler, escrever e compartilhar código. Se algum trecho da tradução poderia ficar melhor podem mandar sugestões de mudança, o texto original você encontra aqui, fiquem agora com o texto traduzido:

Oi a todos, sou Chris Wanstrath, e vou te ensinar como se tornar um desenvolvedor Rails famoso. Um Ruby rock star. Um programador ninja. Não é difícil, apenas foque-se como um raio laser e tenha um pouco de paciência.

Devo dizer de antemão de que você não precisa se preocupar com qualquer habilidade de programação ou dez mil horas de prática. Isso não importa – é fácil de falsificar.

Então! A primeira coisa que você precisa é um blog. Mas não de qualquer blog. Você precisa de um blog com personalidade. Não importa se a personalidade do blog seja compatível com a sua própria personalidade.

A parte mais importante de qualquer blog é o nome. Claramente. Não pode ser “blog de João”. Ou talvez possa -, é que poderia ser retrô neste momento. Mas você entende o que quero dizer. Não escolha um nome que não te deixe feliz, pois se você fizer a escolha certa, você nunca vai ouvir o final da mesma. (o nome pode ser bom, mas se não te deixa feliz você acaba deixando de lado). É como escolher um nome de uma banda. Ou dando um nome para uma criança. Certifique-se de que é algo que as pessoas irão lembrar.

E tente não se tornar demasiado Railsy. Isso é limitante – faça o seu próprio. É o seu blog, apesar de tudo.

Eu não deveria ter de dizer esse próximo passo, eu odeio dizer isso, mas tenho que dizer: nunca use um template de blog default. Isso é um tiro no próprio pé.

Veja por quê: você eventualmente publicará conteúdos de qualidade no seu blog. Não de imediato, não se adiante. Mas você vai escrever alguns posts realmente bons. Eles serão linkados no Hacker News e Reddit, eles serão “tweetados” e guardados no delicious, e, se tiver sorte, você receberá uma menção em um ou dois podcast.

A primeira vez que alguém visitar o seu blog, se o conteúdo é bom o suficiente, ele aprecia isso. Talvez ele adicione aos favoritos dele. Em seguida, ele passará ao próximo item no leitor de feed.

A segunda vez que a mesma pessoa visitar o seu blog, se o design é único e a personalidade brilha através do conteúdo, ele vai lembrar. “Ei. Eu estava aqui antes. Foi bom!”

Agora não sei exatamente quantos posts de qualidade você vai precisar porque vai depender de cada indivíduo. Alguns se conectam imediatamente. Eles não têm vergonha. Outros são mais lentos – eles fazem você trabalhar por isso. Três, quatro, talvez cinco posts maravilhosos antes deles se conectarem. Mas eles vão conectar.

A idéia aqui é associação – se o seu blog usa um template sem identidade, ninguém vai lembrar que eles estiveram lá antes. Que leram um bom post nele. Você está lutando uma batalha difícil.

Gaste tempo com o design. Talvez contratar alguém, faça alguns favores para um amigo designer, não sei, você vai descobri.

E quando você fizer isso, você terá um nome matador e um design elegante. Bom começo.

Agora para as personalizações. A barra lateral, o cabeçalho. Essas coisas essenciais.

Se você vai colocar uma lista de blogs que você gosta na barra lateral, e eu não colocaria, você tem que ter muito cuidado. Se os blogs são muito populares, as pessoas vão pensar que você é um “Maria vai com as outras”. Se eles são muito desconhecidos, eles podem pensar que você está com má companhias. É melhor estar seguro e ignorar completamente a coisa toda.

Na verdade eu só mantenho a barra lateral escassa, muito escassa. Sem tag clouds ou comentários recentes ou posts recentes. Talvez apenas o arquivo, que cria uma lista mensal. Listar os projetos de interesse pode ser bom.

Ah, e seu endereço de email. As pessoas vão querer enviar email para você.

Mas como eu disse, escasso. Não se distraia do seu conteúdo.

E nunca use anúncios Google – você vai eventualmente querer aderir a uma rede de anúncios patrocinados. Os anúncios do Google apenas desvalorizam o bem (blog).

O cabeçalho é importante porque é a primeira coisa que as pessoas veem. Uma foto sua é provavelmente melhor. Algo especial. Mas se você não pode encaixá-la no cabeçalho, a barra lateral funciona igualmente bem. Lembre-se: as pessoas têm de reconhecer você, saber que você é o João de “blog de João”.

Quanto ao conteúdo, você precisa decidir sobre o seu perfil. Você deve fazer uma lista de dez ou mais famosos desenvolvedores Rails, talvez em uma planilha, e escolha um adjetivo que descreva cada perfil deles. Vá até a lista escolha a combinação que funciona para você. Lúdico e espontâneo? Profissional e inspirador? Ofensivo e verborrágico? Escolha duas características que você acha que pode ter sucesso. Escreva elas. Este é agora é o perfil de seu blog.

A etapa final, antes de blogar, são as regras. Você precisa estabelecer diretrizes para o seu blog, as regras sobre o conteúdo. Se Hashrocket começa a falar de Scala, você pode aderir a controvérsia? Você pode postar sobre o grande e novo cliente Twitter que você baixou? E sobre suas experiências com o Android SDK? Você está centrado no código, a comunidade, suas observações, ou truques esotéricos?

(Eu ficaria longe de truques esotéricos como competência central mas ocasionalmente entregue-se ao desejo a fim de manter a sua credibilidade. Mas isso é só comigo.)

A coisa importante sobre as regras é que ajudam a estabelecer a coerência. Você não quer postar sobre uma elegante biblioteca uma vez e nunca mais mencioná-la novamente. Isso confunde as pessoas. Eles desejam algo estruturado.

Dê isso a eles.

Ok, com tudo o que disse, podemos começar a blogar. Mas não estamos realmente blogando ainda. Estamos apenas praticando. Todo dia você precisa escrever um post. Não importa sobre o que. Ninguém vai lê-los. Mas você precisa práticar a escrita e aperfeiçoar seu tom. Dê ao seu blog uma personalidade.

O que postar? Qualquer coisa. Em vez de apenas fazer um Gist seu belo pedaço de código, post sobre isso no seu blog. Adicione uma pequena história de fundo.Mas não fale continuamente sobre ela. A menos, claro, que seja o seu tom, seu perfil.

A grande coisa sobre como iniciar um novo blog é que você pode voltar atrás e olhar para antigos Gists,  plugins antigos que você escreveu, tarefas rake malucas, e fingir que eles são totalmente novas. Escreva. Faça um post. Trata-se de algo novo para qualquer outra pessoa.

Outro truque bom é olhar o que outros blogueiros estão fazendo, bibliotecas populares ou técnicas que foram pioneiras e melhorar as mesmas. Dessa forma eles fazem a maior parte do trabalho, mas porque você fez um pouco melhor, você pode conseguir alguma atenção deles.

Fale sobre testes. Lamente a falta de alguma coisa. Talvez até mesmo inicie algum problema com o código de outro blogueiro. Ele não funciona para você, por isso é uma porcaria.

Após algumas semanas podemos começar a fazer algo sério. Mas, entretanto, o que você vai fazer sobre a sua conta no Twitter?

Você tem uma, certo? Bem, você não vai querer “tweetar” negligentemente postagens do seu blog – Isso é um enorme fora. E você não quer “tweetar” que você apenas começou um blog, porque não há nada lá e é uma oportunidade perdida.

Em vez disso você poderia mudar o design do seu Twitter (o pano de fundo, cores dos links, tudo isso) para corresponder ao seu blog. Faça-os cumprimentar um ao outro. Enfeite-o para o sucesso. E seja legal.

Dessa forma você não está apenas sendo um desenvolvedor Rails aleatório, você é o autor de “blog de João”. Você é que é João. Certifique-se que o seu avatar tem o seu rosto, também.

Na verdade, por que não usa seu Photoshop e faz um daqueles backgrounds sociais para a sua conta Twitter? Você sabe o que estou falando – com todos os links que você pode apenas ler e certamente pode não clicar. Esses fundos permite que as pessoas conheçam sua idéia de negócios e como encontrá-lo de forma conveniente.

Suas mensagens do Twetter provavelmente seguirão o tom do blog, mas, e esta é a parte divertida, aqui você pode quebrar as regras. Permita que as pessoas saibam algo sobre você. Como num reality show.

De qualquer forma, vamos adiante. Você está de pé, você está “twettando”, você está “blogando”, você está se sentindo bem. Hora de atacar.

Sua primeira postagem que você realmente acha que é bom, ponha-o lá fora. “twette” sobre ele, publique-o em sites de notícias sociais, lute para conseguir uma relação no Rubyflow. faça isso de manhã cedo em um dia da semana, horário padrão da costa leste (USA e Canadá), porque as pessoas adoram se refrescar com Reddit no trabalho.

Mas não esperem muito. Não há tal coisa como sucesso em uma noite. Temos ainda muito trabalho a fazer. Uma forma de obter visitantes e leitores é liberar códigos simples, úteis de forma resumida e diretamente em um post do blog. Mostre às pessoas o problema, mostre a solução, diga como instalá-lo e forneça um meio para fazer o download.

Outra forma é discurso retórico. Mas você tem que fazer isso muito.

No que diz respeito à identificação e liberação de código útil e simples, não se gasta muito tempo pensando nisso. siga seu dia, sua rotina normal, mas mantenha um olho para as coisas que te deixa aflito. Coisas que deixam seus colegas aflitos.

Um idiota mecheu no seu código de produção? Repetição e erro tendem a ser práticas seguras? Bug na autenticação do plugin que você está usando?

Mantenha os olhos abertos e, quando você identificar um ponto de aflição, algo que provoca atrito no seu fluxo de trabalho, anote. Armazene em algum lugar.

Mais tarde naquela noite você pode se servir com um copo de vinho, talvez um copo de uísque, sentar-se no sofá e escrever uma solução. Mantenha a solução simples e certifique-se de que você pode completar a biblioteca ou o plugin em uma noite. Em seguida, escreva uma post no blog e publique.

Limpar e repetir.

Se algo te causa dor, provavelmente causa dor em outra pessoa também. Somos todos desenvolvedores Rails  com tarefas muito similares. Bem, a maioria de nós.

Eventualmente, você vai tirar a sorte grande: algo simples que poucas pessoas querem usar. Mantenha-o, aceite patches, e siga em frente.

A medida que você ganhar mais confiança, você pode começar a procurar problemas e soluções mais ambiciosas. Você conseguirá um reconhecimento melhor.

Agora você está pronto para o circuito de conferências. RubyConfs locais, encontros em sua cidade, e no Santo Graal, RailsConf (No Brasil: Rails Summit Latin America). Abrace um projeto sério e fale sobre ele. Publique o progresso da atualizações. Mas não se esqueça de manter o seu tom e seguir as regras. Vá para os coffe brakes e conheça pessoas. Permita que eles saibam que você é o João de blog do João. Nunca tire seu crachá.

Continue postando com consistência. A maioria das pessoas não sabem a diferença entre prolífico e profundo. ambas as palavras compartilham muitas letras. Eles apenas querem algo interessante para ler, e muito disso.

Acompanhe o que todos estão dizendo sobre as seus posts no Twitter, delicious, e FriendFeed. Você não tem que responder, mas eu buscaria freqüentemente seus posts em todos estes serviços. Verifique algumas vezes em um dia.

Se você contribuir para Rails em si, que é enorme. Outros desenvolvedores famosos de Rails vão começar a notá-lo. Mesmo com comentários em blogs – especialmente os dez na sua lista. Você manteve essa planilha, certo?

Uns poucos meses disso e você estará assinando autógrafos, beijando bebês, indo a boates caras – vivendo uma boa vida.

Todo mundo vai saber o seu nome. Editoras estarão te enviando livros, pedindo-lhe para escrever no blog sobre eles. Você será convidado para falar em conferências. Será reconhecido na rua. Recrutadores vão ocupar toda sua caixa de entrada. Coisas que você disser serão significativas. Seu blog será patrocinado. Talvez você até escreva seu próprio livro.

E, claro, você vai ter de sair com os famosos. Agora você é um deles, depois de tudo.

Parabéns.

O problema é que ser programador Rails famoso não é o mesmo que ser um bom programador Rails. Qualquer pessoa pode se tornar um programador Rails famoso. Faça todas as coisas que eu disse. Boom, garanto que funciona.

Pessoalmente, eu olho para os bons programadores. Eles não se preocupam com a sua contagem de subscrição do RSS, eles blogam como complemento. Pessoas que não estão preocupadas com quantos seguidores no Twitter  possuem e trabalham nos seus projetos todas as semanas, porque adoram fazer isso. Que contribuíram para o Rails por anos por paixão e não são excessivamente preocupados com a divulgação de suas vidas.

Pessoas que se preocupam com código, primeiro e acima de tudo.

Há sempre conversas sobre colocar apelidos em IRC ou Twitter nos crachás das conferências, assim você pode identificar as pessoas que você conheceu on-line, mas nunca pessoalmente. Porque é que simplesmente não ignoramos isso e colocamos em seu lugar o projeto favorito que você tenha contribuído?

“Você contribuiu para Rack? Isso é ótimo, eu amo Rack. Talvez possamos ser amigos.”

“Você trabalhou na Webrat? Pode por favor explicá-lo a mim?”

Pense sobre isso – você conhece as pessoas envolvidas no seu favorito RubyGem? Seu plugin mais usado?

Eles são provavelmente as pessoas que você vai querer estar junto delas.

Código, estou compreendendo, é o fio comum que une os desenvolvedores. Não é pelo blog ou mensagens de erro propositais (trolling) ou pela procrastinação, e sim porque nós amamos o código.

Trata-se de leitura, escrita, e compartilhamento de código.

E quanto mais eu blogo, envio mensagens falsas (troll), e procrastino, penso que o código me trouxe a fortuna maior. O maior retorno sobre o investimento com o menor risco.

Depois que saí da faculdade, eu trabalhava com PHP em uma loja fazendo aplicações de logísticas de entrega. Éramos os intermediários entre transportadores independentes e as grandes empresas como a Kmart. Os transportadores deveriam se registrar no nosso site, dizer que iam estar em Delaware no dia 3 de maio, e que eles estão a caminho de Denver, em seguida, eles obtém informações sobre transferências ao longo do percurso escolhido. Eles poderão, em seguida pedir um preço maior no trasporte ou aceitar o valor estipulado, tudo através de nós.

Foi uma aplicação bastante complexa e duas coisas que estavam faltando: controle de versão e constantes. Não havia controle de versão, de modo que você tem coisas como main2.php e compute_radius_of_from_shipment7.php espalhados ao redor. Junto com as versões de 0 a 6 desse mesmo arquivo, no mesmo diretório. Verdadeiramente doloroso.

Não havia constantes e nenhuma configuração, de modo que o código-fonte estava preenchido com números mágicos. Se quiser fazer um ajuste em qualquer um dos nossos algoritmos, você tinha que encontrar o código que fez o processamento e alterar alguns números de forma manual. Esperávamos esperançosamente que os números estivessem corretos.

Naturalmente, a primeira coisa que fiz foi institucionalizar o Subversion. Rei dos sistemas de controle de versão.

A segunda coisa que fiz foi extrair os números mágicos e colocá-los em arquivos de configuração. Na época, nós faziamos códigos em PHP que acessavam arquivos de configuração .ini. A maior parte do que se precisava era suportado, e eu estava encantado porque o PHP vem com uma biblioteca que acessa e entende arquivos .ini.

Este sistema funcionou bem, mas quando eu comecei mexer com Rails Eu fiquei encantado com o YAML. Tão limpo, tão poderoso. Havia o Syck, uma extensão em C escrita por _why, mas era apenas isso: uma extensão C. Eu não sabia muito sobre carregamento de código C em PHP, e ainda menos sobre como fazer isso em nossos servidores de produção.

Então eu comecei a escrever um parser YAML em PHP, no meu próprio tempo. Como uma homenagem a Syck, eu a chamei de Spyc – SPYC – uma Simples Php Yaml Classe. Foi meu primeiro parser, era stateful (mantinha o estado no decorrer da utilização). Não dei suporte a tudo do YAML, mas ele suportava as principais funcionalidades – dumping e o load. As partes boas.

Me debrucei nele e em pouco tempo estávamos utilizando YAML com grande sucesso na minha empresa. Naturalmente, eu fiz o upload do código para o SourceForge. Rei dos hosts de código-fonte. Meu amigo designer fez uma página e no primeiro mês Spyc foi um enorme sucesso. Eu juro que tinha, pelo menos, 70 downloads. SETENTA!

Isso foi um grande negócio.

Avançou rápido cerca de nove meses: o meu teletrabalho de telecomunicações virou um trabalho de verdade, e eu concordei em ir para Nova Jersey. Eu embalei meu carro, disse adeus, conduzi onze horas para Hackensack, trabalhei um dia no escritório, percebi que todos os meus colegas de trabalho eram completos puxa-sacos, entrei no meu carro e dirigi onze horas de volta para Ohio.

E é isso, eu era um desempregado que abandonou a faculdade sem terminar os estudos.

Não foi tão ruim – Passei muito tempo na piscina naquele verão. E eu passei muito tempo aprendendo Ruby e Rails.

Eu até comecei freelancer novamente. Afinal, eu estava totalmente qualificado. Eu tinha 8 anos de experiência de programação – Fiz algumas QBasic, quando eu tinha 12 anos. Eu estava certo que aquilo contava.

Mas verão acabou e eu precisava descobrir o que eu ia fazer com minha vida.

Como tinha sorte, no meio desse tempo, o web site de vídeo game GameSpot estavam contratando. E eu precisava de um emprego.

Eu não tinha idéia de onde era São Francisco ou o que os caras do GameSpot estavam procurando, mas eu fiz a requisição. Criei um novo currículo e fiquei a noite toda trabalhando no tema da carta. Até o momento em que eu tinha terminado, era uma página longa e bastante convincente.

Nela eu prometi me mudar para a Califórnia no dia seguinte, levando nada além de meu violão e Xbox comigo. Minha família ia me perder, mas eu estava pronto para sair, e eu estava faminto para mostrar ao mundo o que eu podia fazer. Pronto para aprender com os mestres.

A entrevista por telefone correu bem, eles gostavam que eu estava por dentro do mundo Macs e Ruby, e eu obviamente consegui o trabalho. A primeira vez que pus os pés na Califórnia foi quando eu voei para para procurar um apartamento com meu pai.

Minha experiência profissional não foi o que fez com que eu conseguisse o trabalho. Eu tenho certeza que a minha carta tinha algo a ver com isso, mas a minha curta carreira na logística de transporte foi menos que glamourosa. Eu só tinha uma coisa para mostrar a GameSpot – Spyc. Meu código foi livremente disponibilizado, tinha sido usado em produção, e funcionou. Eles podem fazer o download e brincar com ela, ou checá-la online. Independentemente de pensarem que era bom ou não, eles poderiam dizer que era limpo e bem organizado. Bom, talvez não, mas eu tinha um site e 70 downloads.

Consegui o emprego no GameSpot, na minha opinião o primeiro grande passo no caminho que me trouxe aqui, foi graças ao código. Código que eu escrevi principalmente para me divertir, para coçar minha própria coceira.

Então isso foi muito legal, e eu achei singular, até que aconteceu de novo. Enquanto eu estava trabalhando na GameSpot, fui fazendo mais e mais Ruby em paralelo. Eu tinha um projeto Rais open souce chamado Ozimodo, péssimo servidor de FTP denominado ftpd.rb (que eu usei como forma de aprender sobre threading), e um DSL parser de linha de comando chamado Choice. Para Choice, eu tinha um suite de testes completa (eu escrevi essa suite para aprender TDD) e uma homepage criada por RDoc no Rubyforge.

Quando CNET, mãe da empresa GameSpot, adquiriu Chowhound, eles decidiram reescrever o site em Rails. A partir do zero. Clássico. Eles trouxeram dois programadores Rails da Wayfaring.com e foram à procura de outro. Então me encontraram.

Mais tarde eu descobri o meu site RDoc, RubyGem, e a suite de testes provou aos caras da Wayfaring que eu era um “verdadeiro” programador Ruby. Eles queriam alguém animado com essas coisas, e eu certamente era.

Aquele foi um grande momento, porque paguei a minha viagem para a RailsConf 2006.

Conversas sobre código.

Se você não tem quaisquer projeto nesse momento, você deve gastar algum tempo aqui começando algo novo. Algo faça sentido para você, mas que ainda não tenha ao seu redor. Uma ideia que tem estado flutuando.

Ou basta encontrar alguém que esteja haqueando e perguntar no que eles estão trabalhando. Talvez seja interessante o suficiente para pular dentro.

Se você deseja criar o seu próprio negócio, o código é a maneira perfeita para encontrar cofundadores e funcionários. Eu sempre me sinto mal por tipos de empresas que postam em fóruns perguntando sobre a melhor forma de encontrar um cofundador ou CTO. Não por causa do tipo de négocios deles – que todos temos de viver com as nossas decisões -, mas porque eu não acho que isso seja um problema.

Conheci todas as outras pessoas do GitHub através de código: PJ através Chowhound, Tom através do seu trabalho open source, Scott por causa de sua quase irritante variedade de bibliotecas Git baseadas Ruby, e Tekkub pelo seu domínio da seção Lua do site.

Na CNET, encontramos pessoas realmente talentosas, tanto através de fonte aberta e projetos locais.

E todos que você conheceu aqui que você não conhecia antes da conferência, tecnicamente, é conhecido através de código.

GitHub não tornou-se popular em virtude do Git. Ele pode ter ajudado, mas não foi o principal catalisador.

GitHub se popularizou porque ele lida com código. Compartilhando, encontrando, e contribuindo com código.

Rubyforge e Sourceforge não são focados no código. Eles nunca foram.

Na verdade, ainda ontem Sourceforge passou por um redesign na sua homepage. Eles tem pesquisa no Twitter e projetos populares ali, frente e centro. Elegante. Então eu cliquei um pouco.

O primeiro projeto que cliquei, Ares Galaxy, é o número sete na lista top dez. O visualizador CVS disse que não possui quaisquer arquivos. Então eu acho que você pode simplesmente baixar um tarball. O que é bom.

O segundo projeto que eu cliquei era o número cinco da lista, 7-Zip. Ele não tem sequer um link para um visualizador de código fonte.

Sem código.

Eu percebi que fazia muito tempo que não criava um projeto no Sourceforge, então eu decidi fazer isso. Lembro-me que é doloroso, mas este é um novo redesign.

A primeira página é constituída por cinco radio buttons, um campo Nome do Projeto, um campo Nome Unix, um textarea para descrição pública, e um textarea para Notas adicionais. A área de notas é carinhosamente fornecida para que você possa justificar ao pessoal do SourceForge porque deve ser permitida a criação de um projeto. E, claro, você não pode continuar sem dar a eles uma razão que contenha pelo menos 200 caracteres.

Penso que é uma loucura – a maioria dos dias tenho problemas com 140 caracteres.

Além disso, há um aviso na parte superior que diz que você precisa armazenar software open source.

Depois de preenchidos todos os campos e que você clicou em ‘Next’ você é convidado a escolher uma licença open source. Há oito licenças listadas, juntamente com uma opção “outros” e, em seguida, um link para documentação sobre open source e escolher uma licença. Eu escolhi MIT.

Na página três você pode atribuir a seu projeto pelo menos cinco categorias. As opções de categorias são coisas como, “Linguagem de programação Ruby”, “User Interface DirectX”, ou “Desenvolvimento Status Beta”.

Eu escolhi quatro muito facilmente, mas teve problemas com a quinta, finalizava com, “Tema Religião e Filosofia New Age”.

Muito apropriado, se você pensar nisso.

Na última página você é convidado a ler sobre o que significa open source, sobre os termos de serviço do site, em seguida submete o projeto para aprovação.

Após o envio aparece uma tela de agradecimento e um pedido para você esperar de um a três dias úteis.

Eu, obviamente, tenho interesse em desaprovar um site competidor, mas este formulário de inscrição é uma das razões para termos começado o GitHub. Uma vez que você tenha uma conta, criar um repositório GitHub é, penso eu, simples:

Pedimos nome do projeto, uma breve descrição, e a URL do projeto. abaixo desses três campos tem dois radio buttons: esse projeto é público ou privado? A única coisa necessária é o nome do projeto. Você pode mudar qualquer um dos campos mais tarde. Não há nenhum processo de aprovação e você pode imediatamente começar a compartilhar código.

Entre decidir compartilhar o seu código e realmente compartilhar o seu código, SourceForge fornece um formulário de inscrição de quatro páginas e um a três dias de espera.

Mas sua documentação em software open source afirma: “A essência do modelo de desenvolvimento Open Source é a criação rápida de soluções dentro de um processo aberto, ambiente colaborativo”.

Correto.

Aqui está a minha sugestão para SourceForge:

Devem cortar o processo de inscrição para uma única página, remover os 200 caracteres do pedido “por favor hospedem o meu projeto”, serem mais favoráveis com relação a categorização, sugerir uma licença de fonte aberta para você, então permitir que altere qualquer destas coisas depois que seu projeto seja criado.

Eles também devem tornar a criação de projeto instantânea e passa-lo através de um filtro de spam ou ter funcionários remunerados para fazerem vistorias manualmente e aprovarem cada projeto em vez olhar para a lista dos projetos recentemente criados e assinalarem os que parecem suspeitos.

Parece-me que todos os passos necessários e formulários são apenas cerimônia, retardando você e fazendo você perder tempo com algo diferente do que você realmente deseja realizar. Eles agregam valor? Certamente que não.

E se há uma coisa que eu aprendi com Rails, é deixar o inferno fora do caminho e permitir que as pessoas concentrem-se na tarefa em questão.

Reduzir atrito.

Primeira lei de Newton do movimento, faz duas afirmações: um objeto em repouso tende a permanecer em repouso e um objeto em movimento tende a permanecer em movimento. É muitas vezes referida como a lei da inércia.

E inércia, para quem não se lembra ou não teve aula de física, é a tendência do objeto resistir a mudanças no seu estado de movimento.

Se você chutar uma bola, ela vai diminuindo a velocidade até parar. Mas ela não quer parar. O Atrito criado pelo movimento ao longo do solo e do ar reage contra a bola, conspirando para pará-la a todo o custo.

Quanto mais você remover atrito, o avanço da bola vai continuar e vai demorar muito mais tempo para parar.

Esta ideia de atrito, é muito parecida com o inverso da produtividade. Ser produtivo significa obter coisas feitas de forma eficiente e eficaz. Atrito impede de você fazer essas coisas, atrasa você, conspira contra você, é uma perda de energia.

E muitas vezes, o atrito custa seu dinheiro.

Poucos meses antes da segunda RailsConf Deixei Chowhound e a CNET para iniciar uma empresa de consultoria com Hyett PJ. Sabíamos como codificar, pensávamos que sabiamos como blogar, mas não sabíamos nada sobre como iniciar um negócio.

Então, fizemos algumas pesquisas. Aparentemente, existem empresas que você pode pagar para criar um negócio para você. Muito oficialmente. Eles até mesmo enviam-lhe uma pasta para documentos de couro com o nome da sua empresa bordado sobre nela.

E existem pessoas que você pode pagar para fazer a sua contabilidade. Nós vamos chamá-los “contadores”.

Estes são dois dos mais importantes investimentos que você pode fazer quando se inicia um novo negócio: profissionais que lidam com a papelada e que manipulam os números.

E não só porque eles sabem o que estão fazendo.

Você ia querer pagar 100 dólares por hora para um contador inexperiente? Porque se seu preço de consultoria é 100 dólares por hora e você faz sua própria contabilidade é exatamente o que está acontecendo.

Mesma coisa para a criação de um negócio. Todo o tempo que você gasta pesquisando, preenchendo papelada, formulários, dirigindo para Sacramento para encontrar um tabelião – é acrescentado e torna-se caro se você fizer tudo sozinho.

A menos, claro, que seu tempo seja sem importância. Mas você está aqui, portanto, isso não é verdade.

Como seu tempo não é inútil, isso significa repetição, trabalho entediante e duro, e todos os custos excessivos de configuração custam seu dinheiro. Bem, e custam seu tempo. O tempo é muito importante, também.

Acho que uma parte essencial de ser um bom programador é a capacidade de identificar estes pontos negativos e removê-los, para agilizar o processo.

Rack, por exemplo, é ótimo porque ele torna a interface com os servidores web tão fácil.

Git branching(ramificação) e merging(mesclar) são sempre apontados como a razão da escolha.

Nós todos amamos Rails porque faz a maior parte das coisas tediosas irem embora.

E testar é famoso porque, bem, bugs e designs ruins são horríveis.

Portanto, vamos seguir esses exemplos. Vamos criar mais projetos que cocem uma coceira ou aliviem alguma dor. Vamos parar a obsessão sobre qual framework de teste usar e começar a obsessão por constuir sites que resolvam problemas. Vamos parar de discutir sobre linguagens e continuar aprimorando a nossa favorita. Vamos parar de criar longos tutoriais para obter assinantes RSS e começar a contribuir para a documentação oficial.

Vamos nos concentrar mais no código e menos nas conversas. Mais nas informações sobre a comunidade e menos sobre nós mesmos.

Na verdade, acho que já estamos no caminho certo. O Ruby Heroes Awards é uma grande idéia e são dadas para as as pessoas certas. Sites como o Rubyflow e até mesmo o Twitter torna mais fácil do que nunca encontrar projetos novos e interessantes. Calendar About Nothing torna simples encontrar programadores apaixonados e dar uma olhada no que estão trabalhando, enquanto RailsCasts e DocRails são alguns dos melhores esforços de documentação em qualquer comunidade.

Então, sim. Queremos mais disso.

Afinal, nós queremos realmente ser estrelas de rock como Kid Rock ou Axl Rose? Pessoas que são famosamente irresponsáveis – que têm reputações degradante para os seus fans e notoriedade para o seu planeta que é do tamanho do próprio ego?

Acho que eu prefiro trabalhar com e ser um bom desenvolvedor.

Obrigado.