Acadêmicos geram quantias enormes de software, alguns dos quais inspiram inovações comerciais em networking (redes) e outras áreas. Mas poucos softwares acadêmicos são lançados ao público e menos ainda atingem o uso comum. Há uma vasta “matéria escura” sendo omitida na comunidade acadêmica? O mundo se beneficiaria caso acadêmicos tornassem mais de seus softwares em projetos livres e de código aberto?

An alternative to replacing the entire frame is to use door-replacement kits, such as Replace Door Systems from Pease Industries. Here, the door is prehung in a small steel frame that attaches to the old one. Benefits include easy installation and the added security of the steel frame.

Me perguntei essas questões há alguns meses quando Red Hat, na abertura de um novo centro de inovações na vizinhança high-tech de Fort Point em Boston, anunciou uma parceria única com o objetivo de tocar a academia. Red Hat está juntando-se com departamentos de ciências da computação da área de Boston -- começando pela Boston University -- para identificar softwares promissores desenvolvidos em projetos acadêmicos e torná-los em projetos de softwares viáveis de código aberto. Pelo motivo de todo software lançado pela Red Hat ser de licença livre, a parceria sugere um novo canal pelo qual softwares acadêmicos podem encontrar maior uso.

Este artigo olha para alguns projetos acadêmicos de sucesso que entraram no uso cotidiano -- listando-sem através da história do computador da Berkeley Software Distribution (BSD) até os notebooks Jupyter -- e busca os fatores que podem ajudar essa transição a funcionar. Os projetos que eu escolhi sugerem os seguintes padrões:

• Acadêmicos, funcionando no sistema de recompensas da academia, não são prováveis de persistirem a conversão de software de um projeto de pesquisa para um produto viável do interesse da comunidade
• Fundos, geralmente do governo ou fundações, é a chave para a criação de produtos de alta qualidade que podem ser amplamente adotados. Esse apoio pode ajudar a suportar a conversão para projeto de um software livre útil.
• Ajuda muito se os usuários alvo compartilham alguns dos valores e conhecimento técnico dos líderes do projeto.
• Softwares de infraestrutura tendem a suceder mais que projetos de nível de aplicação, talvez porque tenha um atrativo mais amplo.

Começaremos com algumas observações de defensores de softwares livre sobre porque é tão difícil derivar softwares prontos para a produção de pesquisa acadêmica.

Sucesso do software ≠ sucesso acadêmico

Acadêmicos são obcecados por publicações. E quase universalmente, os publicadores acadêmicos estão interessados apenas nos resultados das pesquisas, como: “Pacotes de certo tamanho maximizam a saída de transmissão sob tal e tal condições”. As publicações não incluem dados relacionados ou código fonte, que são considerados, no melhor dos casos, como acessórios e, normalmente, como sem valor. (As coisas estão mudando um pouco aqui, especialmente para projetos com apoio governamental, mas principalmente para dados abertos, e não código aberto).

A ironia -- e até tragédia -- deste desprezo pela infraestrutura que torna os resultados possíveis é que acadêmicos economizam em medidas de qualidade de software, como testes. Frequentemente, bugs (erros) no software levam pesquisadores a publicarem resultados incorretos.

If you're looking for home electrical service in Detroit, Mi that you can depend on to get the job done right you've come to the right place! We're a family owned and operated business and have been serving homeowners throughout Detroit Michigan since 1925.

Para terem o código amplamente adotado pelas pessoas fora do âmbito acadêmico onde foi inventado, professores ou estudantes devem primeiro desenvolver o código conscientemente para garantir que é robusto, extensível, e que resolve corretamente o problema oferecido. Então devem polir a lógica do projeto para o qual o código foi desenvolvido, generalizando para uma gama maior de domínios e propósitos. Devem manter um repositório, solicitar contribuições, e examinarem as contribuições. Por último, alguém deve organizar uma comunidade que debata mudanças e escolha novas direções. Nenhuma destas tarefas que exigem tempo têm relação com publicações ou posse. Acadêmicos são pressionados a obterem resultados interessantes, pôr no papel, e seguir para o próximo projeto.

James Vasile, um programador e consultor do espaço open source, nota que os acadêmicos são predispostos a sigilar seus códigos, como suas pesquisas. Ai deles se liberarem o código cedo demais na pesquisa que ajudem pesquisadores competidores chegarem a conclusões mai cedo e serem publicados antes. Para prevenir esse fim de carreira, eles guardam o código até a publicação ou apresentação de conferência. Isso pode ser anos após a escrita do código, que se torna bem tarde para a criação de um repositório público e desenvolvimento de uma comunidade ao seu redor.

No geral, Vasile me disse, é mais provável que acadêmicos compartilharem ferramentas que permitam sua pesquisa como estrutura, mas esses não são os objetivos principais de suas pesquisas. A possibilidade de tornarem infraestrutura em open source tem paralelos em empresas econômicas em um fenômeno que intitulei "closed core" seis anos atrás. Empresas geralmente querem manter seu software comercial básico em segredo tanto quanto acadêmicos desejam manter seus códigos de experimentos por perto.

Vasile mencionou diversas outras barreiras que dificultam o desenvolvimento de projetos open source de códigos acadêmicos. Acadêmicos trabalham lentamente em códigos, não no ritmo de um time profissional. Quando organizações tentam ajudar através de doações, universidades levam uma grande parte -- geralmente metade -- dos fundos. Por último, muitas das tarefas necessárias para tornar um software robusto e útil não são academicamente interessantes.

Marshall Kirk McKusick, um dos primeiros desenvolvedores e mantenedores do BSD, complementou a idéia de que estudantes geralmente não têm tempo para desenvolver habilidades de programação sustentável e extensível, então seu trabalho é rápido e relaxado e não reutilizável. Pode ainda conter raízes inúteis para características que nunca foram realmente desenvolvidas e que provavelmente nunca serão.

Barreiras adicionais para a programação aberta foram apresentadas por Jeffrey Spies, co-fundador e CTO do Center for Open Science. Pesquisadores raramente pensam nos traços de um software adequado para adoção, como manutenção e documentação. E mesmo aqueles que deixam o código disponível em um repositório público têm pouco incentivo para alimentar uma comunidade em torno do software.

Desenvolvimento de alta qualidade de software requer contratação de desenvolvedores de software de alta qualidade, que é difícil no âmbito acadêmico. Bons desenvolvedores desejam trabalhar em um ambiente que aprecia suas contribuições, um traço improvável de atraí-los para o ambiente acadêmico que não considera a importância da qualidade do software.

Vasile, McKusick, e Spies apresentaram perspectivas desanimadoras para o desenvolvimento bem sucedido de código acadêmico. Mas alguns projetos superam os obstáculos e tornam-se softwares livre de sucesso. Vamos observar alguns, e tentar advinhar o que os ajudou a sucederem.

BSD

BSD, que surgiu na University of California, Berkeley, é o topo do sucesso dos softwares acadêmicos. McKusick forneceu uma história do crescimento e adoção do BSD para o livro da O’Reilly Media Open Sources: Voices from the Open Source Revolution.

Um fator que provavelmente permitiu o BSD ganhar ampla adoção foi sua audiência de administradores de sistema, que possuíam habilidade para instalar um complicado e sofisticado software em metal puro. Muitos na comunidade também enviaram contribuições para o código. Por exemplo, melhorias pela comunidade fizeram a rede 4.2BSD mais eficiente e robusta que o código que foi originalmente contribuído por Bolt, Beranek e Newman, que alcançaram a fama ao desenvolverem as fundações da internet para ARPA (o nome original da DARPA). McKusick contou que centenas de contribuintes estavam envolvidos no desenvolvimento do BSD

Foi negado acesso ao capital necessário para o BSD? Parece mais ter sido um projeto do departamento de ciência e computação de Berkeley, apesar de o artigo de McKusick citar fundos da DARPA durante a crítica transação da 3BSD para a 4BSD. Não vejo registros da Sun Microsystems, que usou o BSD como base do seu sistema operacional SunOS, dando dinheiro ao projeto, apesar de ter contribuído com muito código e reparo de bug.

Spark

Vamos agora para outro projeto que começou na UC Berkeley, mas em um tempo e contexto muito diferentes. Um sucessor para o incrível Hadoop, o motor de computação em cluster Apache Spark agora é parte de muitas estratégias de “big-data”. Dentre os projetos que pesquisei para este artigo, Spark é provavelmente o mais próximo do tipo de projeto que a Red Hat vai financiar.

Falei com um dos primeiros organizadores do projeto Spark, Patrick Wendell, que deixou a UC Berkeley junto com alguns membros da equipe para fundar a companhia Databricks, na qual é VP de engenharia. Wendell contou que Spark era uma idéia de um grupo de pesquisa atípico de Berkeley chamado AMPLab, onde cinco ou seis professores trabalham com cerca de 35 estudantes a qualquer hora em ferramentas de processamento de big data. O AMPLab tinha financiamento público e privado, e lá era esperado que pesquisadores desenvolvessem softwares para uma ampla gama da indústria -- como Wendell disse, é “parte da filosofia deles”. Apesar dos projetos não terem que ser liberados como software livre, muitos pesquisadores o fazem para ganhar benefícios de ampla adoção e contribuições para o campo. Por exemplo, o time de Berkeley doou Spark para a Apache Software Foundation em 2013 e construiu uma comunidade de desenvolvedores fora do AMPLab.

Desta forma, Wendell afirmou, acadêmicos no AMPLab podem ter impactos em formas que vão além de publicações. Medem sucesso pela ampla adoção de seu trabalho, não só por idéias que alcançam conferências e jornais. Ele concordou que construir uma comunidade e corrigir bugs não eram os caminhos mais eficientes para publicações, mas para alguns acadêmicos tudo bem. Trabalhar no AMPLab não impede sucesso acadêmico também -- por exemplo, o projeto Spark gerou diversas publicações acadêmicas. Matei Zaharia, fundador do projeto, passou um ano sabático para co-fundar Databricks mas após retornou a academia, onde é um professor assistente no departamento Stanford CS.

PostgreSQL

Esse sistema de gerenciamento de database, talvez como qualquer outro software livre, demonstra o quanto pode ser alcançado por desenvolvedores em uma comunidade aberta. A longa e complexa história do projeto, resumida em uma página do projeto, envolveu alguns esforços falhos de comercialização. Mas o código do atual PostgreSQL aparenta ser derivado completamente de esforços acadêmicos e da comunidade, onde um projeto de database de Berkeley chamado Ingres inspirou outro chamado Postgres, o gênesis do moderno PostgreSQL. Os desenvolvedores originais foram parte da mesma constelação de pesquisadores de Berkeley responsáveis pelo BSD.

Mas, como a página de história mostra: "Em 1996, Postgres95 deixou a academia". E em uma entrevista de podcast, Bruce Momjian sugeriu que muito do trabalho no moderno PostgreSQL foi feito em Berkeley, e que PostgreSQL era realmente um projeto da comunidade de 1996 em diante (2:42 no podcast). Ele também salientou o papel dos professores da faculdade na comunidade PostgreSQL.

Paradoxalmente, os acadêmicos não parecem contribuir muito com o código, uma teimosia que Momjian atribui à sua falta de interesse em uso prático (6:30 no podcast), ecoando minhas conversas com Vasile e Spies. Os principais apoios parecem terem vindo tarde para o projeto. Recentemente, de acordo com Momjian, um número de “big players” ofereceu suporte, incluindo IBM, Amazon, e Microsoft (12:57 no podcast).

Jupyter

Suplementar o suficiente para ser valioso para educadores, apresentadores de conferências e autores gerais no campo da computação, Jupyter surgiu de pesquisadores acadêmicos da Cal Poly State University, San Luis Obispo e UC Berkeley. Ele trouxe a apresentação de informações para a era moderna de multimídia, interatividade e colaboração. Originalmente projetado para exibir e executar códigos em Python (e chamado IPython), ele foi eventualmente estendido para que outras linguagens de programação de computador pudessem ser suportadas, e seu nome foi alterado para Jupyter (ainda mantendo "py" no nome para honrar suas raízes e implementação Python). Jupyter é uma ferramenta central em uso em meu próprio empregador, O'Reilly Media, como foi descrito em uma nota de vídeo; Tem muitos outros usuários também.

Em uma entrevista com um dos primeiros desenvolvedores do Jupyter, Brian E. Granger, eu aprendi que as origens de Python do projeto eram cruciais por razões históricas. Os cientistas, depois de anos de usar ferramentas proprietárias como Mathematica e MATLAB, estavam se voltando para bibliotecas Python poderosas como SciPy, NumPy e os muitos módulos que dependem delas. Segundo Granger, essas bibliotecas foram desenvolvidas no início dos anos 2000, mas não estavam prontas para uso em produção até mais tarde na década. Outras duas vantagens melhoraram sua popularidade: sendo livre de custos e sendo fácil de se misturar com outras bibliotecas Python para outras tarefas. Uma vez que as bibliotecas de Python se tornaram acessório de muitos campos da ciência e engenharia -- particularmente o novo campo que passou a ser conhecido como ciência dos dados -- seus usuários estavam abertos às ferramentas educacionais interativas oferecidas pelo IPython.

Não foi difícil para pessoas fora da academia apreciar o IPython. Todo mundo no campo ensina um curso às vezes, ou apenas dá uma apresentação na conferência. IPython e, em seguida, Jupyter, cortaram horas do tempo necessário para colocar o código e o texto de apresentação em uma formatação bonita. O projeto resolveu várias necessidades científicas de uma só vez: repetição de experiências de forma confiável, reprodutibilidade de resultados por outros pesquisadores e ensino ou conversação.

Granger não esconde nenhum fato sobre a importância do financiamento para o sucesso de seu projeto. Ele se beneficiou bastante cedo do apoio de Joshua M. Greenberg da Sloan Foundation, e agora também é financiado pela Moore Foundation e pelo Helmsley Charitable Trust. O projeto também possui inúmeros patrocinadores e parceiros institucionais e obtém importantes contribuições de código de cerca de 25 desenvolvedores em tempo integral.

Conclusão

Cada projeto de pesquisa que experimentou sucesso no mundo do software maior encontrou seu próprio caminho para a frente. Os exemplos que citei neste artigo não são, de modo algum, o fim da história. Por exemplo, o co-fundador da linguagem estatística R, Ross Ihaka, sugeriu (em um artigo) que os desenvolvedores mantinham R por anos em um "processo relativamente fechado" e tropeçaram por necessidade em práticas básicas de código aberto como o estabelecimento de mala direta listas e um grupo de contribuidores principais. Este projeto se parece com outro exemplo de software acadêmico que poderia ser rapidamente compreendido e adotado porque o público-alvo se parecia muito com os desenvolvedores e era tecnicamente adepto.

O navegador Mosaic, outro projeto histórico, começou como um projeto financiado pelo governo do National Center for Supercomputing Applications (NCSA) na University of Illinois Urbana-Champaign. O triunfo do Mosaic foi de curta duração, no entanto, porque o líder da equipe Mosaic, Marc Andreessen, logo começou a empresa Netscape e criou um navegador muito superior baseado nos princípios do Mosaic.

Não cobri o kernel do Linux ou o projeto GNU aqui, porque (além deles já serem famosos) não eram projetos acadêmicos, mesmo que Linus Torvalds e Richard Stallman passassem a estar associados às universidades quando lançaram os projetos.

Combinando o que eu ouvi dos líderes de projetos e dos outros líderes de software livre que entrevistei, sugiro que um esforço como o da Red Hat que eu mencionei no início do artigo teria as melhores chances de sucesso seguindo alguns princípios abrangentes. Primeiro, escolha um projeto cujo valor possa ser rapidamente compreendido e adotado pelos seus usuários pretendidos. Traha especialistas externos para avaliar o código por qualidade para se certificar de que vale a pena usar; caso contrário, pode fazer sentido lançar uma nova base de código com objetivos semelhantes. O código também deve ser fácil de generalizar e estender. Por último, o projeto deve ser retirado do ambiente acadêmico o mais rápido possível (com um pagamento para a universidade, se necessário) e atribuído de um líder de projeto que tenha experiência em construir comunidades em torno de projetos e recrutar empresas ou indivíduos para desenvolver código e toda a outra infraestrutura que um projeto de software livre precisa.

Terminarei com otimismo. Professores e alunos rotineiramente transformam suas idéias em software proprietário. Mas, dada a facilidade de codificação nos dias de hoje, e a resultante comoditização de software, alguns desses acadêmicos provavelmente considerarão tornar o software livre. Apache Spark, discutido anteriormente, é um exemplo. Outro é o MapD, um grande projeto de banco de dados que se beneficiou de um conselho de Michael Stonebraker, um dos principais pesquisadores e empreendedores do campo. Esta empresa obteve seu produto principal e foi financiada com uma quantia de 25 milhões de dólares. As organizações incipientes podem agora recorrer a organizações como a Apache Foundation e a Software Freedom Conservancy para o conselho organizacional. Em uma década ou mais, podemos saber muito mais sobre o que motiva os pesquisadores a abrir seu código e como eles podem o fazer com sucesso.