Marcus,

Sem querer responder perguntas sobre um projeto do qual não participo, mas ouso alguns comentários:
a) para quê gastar tempo em "definir métodos,processos de desenvolvimento", se eles já existem ? Refiro-me ao modelo de desenvolvimento BAZAR que JÁ É UTILIZADO pelos desenvolvedores de sofwtare livre; Talvez o que falte seja DOCUMENTAR OS RESULTADOS.
No mundo acadêmico, nunca nada está pronto. Nem no mundo profissional. Se dezenas de instituições e empresas se unem em torno de um projeto assim, é porque vêem não um desperdício de tempo, mas o potencial de melhorar metodologias para ganhar tempo, qualidade, resultados... Talvez (mas acho pouco provável), ao final dos estudos, concluam: o modelo Bazar é o bomzão! E veja só: Bazar pode ser até um modelo (mas lhe falta muuuuuito para isso), mas não é um método e nem de longe define processos... Sutilezas que não são nada desprezíveis..

Alguém poderia argumentar na mesma linha: estudar comparativamente as licenças de software livre para quê se todo mundo sabe que a GPL é a melhor e é aplicável sob qualquer legislação do mundo! [NO FLAMES HERE! É só um comentário hipotético!!!] :-)
b) para quê gastar tempo em "definir ... modelos econômicos que facilitarão o desenvolvimento 
do software livre" se tal modelo econômico já existe e é o modelo de SERVIÇOS. Talvez seja a 
velha dicotomia PRODUTO x SERVIÇO atacando novamente. Se me permitem, vou citar meu artigo 
novamente: "SCO x IBM: o que está em jogo ?" em 
http://www.comciencia.br/200406/reportagens/15.shtml
idem, idem. Serviço é um termo muito genérico. Há diversas variáveis que devem ser levadas em consideração ao modelar um serviço: clientela, produtos sobre os quais se vai trabalhar para prestar o serviço, parcerias, fornecedores, governo+impostos, RH, etc. Exagerando: não há 2 empresas de software livre com o mesmíssimo modelo de negócio baseado em serviços...
c) por fim, a expressão "no meio industrial" traz uma carga semântica que não ajuda muito: operários, máquinas, atividades mecânicas, chefia, limites espaciais e temporais, etc, e, por fim, CATEDRAIS. Sim, CATEDRAIS. PRODUTOS feitos dentro de organizações fechadas, ou, como o professor Ole Hanseth descreve:
Engraçado, no artigo que citas, não aparece nenhuma vez a palavra "industrial" nem "industry". O texto da ZDNet France (uma empresa de notícias) é que fala disso. Tenho um panfleto em inglês que apresenta o projeto Qualipso que fala se "industrial", mas não como o jornalista redigiu a matéria. Fala que o objetivo do projeto é levantar o "level of trust to make OSS development an industrial and widely accepted practice" (traduzindo, o nível de confiança para tornar o desenvolvimento de OSS em uma prática industrial e amplamente aceita". Veja a semântica de "industrial" aqui: é algo reproduzível, com capacidade de verificação de qualidade, produtividade, etc.
Algo que desperte a confiança dos clientes!

Vai na mesma linha que outras iniciativas parecidas, como o OpenBRR, por exemplo (http://www.openbrr.org - framework for evaluating OSS) Em função do FUD que se lança por aí, muitos potenciais clientes tem "medo" de abraçar soluções livres. Outros são limitados por regulamentação governamental e/ou interna da empresa: "só se pode contratar software de quem tem CMMI-5". Pronto. Danou-se...

Com um grupo de instituições de reconhecido prestígio dando apoio, fica mais fácil para grandes corporações confiarem nos processos e metodologias de desenvolvimento (mesmo naqueles baseados no modelo Bazar).
"in short: I[nformation] S[ystems] methodologies aim at developing a *closed system* 
by a *closed project organization* for a *closed customer organization* within a *closed 
time frame*."
Tirado de contexto, realmente parece um paradoxo.
Mas uma leitura atenta mostra que esta parte do artigo era uma constatação sobre os modelos tradicionais, ligados à engenharia de software "convencional". E é isso que o projeto vem contestar, baseado nas práticas do mundo livre.
Para quem quiser ler o artigo todo:

Hanseth, O., (2002), “From Systems and Tools to Networks and Infrastructures – 
From Design to Cultivation. Towards a Theory of ICT Solutions and its Design 
Methodology Implications.” Disponível em 
http://heim.ifi.uio.no/~oleha/Publications/ib_ISR_3rd_resubm2.html>. Acesso em: 
10 jan. 2007.
(...)
Fortes abraços a todos e desculpem-me o email longo.
Abraços também. É com emails que a gente se entende!

De Lucca
UFSC
Agradeço desde já às críticas e sugestões ;-)

Marcus Vinicius
"Havendo suficientes colaboradores,
Qualquer problemas é passível de solução"
Eric S. Raymond
A Catedral e o Bazar

"A melhor causa é sempre a próxima"
Evandro Lins e Silva
_______________________________________________
PSL-Brasil mailing list
PSL-Brasil@listas.softwarelivre.org
http://listas.softwarelivre.org/mailman/listinfo/psl-brasil
Regras da lista: 
http://twiki.softwarelivre.org/bin/view/PSLBrasil/RegrasDaListaPSLBrasil

Responder a