Ensaio sobre a colaboração em rede

(version en español, traduzida por Maynar Patricia Vorga Leite y Ana Campo. gracias eiabel lelex!)

Um grupo de pessoas se encontra para compartilhar experiências e logo percebem que tem muitas ideias e objetivos em comum. O encontro é intenso e todas saem de lá determinadas a manterem contato e colaborarem em seus projetos. Todas voltam para os seus afazeres e, algum tempo depois, a única colaboração real que conseguiram foi criar uma lista de emails e compartilhar alguns links interessantes.

Você já viu isso acontecer? Eu já. Muitas vezes. E isso se aplica a Congressos, Fóruns, encontros de coletivos independentes, de empresas ou de cooperativas.

Por que a gente tem tanta dificuldade em criar canais reais de colaboração em nossos projetos com outras pessoas? É mais fácil organizar eventos e atividades que estejam fora do nosso dia-a-dia do que envolver uma colaboração externa no nosso trabalho cotidiano. Como criar uma rede de colaboração que de fato contribua para o trabalho de cada nó dessa rede?

Neste ensaio eu quero explorar um pouco a dinâmica das redes de colaboração, trazendo uma observação da prática das redes de desenvolvimento de software livre, que é a mais bem sucedida rede de colaboração aberta que existe. E fique tranquilo, não é preciso entender nada de software para acompanhar o raciocínio.

O desenho de uma rede

Normalmente, quando fazemos o desenho de uma rede, fazemos assim:

O que eu percebi observando algumas redes de colaboração é que a colaboração entre os nós nunca é uniforme e bilateral como esse desenho coloca. Na maioria das vezes uma parte está contribuindo com o projeto da outra. O que me parece é que na verdade existem dois tipos distintos de conexão entre os nós. Uma conexão de “ação” (), que colabora com outro nó  (ajudando em seu projeto, fazendo uma doação, enviando informações, etc…), e uma conexão de “recepção” (), que cria um canal de colaboração para que outros nós o ajudem. O desenho ficaria assim:

Minha impressão é que os nós que colocam mais esforço em criar uma conexão de recepção têm mais sucesso em receber colaborações que atuem diretamente no seu trabalho, porque colaborar com eles requer menos esforço.

Como disse, vamos começar pelo exemplo do Software Livre

Fazendo Software Livre

Ao contrário do que muita gente pode pensar, fazer um software livre não significa apenas disponibilizar o software e seu código fonte livremente. Se você quer apenas que as pessoas usem o seu software, isso pode funcionar, mas se você quer que outras pessoas colaborem com seu desenvolvimento, você precisa de muito mais.

Aqui estão algumas coisas que um desenvolvedor de software livre tem que fazer se quiser receber a colaboração de outros desenvolvedores:

  • Manter o código bem organizado e documentado
  • Manter um site para o software, com links para download, documentação e um canal de suporte
  • Manter o código em um repositório público, para que outros desenvolvedores tenham acesso
  • Internacionalizar o software, para que ele funcione em diferentes idiomas
Se você não fizer nada disso seu software vai funcionar do mesmo jeito. Você vai resolver o seu problema e pode até liberar sua solução para outras pessoas usarem, mas dificilmente alguém vai conseguir colaborar. E essas ações dão bastante trabalho. Vale até dizer que em alguns casos um desenvolvedor pode gastar mais tempo criando todas essas estruturas de colaboração (canais de recepção) do que realmente programando.
Ou seja, fazer software livre dá muito mais trabalho do que apenas fazer um software – esse é um ponto chave.

Pronto, chega de falar de software, vamos voltar as redes de colaboração como um todo.

Descomplicando a Colaboração

Se não existe uma forma clara de como colaborar com um projeto, muito dificilmente alguma colaboração acontecerá, mesmo se existirem pessoas interessadas em fazê-lo. Quando há um canal claro e facilitado de colaboração, ele atrairá colaboradores.

Outro dia fiz download de um disco que o próprio músico disponibilizava em seu site. Era um disco excelente e eu fiquei com muita vontade de retribuir o trabalho dele com uma doação. Mas como? Eu não o conheço, não sei onde mora, não sei seu email… Claro que eu poderia achar um jeito de encontrá-lo, mas a dificuldade do caminho que eu iria seguir me desencorajou e acabou ficando por isso mesmo.

Em outro caso semelhante, o músico informava no site uma conta bancária. Como a conta não era do meu banco, não queria pagar as taxas de transferência. Queria muito fazer uma doação para ele, mas não a ponto de ir a uma agência e enfrentar uma fila para doar R$15, R$20…

No primeiro exemplo, o músico, que certamente gostaria de receber por seu álbum, não abre nenhum canal de colaboração. No segundo, ele abre um canal muito estreito.

Da minha preguiça de mandar um email para o primeiro e ir a uma agência bancária no segundo, aprendemos uma lição: todos nós gostaríamos de colaborar com outras pessoas, mas o faremos a medida que isso não requeira um esforço desproporcional de nossa parte.

Mas isso não quer dizer que um tradutor, por exemplo, só vai colaborar com traduções fáceis e rápidas. O que isso quer dizer é que ele só vai colaborar em projetos nos quais ele chegue rápida e descomplicadamente ao que sabe e gosta de fazer: traduzir. Se ele tiver que mandar um email, pra falar com alguém, que vai mandar pra ele um texto em um formato ruim, e não está claro o que nem como ele tem que traduzir, isso vai desencorajá-lo. Agora, se existe um processo claro, onde ele rapidamente encontra o que e como traduzir, para onde enviar, etc. ele fará isso com prazer.

Basta dar uma olhada nas redes de tradução de filmes e séries estrangeiras, que publicam seus trabalhos em sites como o legendas.tv. Se alguém quer colaborar com alguma tradução existe um processo muito claro de como fazê-lo.

Da mesma maneira, um tradutor, que não é programador, consegue colaborar com a tradução de softwares livres de maneira muito descomplicada, através de sites que disponibilizam ferramentas muito simples para as pessoas irem traduzindo frase a frase.

Percebemos com os exemplos acima, incluindo o do software livre, que as principais funções desses canais de recepção são:

  • Minimizar o esforço necessário para que um colaborador entre na rede – deixando os caminhos claros e todas as informações necessárias facilmente acessíveis e;
  • Potencializar a colaboração, deixando com que o colaborador foque no que sabe e gosta de fazer – o programador vai gastar a maior parte de sua energia programando, o tradutor traduzindo, e assim por diante.

Mais exemplos

Fora da rede de computadores temos alguns exemplos, e adoraria, com a ajuda de outras pessoas, rechear este artigo de mais casos que não dependem da internet.

O Exército de Salvação é um exemplo extremo – talvez não na criação de redes, mas sem dúvida na capacidade de criar um canal de recepção. Em determinado momento, eles perceberam que doações de moveis, roupas e utensílios usados e a venda desses objetos em bazares beneficentes era uma boa fonte de receita para financiar seus trabalhos.

Há muito tempo eles tinham esse canal de recepção que era uma forma de receber doações. Até que em certo ponto eles resolveram ampliar ainda mais esse canal, criando toda uma estrutura de atendimento e retirada de doações. Quer canal de recepção melhor que esse? Se livrar de um sofá velho pode ser um problema e custar caro, ou você pode ligar que eles vem retirar na sua casa. Você colabora com eles, mas na verdade eles também estão te ajudando.

Claro que manter essa estrutura de atendimento, caminhões, carregadores, etc. custa caro também, mas certamente o número de doações aumentou o suficiente para justificar o investimento.

O foco do trabalho do Exército de Salvação não é retirar doações e fazer bazares. Tudo isso foi um esforço de criar um poderoso canal de recepção de colaboração.

Concluindo

Vocês devem ter percebido que deixei de fora deste ensaio um ponto fundamental para a colaboração: a motivação. Algumas pessoas colaboram por prazer, outras por status, outras por dinheiro, outras por ideais… Seja qual for a motivação, ela é irrelevante para essa análise, que considera que já temos uma rede de indivíduos motivados mas que, mesmo assim, nem sempre é bem sucedida por causa da falta de canais de colaboração.

Meu objetivo aqui foi o de explorar esses dois tipos de conexão em uma rede de colaboração e sugerir que é a partir dos canais de recepção que uma rede de colaboração se forma. Não adianta ter uma rede cheia de gente disposta a colaborar se não houverem canais claros de colaboração. (Claro que existirão exceções, e que colaborações espontâneas acontecem. Mas me refiro aqui a colaborações constantes e recorrentes).

Criar esses canais de recepção dá trabalho. Em alguns momentos pode até parecer improdutivo desviar esforço dos seus problemas para construir esses canais, mas eles são essenciais para que a colaboração aconteça. Encontrar o equilíbrio entre executar o trabalho do dia-a-dia e, ao mesmo tempo, investir energia na infra-estrutura de colaboração, é o desafio a ser vencido se quisermos realmente trabalhar em rede.

Ensaio sobre a colaboração em rede

10 comentários sobre “Ensaio sobre a colaboração em rede

  1. Iuri Guilherme disse:

    Tem exemplos bons de facilidade de encontrar meios para colaborar que são os sites de trabalho independente. O empregador tem facilidade de cadastrar uma necessidade, ou oportunidade de trabalho, e os profissionais tem facilidades para encontrar formas de colaborar, ou oportunidades de trabalho, de acordo com seus conhecimentos e interesses.

    Neste caso específico a motivação é exclusivamente o dinheiro. Os empregadores estão preocupados em gastar o mínimo possível para obter seus resultados, os profissionais estão preocupados em trabalhar no máximo possível de oportunidades para ganhar o máximo possível de dinheiro, e os administradores do site estão preocupados em criar novos meios de atrair mais pessoas para o site, já que todo o uso do site gera renda para a organização mantenedora do mesmo.

    E se estes modelos fossem adaptados para aqueles interessados em trabalhos voluntários e/ou cooperativos?

    Curtir

  2. Iuri Guilherme disse:

    “em alguns casos um desenvolvedor pode gastar mais tempo criando todas essas estruturas de colaboração (canais de recepção) do que realmente programando.”

    Eu tenho um caso assim 😀

    Estou desenvolvendo um software que eu considero muito útil para comunicação de redes para redes.

    Contudo meus conhecimentos de programação ajudam muito pouco ou absolutamente nada para satisfazer a intenção principal deste software: possibilitar o aprendizado e a colaboração de qualquer um interessado no projeto.

    Não é o caso de que o código não esteja claro. O software funciona muito bem, com poucos ou nenhum problema, até onde foi testado, e quando teve problemas foi muito rápido para encontrá-los.

    O caso é que se eu abrir o código hoje, e divulgar o software como ele merece, vou afastar muita gente que vai ficar com a primeira impressão do material que eu tenho pra apresentar, e mesmo que em um prazo curto eu consiga reformatar a estrutura do código e da documentação para facilitar a colaboração, já será tarde.

    Porque a funcionalidade do software é uma das minhas menores prioridades. Levei muito pouco tempo (algumas horas) para produzir a primeira versão funcional. Contudo estou enrolando e estudando há meses formas de disponibilizar o software e o código de forma que atinja os objetivos preconizados. E tenho a impressão de que divulgar da forma em que se encontra vai prejudicar este processo.

    Curtir

      1. Iuri Guilherme disse:

        Esse artigo da wikipedia ta horível, mas eu me lembro de ter estudado este método de distribuição. No artigo diz que o oposto deste método é distribuir softwares limpos, livres de bugs mas eles não se deram o trabalho de citar UM exemplo disto, e boa sorte pra quem tentar 😀

        De qualquer forma, a ideia mesmo não é apresentar um software livre de bugs, mas apresentar algo útil para a comunidade de software livre. Porque a versão para os usuários finais já está distribuída.

        Curtir

  3. Concordo contigo. Gosto muito do Lauchpad para tradução de software. Às vezes quando tenho 15 minutos livres, vou lá e traduzo umas strings. Não preciso permissão, não preciso ser avaliado por uma comunidade… Universal Subtitles, OSM e Wikipédia de certa forma seguem esses padrões.

    Talvez algo que deva ser discutido é sobre gerenciamento de colaboração. É necessário ter ferramentas eficazes para monitorar as modificações, se não fica muito difícil gerenciar a qualidade do que está sendo feito.

    A Wikipédia brasileira, como demonstrou alguns episódios acontecidos nos últimos anos, patina nisso, não por perder a qualidade do conteúdo, mas por punir as falhas de quem tá começando a editar com avisos ríspidos de que a página será apagada por falta de referências ou algum outro motivo. Seria melhor que os usuários mais experientes ajudassem a melhorar a página ao invés de ameaçar apagar. Isso desestimula a colaboração…

    No caso do OSM, há alguns dias descobri que um usuário novo fez edições na cidade em que moro. Adicionou alguns POI, colocou nomes em algumas ruas, mas também por engano, acabou bagunçando um trecho de uma avenida. Gastei cerca de uma hora pra corrigir os erros e depois mandei uma mensagem pra ele dando as boas vindas ao OSM, apontando os erros e me colocando à disposição para ajudá-lo a aprender mais sobre o projeto. Ele respondeu dizendo que havia deixado de editar porque já tinha percebido que havia cometido erros e ficou com medo de prejudicar mais o projeto, mas que agora estaria mais tranquilo em saber que alguém monitora as edições e que voltaria a editar o mapa. Gastei tempo, mas conquistei mais um colaborador para o projeto. Muito melhor que bloquear o usuário ou simplesmente desfazer as modificações que ele fez…

    Curtir

    1. Iuri Guilherme disse:

      E no caso dos foruns do Ubuntu, onde antigamente alguns usuários mais “experientes” (leia-se: pessoas acostumadas a utilizar Windows que recentemente aprenderam a utilizar o Ubuntu, e eliminaram o dual boot e agora só usam Ubuntu) criticavam e afastavam usuários de Windows que vinham apontar falhas no Ubuntu e relatar seus motivos de não conseguirem “migrar” para o software livre.

      Alguns destes usuários “experientes” foram advertidos pelos moderadores dos foruns do Ubuntu e a filosofia agora por lá já não é mais promover, é promover e atrair.

      Curtir

  4. Tati Prado disse:

    Oi, Leo

    Obrigada pelo texto, simples e esclarecedor. Eu não venho do mundo do software livre e, embora goste dos princípios que o fundamentam, sinto que ainda há uma dificuldade de muita gente envolvida nisso em perceber o que destacou aqui:

    Potencializar a colaboração, deixando com que o colaborador foque no que sabe e gosta de fazer

    Muitas vezes a perspectiva doutrinária e pouca sensibilidade para entender que as pessoas têm potenciais e interesses diferentes atrapalha mais até do que a falta de canais claros para a colaboração.

    Fica a sugestão prum próximo texto (já que esse tá bem bacana e dá vontade de ler mais reflexões tuas a respeito) – sobres os níveis ou camadas de colaboração possíveis, tendo em vista a diversidade de projetos e pessoas com as quais nos relacionamos nessa vida em rede.

    Um abraço!

    Curtir

Deixe um comentário