Realmente não há nada de errado em fazer isso, desde que todos possam suportar os custos, benefícios e riscos.
... a correção parece bastante simples ... para corrigir o código eu mesmo
Quando você tem um trabalho a fazer, a perfeição (ter uma biblioteca de terceiros exatamente o que você deseja) é inimiga do suficiente (corrigindo você mesmo) e, às vezes, é preciso fazer coisas assim. Eu já fiz vários projetos nos quais compramos licenças de origem para bibliotecas comerciais, para que pudéssemos resolver problemas antes que o fornecedor chegasse.
... os detratores querem argumentar que essa quase sempre é uma má ideia, pois é arriscada e apresenta uma complexidade problemática.
É uma péssima idéia se você não tiver os recursos necessários para dissecar o código de outra pessoa, identificar um problema e escrever uma correção. Isso é verdade se o código é interno ou de terceiros; a única diferença é se foi jogado sobre um cubículo ou sobre um muro antes de cair no seu colo.
Se seus detratores estão simplesmente descartando a idéia sem pesar os custos de não fazer esse patch, eles não estão fazendo a lição de casa. Se você tiver muitos códigos internos afetados pelo bug que o seu patch corrigia, será necessário alterá-lo para contorná-lo e testar novamente tudo para garantir que funcione corretamente. Então, se você atualizar o pacote para uma versão corrigida, talvez seja necessário localizar e remover as soluções alternativas e testar novamente. Também há riscos em fazer isso, como a falta de um caso que você alterou ou o teste insuficiente. Pessoalmente, se eu tiver a oportunidade de corrigir um bug em sua fonte, prefiro fazê-lo lá do que procurar o resto do código com um mata-moscas e espero ter tudo.
... a alteração do código foi feita por nós ... deve fazer parte de nossa base de código ... devemos apresentá-lo como um novo projeto e incorporar sua compilação automatizada em nosso processo de compilação.
Se você estiver fazendo um patch, ele faz parte do seu próprio código, o que significa que você precisa torná-lo parte do seu processo. Isso não é diferente de adicionar algo que é 100% seu código ao seu sistema. Trate a distribuição de terceiros como sacrossanto e coloque-a em um módulo como se fosse um código-fonte. Quaisquer correções que você escreve são armazenadas em arquivos separados e aplicadas como parte do processo de criação. Dessa forma, você sempre passa de uma fonte limpa para uma fonte corrigida para um produto construído e pode mostrar exatamente o que está acontecendo. (Algumas pessoas descompactam, remendam manualmente, reembalam e armazenam isso no controle de versão. Isso é ruim.)
... estaríamos puxando seu código do repositório de controle de origem para o nosso e perdemos o histórico por trás de qualquer alteração de código ...
Se você estiver tratando a biblioteca de terceiros como uma dependência de terceiros, não terá esse histórico e não estará perdendo nada. Se você tiver acesso contínuo ao repositório de terceiros, poderá consultar o que for necessário. Os lançamentos de terceiros devem ser tratados como blobs amorfos que você faz check-in no seu próprio sistema inalterados. Se você precisar examinar as alterações entre o release que está usando e os posteriores, poderá fazer isso e, se desejar, criar patches para a versão antiga que incorporam as alterações desejadas.
Também parece ser algo muito complicado para uma alteração tão pequena do código que precisa ser feita.
Se o seu processo de compilação for suficientemente sofisticado, adicionar isso não deve ser mais difícil do que adicionar seu próprio código. Há uma pequena quantidade de trabalho para chegar ao ponto em que o processo de descompactação / correção / compilação é automagic, mas, uma vez feito, é feito para sempre. Pode haver um bug agora, mas pode haver vinte no futuro. Se houver, você ficará muito mais feliz ao estabelecer as bases para apoiar tudo isso agora, porque isso fará com que lidar com os próximos 19 seja muito menos trabalhoso.