Num post anterior falei de quatro problemas do software livre. Inerentes a eles está o aspecto social do desenvolvimento de qualquer software, e principalmente de sistemas de informação. Muitas pessoas ainda não se dão conta que todas as etapas de desenvolvimento, da sua concepção enquanto idéia, até o seu uso se dá de forma social e, mais importante, com a participação do usuário. Pelo menos deveria ser assim para todo sistema de informação, já que este tipo de software é uma construção inerentemente social e tem por objetivo atender a uma demanda social (Brooks 1995). Pense em um sistema de controle de estoque, educacional, de controle bancário, de uma loja, etc. e fica fácil perceber que estes ficam sempre no meio de alguma interação social. Por isto, o desenvolvimento de um sistema para uma empresa sem a contribuição de seus potenciais usuários é um sistema fadado ao fracasso já na sua concepção.
No caso do software livre este aspecto social é ainda mais importante pelas características da equipe de desenvolvimento (Weber 2004). Elas são, em geral, dispersas geograficamente e possuem programadores trabalhando por uma motivação pessoal, às vezes sem nenhum tipo de compensação financeira. Por este motivo, os programadores precisam ser e estar motivados para trabalhar num projeto de software livre. Motivação esta que está diretamente atrelada a dois componentes do software: 1) o desafio técnico que ele oferece e 2) a grande base de usuários que terá acesso a seu código e usará o sistema, formando uma comunidade ativa de pessoas discutindo o mesmo. Pense em todos os softwares livre de sucesso: WordPress, Linux, Firefox, Apache, etc. São todos aplicativos de complexidade mais alta e de aplicação mais genérica, multi-uso, com uma comunidade ativa de usuários e desenvolvedores.
Este tipo de software motiva os melhores programadores do mundo inteiro. É exatamente o oposto de trabalhar num software para, digamos, uma loja no Brasil. Construir um software destes é relativamente simples e está restrito apenas aos usuários brasileiros; porque o conjunto de regras aqui é diferente das de outros países para este tipo de software. Assim, como os melhores programadores brasileiros dedicam seus tempos livres a projetos como o Linux, sobram para estes projetos específicos os programadores pagos pelo governo ou empresas, ou aqueles despreparados e que não conseguem contribuir em projetos mais desafiadores.
Não estou dizendo com tudo isto que sou contra o software livre. Também não o acho uma alternativa melhor ou pior que outras formas de desenvolvimento (e.g., software customizado ou produto) sem levar em conta o contexto. Ele é, para mim, apenas mais uma opção a ser considerada, com seus prós e contras. Não acho, por exemplo, que o governo brasileiro está errado em adquirir software livre. Acho que ele está errado em fazer este tipo de aquisição quando o faz porque o software é livre. É preciso sempre ponderar qual é a melhor solução para as necessidades de uso, sendo o tipo de licença do software e a forma de produzi-lo variáveis no processo.
A diretriz arbitrária do governo brasileiro de sempre optar por software livre é ruim para ele, para a população e para a indústria. De maneira análoga, o governo poderia também arbitrariamente decidir por comprar software brasileiro em detrimento de software de outros países. Fazendo isto, ele deixa de fazer a aquisição considerando o mais importante, a compra do software com o melhor potencial de atendê-lo em suas necessidades. A analogia é importante porque a indústria de tecnologia no Brasil era exatamente protegida desta forma até o começo da década de 90. O resultado foi um atraso tecnológico pelo qual até hoje pagamos o preço.
Note que adotar software proprietário não significa adotar padrões fechados ou bloquear o acesso à informação. É perfeitamente possível, comum até, utilizar um software proprietário com padrões abertos e que torne a informação mais acessível e disponível para todos. Basta lembrar que a base da Internet, o conjunto de protocolos TCP/IP, não nasceu aberto, muito pelo contrário, foi desenvolvido pelos militares americanos e com o objetivo de uso exclusivo. Mesmo hoje, o principal conjunto de protocolos e padrões da Internet são mantidos por uma organização americana patrocinada pela gigante VeriSign e pela Agência Nacional de Segurança dos EUA. É uma questão política complexa mas, simplificando, a Internet só é livre hoje porque os EUA deixa. (Sobre este assunto, recomendo o excelente conjunto de visualizações mostrando a geopolítica da Internet – em francês)
Concluindo, software livre não é solução de problemas por ser livre. Aliás, software livre, em si, não é solução de nada. Do ponto de vista do desenvolvimento, ele pode ser visto como uma modalidade de criação do software. Uma muito mais apropriada para alguns tipos de projeto, aqueles com potencial de atrair uma comunidade de desenvolvedores abrangente. Do ponto de vista do usuário final, é apenas mais uma variável a ser considerada no processo de aquisição. E uma que não deveria se sobrepor às suas necessidades de uso.
Num post anterior falei de quatro problemas do software livre. Inerentes a eles está o aspecto social do desenvolvimento de qualquer software, e principalmente de sistemas de informação. Muitas pessoas ainda não se dão conta que todas as etapas de desenvolvimento, da sua concepção enquanto idéia, até o seu uso se dá de forma social e, mais importante, com a participação do usuário. Pelo menos deveria ser assim para todo sistema de informação, já que este tipo de software é uma construção inerentemente social e tem por objetivo atender a uma demanda social (Brooks 1995). Pense em um sistema de controle de estoque, educacional, de controle bancário, de uma loja, etc. e fica fácil perceber que estes ficam sempre no meio de alguma interação social. Por isto, o desenvolvimento de um sistema para uma empresa sem a contribuição de seus potenciais usuários é um sistema fadado ao fracasso já na sua concepção.
No caso do software livre este aspecto social é ainda mais importante pelas características da equipe de desenvolvimento (Weber 2004). Elas são, em geral, dispersas geograficamente e possuem programadores trabalhando por uma motivação pessoal, às vezes sem nenhum tipo de compensação financeira. Por este motivo, os programadores precisam ser e estar motivados para trabalhar num projeto de software livre. Motivação esta que está diretamente atrelada a dois componentes do software: 1) o desafio técnico que ele oferece e 2) a grande base de usuários que terá acesso ao seu código e usará o sistema, formando uma comunidade ativa de pessoas discutindo o mesmo. Pense em todos os softwares livre de sucesso: WordPress, Linux, Firefox, Apache, etc. São todos aplicativos de complexidade mais alta e de aplicação mais genérica, multi-uso, com uma comunidade ativa de usuários e desenvolvedores.
Este tipo de software motiva os melhores programadores do mundo inteiro. É exatamente o oposto de trabalhar num software para, digamos, uma loja no Brasil. Construir um software destes é relativamente simples e está restrito apenas aos usuários brasileiros; porque o conjunto de regras aqui é diferente das de outros países para este tipo de software. Assim, como os melhores programadores brasileiros dedicam seus tempos livres a projetos como o Linux, sobram para estes projetos específicos os programadores pagos pelo governo ou empresas, ou aqueles despreparados e que não conseguem contribuir em projetos mais desafiadores.
Não estou dizendo com tudo isto que sou contra o software livre. Também não o acho uma alternativa melhor ou pior a outras formas de desenvolvimento (e.g., software customizado ou produto) sem levar em conta o contexto. Ele é, para mim, apenas mais uma opção a ser considerada, com seus prós (que quase todo mundo conhece) e contras (dos quais falei aqui). Não acho, por exemplo, que o governo brasileiro está errado em adquirir software livre. Acho que ele está errado em fazer este tipo de aquisição quando o faz porque o software é livre, sem considerar exatamente seus prós e contras e os de outras opções. É preciso sempre ponderar qual é a melhor solução para as necessidades de uso, sendo o tipo de licença do software e a forma de produzi-lo variáveis no processo.
A diretriz arbitrária do governo brasileiro de sempre optar por software livre é ruim para ele, para a população e para a indústria. De maneira análoga, o governo poderia também arbitrariamente decidir por comprar software brasileiro em detrimento de software de outros países quando houver a opção. Fazendo isto, ele deixa de fazer a aquisição considerando o mais importante, a compra do software com o melhor potencial de atendê-lo em suas necessidades. A analogia é importante porque a indústria de tecnologia no Brasil era exatamente protegida desta forma até o começo da década de 90. O resultado foi um atraso tecnológico pelo qual até hoje pagamos o preço.
Note que adotar software proprietário não significa adotar padrões fechados ou bloquear o acesso à informação. É perfeitamente possível, comum até, utilizar um software proprietário com padrões abertos e que torne a informação mais acessível e disponível para todos. Basta lembrar que a base da Internet, o conjunto de protocolos TCP/IP, não nasceu aberto, muito pelo contrário, foi desenvolvido pelos militares americanos e com o objetivo de uso exclusivo. Mesmo hoje, o principal conjunto de protocolos e padrões da Internet são mantidos por uma organização americana patrocinada pela gigante VeriSign e pela Agência Nacional de Segurança dos EUA. É uma questão política complexa mas, simplificando, a Internet só é livre hoje porque os EUA deixa.
(Sobre este assunto, recomendo o excelente conjunto de visualizações mostrando a geopolítica da Internet: http://www.arte.tv/fr/Comprendre-le-monde/le-dessous-des-cartes/392,CmC=396,view=maps.html – em francês)
Concluindo, software livre não é solução de problemas por ser livre. Aliás, software livre, em si, não é solução de nada. Do ponto de vista do desenvolvimento, ele pode ser visto como uma modalidade de criação do software. Uma muito mais apropriada para alguns tipos de projeto, aqueles com potencial de atrair uma comunidade de desenvolvedores abrangente. Do ponto de vista do usuário final, é apenas mais uma variável a ser considerada no processo de aquisição. E uma que não deveria se sobrepor às suas necessidades de uso.