[Rio-pm] (Woodstock|Mojo) && Forks (des)?necessários

breno breno em rio.pm.org
Quinta Dezembro 13 11:35:41 PST 2007


Eu vi muita briga em relação a isso na época que o pessoal do OpenBSD
decidiu fazer fork do apache, pq segundo eles já estavam cansados de
enviar patches para a Apache Foundation e os mesmos nunca serem
aceitos. No entanto, foi só eles dizerem isso que apareceram pessoas
que assinavam a lista do OpenBSD e trabalhavam na Apache, e disseram
que absolutamente *todos* os patches enviados que consertavam
problemas haviam sido aplicados e respondidos, mas que o projeto
OpenBSD, pelo contrário, aplicava as coisas em sua própria árvore sem
notificar o povo da Apache.

Ficou por isso mesmo, e agora o projeto do OpenBSD tem seu próprio
fork do apache 1.

Eu particularmente não gostaria de ver criados "competidores" de
módulos meus no CPAN (ou de qq outra pessoa, na verdade) sem que antes
tenha havido contato direto entre os desenvolvedores e uma tentativa
de o que quer seja que um não tenha gostado (ou queira
mudar/adicionar/consertar) no módulo do outro fosse antes implementado
no módulo original, com os devidos créditos (e não estou falando de
esperar 1 semana, ou de mandar apenas 1 email). Caso realmente não
seja possível (devido a questões de arquitetura ou até da própria
ideologia do módulo/autor original), aí sim seria criado um projeto
concorrente, com a bênção do próprio módulo original.

Isso pra mim é trabalho em comunidade. Isso pra mim é competição
saudável. Isso pra mim daria um sentido realmente positivo ao
TIMTOWTDI no cpan.

Mas é só a minha opinião.

[]s

-b

On Dec 13, 2007 4:55 PM, Blabos de Blebe <blabos em gmail.com> wrote:
> Nesse caso, particularment eu discordo do fernando.
>
> Uma coisa que eu ouvi no mundo windows e que dentro de um certo contexo
> até faz sentido, foi, que abre aspas, o softare livre nunca vai ser
> tão bom quanto
> o proprietario, pq no proprietário as empresas focam em um único objetivo e no
> software livre, cada um atira pra um lado, fecha aspas.
>
> Quem me falou isso tava viajando na maionese, mas num certo contexto tem até
> razão. Como o edem falou, em comunidade, temos que fazer concessões, e o fato
> de não conseguir isso pode (no sentido de talvez) significar que o
> cara nunca esteve
> envolvido com a comunidade de fato, e não pode abandonar a sua própria vaidade.
>
> De qualquer forma, falar isso é muito fácil, ao passo que fazer é
> muito difícil. Eu
> provavelmente faria o mesmo, o que hoje considero inadequado...
>
> Por outro lado, existem inúmeros exemplos de forks bem sucedidos, como
> o free BSD
> e o open BSD. (geraldo que me corrija)
>
> Gênios são bons o suficiente para fazer duas vezes algo bom, mas eu
> preferiria que
> eles fizessem algo duas vezes melhor.
>
>
>
>
> On Dec 13, 2007 1:07 PM, Fernando Oliveira <fernandocorrea em gmail.com> wrote:
> > Eu acho q ter opções sempre é bom... E como estamos falando de softwares
> > livres, uma coisa boa implementada num fork pode ser facilmente migrada para
> > o projeto original, com isso os 2 projetos avançam, e todo mundo ganha.
> >
> > Em 13/12/07, eden <edencardim em gmail.com> escreveu:
> >
> > > On Dec 13, 2007 12:54 AM, Breno G. de Oliveira <breno em clavis.com.br>
> > wrote:
> > > > Pessoal,
> > > >
> > > > no CONISLI desse ano eu estava conversando com o Lorn a respeito de um
> > > > dos autores do Catalyst, o Sebastian Riedel, ter abandonado o projeto
> > > > "para consertar uma série de erros de design feitos no Catalyst",
> > > > inciando um novo framework Web chamado Woodstock e depois renomeado
> > > > Mojo. O mesmo Sebastian iniciou o Catalyst como um fork do Maypole
> > > > (onde também era desenvolvedor ativo) pq "não gostava do rumo que o
> > > > framework estava tomando".
> > > > A fonte é um artigo de 2006 do Dave Cross[1], que critica a postura da
> > > > comunidade Perl em fazer forks e implementações independentes sempre
> > > > que alguém não está inteiramente satisfeito com algum módulo ou
> > > > framework (ao invés de contribuir para o mesmo), associando a enorme
> > > > quantidade de opções a mais dúvidas e novas implementações, ou até ao
> > > > abandono de soluções Perl em detrimento de soluções unificadas em
> > > > outras linguagens (no caso do artigo, ele se referia ao Rails).
> > > >
> > > > Procurando por aí eu não achei mais nenhuma informação sobre o tal
> > > > Woodstock|Mojo, exceto links vazios. Também parece não haver nada
> > > > relacionado a isso no diretório dele no CPAN[2], que continua cheio de
> > > > módulos e plugins do Catalyst e alguns até do Maypole. Teria ele
> > > > mudado de idéia? Alguém sabe mais sobre o assunto?
> > > >
> > > > E o que vcs acham dessa questão? Mais opções independentes ou mais
> > > > flexibilidade dentro da mesma opção?
> > > >
> > > > Eu particularmente acho que isso tem muito a ver com adicionar ao
> > > > "existe mais de uma maneira de se fazer isso" um sufixo como "...mas a
> > > > maneira recomendada é essa". Já dizia o Conway: "algumas maneiras são
> > > > melhores que outras", e o sucesso de livros como o Cookbook mostra que
> > > > muitos programadores se sentem perdidos com a flexibilidade do Perl.
> > > > Sei que isso é de propósito e está intimamente relacionado com o
> > > > perfil da comunidade, mas queria saber o que vcs pensam sobre o
> > > > assunto mesmo assim. :-)
> > >
> > > Como qualquer outra coisa na vida, você precisa participar da
> > > comunidade pra obter sucesso dentro dela. E viver em comunidade requer
> > > que façamos concessões como indivíduos. E é essa dicotomia inidivíduo
> > > x sociedade que sempre manteve a socidade girando. Eu acho que a
> > > opinião do Brian Ingerson serve para equilibrar essa opinião do Dave
> > > Cross:
> > http://search.cpan.org/~adamk/Module-Install-0.68/lib/Module/Install/Philosophy.pod
> > >
> > > --
> > > edenc.vox.com
> > > _______________________________________________
> > > Rio-pm mailing list
> > > Rio-pm em pm.org
> > > http://mail.pm.org/mailman/listinfo/rio-pm
> > >
> >
> >
> >
> > --
> > []'s Fernando
> > _______________________________________________
> > Rio-pm mailing list
> > Rio-pm em pm.org
> > http://mail.pm.org/mailman/listinfo/rio-pm
> >
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>


Mais detalhes sobre a lista de discussão Rio-pm