Sabedoria de usar código-fonte aberto em um produto de software comercial

Eu estou olhando para usar algum código-fonte aberto no meu aplicativo Web ASP.NET (especificamente dapper ). O gerenciamento não é um fã, porque o código aberto é visto como um risco que já nos havia mordido antes. Aparentemente, os desenvolvedores anteriores tiveram que reescrever as coisas após a falha dos componentes de código aberto.

Os profissionais parecem ser:

• Faz muitas coisas para mim que, de outra forma, envolveriam muitos códigos padrão ou a solução mais lenta e recomendada da Microsoft (Entity Framework).

Contras:

• É suficientemente complexo que, se falhasse repentinamente na produção, seria difícil corrigi-lo. No entanto, ele está sendo usado em um site com tráfego muito maior que o meu, então não acho que acabe sendo uma parte de alto risco do projeto.

Qual é o consenso aqui? Não é aconselhável usar código-fonte aberto no meu projeto que eu não conheça / compreenda tão bem quanto meu próprio código?

É uma escolha que você terá que fazer com base nas circunstâncias específicas. Você pode atenuar seus riscos:

• testando a estrutura minuciosamente, evitando a probabilidade de surpresas desagradáveis ​​mordendo você em um ambiente de produção e
• usando acoplamento flexível para minimizar a quantidade de código que depende diretamente da estrutura, para que você possa mudar para sua própria implementação, se necessário, sem reescrever todo o produto.

Por fim, com um projeto de código aberto muito usado, é provável que você gaste muito mais tempo escrevendo o seu próprio texto do que corrigindo os poucos problemas nos quais se depara.

Eu vou ao ponto de dizer que, se sua reação inicial é escrever algo você mesmo, em vez de ver se alguém o escreveu, você está fadado ao fracasso. Não leve de leve todas as horas de trabalho e a correção de bugs que foram lançadas nos principais projetos de código aberto.

Depois de começar a entrar no seu domínio comercial, você terá mais dificuldade em encontrar um OSS que atenda às suas necessidades. Mas não há necessidade de reimplementar outro produto ORM. Se o dapper é complexo o suficiente para que você não consiga depurar e corrigir o código deles, como justificaria passar todas as horas de trabalho escrevendo-o do zero? Além disso, você pode (deveria?) Sempre procurar fora das caixas as soluções NoSQL enquanto você está nisso.

Até Linus admitiu que tentou encontrar uma solução SCM que atendesse a todos os seus critérios antes de desenvolver o Git. Pelo menos ele foi capaz de explicar por que nenhuma das soluções existentes era boa o suficiente.

Em algum momento da minha vida, parei de querer reescrever tudo e queria me concentrar na solução de problemas do mundo real. A maioria dos problemas que precisam ser resolvidos em uma empresa é específica do domínio. Encontre maneiras de escrever menos código e não mais.

Nota: Eu não sou funcionário da Microsoft. A opinião é completamente pessoal. Muitos pensamentos são dos últimos 5 a 7 anos ao usar o código aberto em conjunto com grandes fornecedores como desenvolvedor.

A monocultura é boa: minha regra pessoal para o ASP.NET é dar preferência à Microsoft e não escolher código de terceiros (código aberto ou não), a menos que não haja outra opção. A monocultura é gratificante, porque você está sendo transportado por um grande fornecedor, e a quantidade de usuários que repetem a mesma experiência é sempre grande o suficiente para obter ajuda e encontrar uma solução alternativa.

Cidades fantasmas: O problema do código aberto em 2012 é que não é mais 2000 ou 2005. A quantidade de projetos continua crescendo, quando a quantidade de usuários, adoções e colaboradores é praticamente a mesma de anos atrás. O público é esticado. Muitos projetos interessantes ficaram obsoletos, abandonados. Não existe orçamento de projeto de código aberto. Portanto, quando o interesse termina, não há ninguém para anunciar honestamente que o suporte acabou e apaga as luzes. Os projetos nunca morrem para deixar a atenção do público focada em algo melhor e novo. Portanto, o código aberto sempre continuará crescendo e se fragmentando. Não tendo feedback em forma de recompensa monetária ou morte financeira, são entidades eternas, existindo em prol da glória eterna.

20 graus de separação: toda adoção de uma nova biblioteca o separa do mainstream, muda para uma minoria de casos extremos. Depois de 20 etapas, como escolher a configuração de segurança, usar uma versão, estrutura, plug-in, etc. específicos. Sua solução se torna uma combinação única e global de detalhes. A pesquisa no Google ajudará apenas a provar o quão raro ou único é o problema. É sempre algum problema de autoatendimento, puramente técnico. Nunca é relevante para os negócios reais.

A qualidade vem do foco, o dinheiro é irrelevante: não há oposição entre software comercial e código aberto. Toda a comunidade de desenvolvedores é apenas uma comunidade como sempre foi. Os grandes fornecedores simplesmente têm a vantagem de envelhecer o código por mais tempo, em melhores condições, com públicos mais amplos do que os grupos de código aberto.

Consenso: Você está perguntando se existe consenso. Possivelmente não. Infelizmente, uma grande quantidade de usuários de código aberto é politizada demais. Afinal, o código aberto é um movimento social. O código aberto é imune à crítica, porque muitas vezes a opinião negativa será vista como um ataque pessoal antitecnológico. Meu consenso pessoal: atenha-se à Microsoft.

Eu trabalhei em vários projetos de sucesso para uma grande empresa que usava bits substanciais de software de código aberto. Em particular, usei Curl, SQLite e Webkit para uma empresa muito grande em projetos de sucesso enviados aos usuários finais. Como outros já disseram, é apenas uma questão de ter cuidado com as licenças e, idealmente, pedir a um advogado que as examine.

Existem centenas de licenças de código aberto, mas geralmente elas se enquadram em duas categorias, estilo BSD e estilo GPL. As licenças no estilo BSD não exigem que você abra seu próprio código de código-fonte e, geralmente, possuem apenas algum tipo de cláusula de atribuição. As licenças no estilo GPL exigem que você abra seu próprio código de código-fonte. A maioria das empresas (incluindo a minha) geralmente parece desconfiada, então você deve evitar o estilo GPL. O Dapper parece usar a licença Apache, que é do estilo BSD. Sempre descubra quais são os termos gerais da licença antes de começar a codificar.

Há também o LGPL, que é um caso interessante de borda, pois você pode usá-los sem abrir seu próprio código se restringir o acesso a um limite binário. (Ou seja, acesse a biblioteca apenas como uma biblioteca dinâmica.) O uso da biblioteca LGPL é muito factível, você só precisa ter mais cuidado.

Na minha experiência, o código-fonte aberto não tem mais probabilidade de apresentar erros ou falhas do que as soluções pagas, ou, nesse caso, as soluções de roll-your-own. Se você observar algumas das ferramentas de código aberto mais importantes, a qualidade é muito alta.

Você provavelmente deseja evitar projetos pequenos ou incompletos. Pode ser tentador pegar algo que parece atender às suas necessidades, mas se elas foram criadas por algumas pessoas, nunca concluídas e sem suporte, provavelmente não vale o esforço. (A menos que você esteja disposto a trabalhar diretamente no código.)

Você nunca teve componentes proprietários falhando antes? Eu encontrei muitos erros no software de empresas grandes e pequenas. Esse problema não é um problema de código aberto em si, é mais sobre a maturidade do projeto.

Parece que você deseja usar projetos antigos que oferecem suporte. Alguns projetos de código aberto oferecem suporte pago ou têm uma comunidade grande o suficiente para que você possa obter respostas em um fórum público. Talvez você deva priorizar os critérios de maturidade e suporte ao escolher uma biblioteca, seja ela fechada ou de código aberto.

Você precisa reconhecer que está assumindo mais riscos se decidir usar um projeto imaturo ou um com suporte limitado. Como tal, você precisa determinar qual é o seu plano de mitigação de riscos. Você pode executar mais testes no software de terceiros, por exemplo.

Supondo que os problemas de licenciamento não sejam um problema aqui: observando rapidamente o Dapper, notei que ele tinha apenas 2255 linhas de código legível e bem documentado . Isso é

• grande o suficiente para que você possa investir vários dias ou semanas para produzir código de qualidade comparável, fazendo o mesmo
• pequeno o suficiente para que você possa entender o que ele faz e corrigir quaisquer erros nesse código se eles aparecerem em produção

Se você escrever algo assim por conta própria e "reinventar a roda", você corre um risco muito maior de que seu próprio código apareça bugs na produção e você será realmente "pressionado para consertá-los".

O que você tem que fazer aqui, no entanto, se você introduzir uma peça de código aberto em seu projeto, então você tem que tomar a responsabilidade total para esse código, como se você tivesse escrito sozinho. Verifique se o código está em um estado em que você possa mantê-lo, se necessário. Não culpe os "autores" desse código se algo não funcionar como o esperado.

Em um de nossos projetos, também introduzimos alguns componentes de código aberto, de tamanhos pequenos como Dapper a bibliotecas que tinham entre 20 mil e 30 mil linhas de código. Sempre tivemos que fazer algumas alterações, corrigir alguns bugs, reduzir o tamanho de algo etc., mas tudo bem, já que esperávamos isso. Até o tempo para a depuração incluído, o uso de código aberto nos poupou muito trabalho.

Uma coisa a se pensar aqui: no seu caso, você menciona que existe uma alternativa amplamente aceita de um grande fornecedor disponível (MS Entity Framework, pelo qual você não precisa pagar nenhuma taxa de licença extra!). Você não deseja usá-lo devido a considerações de desempenho. Eu seriamente recomendo não deixar que o desempenho seja o único ou principal ponto a ser considerado. As perguntas que você deve fazer aqui: o Dapper tem toda a funcionalidade que você precisa agora e para a vida útil esperada do seu software? Ou você pode prever que atingirá os limites do Dapper rapidamente e terá que adicionar muitas funcionalidades ausentes ao seu redor, o que provavelmente não seria necessário se tivesse decidido usar o EF em primeiro lugar? Se este for o caso, eu recomendaria não usar o Dapper. Pergunte-se também: o EF não é realmente rápido o suficiente para sua aplicação,

A meu ver, é um ato de equilíbrio.

Se você se tornar dependente de um fornecedor, é quase certo que o suporte desaparecerá em breve

• Como eles têm programadores a pagar, eles precisam continuar criando novas versões e garantir que as antigas sejam impossíveis de obter e não funcionem mais (em plataformas mais novas) para que as novas tenham um mercado.

• Se eles não conseguem vender o suficiente para justificar um modelo de negócios, eles passam da empresa A para a empresa B para C, e cada um deles altera o suficiente novamente, você não pode usar o novo sem reprogramar e pode ' Não pegue o antigo que funciona.

• Eles apenas decidem que não o apoiarão mais porque são muitos problemas e não há dinheiro nele. Todo o dinheiro está em novos aplicativos.

Portanto, se você deseja criar algo que não precise ser reescrito continuamente a cada poucos anos, o código aberto pode ser seu amigo.

Eu acho que é prudente se a devida diligência for feita e parece que você já fez alguma lição de casa em relação à história e à atividade de um projeto específico. A capacidade de estender / adicionar recursos no código-fonte também é um grande profissional. Com testes suficientes, você pode minimizar o risco do lado contrário. É difícil entender completamente todas as dependências do seu código, mas pelo menos nesse caso, você poderá depurar completamente e exibir o código, se necessário.

Pergunte à gerência por que ela falhou antes. Foi realizada a devida diligência?

O jquery tem a opção de usar a licença MIT, muitos sites comerciais e governamentais também usam o jquery. O site da Microsoft também usa jquery! Portanto, a preocupação é com o licenciamento. Evite usar GPL / LGPL é suficiente.

"Quanto tempo para consertar um defeito relatado?" Depois de relatar o bug, ele pode ser corrigido em minutos, horas ou dias. Em situações de urgência, a equipe pode simplesmente "puxar o botão" para obter a fonte e compilá-la. Ele simplesmente relata a versão como "v1.2.3-101-gd62fdae" para o gerenciamento, que é rastreável.

O código aberto é realmente sobre legalidades, não sobre a qualidade do código. Existem bons e maus produtos de código aberto, assim como os bons e os maus de código fechado. Acredito que seu dilema é se deve usar um projeto desenvolvido por uma comunidade de voluntários.

Você tem certeza de que o problema de gerenciamento é uma preocupação técnica?

Digo isso, pois misturar SO e atividade comercial é um campo legal de minas, e mais de um gerente recebeu um "Por favor, explique" da equipe jurídica / CEO ou, pior, de outra organização. A maioria dos gerentes que conheço, mesmo aqueles que adotam ativamente o software do sistema operacional, são (com razão) muito cautelosos para entender completamente as situações legais às quais estão expondo a origem. Se você adota o software do sistema operacional e faz alterações, é obrigado a devolver essas alterações à comunidade. Em alguns casos, essa obrigação é legal, em outros moral. Em algumas licenças de SO, tudo o que você faz se torna SO apenas vinculando-o a elas.

Do ponto de vista técnico, é realmente apenas uma decisão entre produtos concorrentes - faça algumas perguntas básicas - você pode obter o suporte necessário para o pacote que escolher ?, quanto tempo para corrigir um defeito relatado, quanto custará por desenvolvedor, por ano ou uma vez, etc. O sistema operacional possui lotes 0 na coluna $, mas geralmente possui espaços em branco nos outros - somente você e seu chefe podem decidir se os 0 estão fora dos espaços em branco ou não.

E outro ponto a ser lembrado: "Ninguém nunca foi demitido comprando a IBM". (ou seja, a gerência fala por "Se você gastar muito dinheiro, deve ser um produto melhor do que um produto gratuito"