Quais sinalizadores de aviso devo observar ao selecionar o software de código aberto? [fechadas]


13

Ao comparar projetos de código aberto com software comercial, ou mesmo outros projetos de código aberto, que situações levantam uma bandeira vermelha e fazem com que você aperte o botão de ejeção e procure outro lugar?

Respostas:


17

Código aberto

Veja o site do projeto

  • Veja a documentação
  • Veja os arquivos da lista de discussão
  • Veja o SCM (svn, git, hg, etc)

Ao fazer isso, pegue os seguintes pontos ...

  • Quão maduro é o software
  • Qual é o tamanho da base de usuários (muitas pessoas? 3 pessoas?)
  • Quem são as pessoas na base de usuários (corporativa, usuário doméstico, empresa de pequeno porte etc.)
  • O desenvolvimento está ativo? Há quanto tempo está ativo?
  • Os arquivos da lista de discussão também vazam muitas informações sobre o "espírito de equipe" entre os desenvolvedores, entre outras coisas. Parece saudável, hostil, entediado, etc?
  • A documentação é decente?
  • O pacote / projeto foi aceito em distros como Fedora, Debian, RHEL, SLES, Ubuntu etc? Nesse caso - isso é bom - pelo menos mais de uma pessoa lá fora acredita no projeto.
  • O site possui um sistema de bilhética adequado? Se sim - Quantos ingressos estão abertos a partir de 5 anos atrás? Essa é outra indicação de quão "vivo" é o projeto.

Além disso, tome nota da licença sob a qual o software é distribuído. Alguns podem não ser adequados às suas necessidades.

Software empresarial

Não tenho muito o que dizer aqui além de ...

  • Certifique-se (não pergunte ao vendedor - ele simplesmente mentirá) que o aplicativo não é executado comoroot . Especialmente se for ouvir em uma porta TCP / IP. * Olhando para a reputação do fornecedor
  • Certifique-se de que os fornecedores estejam cientes de que as pessoas que administram este produto (ou seja, não terão rootacesso e, portanto, o produto deve oferecer suporte ao sudo . Quem argumenta que sudonão é suportado geralmente é apenas senil, mas são os fornecedores, e eles sejam os que precisam apoiá-lo - você não deseja comprar o produto e depois pede que eles digam "Não, você não pode usar o sudo, você deve su para fazer root".
  • Nunca compre nenhum software de segurança de código fechado - nunca
  • (subjetivo): ... e nunca confie em nada que um representante de vendas diga - todos eles são mentirosos e cobras, sem exceções.

Como você determina a maturidade de um programa? Não é como se os números de versão significassem algo, e muitos projetos permanecem em números de versão ímpares por anos em uso amplo. (Estou olhando para você NetworkManager). O que seria uma bandeira vermelha da imaturidade?
Jldugger #

Correto, embora seja possível que os números de versão tenham algum significado específico para os desenvolvedores, isso é uma coisa interna - o mundo exterior é apenas uma indicação, na melhor das hipóteses -, que o software corporativo parece tentar explorar com saltos ridículos de números de versão . Para ter uma idéia da maturidade, você pode procurar em alguns lugares, especificamente no sistema de bilhética - muitos ticks são uma coisa boa - especialmente se você pode ver que os desenvolvedores fizeram um esforço real para corrigi-los e fechá-los. Por outro lado, se você não tem ingressos, ou pior, não tem sistema de bilheteira, bem, não é um bom começo.
Xerxes

7
  • Falta de atividade. Se o projeto não lançou um novo código, mostra muitos bugs não fechados (ou bugs muito antigos e sem bugs novos) ou possui fóruns de usuários com uma taxa muito alta de spam / postagem, é um cheiro certo de codebase decadente. Projetos ativos têm lançamentos regulares, rotatividade de bugs que indica que os novos abertos não estão superando os antigos, e fóruns de usuários com atividades diárias. Todos os três são vitais para manter o código ativo e bem - liberar, recuperar e depurar / refatorar, formando um loop completo.

  • A atividade é proporcional ao tamanho, complexidade e maturidade da base de código. Quanto maior o programa / projeto, menos freqüentes são os lançamentos pontuais, mas deve haver um fluxo consistente de lançamentos pontuais. Para um projeto como o Samba, com uma grande base de códigos complexa, espere lançamentos de pontos depois de mais ou menos um mês. Para um projeto como o gcc, que é uma base de código amadurecida com objetivos de design mais conservadores, as versões pontuais são mais longas, mas são maiores. Alvos em movimento rápido em quantidades muito pequenas de código também mostram problemas em potencial - pode ser que os desenvolvedores ainda estejam enfrentando bugs ou ainda não tenham todos os objetivos / recursos codificados.

  • O código fonte deve estar prontamente acessível. À queima-roupa, se for um verdadeiro código aberto, não deve haver nenhum aperto de mão mágico, ofertas de vodu ou encantamentos à luz de velas envolvidos para ver o código-fonte. Não importa se é acessível através do CVS, SVN, Git, Mercurial ou até mesmo pombo-correio, desde que você possa acessá-lo sem um contrato de licença de quebra automática de cliques. Se você assinar uma renúncia, NDA ou concordar com algum esquema de licença não ouvido, não estará lidando com código aberto, mas sim com um fornecedor comercial que concordou em abrir a fonte para você - por um preço .


++ para requisitos de atividade.
sh-beta

6

Há muitas, realmente.

Licenciamento fraudulento - Muitas soluções estão tentando niquelar e me custar até a morte. O pacote custa X, mas se você desejar as opções 1, 2 e 3 anunciadas, serão US $ 500-1500 a mais por opção. Não, obrigado.

Ninguém usa - ou pelo menos, o Google não encontra ninguém falando sobre isso. Ou é novinho em folha (nesse caso, você é uma cobaia) ou é tão ruim que todo mundo sabe melhor

É a raiz de vários garfos - se algo já foi bifurcado várias vezes, provavelmente há uma boa razão para isso, e um dos garfos provavelmente resolveu o problema melhor do que a fonte. Investigue-os.

Design de interface constantemente ruim - não me refiro apenas à GUI. Opções ou sinalizadores CLI loucos, não identificados ou com etiquetas incorretas me deixam louco

Não funciona - ou finge que uma situação que precisa ser resolvida não deveria (ou não existe) e, portanto, não a resolve.


1

Eu também acrescentaria que a taxa de rotatividade de código é consistente e é executada por muitas pessoas, não apenas por algumas. Você não quer que uma pessoa produza código em part-time quando ele fica empolgado com o projeto, fica entediado e deixa para a comunidade continuar a apoiar. Drupal e Joomla são dois bons exemplos.


1

Se você estiver olhando o software da sua empresa, para vendê-lo, alterá-lo etc. O aspecto mais importante é a licença. Observando a inclusão do busybox nos roteadores WLAN e seguindo as ações legais, as empresas pensam "código aberto = faça o que quiser".

Algumas outras coisas: também estou procurando a data da última atualização e uma comunidade ativa, portanto, fórum, talvez outras páginas que tenham o software como tópico.


1

No Linux, eu verificava para ver qual software é fornecido pela sua distribuição. O software empacotado não se limita apenas ao código-fonte aberto / GPL - Ubuntu, Gentoo e SLES, no mínimo, incluem software proprietário em suas listas de pacotes. Embora não haja garantia de que esses pacotes funcionem com a mesma eficácia que o software principal da distribuição - alguém investiu tempo e esforço para preparar um pacote.


1

Eu olhava principalmente para maturidade e atividade. Se parece razoavelmente maduro e parece haver uma quantidade decente de atividade (atividade no fórum ou wiki, por exemplo), posso me sentir bem à vontade. Então eu sei que há uma boa chance de que os erros sejam resolvidos e que eu possa obter ajuda com os problemas que surgirem. Eu escolheria um projeto ativo que não corresponde perfeitamente às minhas necessidades, em vez de um projeto que parece uma correspondência perfeita, mas parece morto, em qualquer dia da semana.

Quando se trata de maturidade, depende muito do uso pretendido. Se é algo que eu preciso implementar instantaneamente e que não pode falhar ou causar problemas, a maturidade será obviamente um fator muito importante. Se eu posso viver com algumas peculiaridades e não é crítico com algum tempo de inatividade, prefiro olhar para as perspectivas futuras.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.