Existem exemplos notáveis ​​de desastres comerciais diretamente atraíveis para o software de código aberto? [fechadas]


21

Em ambientes "corporativos", observei um forte preconceito em relação a software proprietário. Mesmo em grandes empresas que usam Java, é incomum encontrar o MySQL ou PostgreSQL, e o WebSphere e o WebLogic são fortemente preferidos ao JBoss ou Tomcat.

Isso é muito compreensível. Embora muitos desenvolvedores prefiram o Tomcat ou o Postgres ao WebSphere ou Oracle DB, eles não são os que tomam as decisões finais nesses assuntos. Quem quer que tome a decisão sobre quais bancos de dados e servidores de aplicativos serão usados ​​na produção, descobrirá que as taxas de licença parecem muito pequenas em comparação com a demissão por escolher o software livre que causou algo realmente muito ruim.

Não estou perguntando se o Postgres é tão bom quanto o Oracle. Essa não é a questão. A Oracle não é escolhida sobre o Postgres após considerações cuidadosas sobre recursos e benchmarks. O Postgres não entra na conversa, porque o software livre não é confiável em determinados lugares.

Estou curioso para saber se essa falta de confiança surgiu em resposta a eventos específicos. Portanto, minha pergunta é a seguinte: existem casos documentados de calamidades de negócios (falhas, perda significativa de receita, perda significativa de dados corporativos etc.) que mostraram ser o resultado de deficiências no software de código aberto?

Esclarecimento: Se você tem experiência com empresas de nível empresarial que adotam completamente o OSS, que precisam prejudicar o assunto, mas fazem escolhas com base nas necessidades de uma situação específica, então Bom para você! Sua experiência não muda o fato de outras empresas terem uma atitude muito diferente, e minha pergunta é válida mesmo que essas empresas sejam minoria.


7
A questão é baseada em uma suposição dúbia de que as empresas "corporativas" não confiam no software livre. Isso é falso.
quant_dev

5
Bem, minha experiência pode não ser tão ampla quanto a sua, @quant_dev, mas observei significativa falta de confiança do MySQL, Postgres, JBoss e Tomcat na empresa. Mas nunca ouvi falar de desenvolvedores que não confiam nesses produtos.
Eric Wilson

5
@FarmBoy: Eu acho que os votos próximos estão aparecendo porque essa não é uma pergunta que pode ter uma única resposta, poderia facilmente se transformar em uma longa lista de anedotas e histórias e, possivelmente, lendas urbanas e FUD sem fundamento. Eu acho que os upvotes são porque esta é uma interessante questão (bem, eu acho que é interessante mesmo se não é verdadeiramente responsável).
FrustratedWithFormsDesigner

3
"A questão é baseada em uma suspeita dúbia de que as empresas" corporativas "não confiam no software livre. Isso é falso." ... Eu discordo, mas como você fala por todos os negócios da empresa, acho inútil.

2
@ Qwerky Bem, existem outros lotes que não consideram o Tomcat ou o MySQL, e minha pergunta é baseada na premissa de que, em vez de eu ter imaginado essas empresas, trabalhei para elas.
Eric Wilson

Respostas:


10

Existem alguns preconceitos, sim, talvez em alguns casos. No entanto, para as grandes organizações, esse caminho para servidores de aplicativos proprietários caros e outros conjuntos de software caros oferece algumas vantagens e valores em que alguns raramente pensam.

1) Suporte : Normalmente, quando uma grande empresa possui um software de milhões de dólares, o suporte é incorporado ao contrato. Não preciso me aprofundar nas vantagens de ter suporte a aplicativos.

2) Alavancagem : software proprietário caro, especialmente software de nicho, tem menos clientes e usuários independentes. Se um grande cliente corporativo decide não renovar um contrato, isso pode afetar seriamente a linha de fundo do fornecedor. Muitos deles usam essa alavancagem para buscar recursos e correções que talvez não possam influenciar no software de código aberto. O argumento para o código aberto afirma que a grande corporação pode contribuir com suas próprias mudanças e recursos no projeto para o bem de todos, mas isso envolveria o tempo dos desenvolvedores que eles tentam evitar.

3) Segurança : E não estou falando de criptografia, firewalls e outras coisas. Projetos de código aberto vêm e vão, alguns são amplamente suportados e superam o software proprietário. Muitos falham ou simplesmente perdem colaboradores ao longo do tempo. Se eles ficarem presos nesse software por 20 anos, a comunidade de código aberto continuará apoiando isso? Com o software proprietário, o dinheiro que você paga como cliente incentiva o fornecedor a permanecer no negócio enquanto você continuar pagando.

No que diz respeito a uma história em que o código aberto explodiu na minha empresa, um projeto de longa duração que foi iniciado em um conhecimento incomum do mapeador ORM que era código aberto. O projeto simplesmente parou quando o colaborador principal morreu ou algo assim, e a empresa ficou com um esforço caro de refatoração para mudar para uma biblioteca proprietária. Isso acontece e esse tipo de cenário assusta as grandes corporações.


3
Você pode dar detalhes sobre a história do ORM? Ou isso é uma lenda urbana?
Eric Wilson

6
Eu acho que a parte "amplamente utilizada" (comprovada) é a chave. Muitas empresas usam ferramentas como jQuery e nHibernate, e não pensam duas vezes sobre isso.
Robert Harvey

2
É possível adquirir um contrato de suporte para o Tomcat e o MySQL. Eles também são produtos bastante seguros e estarão disponíveis no futuro próximo. Se de repente as malas estivessem lotadas, muitas pessoas estariam com problemas.
Qwerky

4
Todos os pontos que você cita são preocupações válidas, mas todos são independentes da questão de propriedade / livre . Você pode obter suporte para software livre (pago ou não), obter novos recursos (pagar alguém, se necessário) e projetos de software proprietários também podem falhar ou ser abandonados. Eu diria que o SW livre realmente vence aqui, porque pelo menos você pode fazer isso sozinho (ou contratar / contratar alguém) se realmente precisar de algo.
sleske

2
Bem, quando uma empresa cai (como muitos na história da TI), seus usuários ficam sem sorte. Pelo menos com código-fonte aberto, você obtém o código de garantia gratuitamente, sem incluir advogados no meio.
Paul Nathan

5

Nunca ouvi falar de nenhum problema resultante do uso de um produto Open Source. Acho que o motivo da preocupação não se deve a algum fracasso histórico, mas a outra coisa.

Quando você usa um produto comercial para alguma tarefa e algo dá errado, geralmente você tem alguém para pedir ajuda. Essa pessoa (e empresa) geralmente tem interesse em ajudá-lo a resolver o problema, porque, se não ajudarem, sempre haverá a ameaça de que você pare de dar-lhe dinheiro.

Com um produto de código aberto, com quem você pode ligar ou entrar em contato? A comunidade? Como você não forneceu nada para o uso do produto, não há nada que possa ameaçar tirar. Você pode registrar um relatório e esperar que ele seja corrigido no próximo lançamento, mas é muito difícil transmitir um senso de urgência a uma comunidade nebulosa de pessoas que se oferecem voluntariamente .

Portanto, o produto de código aberto pode ser muito superior a uma alternativa comercial, mas pelo menos na minha experiência, em um ambiente corporativo em que você precisa planejar contingências se algo der errado com ele, não é necessário ter ninguém para obter suporte. lidar.

Essa é a barreira que eu sempre vi.


2
+1 As pessoas que tomam a decisão geralmente estão bem no alto da cadeia alimentar e querem que alguém culpe / apoie quando as coisas derem errado. É tudo sobre cobrir suas costas.
Qwerky

3
Essa deve ser a linha de tag corporativa: "É tudo uma questão de proteger as costas" :)
maple_shaft

maple_shaft - em muitas empresas, é.
Owe Jessen

3

Suspeito que empresas como a Oracle sejam mais relacionadas a outras empresas "com fins lucrativos"; eles não podem imaginar que uma organização possa produzir um produto tão bom quanto a Oracle sem também ter um motivo de lucro. Obviamente, o PostGres não é totalmente sem fins lucrativos; existe todo um ecossistema de provedores de serviços disponíveis que venderá seu suporte.

Se você realmente quer saber qual é o calcanhar de Aquiles de qualquer produto, faça uma pesquisa no Google por "[nome do produto] é uma merda". Funciona para qualquer produto, incluindo o da Oracle. No caso do PostGres, você encontra o DDG Transaction Control Sucks do Postgres , no qual alguém descreve uma situação hipotética em que os dados foram perdidos em um servidor de teste. Obviamente, a perda de dados é possível em qualquer banco de dados SQL, se for manipulada incorretamente.

Tudo isso dito, eu não ouvi nenhuma calamidade real que ocorreu às empresas porque elas decidiram usar um banco de dados de código aberto. A qualidade do software disponível naquele espaço é bastante boa, rivalizando e (em alguns casos) excedendo suas contrapartes comerciais.


"Não ouvi nenhuma calamidade real que tenha caído sobre as empresas porque elas decidiram usar um banco de dados de código aberto" Hmmm ainda não é necessariamente uma calamidade, mas li como o Facebook e sua profana luta para fazer o MySQL crescer em massa.
maple_shaft

1
@ maple: Ah, mas o MySQL não é realmente "código aberto", é? Bem, suponho que tecnicamente seja, mas depois que a Sun comprou o MySQL e a Oracle adquiriu a Sun, o MySQL nunca mais foi o mesmo depois disso. Não é difícil descobrir o porquê.
Robert Harvey

Eu acho que existem diferentes níveis de "código aberto". Quando o principal colaborador de um projeto de código aberto é uma grande corporação com interesse na direção de longo prazo do projeto, você verá muitos dos colaboradores independentes serem eliminados como o nerd da festa dos atletas. Veja o projeto Android para obter um exemplo perfeito desse comportamento. Isso e Oracle arruinar tudo o que coloca em suas mãos ...
maple_shaft

2
'O MySQL não é realmente "código aberto"' - nenhum verdadeiro escocês faria isso.
Sean McMillan

2

Para contrariar o argumento da OSS como fator de risco, eu gosto de dar o contra-exemplo do SAP, que é freqüentemente citado como um fator importante nas insolvências de pequenas e médias empresas - um exemplo é dado aqui: http: //www.intl- spectrum.com/article/359/Migration_to_SAP_from_U2_Causes_Bankruptcy_of_Company.aspx

Isso afirma ser uma lista das 10 principais falhas corporativas de TI: http://www.computerworld.com/computerworld/records/images/pdf/44NfailChart.pdf

Ele lista as introduções dos produtos SAP três vezes.


1

É um caso de usar o que é popular / estabelecido versus o novo e, presumivelmente, menos testado. Alguém foi demitido por usar o Apache? Tenho certeza de que alguns sites que o rodam foram hackeados a ponto de custar dinheiro, mas eles culparam o Código Aberto ou os responsáveis ​​por uma instalação ruim? Qual é a alternativa de propriedade revestida com ferro?

A questão é uma tentativa de defender uma solução, então qual é o problema? Sua empresa não deseja usar software de código aberto e seu argumento de instabilidade não é substanciado por nenhuma evidência anedótica. Crie um projeto paralelo e prove que eles estão errados. Eles podem pagar o dinheiro que economizam nas taxas de licenciamento.

A maioria das empresas não publica más notícias, então você tem sorte se conseguir obter a versão suja das ruas.

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.