As empresas de software com código aberto (open source) tiveram um impulsionamento no mundo dos negócios nos últimos 2 anos. A ideia de administrar um negócio em software cujo código-fonte está prontamente disponível para qualquer um manipular ganhou validade considerável quando a IBM anunciou suporte total para Linux em seu hardware, incluindo os Mainframes série Z, em 1999.
A potência e capacidade do software de código aberto não estão em dúvida. Softwares de código aberto alimentam a maior parte da Internet: o Linux, o servidor Web Apache, o sendmail e o OpenSSL são apenas algumas tecnologias importantes da Internet que são de código aberto, entre muitas outras.
Mas um pouco de dúvida foi recentemente lançado sobre os softwares de código aberto. O Brasil, que fez um grande esforço de mudar grande parte dos sistemas de governo para softwares de código aberto em 2003, registrou uma grande intenção de compra da Microsoft, citando a falta de desenvolvedores qualificados para fornecer ao país os aplicativos necessários.
O governo têm suas razões, e há uma abundância delas, prós e contras para considerar os softwares de código aberto para o seu negócio. Aqui apresentamos alguns argumentos para ambos os lados código aberto para os negócios.
Pró: Revisões do software
Com um produto comercial, você não pode inspecionar o código para erros e falhas. Com código aberto, você pode ter um monte de gente revisando todo o código. Se você tem talento na área de desenvolvimento, você pode fazer tudo com o código sem ter que depender do primeiro desenvolvedor que o criou, desde nível de personalização ou simplesmente correção de bugs.
Há uma máxima conhecida como “Lei de Linus”, nomeada para o Linus Torvalds, o criador do Linux. Ele afirma que “dado suficientes globos oculares, todos os erros são superficiais.” Isso significa que quanto mais pessoas puderem ver e testar um conjunto de código, prováveis serão as falhas detectadas e corrigidas rapidamente.
Contra: Ele coloca você no negócio de softwares e não há garantias
Depois de iniciar a modificação do código aberto, a responsabilidade pela integridade passa para você. Se você não tem o talento, as coisas podem sair do controle, e você ter um produto que precisa ser corrigido, possivelmente exigindo recursos consideráveis. Como resultado, muitas pessoas não querem esse tipo de responsabilidade. Eles querem que o idealizador resolva isso.
Além disso, ter mais olhos no software não é garantia. O bug “heartbleed” no OpenSSL era uma vulnerabilidade grave que se acreditava ter um pouco mais de dois anos antes de ser descoberto, e o OpenSSL é totalmente open source. O OpenSSL é quase onipresente em seu uso e ainda havia um longo intervalo antes do heartbleed ser encontrado.
Pró: Baixos custos de aquisição
Basta baixar o código do SourceForge, The Apache Foundation, GitHub ou alguma outra fonte legítima e tudo estará pronto para uso. Muitos produtos de código aberto estão disponíveis em uma edição gratuita básica e em uma edição premium com algum custo, como a maioria das distribuições do Linux.
Contra: Custos de longo prazo
Com o tempo, o software de código aberto pode custar mais em várias áreas. Digamos que você decidiu fazer modificações pesadas em um produto. Se você tiver um problema, você não pode chamar o criador do código para pedir suporte, a responsabilidade das modificações gigantes realizadas, é sua, então tem um problema. Mas, possa ser que você consiga ajuda do criador do código, ou nos fóruns, mas não há uma obrigação.
Podem haver outros custos a longo prazo também. Se um projeto é negligenciado ou abandonado você tem problemas vindo por aí, pode custar caro realizar a transição para algo novo. O OpenOffice, um pacote de produtividade de escritório gratuito criado pela Sun Microsystems como uma alternativa ao Microsoft Office, foi negligenciado por anos enquanto os voluntários se afastavam do projeto por razões óbvias e totalmente aceitáveis, mas que não vamos entrar no mérito por ser um assunto já resolvido.
É o mesmo risco que você toma com software comercial, que geralmente quando há o fim do ciclo de vida, você pode pagar por outra versão nova ou produto.
Notícias Relacionadas
Pró: fornecedores estabelecidos
Open source não é mais uma coisa nova. A Red Hat está prestes a completar 30 anos e sobreviveu à fusão DotCom na virada do século, enquanto a Fundação Apache tem cerca de 23 anos. Muitas dessas empresas são maiores e mais saudáveis do que as empresas de software comercial.
Contra: Projetos instáveis
O processo de desenvolvimento de código aberto não é tão profundamente organizado quanto o software comercial. Ele varia de aplicativo para aplicativo e de projeto para projeto. O exemplo do OpenOffice é bom. Voluntários afastaram-se e outra parte nem se quer tiveram interesse em participar do projeto. O que já não acontece com o LibreOffice, que ainda recebe voluntários e é considerado altamente atraente para quem quer colaborar com o projeto, este sim, não possui nem de longe, a possibilidade de acabar.
Em geral, não é uma boa ideia para apostar o seu negócio em uma fonte aberta projetada com voluntários. Você quer um software com uma organização profissional por trás dele, que usa todas as disciplinas regulares de uma boa loja de desenvolvimento de software, evitando coisas como:
- Sem licença, ou usando uma licença GPL. A licença GPL requer a distribuição de suas modificações a uma base de código e você pode não querer fazer isso;
- Não manter e atualizar o código. Isso é uma bandeira vermelha para um projeto perto da morte;
- Nenhuma ou má documentação. Ninguém quer baixar um enorme projeto de código aberto e, em seguida, ter que lê-lo linha por linha para descobrir o que os programadores fizeram. Os bons comentários são tão vitais quanto o bom código.
Da mesma forma, há sinais de que um projeto está em apuros. Eles incluem:
- A base de código é muito grande;
- O código não compila corretamente;
- Documentação pobre;
- Não usam ferramentas de compilação padrão. isso inclui o Visual Studio da Microsoft. É um bom IDE, mas não para o open source e muitos desenvolvedores open source ainda detestam a Microsoft;
- A hospedagem do projeto: SourceForge e GitHub são padrão. Depois disso, torna-se questionável.
- Licenças inconsistentes;
- Nenhuma governança.
Faça sua lição de casa na empresa por trás do projeto e verifique se ele é executado por profissionais.
Pró: Ferramentas de código aberto estão se tornando o padrão
Há uma geração inteira de desenvolvedores mais jovens que só conhecem ferramentas de código aberto. E essa população vai crescer a cada ano. Ferramentas de código aberto tornaram-se as ferramentas e ambientes padrão para muitos desenvolvedores.
Contra: Ainda é um mundo da Microsoft
A fonte aberta nunca decolou no desktop apesar dos repetidos esforços. A Microsoft ainda possui a área de trabalho, e esse é um destino importante. O Brasil se afasta da exclusividade de código aberto porque não consegue obter produtos de desktop que ganhassem em comparação com o que a Microsoft oferece (porque não tem quem defenda o software livre e de código aberto no governo, mais isso não vem ao caso).
E a Microsoft faz o alcance aos desenvolvedores e aos seus clientes finais como ninguém mais, e tornam muito fácil para os clientes permanecerem clientes estando lá para ajudar. Eles levam muito do peso por isso, se um problema acontece, esses problemas são corrigidos rapidamente. Não é sempre assim com os produtos de código aberto.
Pró: Melhor governança
Ter acesso ao código-fonte não significa apenas encontrar bugs, mas potenciais “backdoors”, “keyloggers” ou qualquer outra coisa maliciosa. Você pode rastrear a execução do código e ver o que ele faz, uma opção não disponível quando você recebe um aplicativo compilado.
Contra: Aberto à exploração
Quando muitas pessoas têm acesso ao código-fonte do software, alguém com más intenções pode causar algum estrago. Um usuário mal-intencionado pode ser muito mais prejudicial do que qualquer hacker externo e pode usar seu acesso para explorar vulnerabilidades, criar bugs ou códigos maliciosos, usurpar identidades ou simplesmente irritar outros usuários. Portanto, cabe ao usuário de código aberto garantir seu código, controlar o acesso e monitorar as alterações como qualquer outra parte do código interno.
