| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Como referido no texto, o método de desenvolvimento Open Source inerentemente é mais vantajoso porque:
- o código está disponível a qualquer e, como tal, e embora isto pareca desprezável, nós gostamos de fazer código eficaz e eficiente que o próximo não possa atirar críticas. Como tal, é empregue um maior cuidado e dedicação, e também abstracção, a escrever código Open Source;
- toda a gente pode participar; Ora, se o ditado popular "duas cabeças pensam melhor que uma" se aplica, então publicar um código aberto e contar com a ajuda de terceiros é sempre vantajoso;
- geralmente o código aberto, e aqui mais especificamente software livre, recorre a ferramentas livres e disponíveis a todos. Assim, se eles implementarem o protocolo XPTO, sabemos que não vamos estar dependentes de terceiros. Algures nos confins de um site deverá estar a documentação do protocolo;
Julgo que haverão bastantes mais vantagens, mas apenas enumerei estas que considerei cruciais.
Relativamente ao closed source, penso que a estrutura aberta do open source também trás desvantagens, isto é:
- se o código está mal escrito e não houve ninguém para o corrigir, uma passagem na vertical pelo código pode revelar bugs que podem servir de fáceis exploits. Embora um dump do binário "faça o mesmo", ler opcodes e código asm não é tão fácil e intuitívo como lêr um pedaço de linhas em C, Java, put your favorite flavour here. Ora, o facto de estar closed esconde eventuais erros..
De realçar também que é mais fácil cometer ilegalidades no closed source, como incluir código patenteado não licensiado, sujeito a punição, sem que seja facilmente detectável.
Em suma, e como forte apoiante do software livre, recomenda-se de boa saúde a escrita de software mediante a licença GNU/GPL :-)
Dominus vobiscum |
| | | | | | "Em suma, e como forte apoiante do software livre, recomenda-se de boa saúde a escrita de software mediante a licença GNU/GPL :-)"
Não sei se percebeste, mas o artigo em causa não é sobre isso. Ora lê:
"The Open Source tools do not require that someone release their code to the public. Somehow and somewhere someone got the notion that Open Source development meant that everything had to use one of the many open source licenses. Again that's a misconception. Anyone can use Open Source development tools and processes to create proprietary software. You do not have to release the code or the executables."
|
| | | | Noto uma desvantagem no Open Source. Não me parece que seja intrínseca ao modelo no entanto:
Tipicamente a compatibilidade entre versões não é a melhor. No closed source isto verifica-se mais. Falo por exemplo de BDs closed source e em contraponto do PHP.
Diria que a forma distribuída de desenvolvimento facilita que haja alterações mais radicais e não compatíveis com versões anteriores, talvez por não haver uma entidade centralizadora e fiscalizadora que garanta o rumo das versões.
Cumprimentos.
|
| | | | Boas.
"Tipicamente a compatibilidade entre versões não é a melhor."
R.T.F. Changelog. :-)
@183, Nbk
|
| | | | "
Tipicamente a compatibilidade entre versões não é a melhor. No closed source isto verifica-se mais. Falo por exemplo de BDs closed source e em contraponto do PHP."
Mas quem precisa de compatibilidade binária se temos os fontes para recompilar ? Esta é a beleza do código aberto, que não restringe as inovações que quebram compatibilidade retroativa.
Por causa da manutenção de compatibilidade binária (afinal o monopólio tem que ser mantido) a M$ não pode resolver grande parte dos problemas dos seus produtos...
O único efeito colateral que vejo é com aplicativos comerciais para linux. Eles tendem a "quebrar" em pouco tempo, quando a glibc muda. Mas nesses casos bastaria que o fabricande fornecesse uma atualização, feita a partir de uma recompilação.
|
| | | | Ele não estava a falar de compatibilidade binária. Estava a falar de formatos, APIs, etc.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | | Eis o que se chama a cunning point! No entanto parece mal enquadrado. O problema da incompatibilidade relaciona-se mais com a "liberdade" do projecto que pelo modelo de desenvolvimento (open/closed). Ou seja, se um dado projecto é open source, não pago e sem suporte oficial, é provável que os responsáveis pelo seu desenvolvimento tomem as decisões que lhe apetecerem , incluindo quebras de backward compatibility. No entanto podes ter projectos opensource onde isso não se verifique. Esta situação acontece sobretudo quando há suporte oficial desses produtos, ou quando existe um certo grau de maturidade da comunidade envolvida nos mesmos. No primeiro caso, temos os exemplos do Mozilla fire/thunderbird (importa bookmarks e mails do netscape4, por exemplo) e Openoffice. No segundo caso temos o exemplo do python, que apesar de ter evoluído um bom bocado desde a 1.5 (quando eu lhe peguei), ainda se mantém quase totalmente fonte-compatível com a actual 2.3.2. Claro que os exemplos de quebras de compatibidade associados ao opensource são muito mais e significativos (linux, agora tb o eclipse, perl, php, ...) o que leva a associar os dois conceitos.
|
| | | | Julgo que a incompatibilidade mesmo a nível de API's e formatos não se deve tanto ao facto de ser opensource ou closed source, mas:
1) ao facto de a maioria dos grandes projectos opensource serem relativamente "jovens" quando comparados com alguns projectos closed source, que já têm um tempo de vida razoável e já amadureceram bastante.
2) ao facto de alguns projectos opensource terem mesmo que criar imcompatibilidades para poderem evoluir, o mesmo acontecendo com projectos closed source como, por exemplo, o Windows o Office, etc.
3) o facto de o closed source ter uma tendencia a estabilizar mais depressa prende-se com o facto de ser geralmente comercial, e estar a ser feito por profissionais, que são pagos para o fazer mesmo, e que têm que logo à partida planear tudo muito bem.
Não me parece que se trate de uma associação rígida, mas o facto de numa forma estabilizar mais rapidamente que na outra é apenas uma curiosidade estatística graças à forma como ambos os modos de desenvolvimento são usados na sua maioria.
Se repararem bem, o próprio Windows entre versões transformou-se várias vezes incompátivel entre transições. E o mesmo continua a acontecer hoje em dia, pois há programas que corriam, por exemplo, no 2000 e não correm no XP. E quanto à mudança de formatos de ficheiros, nem se fale.
|
| | | | Queria só deixar um testemunho relativamente ao Closed Source e particularmente às suas etapas de desenvolvimento.
Trabalho numa empresa que recentemente foi adquirida por uma multi-nacional, e claro está o departamento de informática foi informado das novas políticas do grupo. A nova política involve o uso de um framework em java baseado num application server, ora que acontece é que o framework apesar de estar bem estruturado é enorme e fazer uma qualquer implementação de um protótipo por exemplo requere o uso -- ou direi mesmo abuso -- de cerca de 6 ferramentas diferentes, desde geradores de xml, scripts e extensões para IDEs Java que deixam muito a desejar. Ou seja, temos algo técnicamente válido, mas que no fundo é um polvo de software que agarra o nosso pescoço de programadores limitando a criatividade e pior a expediência da nossa produtividade.
Uma das minhas critícas vai directa ao aspecto de refactoring do framework pois este basicamente... não o tem. A resposta da multi-nacional perante factos concretos de como o refactoring era uma tarefa complicada foi, "bem, é suposto terem a fase de ánalise completa quando forem para a implementação". O que traduzi para, "don't touch the code! try not too!! please!!!". Ou seja, o conceito de desenvolvimento iterativo, que é uma peça chave do Open Source é aqui desdenhado e é suposto sermos completamente visionários antes de implementarmos qualquer coisa. Para não falar nos requesitos de documentação...
Portanto se querem um bom exemplo de que às vezes aquelas caixas pretas nos acetatos de teoria de software é levado ao extremo e ao fanatismo absoluto, aqui o têm.
Para completar, e demonstrar porque é que eles podem ser os tais visionários da análise de software, o centro de desenvolvimento deles emprega duzentas (200) pessoas, e este framework levou três (3) anos a ser feito. Em comparação no meu departamento somos 4 tugas a bater código e sim, se aquele cliente especial pede um serviço web que pode render à empresa 6 mil contos por mês, então nós temos todo o gosto em fazer o web-service em 3 dias.
|
| |
|
