Faço este post motivado por diversos acontecimentos recentes, por diversas reclamações de amigos, e, na gota d’água, pelo twitt do amigo Alexandre Tarifa, que dizia:

“Nunca apoie uma comunidade por promessa de algum reconhecimento… Apoie pq vc acredita na idéia e tem prazer em contribuir”

Concordo com ele. Vamos ao porquê. Não posso falar pelos outros, nem pelos amigos, como o Tarifa. Mas posso falar por mim. Então muito deste post vai dar minha perspectiva pessoal sobre o problema.

Eu faço trabalhos sociais há 20 anos. Comecei trabalhando com comunidades carentes ainda muito novo, e até hoje desenvolvo um trabalho que nada tem a ver com tecnologia. Em torno de 90% do tempo esse trabalho tem a ver com educação. Mesmo com 13 anos de idade o trabalho era dar aulas, eu dava aulas para crianças de 5 anos, 7 anos por aí. Já fiz muita organização de eventos, já carreguei muita sacola também, mas a maior parte é palestrando e dando aulas.

É o tipo de coisa que eu não costumo comentar por aqui simplesmente porque esse é um aspecto da minha vida pessoal que não interessaria vocês, que estão neste blog para obter conteúdo técnico. Mas neste caso é relevante, porque a intenção é dizer que eu faço isso porque gosto. Nunca ganhei um centavo com o trabalho social que desenvolvo fora da área de TI.

Há alguns anos recebi um chamado do amigo, então desconhecido, Renato Haddad, para escrever na antiga MSDN Magazine, hoje .Net Magazine. Ele era editor, e eu atendi o chamado. Fui descobrindo que havia uma área gigante de trabalho comunitário que envolvia conhecimento na minha área profissional, peloa qual sou apaixonado. Esse foi o começo deste trabalho. Comecei com artigos, mas daí pra palestras, podcasts, e comunidade foi um pulo. Em alguns momentos eu fiquei absolutamente sobrecarregado de trabalho, e isso só melhorou de verdade quando comecei a trabalhar por conta própria como consultor independente. A partir desse ponto passei a fazer os meus próprios horários, e tinha mais tempo pra me dedicar à comunidade, já que não havia uma consultoria entre o meu dinheiro e eu. O valor/hora mais alto me permitiu trabalhar menos. Desde o começo, eu comentava com o Rodolfo Roim, antigo MVP lead e amigo, que isso iria ajudar muito, porque finalmente eu poderia fazer as coisas que gosto sem precisar me matar. Ao abrir a Lambda3, em conversa com o André Dias, Felipe Rodrigues, e Victor Hugo Germano, deixei claro que eu não abriria uma empresa se isso significasse parar de trabalhar com a comunidade, e fiquei muito feliz que o ideal deles era exatamente o mesmo. O André estava ainda na Microsoft, e com menos tempo do que gostaria para se dedicar, algo que mudou quando abrimos a empresa. O Felipe e o Victor estavam também envolvidos com atividades diversas das comunidades que participam. Tudo batendo, abrimos a empresa, e os valores de comunidade, não remunerados e 100% altruístas estavam na base da empresa, que só acabou sendo criada porque todos compartilham deles.

No meio deste caminho fui nomeado MVP. Em grande parte porque criei o .Net Architects, mas também pelas palestras, podcasts, eventos organizados, webcasts, artigos e várias outras atividades que realizo. Era algo que eu queria? Era. Era o motivo de eu estar trabalhando para a comunidade? Não, como eu disse, faço isso há 20 anos. Se meu único objetivo fosse o MVP, não teria trabalhado na organização do AgileBrazil ano passado, e não repetiria isso este ano, já que não há nenhuma ligação direta entre este trabalho e nenhum produto da Microsoft, e não faz sentido listar a organização como contribuição para o MVP, apesar de ela me tomar muitas e muitas horas no ano. Dito isso tudo, primeiro ponto:

Ser nomeado MVP deve ser consequência de um trabalho realizado, não o objetivo deste trabalho.

Porque estou contando pra vocês isso tudo? Porque tenho recebido diversas reclamações de membros da comunidade. Muito dizem a mesma coisa, mesmo não se conhecendo: tem gente trabalhando pra ser nomeado MVP. Tem gente tentando roubar o sistema pra ser MVP. Como seria possível driblar o sistema? Eu acho muito difícil, ainda mais quando o Rodolfo Roim era MVP Lead, já que ele era muito preocupado em nomear e manter pessoas verdadeiramente interessadas. Mas isso não impede as tentativas.

Algo que ouço recorrentemente é a criação de comunidades. A pessoa acredita que se criar uma comunidade vai virar “líder de comunidade”, ser convidada para o Community Zone, fazer um networking, e pronto: está a um passo de ser nomeada. Só que não funciona assim, uma comunidade atende a um anseio, ela existe porque as pessoas precisam dela, já estavam dispostas a fazer parte dela, mesmo antes dela existir. Quando ela surge, as pessoas se aglutinam em volta dela. Podem observar como funcionou nas comunidades de verdade que estão por aí faz alguns anos, como o Codificando e o .Net Architects. Posso falar pelo .Net Architects: ele surgiu porque eu queria falar mais de arquitetura com pessoas que trabalhavam com a mesma tecnologia que eu. Eu nunca quis criar uma comunidade, aliás, se uma já existisse, eu iria me unir a ela, algo que deixei muito claro no post que deu origem à comunidade. Como não existia, eu puxei a criação junto com pessoas que se tornaram depois minhas amigas, mas que até então eram meros conhecidos, ou nem isso. E desde sempre eu disse que a comunidade não era minha, mas que eu estava só puxando pra que ela existisse. Nada foi escolhido por mim, mas por todos: nem o nome, nem o site, nem o nome do evento anual, nem os nomes dos líderes, nem como seria o podcast, nem nada. A comunidade é a dona do .Net Architects, não eu. E se um dia eu estiver muito ocupado e não puder continuar me dedicando a ela, ela vai continuar existindo, e eu passo todas as chaves aos líderes que já temos, líderes, aliás, que já compartilham de praticamente todas as chaves.

O Codificando me parece a mesma coisa, quem puxou e em grande parte continua puxando a comunidade é um grupo de amigos, interessados em trocar conhecimento.  São dois exemplos de verdadeiras comunidades, não de sites pra fazer personalidades. Meu segundo ponto, então:

Comunidades técnicas existem por uma demanda real de uma comunidade real, e não para servir ou promover alguém.

Qualquer comunidade que não atenda essa premissa vai existir por pouco tempo, e vai sumir, como já aconteceu tantas vezes.

Aprendi uma coisa com um líder de um trabalho social que eu realizava: se alguém quer fazer algo, deixe fazer. Os líderes são incapazes de tocar tudo, eles atuam às vezes como executores e às vezes como facilitadores. Temos que estimular as pessoas a tornar a comunidade maior ou melhor, a trazer novas ideias. Assim surgiu o podcast do .Net Architects, e o dojo. Pessoas queriam fazer, perguntaram pra mim, eu só disse: eu não tenho tempo de puxar, mas se você puxar eu ajudo e apoio. Elas fizeram, puxaram, lideraram. Eu apoiei, ajudei, estive presente. Novas iniciativas surgiram, muito além do que eu conseguiria fazer sozinho, ou gostaria, ou idealizaria. Aí vem então meu terceiro ponto, já antecipado:

Antes de criar uma nova comunidade técnica, veja se já não existe outra que atende o que você quer ou onde você pode crescer a ideia que tem.

Por fim, entendo que não deve haver competições entre as comunidades. Já palestrei pros Raptors, estou sempre junto do pessoal do Codificando, já estive no Pantanet, no DevIsland (BH), entre vários outros, e é sempre um prazer estar com eles. E quero que eles estejam junto do .Net Architects. Me considero participante de todas elas, ainda que eu atue mais no .Net Architects. São todos meus amigos, quero parceria e ajuda de todos, e ofereço minha ajuda e parceria a todos. Meu objetivo nunca foi fazer do .Net Architects um grupo grande ou maior que os outros, mas um grupo capaz de trocar informações relevantes sobre arquitetura. Se pudermos influenciar para tornar o ambiente de trabalho para todos melhor, explicando a importância da arquitetura de software, excelente! É por isso que comemoramos quando ganhamos mais membros, esse é o único motivo. Assim, meu quarto ponto:

Não existe a sua comunidade ou a minha comunidade. Existe a comunidade de desenvolvimento de software. São apenas divisões de participação da comunidade maior. Todas devem trabalhar como se fossem parte de um grupo único, sem exclusividades ou exclusões.

Isso inclui pessoas que trabalham com tecnologias diferentes, como a comunidade GURU, que trabalha com Ruby, ou o GUJ, que trabalha com Java. Estar com eles também é muito legal, e sempre cresço quando estamos juntos. Se com eles é legal, imagina encontrar as comunidades regionais, ou as especialistas, como WCF ou Silverlight, ou qualquer outra de .Net?

Pra concluir então: vamos trabalhar juntos para melhorar a nossa profissão. Vamos comemorar os avanços das nossas comunidades porque são avanços da nossa profissão, e não porque estão maiores que uma suposta comunidade concorrente. Vamos trabalhar nossa influência para melhorar o ambiente de trabalho e o conhecimento geral, e não por autopromoção. E vamos ficar atentos para tentativas de transformar o trabalho gratuito e comunitário em atividade focada em resultados financeiros ou autopromoção, e minar estas tentativas se elas existirem.

É uma chamada que eu faço a cada um de nós.