Por que algumas bibliotecas opensouce não têm comentários?

Não sei se isso acontece com a maioria das bibliotecas de código-fonte aberto, mas muitas delas eu conheço e uso (por exemplo, OpenSSL, Webkit, ...) todas elas não têm comentários ou contêm muito poucos comentários.

Sem mencionar seus poucos documentos, é difícil ler o código fonte. Mal podemos entender o que significa uma variável membro ou o que essa função faz. Parece ser contra a prática padrão de codificação

Por que é que? Como as pessoas podem colaborar com esse código-fonte aberto com muito poucos comentários?

Escrever código fonte é divertido.

Escrever documentação e comentar códigos é menos divertido.

Quando um desenvolvedor trabalha em uma empresa que aplica bons comentários e documentação, não há escolha: esse desenvolvedor os escreve ou corre o risco de ser demitido.

Quando um desenvolvedor contribui para um projeto de código aberto, ele o faz de graça e principalmente por diversão. Não há ninguém para forçar esse desenvolvedor a fazer coisas que ele não está disposto a fazer, como escrever documentação e comentários.

É por isso que muitos projetos de código aberto não possuem documentação e comentários extensivos.

Como as pessoas ainda podem contribuir para projetos de código aberto sem documentação ou comentários?

• Se o código fonte for de alta qualidade, os comentários não serão necessários demais. Os comentários de interfaces públicas e a documentação são especialmente úteis para os consumidores do projeto, ou seja, desenvolvedores que simplesmente usam bibliotecas, não contribuem para eles.

• Não há fator de produtividade envolvido. Estou trabalhando em uma empresa em que a base de código real não possui testes de unidade, documentação e comentários. Passo muito tempo descobrindo o que um método 600-LOC está fazendo ou codificando coisas que já foram feitas, mas que não podem ser descobertas por causa da falta de documentação; portanto, na maioria das vezes, estou simplesmente desperdiçando o dinheiro da empresa em vez de fazer algo valioso.

  Por outro lado, para um projeto de código aberto, não importa se um dos colaboradores perdeu uma semana devido à falta de documentação ou comentários adequados. A pior coisa que pode acontecer é que esse colaborador saia do projeto.

  Descobrir código sem comentários ou documentação pode até ser desafiador, ou seja, atrair alguns colaboradores, em vez de desencorajá-los.

• Em projetos empresariais, não é incomum um desenvolvedor ser forçado a trabalhar em todos os aspectos de um produto e, alguns anos depois, ter que conhecer quase todo o sistema. Em um projeto de código aberto, ninguém o obriga a saber tudo. Você pode simplesmente contribuir com uma parte minúscula e ter um excelente conhecimento dessa parte, sem a necessidade de documentação.

Vários motivos.

• Escrever documentação não é divertido e, para muitos projetos, a base de usuários é a equipe de programação; todo mundo sabe do que se trata o código; portanto, a documentação não é realmente vista como um aspecto importante do projeto.
• A documentação pode (e vai) ficar desatualizada, e a documentação desatualizada é pior do que nenhuma. Isso significa que a documentação é uma responsabilidade extra e pode afetar a flexibilidade da sua base de código (mais documentação significa para qualquer alteração que você precise atualizar o código e a documentação). Especialmente para projetos de código aberto muito específicos, esse é realmente um argumento válido para obter o mínimo de documentação e, em vez disso, escrever código legível.
• A economia do software de código aberto é diferente. Embora seja bom ter colaboradores em seu projeto, muitos projetos são do tipo scratch-an-itch que o autor escreveu para resolver um problema específico e depois jogou fora como está. Como você está basicamente comendo migalhas de pão de outra pessoa, a atitude é que você não está em posição de exigir nada, muito menos de documentação.

Como as pessoas podem colaborar com esse código-fonte aberto com muito poucos comentários

Supondo que você quis dizer "Como as pessoas podem colaborar com esse código de código aberto que é difícil de ler" - bem, acho que um projeto de código aberto com código incorreto simplesmente terá menos colaboradores do que poderia ter com um bom código. Mas não esqueça que a legibilidade do código está sempre nos olhos de quem vê, e a maioria do código-fonte aberto não é tão ruim que você não possa entender pelo menos um pouco ou as intenções de algumas funções e classes.

Frequentemente, quando você deseja contribuir com algo para um projeto de código aberto, não precisa entender tudo, apenas as partes em que deseja adicionar um recurso específico. Portanto, se um desenvolvedor precisar de um recurso ausente, ele provavelmente irá morder a bala, identificará as partes que precisa mudar, "decodificará" essas partes mentalmente e incluirá os novos recursos. Se ele é bom, ele também tentará revisar e refatorar as partes "decodificadas", mas acho que na prática isso acontecerá muito raramente.