Modificar código alheio pode ser difícil ou fácil. O pessoal do opensource "apregoa" que é fácil, porque o é na maioria dos projectos opensource.

Eu já tive de mergulhar no código de vários projectos opensource (para corrigir bugs que me irritavam particularmente) e nunca tive grandes dificuldades, mesmo em projectos com uma dimensão razoável como o Qt.

No mundo do software proprietário é provável que não seja assim, já que os métodos e os objectivos são diferentes. No mundo do opensource há muito mais interesse em ter uma boa organização interna e código claro, enquanto que no mundo proprietário isto só interessa até ao ponto em que começa a colidir com o "time-to-market" e a implicar custos mais elevados de desenvolvimento.

Leste o que eu escrevi? Eu tenho lá argumentos para a dificuldade de modificação de código alheio. Se não concordas com o que lá tá escrito então não sei o que dizer, podes sempre tentar argumentar.

Dizes que a modificação de código open source é fácil e por outro lado do software proprietário já não, com base em? Naquilo que tu achas? Nos teus ideais? Eu já mexi em N projectos open source e tenho uma opinião diferente. E agora? Quem é que tem razão? Por isto é que convém sempre argumentar as nossas *opiniões*.

Ha coisas basicas que dificultam muito a leitura do codigo. Maus comentarios, fraca organização do código, exagero na complexidade da implementacao de tarefas simples e também a forma de escrever código. É "normal" os programadores trazerem os vicios de outras linguagens para novas plataformas. Daí que eu penso que seja em opensource ou em empresas o problema é o mesmo. Depende da qualidade do codigo que se faz e da organização do mesmo, alem de claro a documentação.

"Dizes que a modificação de código open source é fácil e por outro lado do software proprietário já não, com base em?"

Com base nos objectivos de ambos os lados, that's what. Aliás, tu é que não leste o que eu escrevi, porque eu disse porquê.

No mundo proprietário tens prazos, tens custos, és pago para produzir software. Ora, todos estes factores contribuem para uma degradação da qualidade do código (por mais que os programadores sejam tipos capazes).

Quando falta pouco para atingir o prazo, o código começa a ser ajavardado para o conseguir cumprir (nunca te aconteceu nos trabalhos da faculdade?).

Contratar o pessoal necessário para produzir bom código tem custos, tal como alargar os prazos. Os prazos normalmente são curtos, como tu podes constatar perguntando a qualquer pessoa que trabalhe no ramo (não a mim, no entanto). Excesso de trabalho e prazos curtos significa degradação da qualidade do código.

Ser pago para produzir software significa que, na maior parte do tempo, não se tem grande interesse no produto final. Isto significa que o factor "arte" da programação é deixado para traz, porque só existe quando se está a fazer algo por gosto.

No lado do opensource é diferente, porque tens a maioria das pessoas a programar por gosto e sem pressão de prazos. Se juntares a isto o facto de não haver equipas, vês que a organização do código tem de ser bastante melhor se o projecto quer ter um mínimo de hipóteses de ser bem sucedido.

Código mal organizado ou atabalhoado é fatal para um projecto opensource, porque ninguém vai pegar nele.

Podes dizer que há muita gente a ser paga para participar em projectos opensource, paga por empresas que querem resultados. Mas, mais uma vez, a organização e a clareza do código é essencial. Caso contrário vão ser expostos pela comunidade, e vão acabar por ser rejeitados até que produzam código decente e enquadrado no projecto (dedica uns dias a acompanhar a LKML, e vais ver quantas vezes isto acontece...).

As diferenças entre o modelo proprietário e o modelo opensource podem ser claramente observadas nos projectos proprietários que passaram a opensource. São poucos os que conseguiram atrair uma comunidade de programadores externa, e as queixas mais frequentes prendem-se com a opacidade e má organização do código.

Todos os dias aparece gente a contribuir qualquer coisa para o Linux (kernel), coisas pequenas e grandes. Mas mesmo as coisas pequenas, quando são para um dos subsistemas internos, exigem que o código seja legível, senão o pessoal desiste.

Inversamente, o Firefox sofre cronicamente de falta de programadores (uns 90% são pagos pela Mozilla Foundation, os restantes 10% são pagos pela Red Hat, Mozdev Group, etc.). Ninguém se quer meter no meio daquilo. A herança do Netscape ainda anda por lá, e o peso da comunicação está todo em cima dos programadores existentes e não em cima do código. Resultado, o pessoal foge daquilo como da peste.

És livre de contrariar o que eu estou a dizer, mas se parares um pouco para pensar vais ver que faz todo o sentido. No mundo proprietário pode haver bom código, tal como no mundo opensource há mau código, mas o ambiente de ambos os lados potencia resultados diferentes.

Só para acrescentar ao que disse acima, quando estás a fazer as coisas por gosto, podes dar-te ao luxo de demorar mais tempo para chegar a uma solução elegante, ou tentar convencer os outros de que há uma solução mais elegante (quando isto falha, acontecem os forks), etc., etc.

Quando estás a fazer as coisas porque têm de ser feitas, és obrigado a cortar curvas. Não podes esperar eternamente pela solução mais elegante, nem podes desatar a fazer "rewrites from scratch". E muito menos podes começar a arranjar conflitos com os colegas criticando-os quando programam "à cão" (este é um caminho certo para criar mau ambiente).

É como em tudo, ou nunca estiveste em situações onde eras obrigado a implementar algo que não te agradava minimamente? Ou onde o resultado final não saiu exactamente como querias, mas não tinhas outra escolha senão usar mesmo assim? Ou ambos? A mim já me aconteceu bastantes vezes...

"É como em tudo, ou nunca estiveste em situações onde eras obrigado a implementar algo que não te agradava minimamente? "

Sim, em projectos open source por exemplo. Alguém terá de fazer o código chato. As coisas não se fazem sozinhas.

Da maneira como falas, parece que o pessoal que faz software proprietário faz tudo de má vontade e sem qualidade, devido aos prazos. Na minha opinião, a qualidade do software pode ser medida de várias formas e, ser open source, não é um requesito. Portanto, tu falas em termos ideiais e sim, as situações que feres podem acontecer várias vezes. Mas não são regra.

"Código mal organizado ou atabalhoado é fatal para um projecto opensource, porque ninguém vai pegar nele. "

Engraçado dizeres isso e eu lembrar-me logo de 1/2 projectos open source em que meti a mão e efectivamente o código é uma treta. Só mostra que ser open source não é requesito para ter qualidade. Nota que não tou a dizer que ser closed source o é, simplesmente defendo que estes factores dependem de inúmeras variáveis.

"No mundo proprietário pode haver bom código, tal como no mundo opensource há mau código, mas o ambiente de ambos os lados potencia resultados diferentes."

Depende do ambiente... tenho experiências muito boas a trabalhar em empresas, e outras más. Por outro lado certos projectos open source não têm assim tão bom ambiente devido às intransigências de quem os lidera. Pelo que tu dizes, o gaim pode ser um exemplo, e eu conheço outros.

Ou seja, embora os ideais por detrás do open source tenham valor, na prática as coisas nem sempre são assim tão cor de rosa. Tal como o desenvolvimento proprietário pode não sofrer dos males que dizes (e com os quais eu concordo).

Portanto, que vantagens reais e inquestionáveis tem o open source? Pergunto isto, pois também me tenho andado a fazer esta pergunta.

Ah, e estamos a fugir ao tema... eu falava dos problemas da modificação de código alheio!

"Engraçado dizeres isso e eu lembrar-me logo de 1/2 projectos open source em que meti a mão e efectivamente o código é uma treta. Só mostra que ser open source não é requesito para ter qualidade."

Não é requisito, mas programar por gosto potencia melhor código do que programar por salário.

Existem dezenas (senão centenas) de milhares de projectos opensource, e em todos eles tu podes olhar para o código e avaliar a qualidade do código. É certo que vais encontrar muita (mesmo muita) porcaria, mas quase sempre em projectos pequenos (até porque muita gente nem com muito boas intenções tem jeito para programar). Estes projectos são os que não vão a lado nenhum.

Eu não estou a dizer que ser opensource torna o código *automaticamente* bom. Mas quando se trata de programar sem pressões, com o código à vista de todos, com a intenção de atrair ajuda, o código tende a ser bom, ou o projecto fracassa (e inúmeros projectos opensource fracassam todos os dias). No mundo proprietário o projecto só fracassa se não produzir um resultado, independentemente da qualidade do código.

Pega em qualquer dos projectos grandes (em código ou popularidade) e aponta-me um que tenha mau código (não num ponto, mas globalmente mau). Vais ver que é difícil encontrar um... Porque não seria "grande" se assim fosse...

Daí, a minha conclusão é *apenas* uma: o modelo opensource favorece o código bom (porque os programadores não são obrigados a produzir código mau para atingir objectivos) e penaliza o código mau (porque ninguém lhe pega, e o projecto fracassa).

Portanto, o corolário disto é: dado um projecto opensource estável (que não parece ir acabar proximamente), a probabilidade de ter bom código é elevada. Este tipo de conclusão nunca se pode tirar num projecto proprietário.

"Portanto, tu falas em termos ideiais e sim, as situações que feres podem acontecer várias vezes. Mas não são regra."

Não são regra na tua experiência talvez, mas toda a gente que anda por aí a fazer 12 horas de trabalho por dia decerto que não concordará contigo.

Mas já agora, que exemplos são esses? São projectos maduros, ou são projectos de uma pessoa que provavelmente vão ser abandonados mais dia, menos dia? E tens a certeza que de não gostares de C não te faz ver todos os projectos em C como tendo "mau código"? (Já que o C é a linguagem dominante.)

Da minha parte o código do KDE, Gimp, Qt, nedit, por exemplo, pareceram-me bons o suficiente para eu poder despachar uns bugs de uma ou duas linhas no espaço de meia hora depois de ter começado a olhar para o código. Se fossem assim tão maus, tinha desitido nos primeiros minutos (o que já me aconteceu uma ou duas vezes, em projectos que eu nem já me recordo...).

Eu já trabalhei numa empresa e trabalhava 8 horas... o ambiente era agradável e eu tinha interesse no que fazia. Conheço vários colegas na mesma situação.

"E tens a certeza que de não gostares de C não te faz ver todos os projectos em C como tendo "mau código"?"

Não. Eu só falo do que conheço e onde ponho as mãos e, como deves imaginar, não costumo por as mãos em projectos escritos em C (bem, a VM do Mono tá em C, mas eu não me meto nesses campos).

Um dos exemplos de mau código de que falava, é o Flexwiki.

Seja como for não me respondeste objectivamente. Dizes que o open source favorece código com qualidade. Ok, eu até posso concordar com isso, mas é sempre relativo a cada projecto. Mas que vantagens reais e inquestionáveis tem o open source? O que tás a dizer depende praticamente de quem programa e das suas motivações.

"Mas que vantagens reais e inquestionáveis tem o open source?"

Isso é uma pergunta de retórica, logo, não tem resposta. As vantagens variam de caso para caso (e em alguns casos não há grande diferença entre ser opensource ou proprietário).

"Eu já trabalhei numa empresa e trabalhava 8 horas... o ambiente era agradável e eu tinha interesse no que fazia."

Mais de 10 anos na mesma empresa pode levar a uma desmotivação total, em qualquer ambiente "agradável" e seja qual for a remuneração e profissão... A satisfação inicial vai desaparecendo ao longo dos anos, por cansaço ("desgaste") psicológico.

Pedro Santos,

Tenho consultado o teu blog algumas vezes e tenho lido com muita atenção os teus conceitos, ideias... em algumas opiniões eu concordo, noutras nem por isso, mas nunca coloquei em questão a qualidade dos "artigos" expressos por ti.
Hoje foi com muita desilusão que leio esse teu artigo sobre Modificação de Software.
Esse teu artigo não tem qualquer fundamento, não tem qualquer validade teórica/prática e para quem não conhece o open-source dá uma ideia errada do conceito.

Confusão geral do teu artigo, Open-Source não pretende medir qualidade de código, nem nunca pretendeu. (ponto final)

Pedro, ler/alterar qualquer código fonte de qualquer outro programador nem sempre é uma maravilha. Mas nunca ninguém apregoou que isso era maravilha... o que apregoam é que ter a possibilidade de ler/alterar o código é muito benéfico ( nem que seja para verificar que o código é uma m*rda e que mais vale pegar noutro package/projecto ).
Lembra-te que, se eu puxo um package open-source que eu à partida, e por análise de funcionalidade verifico que me vai ser útil, eu tenho a possibilidade de analizar o código e verificar se tenho a possibilidade de o integrar melhor no meu sistema ( fazendo claro algumas alterações ).
Pedro, eu já utilizei e alterei vários sistemas/aplicações open-source para se integrarem em sistemas meus e melhor responderem aos meus requisitos e isso foi sempre benéfico e poupou-me bastante tempo.
Pedro, a tua confusão está no facto de generalizares as coisas, eu não pego no primeiro projecto open-source e ponho-me a altera-lo. Eu pego em vários projectos e analizo o que melhor se adequa ( e isso tb significa possibilidade de alteração fácil).
A ideia e conceito de open-source não está errada e apregoar que o conceito é benéfico está mais que correcto, e não estou a falar de teoria eu falo de experiência própria. O que pode falhar, e isso nada tem a ver com o conceito open-source, é o modo como as pessoas programam. Se o programador for mau, o projecto vai ser mau, seja ele open-source ou proprietário.
Tens que ver uma coisa, o conceito de open-source tem muita validade, mas o conceito apenas diz que "ter acesso ao código fonte é benéfico e não que alterar qualquer código é benéfico".
Depois, quando se diz que qualquer um pode alterar não se deve levar à letra que qualquer um mesmo pode alterar. Seria absurdo colocar uma pessoa que não entende do assunto alterar o código, mas, por outro lado, essa pessoa pode contratar alguem para o fazer e pode com isso diminuir o orçamento do desenvolvimento. Mas como tudo no mundo empresarial isso é uma questão de gestão e não técnica. Nenhum gestor de projectos vai aceitar pagar uma alteração que fique mais caro que desenvolver o projecto em si.
Depois, ter possibilidade de alteração não significa obrigatoriedade de o fazer.

Por último comparas noutro artigo Design Patterns com Open-source. Uma coisa não tem nada a ver com a outra, logo não se deve comparar.
Open-Source é um conceito de distribuição, e não tem nada a ver com qualidade de código.
Design-Patterns é um conceito de desenvolvimento de software, que diz que, usando certos modelos conhecidos e desenhados para integração e reutilização vai facilitar o desenvolvimento e futura manutenção do código.
Eu posso num projecto open-source usar design patterns e isso apenas me garante ( se o pattern for bem aplicado ) que o meu código terá melhor qualidade.

Olá Pedro. No geral concordo com o que dizes e não sei o que escrevi que vai contra. Contudo, alguns reparos:

" Hoje foi com muita desilusão que leio esse teu artigo sobre Modificação de Software. "

O artigo é inspirado num livro que estou a ler e, é só sobre Modificação de Código em geral (não interessa se o código está disponível ou não). Acho que ninguém pode negar os problemas que sublinhei. Mas sim, coloquei uma adenda a falar de Open Source, não a criticar, mas a sublinhar que por haver código disponível isso pode ser mais perigoso. E isto eu já senti na pele.

" Por último comparas noutro artigo Design Patterns com Open-source."

Podes-me dizer onde faço essa comparação?

" Open-Source é um conceito de distribuição, e não tem nada a ver com qualidade de código. "

Cheque mate! Era só aqui que eu queria chegar.

Só mais uma coisa: eu sou a favor do Open Source! Sou é conta os zelotas que dizem que é a melhor coisa do mundo quando na verdade tem os seus problemas. E os problemas só são ultrapassados se tivermos consciência deles.

Dizer que potencia melhor código não é dizer que não tem problemas. Uma coisa não implica a outra.

Modificar código alheio pode ser difícil ou fácil. O pessoal do opensource "apregoa" que é fácil, porque o é na maioria dos projectos opensource.

Eu já tive de mergulhar no código de vários projectos opensource (para corrigir bugs que me irritavam particularmente) e nunca tive grandes dificuldades, mesmo em projectos com uma dimensão razoável como o Qt.

No mundo do software proprietário é provável que não seja assim, já que os métodos e os objectivos são diferentes. No mundo do opensource há muito mais interesse em ter uma boa organização interna e código claro, enquanto que no mundo proprietário isto só interessa até ao ponto em que começa a colidir com o "time-to-market" e a implicar custos mais elevados de desenvolvimento.

Leste o que eu escrevi? Eu tenho lá argumentos para a dificuldade de modificação de código alheio. Se não concordas com o que lá tá escrito então não sei o que dizer, podes sempre tentar argumentar.

Dizes que a modificação de código open source é fácil e por outro lado do software proprietário já não, com base em? Naquilo que tu achas? Nos teus ideais? Eu já mexi em N projectos open source e tenho uma opinião diferente. E agora? Quem é que tem razão? Por isto é que convém sempre argumentar as nossas *opiniões*.

Ha coisas basicas que dificultam muito a leitura do codigo. Maus comentarios, fraca organização do código, exagero na complexidade da implementacao de tarefas simples e também a forma de escrever código. É "normal" os programadores trazerem os vicios de outras linguagens para novas plataformas. Daí que eu penso que seja em opensource ou em empresas o problema é o mesmo. Depende da qualidade do codigo que se faz e da organização do mesmo, alem de claro a documentação.

"Dizes que a modificação de código open source é fácil e por outro lado do software proprietário já não, com base em?"

Com base nos objectivos de ambos os lados, that's what. Aliás, tu é que não leste o que eu escrevi, porque eu disse porquê.

No mundo proprietário tens prazos, tens custos, és pago para produzir software. Ora, todos estes factores contribuem para uma degradação da qualidade do código (por mais que os programadores sejam tipos capazes).

Quando falta pouco para atingir o prazo, o código começa a ser ajavardado para o conseguir cumprir (nunca te aconteceu nos trabalhos da faculdade?).

Contratar o pessoal necessário para produzir bom código tem custos, tal como alargar os prazos. Os prazos normalmente são curtos, como tu podes constatar perguntando a qualquer pessoa que trabalhe no ramo (não a mim, no entanto). Excesso de trabalho e prazos curtos significa degradação da qualidade do código.

Ser pago para produzir software significa que, na maior parte do tempo, não se tem grande interesse no produto final. Isto significa que o factor "arte" da programação é deixado para traz, porque só existe quando se está a fazer algo por gosto.

No lado do opensource é diferente, porque tens a maioria das pessoas a programar por gosto e sem pressão de prazos. Se juntares a isto o facto de não haver equipas, vês que a organização do código tem de ser bastante melhor se o projecto quer ter um mínimo de hipóteses de ser bem sucedido.

Código mal organizado ou atabalhoado é fatal para um projecto opensource, porque ninguém vai pegar nele.

Podes dizer que há muita gente a ser paga para participar em projectos opensource, paga por empresas que querem resultados. Mas, mais uma vez, a organização e a clareza do código é essencial. Caso contrário vão ser expostos pela comunidade, e vão acabar por ser rejeitados até que produzam código decente e enquadrado no projecto (dedica uns dias a acompanhar a LKML, e vais ver quantas vezes isto acontece...).

As diferenças entre o modelo proprietário e o modelo opensource podem ser claramente observadas nos projectos proprietários que passaram a opensource. São poucos os que conseguiram atrair uma comunidade de programadores externa, e as queixas mais frequentes prendem-se com a opacidade e má organização do código.

Todos os dias aparece gente a contribuir qualquer coisa para o Linux (kernel), coisas pequenas e grandes. Mas mesmo as coisas pequenas, quando são para um dos subsistemas internos, exigem que o código seja legível, senão o pessoal desiste.

Inversamente, o Firefox sofre cronicamente de falta de programadores (uns 90% são pagos pela Mozilla Foundation, os restantes 10% são pagos pela Red Hat, Mozdev Group, etc.). Ninguém se quer meter no meio daquilo. A herança do Netscape ainda anda por lá, e o peso da comunicação está todo em cima dos programadores existentes e não em cima do código. Resultado, o pessoal foge daquilo como da peste.

És livre de contrariar o que eu estou a dizer, mas se parares um pouco para pensar vais ver que faz todo o sentido. No mundo proprietário pode haver bom código, tal como no mundo opensource há mau código, mas o ambiente de ambos os lados potencia resultados diferentes.

Só para acrescentar ao que disse acima, quando estás a fazer as coisas por gosto, podes dar-te ao luxo de demorar mais tempo para chegar a uma solução elegante, ou tentar convencer os outros de que há uma solução mais elegante (quando isto falha, acontecem os forks), etc., etc.

Quando estás a fazer as coisas porque têm de ser feitas, és obrigado a cortar curvas. Não podes esperar eternamente pela solução mais elegante, nem podes desatar a fazer "rewrites from scratch". E muito menos podes começar a arranjar conflitos com os colegas criticando-os quando programam "à cão" (este é um caminho certo para criar mau ambiente).

É como em tudo, ou nunca estiveste em situações onde eras obrigado a implementar algo que não te agradava minimamente? Ou onde o resultado final não saiu exactamente como querias, mas não tinhas outra escolha senão usar mesmo assim? Ou ambos? A mim já me aconteceu bastantes vezes...

"É como em tudo, ou nunca estiveste em situações onde eras obrigado a implementar algo que não te agradava minimamente? "

Sim, em projectos open source por exemplo. Alguém terá de fazer o código chato. As coisas não se fazem sozinhas.

Da maneira como falas, parece que o pessoal que faz software proprietário faz tudo de má vontade e sem qualidade, devido aos prazos. Na minha opinião, a qualidade do software pode ser medida de várias formas e, ser open source, não é um requesito. Portanto, tu falas em termos ideiais e sim, as situações que feres podem acontecer várias vezes. Mas não são regra.

"Código mal organizado ou atabalhoado é fatal para um projecto opensource, porque ninguém vai pegar nele. "

Engraçado dizeres isso e eu lembrar-me logo de 1/2 projectos open source em que meti a mão e efectivamente o código é uma treta. Só mostra que ser open source não é requesito para ter qualidade. Nota que não tou a dizer que ser closed source o é, simplesmente defendo que estes factores dependem de inúmeras variáveis.

"No mundo proprietário pode haver bom código, tal como no mundo opensource há mau código, mas o ambiente de ambos os lados potencia resultados diferentes."

Depende do ambiente... tenho experiências muito boas a trabalhar em empresas, e outras más. Por outro lado certos projectos open source não têm assim tão bom ambiente devido às intransigências de quem os lidera. Pelo que tu dizes, o gaim pode ser um exemplo, e eu conheço outros.

Ou seja, embora os ideais por detrás do open source tenham valor, na prática as coisas nem sempre são assim tão cor de rosa. Tal como o desenvolvimento proprietário pode não sofrer dos males que dizes (e com os quais eu concordo).

Portanto, que vantagens reais e inquestionáveis tem o open source? Pergunto isto, pois também me tenho andado a fazer esta pergunta.

Ah, e estamos a fugir ao tema... eu falava dos problemas da modificação de código alheio!

"Engraçado dizeres isso e eu lembrar-me logo de 1/2 projectos open source em que meti a mão e efectivamente o código é uma treta. Só mostra que ser open source não é requesito para ter qualidade."

Não é requisito, mas programar por gosto potencia melhor código do que programar por salário.

Existem dezenas (senão centenas) de milhares de projectos opensource, e em todos eles tu podes olhar para o código e avaliar a qualidade do código. É certo que vais encontrar muita (mesmo muita) porcaria, mas quase sempre em projectos pequenos (até porque muita gente nem com muito boas intenções tem jeito para programar). Estes projectos são os que não vão a lado nenhum.

Eu não estou a dizer que ser opensource torna o código *automaticamente* bom. Mas quando se trata de programar sem pressões, com o código à vista de todos, com a intenção de atrair ajuda, o código tende a ser bom, ou o projecto fracassa (e inúmeros projectos opensource fracassam todos os dias). No mundo proprietário o projecto só fracassa se não produzir um resultado, independentemente da qualidade do código.

Pega em qualquer dos projectos grandes (em código ou popularidade) e aponta-me um que tenha mau código (não num ponto, mas globalmente mau). Vais ver que é difícil encontrar um... Porque não seria "grande" se assim fosse...

Daí, a minha conclusão é *apenas* uma: o modelo opensource favorece o código bom (porque os programadores não são obrigados a produzir código mau para atingir objectivos) e penaliza o código mau (porque ninguém lhe pega, e o projecto fracassa).

Portanto, o corolário disto é: dado um projecto opensource estável (que não parece ir acabar proximamente), a probabilidade de ter bom código é elevada. Este tipo de conclusão nunca se pode tirar num projecto proprietário.

"Portanto, tu falas em termos ideiais e sim, as situações que feres podem acontecer várias vezes. Mas não são regra."

Não são regra na tua experiência talvez, mas toda a gente que anda por aí a fazer 12 horas de trabalho por dia decerto que não concordará contigo.

Mas já agora, que exemplos são esses? São projectos maduros, ou são projectos de uma pessoa que provavelmente vão ser abandonados mais dia, menos dia? E tens a certeza que de não gostares de C não te faz ver todos os projectos em C como tendo "mau código"? (Já que o C é a linguagem dominante.)

Da minha parte o código do KDE, Gimp, Qt, nedit, por exemplo, pareceram-me bons o suficiente para eu poder despachar uns bugs de uma ou duas linhas no espaço de meia hora depois de ter começado a olhar para o código. Se fossem assim tão maus, tinha desitido nos primeiros minutos (o que já me aconteceu uma ou duas vezes, em projectos que eu nem já me recordo...).

Eu já trabalhei numa empresa e trabalhava 8 horas... o ambiente era agradável e eu tinha interesse no que fazia. Conheço vários colegas na mesma situação.

"E tens a certeza que de não gostares de C não te faz ver todos os projectos em C como tendo "mau código"?"

Não. Eu só falo do que conheço e onde ponho as mãos e, como deves imaginar, não costumo por as mãos em projectos escritos em C (bem, a VM do Mono tá em C, mas eu não me meto nesses campos).

Um dos exemplos de mau código de que falava, é o Flexwiki.

Seja como for não me respondeste objectivamente. Dizes que o open source favorece código com qualidade. Ok, eu até posso concordar com isso, mas é sempre relativo a cada projecto. Mas que vantagens reais e inquestionáveis tem o open source? O que tás a dizer depende praticamente de quem programa e das suas motivações.

"Mas que vantagens reais e inquestionáveis tem o open source?"

Isso é uma pergunta de retórica, logo, não tem resposta. As vantagens variam de caso para caso (e em alguns casos não há grande diferença entre ser opensource ou proprietário).

"Eu já trabalhei numa empresa e trabalhava 8 horas... o ambiente era agradável e eu tinha interesse no que fazia."

Mais de 10 anos na mesma empresa pode levar a uma desmotivação total, em qualquer ambiente "agradável" e seja qual for a remuneração e profissão... A satisfação inicial vai desaparecendo ao longo dos anos, por cansaço ("desgaste") psicológico.

Pedro Santos,

Tenho consultado o teu blog algumas vezes e tenho lido com muita atenção os teus conceitos, ideias... em algumas opiniões eu concordo, noutras nem por isso, mas nunca coloquei em questão a qualidade dos "artigos" expressos por ti.
Hoje foi com muita desilusão que leio esse teu artigo sobre Modificação de Software.
Esse teu artigo não tem qualquer fundamento, não tem qualquer validade teórica/prática e para quem não conhece o open-source dá uma ideia errada do conceito.

Confusão geral do teu artigo, Open-Source não pretende medir qualidade de código, nem nunca pretendeu. (ponto final)

Pedro, ler/alterar qualquer código fonte de qualquer outro programador nem sempre é uma maravilha. Mas nunca ninguém apregoou que isso era maravilha... o que apregoam é que ter a possibilidade de ler/alterar o código é muito benéfico ( nem que seja para verificar que o código é uma m*rda e que mais vale pegar noutro package/projecto ).
Lembra-te que, se eu puxo um package open-source que eu à partida, e por análise de funcionalidade verifico que me vai ser útil, eu tenho a possibilidade de analizar o código e verificar se tenho a possibilidade de o integrar melhor no meu sistema ( fazendo claro algumas alterações ).
Pedro, eu já utilizei e alterei vários sistemas/aplicações open-source para se integrarem em sistemas meus e melhor responderem aos meus requisitos e isso foi sempre benéfico e poupou-me bastante tempo.
Pedro, a tua confusão está no facto de generalizares as coisas, eu não pego no primeiro projecto open-source e ponho-me a altera-lo. Eu pego em vários projectos e analizo o que melhor se adequa ( e isso tb significa possibilidade de alteração fácil).
A ideia e conceito de open-source não está errada e apregoar que o conceito é benéfico está mais que correcto, e não estou a falar de teoria eu falo de experiência própria. O que pode falhar, e isso nada tem a ver com o conceito open-source, é o modo como as pessoas programam. Se o programador for mau, o projecto vai ser mau, seja ele open-source ou proprietário.
Tens que ver uma coisa, o conceito de open-source tem muita validade, mas o conceito apenas diz que "ter acesso ao código fonte é benéfico e não que alterar qualquer código é benéfico".
Depois, quando se diz que qualquer um pode alterar não se deve levar à letra que qualquer um mesmo pode alterar. Seria absurdo colocar uma pessoa que não entende do assunto alterar o código, mas, por outro lado, essa pessoa pode contratar alguem para o fazer e pode com isso diminuir o orçamento do desenvolvimento. Mas como tudo no mundo empresarial isso é uma questão de gestão e não técnica. Nenhum gestor de projectos vai aceitar pagar uma alteração que fique mais caro que desenvolver o projecto em si.
Depois, ter possibilidade de alteração não significa obrigatoriedade de o fazer.

Por último comparas noutro artigo Design Patterns com Open-source. Uma coisa não tem nada a ver com a outra, logo não se deve comparar.
Open-Source é um conceito de distribuição, e não tem nada a ver com qualidade de código.
Design-Patterns é um conceito de desenvolvimento de software, que diz que, usando certos modelos conhecidos e desenhados para integração e reutilização vai facilitar o desenvolvimento e futura manutenção do código.
Eu posso num projecto open-source usar design patterns e isso apenas me garante ( se o pattern for bem aplicado ) que o meu código terá melhor qualidade.

Olá Pedro. No geral concordo com o que dizes e não sei o que escrevi que vai contra. Contudo, alguns reparos:

" Hoje foi com muita desilusão que leio esse teu artigo sobre Modificação de Software. "

O artigo é inspirado num livro que estou a ler e, é só sobre Modificação de Código em geral (não interessa se o código está disponível ou não). Acho que ninguém pode negar os problemas que sublinhei. Mas sim, coloquei uma adenda a falar de Open Source, não a criticar, mas a sublinhar que por haver código disponível isso pode ser mais perigoso. E isto eu já senti na pele.

" Por último comparas noutro artigo Design Patterns com Open-source."

Podes-me dizer onde faço essa comparação?

" Open-Source é um conceito de distribuição, e não tem nada a ver com qualidade de código. "

Cheque mate! Era só aqui que eu queria chegar.

Só mais uma coisa: eu sou a favor do Open Source! Sou é conta os zelotas que dizem que é a melhor coisa do mundo quando na verdade tem os seus problemas. E os problemas só são ultrapassados se tivermos consciência deles.

Dizer que potencia melhor código não é dizer que não tem problemas. Uma coisa não implica a outra.