Aaron Patterson
Também conhecido como @tenderlove, Aaron mudou o cenário de parsers no mundo Ruby com suas contribuições em projetos como o Psych, o novo parser de YAML do Ruby 1.9. Mais do que isso, se você trabalhar com XML hoje, provavelmente está usando por baixo o projeto Nokogiri. Antes disso tínhamos o REXML e o Hpricot, mas o Nokogiri foi quem trouxe performance nessa área. Outro projeto que ele contribuiu foi o Mechanize. Com isso temos hoje ótimos parsers para os principais formatos da internet, especialmente se contar que o parser de JSON do Rails basicamente é o mesmo parser de YAML dele.
Gregory Brown
Também conhecido como @seacreature e pelo Ruby Mendicant. Eu já havia usado um projeto seu chamado Ruport que usa o antigo PDF Writer para gerar relatórios em PDF. Mas o PDF Writer estava ficando meio abandonado. Então o Gregory decidiu criar uma nova fundação para geração de PDFs e disso nasceu o Prawn, uma biblioteca mais moderna e mais capaz. Além disso ele escreveu o livro “Ruby Best Practices”, que eu recomendo a todos que querem melhorar seu Ruby.
Nick Quaranto
Também conhecido como @qrush, ele é jovem e trabalha na Thoughtbot, a empresa que já nos trouxe diversos projetos open source importantes como Paperclip ou Shoulda. O Nick tinha uma reclamação: publicar gems era um processo tedioso via o antigo RubyForge.net.
Hoje temos Github que mudou da água para o vinho o processo de trabalhar com open source, mas para publicar gems ainda era preciso usar o caminho antigo. Então o Nick criou o Gemcutter.org que rapidamente evoluiu e tomou o lugar do antigo Rubygems.org, se tornando o repositório principal de gems da comunidade. Agora com um simples “gem push” conseguimos publicar nossas gems sem problemas. A dobradinha Github + Gemcutter literalmente modernizou o processo de trabalho open source dos rubistas.
Wayne E. Seguin
Este é fácil: @wayneeseguin. Wayne ficou mais conhecido por causa de seu projeto mais recente, o RVM. Com ele é possível ter diversas versões e implementações de Ruby rodando na mesma máquina. Podemos ter Ruby 1.8 e Ruby 1.9 e JRuby rodando no mesmo ambiente. Melhor ainda: podemos configurar cada projeto nosso com cada uma dessas versões. Um simples comando “rvm ruby-1.9.2” é suficiente para mudar de implementação a quente. Isso mudou nosso jeito de codificar e facilitou ordens de grandeza a organização de nossos projetos. Mais do que isso: facilitou o processo de ter aplicações web que dependem de implementação de Ruby diferentes rodando todos no mesmo servidor. Literalmente digno de um prêmio.