Engenharia de software e o movimento OpenSource

O movimento OpenSource é um notável exemplo de modelo de cooperação, colaboração, formação de redes e emergência de padrões, o que até o momento tem sido considerado o modelo de negócios e social mais adequado para um mundo plano e conectado (vejam as postagens O mundo é plano de 16/05/2007 e OScar: OpenSource Car, de 31/05/2007). Aparentemente, desafia as práticas correntes em Engenharia de Software, pois escapa dos modelos e processos tradicionalmente aceitos e em uso corrente pela comunidade. Mas, como é que os desenvolvedores da comunidade OpenSource conseguem produzir sistemas confiáveis e muito utilizados, como por exemplo o servidor Apache que de longe é o mais usado no mundo? e o SendMail, que é a base da maioria dos programas de mensagens? Essa pergunta me incomoda, e fui achar uma resposta parcial em um capítulo do livro Open Sources: Voices from the Open Source Revolution, da editora O’Reilly, escrito por precursores do movimento OpenSource: Chris di Bona, Sam Ockman, Mark Stone, e Brian Behlendorf. Apesar de ser um livro de 1999, faz uma análise interessante do ponto de vista de modelo de negócio, sustentabilidade econômica e aderência à engenharia de software.

No OpenSource, as pessoas desenvolvem software por diversão, pelo puro desafio e prazer intelectual de produzir o software. A propagação da filosofia do movimento está acima da garantia formal de qualidade, análise de requisitos e análise de marketing, cronogramas e custos. O resultado do trabalho deve atingir o maior número de usuários quanto possível, e as ferramentas de produtividade são normalmente produzidas pelos próprios desenvolvedores de acordo com a necessidade de cada projeto. A pesquisa de mercado, que normalmente antecede a produção de qualquer tipo de produto ou serviço, é feita de maneira anti-convencional. Os nichos de necessidades são identificados nas listas de discussão e nos grupos de usuários, sem pesquisa formal que aponte um consenso forte. Essa ausência de consenso explica, por exemplo, a derivação de um projeto em várias ramificações diferentes, resultando em produtos com um mesmo ancestral, mas com características finais diferentes. O fato de os projetos normalmente não serem financiados livra o programador dos compromissos de um projeto organizado, planos de negócio, compromisso com prazos apertados e funcionalidades pré-estabelecidas.

De modo geral, o desenvolvimento do software começa com uma idéia e sem um projeto organizado. O projeto é implícito, sai da cabeça de Zeus e vai sendo produzido na medida em que a implementação vai se desenvolvendo, e lá pela versão 2 ou 3 é que aparece algum projeto para embasar as próximas versões. Se eu preciso de um parser durante o projeto, então eu implemento um para as minhas necessidades, mas essa decisão não faz parte de um planejamento prévio de funcionalidades ou versão. Considera-se que esse seja um ponto fraco, pois sem algum projeto, a disseminação das idéias fica comprometida, prejudicando por exemplo a adesão de novos colaboradores no desenvolvimento, que vão ter apenas o código para entenderem o que anda acontecendo e descobrirem onde vão poder colaborar.

A diversão de fato começa na implementação, que mantém a turma acordada e trabalhando até altas horas, a produção de código é considerada a total liberdade de expressão. Busca-se a eficiência de execução e os usuários de software livre geralmente não se importam com estilo de programação ou documentação do código, desde que ele funcione de maneira confiável e resolva seu problema. O código não passa por uma verificação formal ou informal, não existem os papéis do aferidor de qualidade ou outros papéis da hierarquia. Os sistemas são testados no uso, por uma enorme comunidade que, de forma colaborativa, se dispõe a utilizar o sistema, encontrar erros e adicionar ou corrigir funções por conta própria, doando ao projeto seu tempo como programador. Este é considerado o ponto de destaque no desenvolvimento do software livre. O código alterado é retornado para um controlador de versões, que deixa a nova versão disponível para a comunidade. Esse é o principal ciclo de desenvolvimento do software livre, que tem sua maior força no teste de campo dos sistemas. Quanto ao suporte… melhor não se preocupar com isso, pois não existe um suporte formal, uma pessoa a quem se possa recorrer se der algum pau no sistema. O problema tem que ser relatado na lista de usuários apropriada, e em algum momento aparece outra versão com o problema corrigido.

Existe alguma semelhança entre o que foi descrito sumariamente acima, e a Engenharia de Software tradicional? Muito pouco ou nenhuma mas, que funciona, lá isso funciona, pois há vários exemplos de sistemas de sucesso desenvolvidos por essa comunidade. Não resta dúvida sobre um ponto: a comunidade de desenvolvedores opensource não é constituida por amadores, marinheiros de primeira viagem. Uma boa parte dessa comunidade é formada por profissionais experientes, eximios codificadores e conhecedores profundos das linguagens e sistemas, e com uma enorme disposição para programar e doar tempo a projetos somente pelo amor à causa. Talvez seja essa a principal explicação para o sucesso do modelo.

No meu entendimento, é perda de tempo querer procurar explicações sobre porque funciona ou porque não funciona. O movimento é emergente, e vai aos poucos se firmando a passos curtos, ganhando adeptos e espaço no desenvolvimento de sistemas até então considerados praia da Engenharia de Software tradicional. Tirem suas próprias conclusões… Tenho projetos sendo desenvolvidos na filosofia opensource, como o Proface e o UFVBeerGame (descritos em postagens anteriores aqui nesse blog), e para esse tipo de sistema, certamente a abordagem funciona.

(uma outra referência muito citada e famosa sobre o tema é o livro The Cathedral and the Bazaar, do Eric S. Hammond que é outro precursor do software livre, disponível na web aqui)

Anúncios

Consultor Independente, Treinamento Empresarial, Gerência de Projetos, Engenharia de Requisitos de Software, Inovação. Professor Titular Aposentado, Departamento de Informática, Universidade Federal de Viçosa, Minas Gerais, Brasil. Doutor em Informática, PUC-Rio, 1990. Pós-Doutoramento, University of Florida, 1998-1999

Publicado em Engenharia de Software
6 comentários em “Engenharia de software e o movimento OpenSource
  1. Juan Bernabó disse:

    Uma coisa interesante em projetos OpenSource é o modelo de gestão, ao inves de existir alguem que determina o que cada um deve fazer, este processo descissorio é distribuido nos participantes, que vão se auto-organizando puxando as tarefas nas quais tem conhecimento, habilidade e interesse ao contrario do modelo de gestão tradicional que empurra as tarefas apartir de um plano.

    Outra coisa interesante é os requisitos e arquitetura, ao inves de ser definidos no inicio do projeto eles vão evoluindo criando incrementos de produto funcionais que outras pessoas podem executar, entender e modificar, sem grande nescesidade de informações complementares, e desenvolvidos em pequenos lotes ao invês de grandes lotes por equipes pequenas e multidisciplinares que usam principios de Lean para engenharia de software.

    Quando você cita a falta de pesquisa, outro paralelo que se me ocorre é que é software produzido em regime JIT (Just In Time) espera que exista uma demanda para se iniciar a produção assim na verdade se responde a mudanças e necessidades com menos esforço e sobre produção do que em um projeto tradicional.

    Estes conceitos desafiam todo o status quo em gestão de projetos e engenharia de software, porem estão muito mais alinhados com inovação e desenvolvimento rapido e evolutivo de produtos.

    Meu papel hoje é ensinar e auxiliar empresas a usar este modelo para criar produtos inovadores usando gestão ágil de projetos com Scrum e as ferramentas, tecnicas e processos que aprendi com OpenSource e abordagens ágeis nos ultimos 17 anos.

    Uma coisa que realmente me preocupa é por quantos anos cursos de engenharia de software e de gestão de projetos continuaram a ensinar coisas com baixa efetividade.

    Abraços,
    Juan.

  2. Alo, Juan. O enorme desafio para quem ensina Engenharia de Software principalmente nos cursos de graduação, é conseguir mostrar aos alunos todas as tendências na área, e fazer com que eles saiam das disciplinas com uma boa noção de futuro. Os Métodos Ágeis incorporam algumas práticas do desenvolvimento opensource, e já existe documentação e aceitação suficientes para esse tema ser levado para a sala de aula. Mas ainda considero um desafio falar e praticar extensivamente técnicas opensource na sala de aula. Obrigado por seu comentário, zeluis

  3. André Luiz Rossotti Batista disse:

    Olá pessoal. Estou iniciando um estudo referente a adequação de métodos ágeis no desenvolvimento de software livre. Gostei muito do texto descrito pelo José Luis e procuro mais conteúdo sobre o assunto. Alguém poderia me indicar algum material?

    Um abraço.

  4. Frederico de Souza Ribeiro disse:

    Muito curioso o fato de um software de qualidade surgir através de uma rede não muito organizada de programadores. Pois mesmo que haja experiência dos programadores, não há plano de projeto e nem objetivo definido. Uma coisa é verdade, Se o produto é realmente de grande qualidade, não precisa de pesquisa de mercado, o produto tem espaço garantido. Talvez esse seja um seguredo!
    Outro fato é que um software livre, por contar com milhares de colaboradores experientes, tem recurso imensurável, isto é, se for transformar as horas empenhadas em custo, o “projeto” seria inviável.
    Portanto, acredito que a prática de Engenharia de Software e Gerenciamento de Projetos existem não só para produzir softwares de qualidade como também aproveitar o mínimo de recurso possível.
    Aí vai a pergunta: Se a mesma quantidade de recursos empenhados no APACHE fosse gerenciados e com processos definidos, o produto chegaria mais rápido no mercado? O APACHE não seria melhor?

  5. Eu tenho certeza de que o Apache não teria a qualidade que tem, nem atenderia aos anseios dos seus usuários, se tivesse sido desenvolvido como um projeto tradicional, com planejamento de tempo e custo, etc. Ele foi sendo melhorado e aprimorado pelos próprios experts que o utilizaram na prática. Mas não é qualquer tipo de software que pode ser desenvolvido dessa maneira, certamente software comercial, contratado, com data de entrega estabelecida pelo cliente, não poderia ter tanta liberdade assim. Pelo menos até agora… zeluis

  6. Frederico de Souza Ribeiro disse:

    Concordo com você que dá vontade de estudar o porquê de algo que, apesar de não precisar de $investimento$, da tão certo. Fiquei interessado em descobrir o segredo e tentar imitá-lo nos projetos da empresa onde trabalho. Nesses dias eu li sobre o assunto, conversei com colaboradors de Softwares Livre, e sabe qual conclusão eu cheguei? Nenhuma. Agora entendo quando escreveu: “é perda de tempo querer procurar explicações sobre porque funciona ou porque não funciona…”

    Mesmo que encontremos o elemento X da fórmula Software Livre acho que ele estragaria quando for utilizado em meio comercial.
    Uma coisa é certa, o prazer de desenvolver realmente algo é crucial para a produtividade. Fizemos um processo interessante na empresa onde eu trabalho de forma a levar em conta os objetivos das pessoas antes de serem alocadas em projetos. Portanto, quem se interessar em aprender JAVA era alocado em projetos dessa tecnologia junto com pessoas mais experientes. Os resultados foram bem interessantes!

    Abraço de quem ainda é seu aluno,

    Fred__

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: