O Fluent Assertions vai ser PAGO!

[@luan_maik]

Eu tenho dúvidas sobre o quanto esse tipo de acontecimento é problemático e poderá ser recorrente no futuro. Ao mesmo tempo eu me pergunto sobre a escolha em abstrair o uso de todas as bibliotecas de terceiro para evitar esse tipo de acontecimento e conseguir trocar de biblioteca "sem muito esforço". Eu gostaria de ver a opinião da galera aqui para entender como seria lidar com essa situação em uma aplicação grande, com vários pontos que faz o uso do Fluent de forma direta, e como ver esse caso para justificar uma estratégia de abstração e até entender se isso é viável (tudo é tradeoff), pois a solução padrão nesse caso seria travar a dependência na v7, ficar com ela até onde der e com o tempo ir migrando para outra lib, sem garantias que essa outra lib seria free para sempre.

Pois é, não temos como ter essas garantias. Pode acontecer com outras, mas sempre tem a opção do fork e aí vem uma ramificação que ainda é gratuita. Isso já aconteceu com vários pacotes e soluções ao longo do tempo. Sobre abastração, para algumas temos como fazer isso, já pra outras não faz muito sentido na minha opinião, como é o caso do FluentAssertions.

[@luan_maik]

muito obrigado pela resposta. Seria interessante se a comunidade open source tentasse padronizar uma interface para certos tipos de biblioteca, oq facilitaria não dependermos diretamente de uma implementação. Por exemplo, na comunidade PHP existe o PHP-FIG, que definem as PSRs, nas quais algumas definem literalmente uma interface padrão para certas implementações, de modo que várias libs opensource se baseiam nessa mesma interface (por exemplo PSR-3). Não sei se existe alguma iniciativa desse tipo para o C#, mas por se tratar de uma linguagem muito presente em sistemas grandes, então talvez facilitasse a propagação desse tipo de iniciativa.

[@X3noic]

ai é sacanagem

[@CodificadorAnônimo-c4n]

Kibe surdo! 😢