Software de código aberto (do inglês open source software ou OSS) é o software de computador que tem seu código fonte disponibilizado e licenciado com uma licença de código aberto no qual o direito autoral fornece o direito de estudar, modificar e distribuir o software de graça para qualquer um e para qualquer finalidade. O software de código aberto muitas vezes tem desenvolvimento colaborativo e público.
Um software disponibilizado com uma licença de código aberto permite que qualquer pessoa possa investigar seu funcionamento interno e fazer alterações, portá-lo para novos sistemas operacionais e arquiteturas de processadores, compartilhá-lo com outras pessoas ou, em alguns casos, comercializá-lo.
Embora aplicados indiscriminadamente, os termos software de código aberto e software livre não são sinônimos.
História
O movimento software livre foi lançado em 1983 sob liderança do hacker Richard Stallman, que posteriormente (1985) fundaria a Free Software Foundation (FSF) com foco no aspecto filosófico e político do software livre. Em 1998, Bruce Perens, Eric Raymond e outros defensores argumentaram que o termo software livre deveria ser substituído por software open-source (OSS) como uma expressão menos ambígua e mais confortável para o mundo corporativo.
O termo surgiu de uma reunião estratégica realizada em 7 de abril de 1998, em Palo Alto, que incluiu indivíduos como Tim O'Reilly, Linus Torvalds, Tom Paquin, Jamie Zawinski, Larry Wall, Brian Behlendorf, Sameer Parekh, Eric Allman, Greg Olson, Paul Vixie, John Ousterhout, Guido van Rossum, Philip Zimmermann, John Gilmore e Eric S. Raymond, na conjuntura do lançamento do código-fonte do browser da Netscape Navigator sob uma licença de código aberto. Na ocasião, aproveitaram a oportunidade para esclarecer a potencial confusão causada pela ambiguidade da palavra "free" em inglês. Surge então a Open Source Initiative (OSI)
A OSI esperava que o uso do rótulo open source, sugerido por Christine Peterson durante a reunião estratégia, eliminaria a ambiguidade do termo, especialmente para os indivíduos que compreendem "software livre", como anticomercial. Com o termo, buscou-se trazer mais visibilidade para os benefícios práticos do código fonte livremente disponível, e trazer grandes empresas de software e outras indústrias de alta tecnologia para a colaboração open source.
A Definição de código aberto thumb|O logotipo da Open Source Initiative A Definição de código aberto é o documento utilizado para determinar se uma licença de software pode receber a certificação de código aberto. A definição foi baseada na Debian Free Software Guidelines, escrito e adaptado principalmente por Bruce Perens.Perens, Bruce. Open Sources: Voices from the Open Source Revolution. O'Reilly Media. 1999., The Open Source Definition according to the Open Source Initiative Segundo o próprio Perens, ele não baseou a sua escrita nas "quatro liberdades" da Free Software Foundation porque naquela altura estas ainda não eram públicas.
As licenças assim certificadas concedem direitos aos usuários que seriam reservados, pela lei de direitos autorais, apenas para o titular dos direitos autorais. O exemplo mais proeminente da licença de código aberto é a GNU General Public License (GPL).
Extensão do uso do termo
Embora o termo "open source" tenha sido concebido inicialmente apenas para o código fonte do software, o termo é agora aplicado a muitas outras áreas (como Open Source Ecology) para descrever movimentos de descentralização de tecnologias para que qualquer ser humano possa usá-las.
Os princípios do código aberto foram adaptados para muitas formas de conteúdo gerado pelo usuário e tecnologia, incluindo hardware open-source, Wikipedia, e de acesso aberto a publicações.
Os defensores do movimento conteúdo aberto defendem algumas restrições de uso, requisitos para compartilhar alterações e atribuição de outros autores do trabalho, visto que estes movimentos facilitam a entrada simultânea e não-coordenada de diferentes interesses, abordagens e prioridades, em contraste com os modelos mais centralizados de desenvolvimento voltados para objetivos específicos, como os normalmente usados em empresas comerciais.Raymond, Eric S. The Cathedral and the Bazaar. ed 3.0. 2000.
Os modelos de negócios
Há uma série de barreiras comumente reconhecidos para a adoção de software open-source pelas empresas. Estas barreiras incluem a percepção de que as licenças de código aberto são virais, nos quais há falta de suporte formal e formação, a velocidade das mudanças, e a falta de um roteiro a longo prazo. A maioria dessas barreiras estão relacionadas com o risco. Do outro lado, nem todos os projetos proprietários revelam exatamente os planos para o futuro, nem todas as licenças de código aberto são igualmente virais e diversos projetos sérios OSS (especialmente sistemas operacionais) realmente ganham dinheiro com suporte pago e documentação.
A estratégia de negócios de empresas de software de fonte aberta comerciais comumente empregada é a estratégia de licença dual, como demonstrado por Ingres, MySQL, Alfresco, e outros.
Outra estratégia de negócio poderia ser adaptada dos sistemas de micropagamentos existentes na Internet, incluindo Flattr e PayPal.
Produtos de código aberto amplamente utilizados Projetos de software em código aberto são construídos e mantidos por uma rede de programadores voluntários. Os principais exemplos de produtos de código aberto são o Apache HTTP Server, a plataforma de comércio eletrônico OsCommerce e o navegador de internet Mozilla Firefox. Um dos produtos de código aberto mais bem sucedidos é o sistema operacional GNU/Linux, um sistema operacional open-source Unix-like e seus derivados Android, um sistema operacional para dispositivos móveis.Michael J. Gallivan, "Striking a Balance Between Trust and Control in a Virtual Organization: A Content Analysis of Open Source Software Case Studies", Info Systems Journal 11 (2001): 277–304Hal Plotkin, "What (and Why) you should know about open source software" Harvard Management Update 12 (1998): 8-9 Em alguns campos, open software é a norma, como aplicações em voz sobre IP como Asterisk (PBX).
Filosofia de desenvolvimento Em seu ensaio de 1997 A Catedral e o Bazar, evangelista de código aberto Eric S. Raymond sugere um modelo para o desenvolvimento OSS conhecido como o modelo bazar. Raymond compara o desenvolvimento de software por metodologias tradicionais para a construção de uma catedral", cuidadosamente elaborado por mágicos ou pequenos grupos de magos trabalhando em esplêndido isolamento". Ele sugere que todo o software deve ser desenvolvido usando o estilo bazar, que ele descreveu como "um grande e barulhento bazar de diferentes agendas e abordagens."
No modelo tradicional de desenvolvimento, que chamou o modelo catedral, o desenvolvimento ocorre de forma centralizada. As funções são claramente definidas. As funções incluem pessoas dedicadas ao projeto (os arquitetos), as pessoas responsáveis pela gestão do projeto, e as pessoas responsáveis pela execução. Engenharia de software tradicional segue o modelo catedral. Fred P. Brooks, em seu livro The Mythical Man-Month defende este modelo. Ele vai mais longe ao dizer que, a fim de preservar a integridade da arquitetura de um sistema, o projeto do sistema deve ser feito por tão poucos arquitetos o possível.
O modelo bazaar, contudo, é diferente. Neste modelo, os papéis não estão claramente definidos. Gregorio Robles sugere que o software desenvolvido utilizando o modelo bazar deve apresentar os seguintes padrões:
Os usuários devem ser tratados como codesenvolvedoresOs usuários são tratados como codesenvolvedores e assim eles devem ter acesso ao código-fonte do software. Além disso, os usuários são incentivados a apresentar adições ao software, correções de código para o software, relatórios de bugs, documentação etc. Ter mais codesenvolvedores aumenta a taxa em que o software evolui. Lei de Linus diz: "Dados olhos suficientes, todos os erros são triviais." Isto significa que, se muitos usuários visualizarem o código fonte, eles acabarão por encontrar todos os bugs e sugerir como corrigi-los. Note-se que alguns usuários têm habilidades avançadas em programação e, além disso, a máquina de cada usuário fornece um ambiente de testes adicional. Este novo ambiente de teste oferece a habilidade de encontrar e fixar um novo bug. As primeiras versões A primeira versão do software deve ser lançada tão cedo quanto possível, de modo a aumentar as chances de encontrar codesenvolvedores mais cedo.
Integração frequente Alterações de código devem ser integradas (incorporando uma base de código compartilhado) o mais rápido possível, de modo a evitar a sobrecarga de fixação de um grande número de erros no final do ciclo de vida do projeto. Alguns projetos de código aberto têm nightly builds onde a integração é feita automaticamente em uma base diária. Várias versões Deve haver pelo menos duas versões do programa. Deve haver uma versão buggier com mais recursos e uma versão mais estável, com menos recursos. A versão de buggy (também chamado de versão de desenvolvimento) é para usuários que querem o uso imediato dos recursos mais recentes, e estão dispostos a aceitar o risco de usar um código que ainda não completamente testado. Os usuários podem, então, agir como codesenvolvedores, relatar bugs e fornecer correções de bugs.
Alta modularizaçãoA estrutura geral do software deve ser modular, permitindo o desenvolvimento paralelo em componentes independentes. Estrutura de tomada de decisão dinâmicaHá uma necessidade de uma estrutura de tomada de decisão, seja formal ou informal, que toma decisões estratégicas, dependendo da mudança de requisitos de usuário e de outros fatores. Cf.Programação extrema.
Os dados sugerem, contudo, que a OSS não é tão democrática como o modelo bazar sugere. Uma análise de cinco mil milhões de bytes de código fonte livre/aberto por 31.999 desenvolvedores mostra que 74% do código foi escrito pelos mais ativos de 10% dos autores. O número médio de autores envolvidos em um projeto foi de 5,1, com mediana em 2.
Licenciamento
A licença define os direitos e obrigações que um licenciante concede ao licenciado. As licenças de código aberto concedem ao licenciado o direito de copiar, modificar e redistribuir o código fonte (ou conteúdo). Essas licenças podem ainda impor obrigações (por exemplo, modificações no código que são distribuídos devem ser disponibilizados em forma de código fonte, uma atribuição autor deve ser colocado em um programa/documentação com o código aberto).
Autores inicialmente derivar um direito de conceder a licença para o seu trabalho com base na teoria legal que, após a criação de uma obra o autor detém os direitos autorais nesse trabalho. O que o autor/licenciador é concessor quando concede uma licença para copiar, modificar e redistribuir o trabalho deles é o direito de uso, direitos autorais do autor. O autor ainda retém a propriedade dos direitos autorais, o licenciado simplesmente está autorizado a utilizar esses direitos, conforme concedido na licença, desde que mantenham as obrigações da licença. O autor tem a opção de vender/ceder, contra licença, o direito exclusivo aos direitos autorais de seu trabalho, pelo que o novo proprietário/adquirente controla os direitos autorais. A propriedade dos direitos autorais (os "direitos") é separado e distinto da propriedade da obra (a "coisa") - uma pessoa pode possuir uma cópia de um pedaço de código (ou uma cópia de um livro), sem os direitos copiar, modificar ou redistribuir cópias do mesmo.