WebYES! Internet Re-think

Um dos desafios apresentados às empresas e governos que hoje adotam
GNU/Linux e as tecnologias abertas é, sem dúvidas, como estabelecer um
processo de desenvolvimento sustentável de softwares livres.

Como regra geral, os programadores de software participam
voluntariamente de projetos Open Source e, dependendo de suas
contribuições, envolvem-se com mais ou menos profundidade no projeto do
sistema e em sua estrutura de tomada de decisões. Estes projetos nascem
e organizam-se naturalmente. A participação no projeto do software é
voluntária e, a princípio, não prevê recompensas financeiras a seus
participantes. Ao contrário de projetos de software tradicionais, os
projetos livres não começam analisando as necessidades dos usuários
finais, mas partem de uma idéia ou solução de um problema específico
que um desenvolvedor resolveu implementar. O projeto começa com a
publicação de seus objetivos e um código fonte original, base da
solução. Se o projeto mostrar-se interessante, mais desenvolvedores
aparecerão e se juntarão à equipe do projeto. Se o projeto cresce,
provavelmente organiza-se uma estrutura na qual existe um mantenedor ou
uma equipe núcleo, que é responsável por fazer as decisões críticas a
respeito do futuro do projeto. Em uma estrutura assim, existem diversas
formas de colaboração no projeto, desde pessoas que apenas fazem testes
e sugerem novas funcionalidades, passando por pessoas que apenas
corrigem bugs ou documentam o projeto, até chegar àqueles que
verdadeiramente escrevem o sistema. As formas de comunicação preferidas
são o e-mail, listas de discussão e salas de conversação IRC (Internet
Relay Chat).

A comparação entre um bazar e a construção de uma catedral é comumente
usada como exemplo para ilustrar este tipo de desenvolvimento
colaborativo. Nesta comparação, o desenvolvimento de softwares livres
se assemelha muito à organização de um bazar.

Na sua obra entitulada “A Catedral e o Bazar”, Eric S. Raymond defende que:

Dada uma base grande o suficiente de beta-testers e co-desenvolvedores,
praticamente todo problema será caracterizado rapidamente e a solução
será óbvia para alguém. Ou, menos formalmente, “Dados olhos
suficientes, todos os erros são triviais.” Eu chamo isso de: “Lei de
Linus”. Minha formulação original foi que todo problema “será
transparente para alguém”. Linus objetou que a pessoa que entende e
conserta o problema não é necessariamente ou mesmo freqüentemente a
pessoa que primeiro o caracterizou. “Alguém acha o problema,” ele diz,
“e uma outra pessoa o entende. E eu deixo registrado que achar isto é o
grande desafio”.
Está claro que ninguém pode codificar desde o início no estilo bazar.
Alguém pode testar, achar erros e aperfeiçoar no estilo bazar, mas
seria muito difícil originar um projeto no estilo bazar. Linus não
tentou isto. Eu também não. A sua comunidade nascente de
desenvolvedores precisa ter algo executável e passível de testes para
utilizar.

Quando você começa a construção de uma comunidade, o que você precisa
ter capacidade de apresentar é uma promessa plausível. Seu programa não
precisa funcionar particularmente bem. Ele pode ser grosseiro, cheio de
erros, incompleto, e pobremente documentado. O que não pode deixar de
fazer é convencer co-desenvolvedores em potencial de que ele pode
evoluir para algo realmente elegante em um futuro próximo.

Isso significa que um dos pontos iniciais para o desenvolvimento de um
modelo auto-sustentável de negócios em software livre é a existência de
uma comunidade interessada no constante desenvolvimento dos produtos
livres e lideranças naturais dentro destes projetos. A partir daí, é
preciso estabelecer um relacionamento empresa-comunidade de forma em
que todos saiam ganhando. As empresas podem decidir por exemplo
contratar desenvolvedores de software livre para customização interna
dos seus projetos, e os permitir colaborar paralelamente com outros
projetos Open Source. O importante dentro de uma empresa “amiga” da
comunidade é que ela saiba reconhecer o valor de seus colaboradores
e/ou eventuais voluntários de projeto, ao mesmo tempo em que devolve à
comunidade o produto (ou ao menos uma boa parte dele) final deste
esforço conjunto, para que o ciclo de desenvolvimento colaborativo
continue funcionando de forma saudável.

Filed under: asl, floss, business, aemp, article, pt-br