• Aucun résultat trouvé

CHAPITRE 5 GESTION DU TEMPS DANS LES SIMULATIONS

5.3 L ES POLITIQUES DE GESTION DU TEMPS DES SMA

5.3.2 Les modèles à pas de temps : simulation dirigée par l'horloge

O perfil da comunidade Noosfero, como já vimos, é de poucos desenvolvedores ativos, em comparação com grandes comunidades de centenas e até milhares de desenvolvedores e além disso, é uma comunidade com organicidade fraca, já que é formada por organizações autônomas que se relacionavam em torno de um Comum de software. Por

91

conta disso, seria esperado que o tipo de pressão pública teorizado pelos autores fosse mais raro de acontecer. E foi isso que vimos na análise dos dados:

Nunca tinha pressão não. Acho que pela própria forma que a comunidade que ela se dá né. Aquilo que eu coloquei que ela nunca teve uma, digamos assim, uma estrutura de comunidade autônoma realmente. Então, todo o trabalho que é feito na comunidade, que não seja proveniente de investimento de alguns dos agentes, ele é assim específico um trabalho de um cliente (Entrevistado 4, Commiter/RM, Colivre, [34037:37115]).

Além de ter sido mais raro esse tipo de tática, ela ficou concentrada no momento em que ainda não havia uma participação maior das outras organizações da comunidade - além da Colivre - no grupo central de commiters. Nessa fase, houve casos de envio de mensagens com cobranças na lista de emails da comunidade - que era o canal em que todos os desenvolvedores participavam - direcionadas principalmente à Colivre, que era a organização que concentrava o papel de incorporar código na raiz principal. Ao relatar esse tipo de pressão, os membros apontam duas abordagens diferentes, uma mais agressiva - que é a que cabe aqui na tática de pressão na audiência - e outra mais sutil que vamos classificar mais adiante na tática “alertando o core”:

Mas tinha gente que mandava na lista, exigindo, que aí normalmente os que mandavam na lista tinha um outro perfil, uma outra forma de falar. No privado era um “na moral aí”, na lista era “que merda, já tem tanto tempo que meu negócio tá lá e não tá feito!”. Obviamente você recebe de forma diferente cada pedido, uma coisa é pedir com jeitinho outra é pedir com jeito bruto (Entrevistado 2, Commiter/RM, Colivre, [29886:30252]).

A pressa - e a consequente angústia - em ter rapidamente sua contribuição aceita podia ser gerada tanto pela demora em ter a nova funcionalidade ou correção disponível para os usuários (quando a Colivre, principalmente na primeira fase da comunidade, administrava algumas das instâncias de Noosfero) ou pelo fato do desenvolvedor já ter feito uma cópia do código (fork), incorporado e já estar utilizando a sua atualização no seu projeto, mas a árvore principal ainda não refletir essa atualização. Como o acesso ao código é ilimitado, qualquer desenvolvedor poderia fazer o que quiser dentro do seu projeto, sem precisar pedir permissão para o grupo de commiters. Ainda que nesse caso a demora não impedisse o desenvolvedor de entregar a solução para os seus usuários, por outro lado gerava a angústia de estar com uma versão diferente do resto da comunidade. Isso é angustiante pois significa trabalhar com a certeza de, num futuro próximo, ter de enfrentar uma enorme dificuldade para ressincronizar

92

as bases de código. Esse dilema é bem explicado nessa saborosa explicação de um dos desenvolvedores do Noosfero:

A ideia positiva do fork é que essa divergência, ela é temporária e rápida né, a medida que passa a integrar código novo. Então, a gente sabia que sempre ia ter um atraso né, o nosso código ia sempre tá divergindo, mas que a gente sempre poderia diminuir ou minimizar esse atraso. [...] Porque o que acontece é que se você começa a atrasar muito, dois, três meses, aí isso causa conflito. Isso gera uma angústia gigantesca no desenvolvedor. É, ele se sente que se separou, sabe! Uma separação assim de um homem e de uma mulher e agora ele não tem mais como conversar. O código, ele não se junta mais. É como se você não pudesse mais transar com a pessoa porque agora você não tem um mínimo de diálogo com ela, sabe! Não tem um mínimo de química com ela, então, é isso, você não pode ficar muito longe. Você tem de manter essa distância controlada, sabe! E quando você não tem acesso ao código, a separação é iminente. [Quando eu mantinha uma instância de Noosfero e ainda não era commiter] era tão dramático que você desfocava né, você começava a desenvolver menos, você começava a ficar preocupado na hora de desenvolver: “Por que eu tô fazendo isso, mas esse código eu não tenho perspectiva nenhuma dele entrar. [...]”. Entendeu? Na hora, “Esse código aqui não vai entrar mesmo”, você já perde as esperanças. Então, por isso é que a gente fazia a briga política, para não perder as esperanças assim, sabe, no próprio Noosfero, no próprio código que a gente tava fazendo. Porque se a gente não brigasse politicamente para que um dia esse código voltasse, o próprio desenvolvimento do Noosfero perdia sentido, sabe! Você nem tava mais no Noosfero, você tava em outro software que você tinha até que dar outro nome pra ele, sabe. [...] Porque já não é sincronizado mais, você tem de dar um outro nome, sabe! (Entrevistado 5, Commiter, EITA, [31335:34321])

Os membros que optaram por fazer um fork do código, também abordavam de duas formas, uma pressionando e outra tentando sensibilizar de forma mais sutil a comunidade e os commiters da importância de incorporar aquela atualização:

Porque por exemplo quando alguém contribuiu com alguma coisa e não foi pro master, só que a pessoa já lançou a versão dele com fork, e aí a tentativa normalmente era que o fork não ficasse muito forkado, que a gente não se afastasse muito do principal. Por exemplo, estou lembrando de dois casos, de dois grupos, um eles faziam essa pressão, até pública, de um jeito complicado, como se quisesse arranjar confusão, querendo incomodar mesmo. Enquanto que tinha um outro que fazia, olha eu to fazendo aqui, se vcs quiserem tá aqui depois eu me responsabilizo. Que eu achava até mais interessante, porque você não tem como obrigar alguém a fazer alguma coisa porque não é seu funcionário. Então teve as duas abordagens (Entrevistado 2, Commiter/RM, Colivre, [31266:32106]).

No geral, salvo alguns incidentes dessa primeira fase da comunidade, os membros não apontaram o uso da tática da pressão na audiência como uma prática comum da comunidade

93

Noosfero. Os caminhos escolhidos tendiam a ser outros, mais sutis ou de articulação política com os membros, como veremos a seguir.