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

Quinta Dezembro 13 13:25:34 PST 2007

'Fork de projetos' no meu dicionário significa dispersar energia e ponto.
Tipo, porquê será que temos um milhão de gerenciadores de janelas no Linux ?
Mas precisamos entender porquê existem, e a minha opinião é de que existe
duas famílias de forks, a produtiva e a imbecil, sendo classificadas
motivadas :

Imbecil

* vaidade, o cara é um colaborador importante e acaba se achando maior que o
projeto onde ele está;

* dificuldade em sentir-se motivado com o projeto, isto me lembra da
apresentação da Audrey que mostrava como os 'hackers' perdem interesse em
algo rápido. Projeto relacionados com Perl tem enfrentado este problema, o
perlmonks por exemplo muito a classificação porquê em pouco tempo teríamos
mais santo do quê novatos, e os santos se sentem desmotivados a participar
(eu conheço alguns assim);

* dificuldade de relacionamento onde, ou pelo líder, ou pelo projeto, o
relacionamento fica muito difícil e até desrespeitoso. Me parece que esta é
a situação do Catalyst, onde os lideres não são necessariamente
embaixadores.

Produtivo

* mudança de foco. sempre que um fork nasce porque é necessário atender a um
novo foco, novas especificações de requisitos (hardware e/ou legislação)
e/ou perfil de consumo.

Forks que não são originados por questões produtivas, eu considero como
dissipação de energia [ou não, como diria o nosso ministro da cultura :)]. O
blabos já colocou parte da minha opinião então não vou me estender mais :).

Solli M. Honório

Em 13/12/07, Marco A P D'Andrade <mdacwb em gmail.com> escreveu:
>
> Blabos,
>
> Concordo com vc em 2 pontos...
>
> No texto descrito, e principalmente... discordar do Fernando :D
> (isto em geral termina em uma argumentação longa e produtiva)
>
> Acrescentando uma historia...
>
> Meu irmão, pcpa, trabalhou varios anos na conectiva, quase sempre
> focado no X, porém ele optou por fazer "trabalhos que ninguem quer"
> corrigindo bugs diretamente no X, e acrescentando recursos que fariam
> mais sentido estarem nesta camada, em vez de fazer isto nos
> gerenciadores de janela, que segundo ele são feitas no KDE, GNome, etc
>
> Um dos trabalhos que ele produziu foi o famoso driver vesa, para a
> virada do X 3.4.x para o 4.0 (que a conectiva/mandriva destaca até
> hoje).
>
> Só que isto tem muito a ver com postura da pessoa, a exemplo, ele não
> trabalha nem um pouco o marketing pessoal, pois do contrário estaria
> preferindo fazer um fork a cada novo projeto, pois isto traz muito
> mais evidência que simplesmente fazer uma correção e entrar na lista
> de N colaboradores...
>
> PS: estas informações estão sujeitas a erros de interpretação e
> memoria, pois me foram dadas a uns 4 ou 5 anos atrás!
>
>
> Sds,
> Marco Antonio
>
> Em 13/12/07, Blabos de Blebe<blabos em gmail.com> escreveu:
> > 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
> >
> _______________________________________________
> Rio-pm mailing list
> Rio-pm em pm.org
> http://mail.pm.org/mailman/listinfo/rio-pm
>

-- 
"o animal satisfeito dorme". - Guimarães Rosa
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: http://mail.pm.org/pipermail/rio-pm/attachments/20071213/7c52520d/attachment-0001.html 