ITI/SOFTEX 1 Alves, A.M. INDICE 1. INTRODUÇÃO... 6 1.1. OBJETIVOS... 6 1.2. ESTRUTURA DO ESTUDO... 7 CAPÍTULO 1. MODELO DO SOFTWARE LIVRE...10 1.1. CONCEITOS E DEFINIÇÕES...10 1.1.1 Software livre e código aberto...11 1.1.2 Licenças...13 1.1.3 Segurança e Transparência...15 1.2. DINÂMICA DE DESENVOLVIMENTO DE SOFTWARE LIVRE...15 1.3. MERCADO DE SOFTWARE LIVRE...17 CAPÍTULO 2. O JOGO DO SOSTWARE LIVRE...19 2.1. MARCO CONCEITUAL...19 2.2. AS CARACTERÍSTICAS DO JOGO DO SOFTWARE LIVRE...21 2.3. OS ATORES DO JOGO DO SOFTWARE LIVRE...22 CAPÍTULO 3. MARCO ANALÍTICO...24 3.1. CARACTERIZAÇÃO DAS PREFEITURAS...25 3.2. DESCRIÇÃO DO COMPORTAMENTO DAS PREFEITURAS...27 3.2.1. Os Arranjos Institucionais...27 3.2.2. Os Tipos de Licença...28 3.2.3. Forma de Representação do comportamento das Prefeituras...28 3.3. DOMÍNIOS DA APLICAÇÃO DO SOFTWARE...30 3.4. CONFIGURAÇÕES E ESTILOS DE DISPONIBILIZAÇÃO...31 3.4.1. O Estilo de Disponibilização Induzido...32 3.4.2. O Estilo de Disponibilização Sem Indução...32 3.5. CONSIDERAÇÕES SOBRE O MARCO ANALÍTICO...34 3.5.1. Primeiro conjunto de informações-evolução e Avaliação dos Atributos...36 3.5.2. Segundo conjunto de informações-trajetória Contextual dos Atributos...36 3.5.3. Terceiro conjunto de informações - Processo de Migração dos Domínios de Aplicação...37
ITI/SOFTEX 2 CAPÍTULO 4. AMOSTRA, METODOLOGIA E ANÁLISE DOS RESULTADOS...39 4.1. DEFINIÇÃO DA AMOSTRA E METODOLOGIA...39 4.1.1. Os Municípios no Brasil...39 4.1.2. A Amostra...42 4.1.3. Os municípios da amostra...43 4.1.4. As empresas fornecedoras de serviços de SL para as prefeituras...43 4.1.5 Representação do Comportamento das Prefeituras...44 4.1.5.1. Amparo...44 4.1.5.2. Rio das Ostras...45 4.1.5.3. Porto Alegre...46 4.1.5.4. Viamão...47 4.1.5.5. Belo Horizonte...48 4.1.5.6. Sobral...49 4.1.5.7. Solonópole...50 4.1.5.8. Manaus...51 4.1.5.9. Recife...52 4.1.5.10. Petrolina...53 4.1.5.11. Campinas...54 4.1.5.12. Sao Paulo...54 4.1.5.13. Pirai...55 4.1.6 Caracterização detalhada das prefeituras da Amostra...56 4.2. ANÁLISE DOS RESULTADOS...63 4.2.1. Aspectos relacionados à Demanda de SL nas Prefeituras...63 Barreiras...63 Oportunidades...66 Licenças...67 Mão de Obra...67 Hardware...68 Liderança...68 Comunidade & Colaboração...69 Universidades & Empresas Parceiras...69 Decisão...70 4.2.2. Aspectos Econômicos...70 4.2.2.1. Custos & Oportunidades de Difusão...70 4.2.2.2 Impactos Econômicos...72 4.2.2.3. Fornecedores...74 4.2.3. Aspectos Sociais...75 4.2.3.1. Não aprisionamento tecnológico e dificuldades para migração e custos...75 4.2.3.2. Impacto Social...77 4.2.3.3. Laços com Universidades...78 4.2.3.4. Realocação de recursos...79 4.2.4. Aspectos Tecnológicos...80 4.2.4.1. Categorias de Software para uso no âmbito da prefeitura...80
ITI/SOFTEX 3 4.2.4.2. Cenários de difusão...81 4.2.4.3. Estrutura de Produtos...83 4.2.4.4. Capacitação Tecnológica...84 4.2.4.5. Melhoria de Segurança e Qualidade...86 4.2.4.6. Barreiras a extensão e aprofundamento do SL...87 4.3. MODELOS DE NEGÓCIOS...89 4.3.1.Modelo Proprietário utilizando Ferramentas Livres...90 4.3.2. Modelo de Desenvolvimento de Software Livre...92 4.3.2.1. Mercado das Pequenas Prefeituras...96 4.3.2.2. Mercado das Médias Prefeituras...97 4.3.2.3. Mercado das Grandes Prefeituras...97 4.3.2.4. As Empresas Fornecedoras de SL...98 4.4. FINANCIAMENTO...98 PMAT...98 PNAFM...99 Obstáculos para obtenção... 100 CAPÍTULO 5. CONCLUSÕES E RECOMENDAÇÕES...102 REFERENCIAS BIBLIOGRÁFICAS...104 BIBLIOGRAFIA CONSULTADA...106 ANEXO 1- CARACTERIZAÇÃO DA AMOSTRA...114 1. PREFEITURA DE AMPARO(SP)...115 2. PREFEITURA DE RIO DAS OSTRAS (RJ)...118 3. PREFEITURA DE PORTO ALEGRE (RS)...123 4. PREFEITURA DE VIAMÃO (RS)...131 5. PREFEITURA DE BELO HORIZONTE(MG)...133 6. PREFEITURA DE SOBRAL(CE)...141 7. PREFEITURA DE SOLONÓPOLE(CE)...150 8. PREFEITURA DE MANAUS(AM)...157 9. PREFEITURA DE RECIFE(PE)...163 10. PREFEITURA DE PETROLINA(PE)...185 11. PREFEITURA DE CAMPINAS(SP)...187
ITI/SOFTEX 4 13. PREFEITURA DE PIRAÍ...199 ANEXO 2 BANCO DE DADOS E REPRESENTAÇÃO GRÁFICA DAS PREFEITURAS...204 ANEXO 3 QUESTIONÁRIO DE SOFTWARE LIVRE NAS PREFEITURAS...219 QUESTIONÁRIO SOFTWARE LIVRE...220
Projeto Aplicação de Software Livre em Prefeituras ITI/SOFTEX 5
ITI/SOFTEX 6 1. Introdução Este capítulo possui duas seções. A primeira apresenta os objetivos do estudo. A segunda sintetiza os grandes blocos do estudo e suas metas e pontos principais. 1.1. Objetivos Cinco blocos foram inicialmente identificados pela equipe do Projeto, por ocasião dos primeiros contatos com a equipe do ITI, como balizadores para a sua concepção. A caracterização de objetivos elaborada a partir desses elementos contribui para o entendimento da orientação que a equipe imprimiu ao Projeto e, logo, para a obtenção dos resultados alcançados. Os objetivos são: Principal: Apresentar uma análise de viabilidade de difusão do modelo de Software Livre (SL) nas prefeituras brasileiras Secundários: Construir um painel analítico das principais experiências de aplicação de SL em municípios, sistematizando e avaliando os resultados obtidos; Avaliar as condições de financiamento e modelos de negócios viáveis para o desenvolvimento de projetos de SL para prefeituras; Gerar subsídios para ações governamentais voltadas para implantação de SL em prefeituras. O contexto estrutural ao qual se direcionam os resultados desse projeto é caracterizado pelos seguintes aspectos: as mais de 5.500 prefeituras brasileiras objeto deste Projeto - conformam um todo sob vários aspectos heterogêneo;
ITI/SOFTEX 7 90% das prefeituras brasileiras são de pequeno porte (IBGE,2001); as definições usualmente utilizadas para definir a informatização de prefeituras, critério adotado pelo IBGE, são insuficientes para relatar a realidade atual, os programas de financiamento à informatização das prefeituras não estão alcançando um nível satisfatório de efetividade. mercado brasileiro de software, estimado em 10,4 bilhões de dólares, é o sétimo maior mercado mundial 77 empresas nacionais (64% do total) faturam 1,7 bilhões (16% do mercado) 44 empresas estrangeiras (36% do total) faturam 8,7 bilhões (84% do mercado) setor público responde por 30 a 50% do mercado legal as empresas pequenas são discriminadas no atendimento ao setor público, sobretudo federal a Legislação (8666 e Responsabilidade Fiscal) induz o setor público a usar Software Proprietário (SP) a formação de RH nas universidades é focada em SP Para a avaliação do mercado potencial de prefeituras brasileiras foram analisados os dados da Pesquisa Perfil dos Municípios Brasileiros - Gestão Pública 2001, disponível no site do IBGE. O IBGE apresenta as informações obtidas pela pesquisa realizada em 2001, junto às prefeituras dos 5.560 municípios brasileiros, relativamente ao tema Gestão pública. As Notas Técnicas da pesquisa, disponíveis no mesmo site apresentam as características, dificuldades e outros aspectos relevantes da pesquisa. As tabelas e dados relevantes para este estudo estão descritos na parte inicial do Capítulo 5 - AMOSTRA, METODOLOGIA E ANÁLISE DOS RESULTADOS. 1.2. Estrutura do Estudo Este estudo apresenta os resultados e recomendações que se constituem em subsídios significativos para tomadas de decisão do ITI em relação ao tema. À medida que, de forma iterativa e recorrente, foi se realizando o trabalho de coleta e processamento de informação secundária e empírica, de interpretação teórica dos processos de construção sócio-técnica e adoção do modelo do SL, e de formulação de esquemas relacionais capazes de integrar os blocos de conteúdo que se estava produzindo em simultâneo,
ITI/SOFTEX 8 esse movimento de afunilamento foi fazendo emergir os resultados e algumas recomendações mais significativas. Os cinco blocos identificados pela equipe do projeto estão descritos abaixo. O primeiro trata da compreensão dos assuntos relacionados a SL por diversos prismas e diversas interpretações, da dinâmica de desenvolvimento do SL, do mercado de SL e é apresentado no Capítulo 5 Modelo do SL. A definição de um modelo do SL, este conhecimento em processo de construção sóciotécnica ainda em aberto cujas implicações sociais se trata de conformar, compõe o segundo bloco e é apresentado no Capítulo 2 O Jogo do SL. Esse segundo bloco resulta de um esforço para entender a relação existente entre os atores quadros técnico-políticos de governo, empresários de software, Prefeituras, comunidade de SL - que participam nesse jogo do SL. Esse resultado procura dar conta, a partir do enfoque de Análise de Políticas Públicas, das interações - pactos, alianças, movimentos de cooptação, neutralização e enfrentamento - que atores sociais - pessoas, organizações - realizam, por intermédio dos recursos - políticos, econômicos, midiáticos, cognitivos - que controlam, para influenciar agendas e processos decisórios - e de não-tomada de decisão - visando à construção, a partir do modelo do SL, de estilos sócio-técnicos - e, em particular, Arranjos Institucionais - que potencializem seus interesses e projetos políticos. O terceiro bloco, Capítulo 3 - Marco Analítico, mantém a preocupação com a explicação dos comportamentos esperados dos atores, agora colocando o foco no ator Prefeitura e buscando referi-los e explicá-los mediante o marco de referência analítico-conceitual formulado pela equipe do Projeto. Através desse marco foi possível sistematizar conteúdos dos dois blocos já citados e orientar o trabalho de campo previsto pelo Projeto, abarcando entrevistas a Prefeituras envolvidas com SL, empresas, agências de governo, órgãos de financiamento e formadores de opinião. O emprego do marco analítico na sistematização da informação empírica coletada através do trabalho de campo permitiu a geração do quarto bloco contendo os resultados da pesquisa de campo, apresentados de forma sintética no Capítulo 4 - Amostra, Metodologia e Análise dos Resultados. Esse capítulo, após apresentar a amostra e a metodologia empregada na sua seleção, focaliza na análise desses resultados, agrupados segundo atributos de natureza genérica - Capacidade Financeira, Capacidade Técnica, Grau de Informatização, Capacidade de Articulação - ou especificamente relacionados ao SL - Motivação /Demanda, Entorno/Ambiente, Imposição Legal.
ITI/SOFTEX 9 Complementa-se com a análise da trajetória recente de cada Prefeitura, observada mediante sua referência a um espaço bidimensional - eixos de crescente indução do Estado e de adoção de SL. Dessa maneira, ao proporcionar uma explicação das trajetórias individuais das Prefeituras segundo um mesmo conjunto de atributos, o marco de referência empregado sugere hipóteses preliminares acerca das motivações que as levaram à definição e perseguição de uma estratégia de entrada nos ambientes sócio-técnico e institucionais do SL e, principalmente, à busca de implementação de mudanças em seus domínios de aplicação (infra-estrutura, desktop, gestão interna, e integração e comunicação). Essas hipóteses explicativas das trajetórias observadas, bem como o comportamento esperado das Prefeituras frente a dois modelos extremos de Arranjos Institucionais para a disponibilização de SL com ênfases opostos nos níveis de indução por parte do Estado, são os elementos a partir dos quais se organizam as Conclusões e Recomendações o quinto bloco, apresentado no Capítulo 5. Frente a este contexto, o estudo pode vir a contribuir para a construção de uma estratégia nacional em SL que promova o desenvolvimento nacional, em especial das pequenas e médias empresas.
ITI/SOFTEX 10 Capítulo 1. Modelo do Software Livre 1.1. Conceitos e Definições CONTEXTO Por um lado, a análise de janelas de oportunidades tecnológicas pelos estudiosos da economia da tecnologia já demonstrou, sobretudo quando aplicada a países periféricos, a importância das ações do estado, de caráter antecipatório e de natureza normativa no sentido de seu aproveitamento em beneficio do conjunto da sociedade. A sociologia da inovação, por sua parte, tem mostrado como um corpo de conhecimento técnico-científico pode dar lugar a diferentes trajetórias de construção sócio-técnica a depender dos interesses dos grupos de atores sociais que, durante o período inicial de flexibilidade interpretativa, participam do seu desenvolvimento. O processo de fechamento que se segue, a partir do qual esse conhecimento é materializado em artefatos tecnológicos, e que novos bens e serviços passam a ser produzidos, é determinado pelos contratos econômicos e sociais, e pelos arranjos político-institucionais influenciados por esses interesses. São eles que, ao limitar, modificar e realimentar aquelas potencialidades, originam o tecido sem costuras que passa a caracterizar o paradigma técnico-econômico que irá determinar a forma de emprego do conhecimento e as implicações diferenciadas que terá na vida dos diferentes grupos sociais. O SL encontra-se atualmente, principalmente nos países periféricos, no estágio de construção, flexibilidade interpretativa, longe ainda de alcançar o fechamento. Com o objetivo de contribuir para a construção e entendimento deste processos, são apresentados a seguir conceitos e entendimentos necessários para a formulação de estratégias que sejam vetores para a construção sócio-técnica do SL adequadas para o país.
ITI/SOFTEX 11 DEFINIÇÕES Os assuntos relacionados a software livre podem ser observados por diversos prismas, resultando em diferentes interpretações. Segundo Cezar Taurion (Taurion, 2004), software livre é, antes de tudo, um modelo de negócios. Já para Amadeu (2004), é um modelo de contratação. Neste estudo, o software livre é abordado como um modelo de disponibilização associado a uma dinâmica de desenvolvimento de software. Por disponibilização compreende-se formas de comercialização (produtos/serviços) associados a modelos de licenciamento do software para os usuários. Neste documento, considera-se que os conceitos convencionais relacionados às questões de software livre sejam de conhecimento geral. Existe atualmente uma vasta literatura que cobre estes temas, seja na Internet ou impressos. Para evitar a simples reprodução dos conceitos, sugere-se a leitura de algumas das referências bibliográficas selecionadas e apresentadas ao final deste documento. Entretanto, por existirem diferentes definições possíveis para alguns conceitos fundamentais, considera-se oportuno delineá-los, especificando como são interpretados e utilizados no contexto deste documento, para que haja uma homogeneização da compreensão do mesmo. 1.1.1 Software livre e código aberto Um software é dito livre quando apresenta quatro liberdades: é livre para ser utilizado, estudado, alterado, redistribuído e copiado. Para que algumas destas características sejam possíveis, também é fundamental que esteja disponível o código fonte que deu origem ao software. Logo, um software livre tem código aberto. Dentro do conceito de software livre, há duas grandes correntes que se diferenciam por suas orientações e filosofias: Free Software, software livre em inglês, mais antiga, criada na década de 80, e que incorpora alguns princípios ao conceito geral: as liberdades citadas, conferidas aos usuários, devem ser características inerentes do software e de todas as suas versões futuras e trabalhos derivados. Open Source, código aberto em inglês, criada na década de 90, que dá o foco nas virtudes do código fonte aberto - difusão, possibilidade de cooperação entre os desenvolvedores, reaproveitamento de trabalho anterior, permite rápido
ITI/SOFTEX 12 desenvolvimento com qualidade, sem preocupar-se com as questões das liberdades defendidas pela outra corrente. Em termos práticos, um software que é livre segundo os conceitos Free software sempre o será e ninguém poderá incorporá-lo nem transformá-lo em software proprietário. Se o código fonte de um software que é Free Software for incorporado em outro programa, este novo software também terá que ser Free Software. Por outro lado, um software que é livre segundo os conceitos Open Source, também seguirá livre para sempre, mas seu código fonte também poderá ser utilizado em projetos de software proprietário. Para simplificação, nesse estudo serão adotados os seguinte conceitos : Software Livre, com iniciais maiúsculas, denotará o software livre segundo os conceitos de Free Software. Código Aberto, com iniciais maiúsculas, denotará o software livre segundo os conceitos de Open Source. Tem-se percebido recentemente o uso inadequado do termo software livre para designar produtos de software que não são livres, mas que são desenvolvidos com a finalidade de serem executados em plataformas consideradas livres, como por exemplo, plataformas com sistema operacional Gnu/Linux e OpenBSD. Da mesma forma como há software livre que pode ser utilizado em sistemas operacionais não-livres, como as ferramentas de escritório OpenOffice sobre as diversas versões de MS Windows, também é possível a existência de software não-livre para utilização em sistemas operacionais livres, como bancos de dados Oracle sobre Gnu/Linux. É fundamental fazer esta distinção e caracterizar adequadamente cada software. Em última análise: para ser considerado livre, seja Software Livre ou Código Aberto, o código fonte completo do software em questão deve sempre estar disponível para seus usuários. Se não estiver disponível, não é software livre. Esta é uma condição necessária mas não suficiente como já observado anteriormente. Em contraposição ao software livre está o software proprietário, ou seja, o software fechado, em que somente o detentor dos direitos de propriedade intelectual tem acesso ao seu código fonte e os usuários podem utilizar o software, mas não têm permissão de alterá-lo, até porque não dispõem do código fonte para tal, copiá-lo, redistribuí-lo nem revendê-lo. São estabelecidos preços por cópia instalada e para a atualização para novas versões.
ITI/SOFTEX 13 1.1.2 Licenças De acordo com a legislação brasileira (LEI, ano), pautada por acordos internacionais de direitos autorais, o criador de um software tem o poder de definir a forma como sua criação pode ser utilizada. Esta característica é indistinta para software livre e para software proprietário. O(s) desenvolvedor(es) de um software escolhem a forma pela qual o software poderá ser usado e distribuído, segundo suas próprias visões, necessidades e/ou filosofias e segundo as regras e restrições que lhes são definidas. Esta definição se dá aplicando-se ao programa de computador licenças de uso de software. O autor associa o software a uma licença, onde descreve as situações, as restrições e os direitos dos usuários sobre o software, e como estes podem exercê-las. Uma licença de software é, portanto, como um contrato de adesão, ao qual o usuário deve submeter-se se deseja utilizar o software. Esta é a forma pela qual os desenvolvedores de software proprietário e de software livre disponibilizam suas criações para terceiros, usuários e desenvolvedores. Em geral, as licenças de software proprietário permitem somente que o usuário utilize o software, de acordo com as regras do titular, geralmente a empresa desenvolvedora ou distribuidora, sendo vedada sua reprodução, instalação múltipla sem o devido pagamento adicional, alteração, cessão, revenda ou redistribuição. No caso de software livre, a escolha destas regras, licenças, permite definir o modelo, Software Livre ou Código Aberto, pelo qual o software deverá reger-se. Existem dezenas de tipos de licenças de software livre, mais ou menos populares e cada desenvolvedor pode adotar uma delas ou criar a sua própria, baseada ou não nas existentes. Tomemos dois exemplos de licenças que servirão de protótipo para os modelos citados: como exemplo de licença de software livre/software Livre, será utilizada a GNU GPL e como exemplo de licença de software livre/código Aberto será utilizada a licença BSD atualizada. A figura 1.1 ilustra possíveis caminhos de um software em relação às licenças a que poderá ser submetido ao longo do tempo, a partir da criação original por parte de um autor. A figura apresenta as possíveis conseqüências ao longo do tempo da decisão do autor do software quando da publicação da sua criação. Se o autor decidir publicar seu software com a licença GNU GPL, o software original, todas suas versões futuras e trabalhos derivados, ou seja, aqueles que utilizam boa parte do software em sua versão original ou nas versões subseqüentes, também deverão ser publicados sob esta mesma
ITI/SOFTEX 14 licença. Todas as versões futuras e trabalhos derivados serão software livre/free Software. Por outro lado, se o autor decidir publicar seu software original sob a licença BSD, as versões futuras e os trabalhos derivados terão outras possibilidades de continuidade. Em qualquer momento, o autor ou outros desenvolvedores poderão publicar novas versões e trabalhos derivados baseados no código fonte original sob outra licença. A versão original continuará com sua licença BSD, mas as versões subseqüentes poderão ser inclusive não livres. Figura - Licenças de software e seus relacionamentos Software livre Versão A A - GPL B - GPL n - GPL B - GPL n - GPL A - BSD B - BSD n - BSD Free software Open Source Software proprietário B - PRP n - PRP Obs: PRP identifica uma licença de software proprietário, não-livre. Figura 1.1. Licenças de Software e seus Relacionamentos Ainda observando a Figura 1.1 pode-se também avaliar a situação em que um desenvolvedor decide criar um software e que lança mão de trechos de software livre já disponível, essa é uma vantagem do modelo de desenvolvimento de software livre: a possibilidade de reaproveitar código pronto e já testado, do qual não se é o autor. No caso de ter sido utilizado como ponto de partida um código fonte GNU GPL, este novo software também deverá ser GNU GPL, obrigatoriamente. Cabe ressaltar aqui que o desenvolvedor deste trabalho derivado não será obrigado a redistribuir o novo software se o fizer para seu próprio uso, de seu empregador ou de seu contratante, mas se o fizer terá que respeitar esta regra. Por outro lado, se o código fonte original for licenciado segundo uma licença de Código Aberto, como é o caso da BSD citada acima, este novo programa poderá ser licenciado da forma que aprouver ao seu desenvolvedor: continuar como BSD, ser transformado em
ITI/SOFTEX 15 GNU GPL ou em outra licença de software livre ou ser transformado em software proprietário sem que o código fonte esteja disponível. 1.1.3 Segurança e Transparência Esta é uma das características mais importantes do ponto de vista do setor público, uma vez que o sigilo e a privacidade das informações são fundamentais para muitos dos dados que são armazenados nos seus sistemas de informação. Ao ter seu código aberto ao escrutínio público, o software livre é naturalmente seguro. Todo código de software livre está à disposição para avaliação e melhorias. Isto dá a oportunidade de muitos aprenderem técnicas de programação e também de colaborarem na melhoria de programas, por exemplo, nas questões ligadas à segurança. Além disso, o sigilo e a privacidade nos software livres também são características marcantes, uma vez que é impossível introduzir, por exemplo, portas traseiras no software ou definir canais de comunicação sem que isto possa ser detectado com simples inspeção do código fonte. Se por motivos quaisquer o produtor de um software decidir introduzir algum tipo de mecanismo de escuta ou de acesso não autorizado no código fonte pensará duas vezes ao saber que seu código poderá ser, a qualquer momento, avaliado por terceiros que poderão encontrar tal código indevido. 1.2. Dinâmica de desenvolvimento de software livre Outra característica marcante no software livre é sua dinâmica de desenvolvimento. Tradicionalmente, o desenvolvimento de software proprietário é realizado por grupos de desenvolvedores dentro de uma empresa ou de empresas contratadas para tal, sob contratos que impedem a divulgação e o uso de informações relacionadas ao produto em desenvolvimento. Tudo está envolvido em questões de sigilo industrial e o conhecimento relacionado à produção dos software é considerado como um ativo muito importante da empresa proprietária dos mesmos. No âmbito do software livre, ao contrário, o desenvolvimento ocorre mais freqüentemente em grupos heterogêneos e fracamente relacionados, ou seja, sem que haja contratos formais nem vínculos dos desenvolvedores a empresas ou organizações que estejam diretamente envolvidas com o desenvolvimento do dito software. Esta forma de ação permite a troca de informações e a constante evolução tanto do software quanto dos que
ITI/SOFTEX 16 participam daquele grupo, pois estarão sempre aprendendo técnicas e métodos com os demais companheiros de desenvolvimento. O desenvolvimento de um software sob estas condições exige que exista um líder de projeto - em geral a pessoa com atuação mais destacada no mesmo, que decide quais colaborações incorporar, quais as prioridades e os rumos do software. Se alguém discorda, pode haver debates e ajustes. Se não se chega em um acordo, sempre há a possibilidade de iniciar-se um novo projeto, com novas prioridades e rumos, utilizando todo o software já desenvolvido, e partindo do ponto exato onde houve a ruptura. Formam-se comunidades em torno da criação e evolução de determinados software. Aos desenvolvedores se somam os usuários dos software, que sempre contribuem de uma forma ou outra, para a evolução do mesmo - quer seja pela descoberta de bugs quer pela sugestão de melhorias e de possíveis direcionamentos do desenvolvimento. Outros colaboradores se unem também às comunidades - tradutores, investidores, artistas gráficos, editores de livros; para apoiar e participar da criação do software. Este modelo de desenvolvimento também permite que muitos indivíduos e empresas possam colaborar para produzir um produto que nenhum deles seria capaz de elaborar sozinho, por complexo ou pelo custo. Também permite uma correção rápida de bugs e o incremento da segurança, porque o código fonte pode ser inspecionado publicamente e isto faz com que ele seja exposto a severas avaliações. Outra característica interessante é a possibilidade de realizar alterações específicas, de acordo com as necessidades individuais de cada usuário, gerando diversas versões personalizadas. Quando a massa de usuários de um software torna-se significativa, é freqüente que alguns membros destes coletivos organizem-se de forma a poder prestar serviços profissionais relacionados aos software criados - capacitação, implantação, suporte, manutenção, adaptações específicas não contempladas pelo planejamento do software, integração com outras ferramentas. Outras vezes, empresas já estabelecidas percebem a oportunidade de mercado e passam a oferecer estes serviços relacionados e/ou a incorporar o software em seu leque de opções para seus clientes. Estas empresas, muitas vezes passam a contribuir financeiramente ou com pessoal para que a comunidade continue melhorando o software - (que agora faz parte do seu negócio. A dinâmica do desenvolvimento de software, bem compreendida e bem implementada, é o que permite às cooperativas e às empresas de software livre participar do mercado, por vários motivos. O reaproveitamento de código propicia ganhos de produtividade, o que permite o desenvolvimento rápido e a possibilidade de estar mais cedo no mercado.
ITI/SOFTEX 17 Adicionalmente, como o código reaproveitado já foi testado e depurado em outras soluções haverá potencialmente uma menor quantidade de erros no software e ele será potencialmente mais estável e mais seguro. Ao adotar a dinâmica do software livre como padrão de desenvolvimento -comunidade, reaproveitamento de código, colaboração, a empresa amplia seu capital intelectual sem necessariamente investir em ampliação de quadro de pessoal - pela participação de diversos desenvolvedores e colaboradores sem vínculo com a empresa - e reduz custos internos, pois utiliza plataformas de desenvolvimento livres compostas por ferramentas de baixo ou nenhum custo - compiladores, bibliotecas, ambientes de desenvolvimento. Além disso, os desenvolvedores, que trabalham em colaboração com terceiras empresas e pessoas, aprendem constantemente com o código de outros. Por outro lado, nos modelos de negócio baseados em software livre, o retorno financeiro tende a ser menor se comparado com os possíveis retornos em modelos ligados ao software proprietário, uma vez que não se aplicam os valores referentes às licenças de uso e o usuário tem a possibilidade de migrar de prestador de serviço sempre que desejar, tornando mais baixa a barreira de entrada de novas empresas neste mercado. Também é importante ressaltar que, muitas vezes, uma encomenda específica de uma solução informática não encontra, dentre os milhares de projetos livres disponíveis, um software pronto para implantação. Neste caso, os profissionais que receberam a encomenda devem tomar a decisão de ou partir para uma implementação completa ou adaptar um software existente de acordo com os requisitos definidos para a solução encomendada. Mesmo no caso de uma implementação completa haverá o reaproveitamento de código livre - uma vez que, por definição, trechos de código livre também o são - quer seja pelo uso de bibliotecas prontas e já testadas para a realização de tarefas comuns - tarefas que são encontradas freqüentemente em muitos software, como manipulação de arquivos - ou pelo uso de trechos retirados diretamente de outros software que apresentem funcionalidades desejadas para a nova solução. 1.3. Mercado de software livre As diversas licenças de software livre definem, portanto, as trajetórias possíveis do código fonte ao longo do tempo. Também definem o enquadramento do software em uma das duas correntes identificadas dentro da comunidade internacional de software livre. Entretanto elas não afetam substancialmente a forma de realização de negócios em torno
ITI/SOFTEX 18 ao software, dentro do que se convenciona chamar modelos de negócio adequados ao mundo do software livre. Não é na venda de produtos empacotados que está o negócio do software livre. O software em si muitas vezes está facilmente disponível, inclusive sem custos de aquisição, mas com a complexidade dos sistemas e das necessidades dos usuários de hoje em dia, não basta possuir um CD com o software. É sim necessário pessoal especializado para, por exemplo, identificar e definir as necessidades do usuário, desenvolver um sistema que as atenda no marco da estrutura econômico-financeira da organização e de suas vinculações operacionais, municípios com outros municípios, estados e governo federal, implantá-lo e capacitar os usuários no uso do mesmo. Bem como oferecer manutenção e upgrades. Como não existem restrições para reprodução e redistribuição, a cobrança por cópia instalada é impraticável como negócio: não haveria demanda por algo com um preço elevado que pode ser conseguido facilmente sem custos ou com custo irrisório.
ITI/SOFTEX 19 Capítulo 2. O Jogo do Sostware Livre Este capítulo apresenta o resultado do esforço da equipe do projeto para entender com propriedade a relação existente entre os atores agências de governo, empresas, Prefeituras, comunidade de SL - que participam no que denominamos Jogo do SL. Ele tem como balizamentos a observação das características do Modelo do SL analisado no capítulo anterior, a sistematização de aspectos políticos, econômicos, técnicos, de financiamentos etc., proporcionados pelo levantamento da situação atual das prefeituras e seu entorno, realizada mediante o marco de referência exposto no capitulo que segue. Através desse resultado foi possível conceber a formatação da situação-problema que deu origem ao marco de referência apresentado no Capítulo que segue, e avaliar as respostas plausíveis dos atores às ações desencadeadas pelo ITI no sentido da construção dos Cenários apresentados no último Capítulo. Sua primeira seção apresenta brevemente a referência conceitual da Gestão Estratégica que adotamos para caracterizar o Jogo do SL. 2.1. Marco Conceitual Chamamos ator social uma pessoa, grupo ou organização que participa de algum jogo social; que possui um projeto político, controla algum recurso relevante, tem, acumula ou libera forças no seu decorrer e possui, portanto, capacidade de produzir fatos capazes de viabilizar seu projeto. Assim, qualquer ator social, com projeto e capacidade de produzir fatos, é capaz de fazer pressão para alcançar seus objetivos, podendo acumular força, gerando e mudando suas estratégias para converter-se num centro criativo de acumulação de poder. O diagnóstico inicial de problemas que conformam uma situação a ser enfrentada por um ator mediante ações estratégicas pode ser visto como o resultado do jogo em que tomaram parte, num momento pretérito, um conjunto de atores.
ITI/SOFTEX 20 É possível caracterizar o agir social como um jogo, que pode ser de natureza cooperativa ou conflitiva, em que diferentes jogadores, com perspectivas que podem ser comuns ou divergentes, possuem recursos distribuídos segundo suas histórias de acumulação de forças em jogos anteriores. As regras do jogo podem se alterar segundo o interesse dos atores em função de jogadas e acumulações dos jogadores, reconfigurando as condições em que ele se desenvolverá. Nessa perspectiva, qualquer situação pode ser entendida pelo ator com ela envolvido como o resultado, o placar, de um jogo e pode ser por ele encarada como um problema a resolver, ou seja, o êxito em um jogo será a solução de um problema ou a mudança do placar. Os governantes ou encarregados da gestão de uma dada situação podem ser visto como jogadores que, com suas ações, produzem acumulações durante um jogo, procurando alterar seu resultado. É com base nessas acumulações que eles podem ampliar, ou reduzir, sua capacidade de produzir novas jogadas e alterar a situação inicial. Este é o mecanismo básico através do qual se acumula ou libera poder e se produz ou não mudanças significativas sobre uma dada situação problemática. A ação de governo, para gerar acúmulo de poder e gerar resultados socialmente valorizados, exige: a perfeita identificação dos jogos e problemas em que o governante está envolvido; a determinação de qual deve ser sua relação com outros problemas e jogadores; a identificação precisa de suas manifestações sobre a realidade ou evidências que permitam verificar se o problema está se agravando ou sendo solucionado pela ação de governo, e a diferenciação entre as causas e conseqüências dos vários jogos parciais em que se encontra envolvido. Encerrando esta breve referência conceitual sobre o tema, vale enfatizar a importância de que o governante encarregado da gestão de um determinado jogo elabore um diagnóstico do jogo em que esta envolvido, um quadro que identifique e relacione entre si os atores e os problemas mais relevantes de uma dada situação em um determinado momento No caso em pauta o Jogo do SL, em que a situação envolve o amadurecimento de um dado artefato tecnológico em processo de construção e fechamento, trata-se de identificar