À medida que o código aberto se aproxima do dia-a-dia do mercado, vão ficando cada vez mais comuns os casos em que grandes empresas adquirem os direitos sobre projetos que trazem consigo comunidades já formadas de desenvolvedores (muitas vezes voluntários) livres.

Várias dessas empresas lidam suficientemente bem com as comunidades que herdam ou formam – basta ver o entusiamo dos membros das comunidades associadas a várias empresas.

Mas outras vêem as comunidades como ameaças à ordeira organização corporativa e estrutura de poder pré-existente, e aí conseguem fazer tudo errado, e o fazem tão caprichado, que até parece que é de propósito. E é sobre isso que a palestra de Josh Berkus (do PostgreSQL, e ex-Sun) na LCA 2010 tratou: “10 maneiras de matar uma comunidade Open Source”.

Ele fala por experiência própria: diz que a empresa em que trabalhou usava todas estas “técnicas”. E de fato eu reconheço várias delas.

Destaco algumas:

• Prover ferramentas difíceis para o pessoal do código aberto: build systems complicados, sistemas de controle de versão proprietários, um website baseado em um CMS frágil…
• Manter documentação insuficiente, incompleta ou ultrapassada, e mesmo assim mandar os interessados irem RTFM.
• Fazer reuniões de desenvolvimento a portas fechadas, excluindo o pessoal da comunidade.
• Mudar os termos de licenciamento e outros acordos periodicamente, se possível com pouco aviso.
• Escolher uma pessoa inacessível ou desinteressada para ser o elo de ligação.
• Adotar uma cadeia de aprovação difusa e confusa, impedindo que as pessoas saibam a quem se dirigir para propor alguma coisa.
• Permitir apenas a empregados da empresa o acesso de escrita aos repositórios oficiais. Se possível, fazendo com que pessoas que nem mesmo entendem do que se trata o código sejam responsáveis pelos commits.
• Manter-se em silêncio e simplesmente não se comunicar com os integrantes do projeto open source.

Quais as armas mais eficazes na sua opinião? Para mim, as de ferramentas e de documentação quebram as pernas dos interessados mais cedo, mas quando acontece de eles conseguirem superar estas barreiras, desenvolver algo interessante mesmo assim, e aí dar de cara no muro da propriedade intelectual cambiante, governança críptica e comunicação insuficiente, o fim da comunidade pode ser alcançado de forma bem mais definitiva – e há o bônus extra de isto alcançar também os usuários não-desenvolvedores… (via itwire.com)