646 - 660 of 703
ctaurion 120000QEUW | | Tags: opensource odf ‎ | 7 Comments ‎ | 4,110 Views
ctaurion 120000QEUW | | Tags: opensource ‎ | 3,087 Views
Bem, continuando com o assunto de gerenciamento de projetos Open Source, que começamos no post anterior, vamos abordar a questão dos líderes de projetos ou mantenedores.
O líder do projeto é de fundamental importância. Tem como papéis principais dar a visão do projeto para a comunidade; assegurar-se que o projeto está adequadamente modularizado para ser trabalhado de maneira simultânea; atrair e reter colaboradores; e manter o projeto unido, sem dissidências.Os líderes de projetos de Open Source conquistam este posto ou por terem iniciado o projeto (geralmente assumem a função de mantenedor) ou por méritos próprios, reconhecidos pelos seus pares. Devem assumir uma postura de coaching, liderando os esforços da comunidade, resolvendo conflitos e tomando decisões sobre os rumos do software. Não existe a figura do chefe ou do patrão, uma vez que não existem vínculos empregatícios entre os membros da comunidade e toda colaboração é voluntária.
Reconhecer os fatores motivacionais e incentivá-los é uma das principais funções dos líderes de projetos de Open Source. Os valores para motivação são diferentes. Por exemplo, entre a maioria do pessoal técnico um fator motivacional é o reconhecimento de sua expertise pelos pares. A meritocracia é o modelo de incentivo. Em áreas de vendas, a motivação principal é geração de dinheiro, com bônus por resultados. Manter a motivação da comunidade em todo o ciclo de vida do software é questão de sobrevivência do projeto. Desenvolver software em comunidade implica em total colaboração.E colaborar não é uma ação incentivada em muitas organizações tradicionais, muito mais focadas nas competições individuais pela conquista de uma nova posição hierárquica ou bônus financeiros.
Nos projetos com muitos colaboradores, observa-se que uma grande parcela do código vem de apenas um reduzido número de desenvolvedores. Alguns projetos recebem colaboração apenas de estudantes, que desenvolvem código como parte de seus cursos de graduação. Se as colaborações não vierem também de desenvolvedores de nível sênior, a qualidade do código pode ser bastante sofrível. Os desafios gerenciais aumentam sensivelmente, pois os líderes do projeto devem ter muito mais cuidado (e trabalho) na aceitação do código.
Na prática, controlar a qualidade do software é um tarefa pesada, pois como a comunidade é diversa em sua expertise e proficiência técnica, a variedade de estilos de codificação que chega aos líderes de projetos populares é muito grande, com muita contribuição de qualidade duvidosa.Este é um outro grande desafio do gestor do projeto: o que aceitar ou recusar das colaborações. Muitas colaborações não são aceitas, sejam por existirem outras mais eficientes ou simplesmente por não atenderem aos critérios de codificação do projeto. Os líderes devem ter cuidado na comunicação destas recusas e as decisões devem ser sempre baseadas no voto majoritário da comunidade. Decisões isoladas não fazem parte da cultura colaborativa e são adotadas por poucos projetos.
Diante do sucesso de muitos projetos de Open Source, surge o questionamento da possibilidade de aplicarmos seu processo de desenvolvimento internamente, por uma empresa comercial, que não tenha como objetivos de negócios desenvolver software.
Software é importante para a maioria dos setores empresariais, pois são fundamentais em criar diferenciações competitivas. Processos de negócios podem ser inteiramente redesenhados, mas para serem implementados exige-se suporte de software. E velocidade para esta implementação é cada vez mais um fator crítico para o sucesso.
Analisando uma empresa comercial observamos que o conhecimento de informática está permeada pela organização. A maioria dos usuários finais tem acesso e utiliza computadores. Não sabem programar com proficiência em linguagem de baixo nível como C ou C++, mas sabem o que querem e precisam dos seus sistema de informação.
Existe então a possibilidade de engajar todos os interessados em projetos de software interno e eventualmente ampliar esta colaboração para empresas parceiras.
Uma preocupação sempre latente é se estes projetos podem implementar processos e "best practices" de engenharia de software. Existem iniciativas nesta direção que podem servir de orientação. Um exemplo é a comunidade Tigris (www.tigris.org) que se propõe a ser uma comunidade de software livre voltada a desenvolver processos e ferramentas para uso das práticas de engenharia de software em projetos de Open Source. Também já contabilizamos algumas experiências bem sucedidas de uso de processos de engenharia de software em projetos de software livre, como nos projetos Eclipse (www.eclipse.org) apoiadas por empresas fortemente estruturadas em seus processos de desenvolvimento como IBM.
O modelo de desenvolvimento de Open Source já passou por alguns testes práticos. Existem projetos de grande complexidade, com milhões de linhas de código, desenvolvidos com qualidade e rapidez. O ritmo de desenvolvimento incremental de projetos como o kernel do Linux tem se mostrado superior a de muitos projetos de softwares houses.
Existem projetos de alta qualidade, devido ao uso de peer review, com custos diluídos por toda a comunidade. Claro que o que deu certo em Linux e no Apache não necessariamente dará certo em qualquer outro projeto de software. As circunstâncias peculiares que envolvem estes projetos (timing, motivação, área de domínio, apoio da indústria e outras) não se replicam automaticamente.
Para o sucesso de uma iniciativa de Open Source dentro de uma empresa ou instituição nos atrevemos a fazer algumas recomendações:
a)	O projeto pode começar do zero ou aproveitar o código já existente em algum repositório como sourceforge e outros. Começar do zero é sempre mais complicado, pois neste caso não existe nenhuma peça de código que funcione, mesmo precariamente. É sempre melhor começar com algum código, mesmo defeituoso, uma vez que este pode ser depurado e tornar-se rapidamente um software funcional. Mas, se começar do zero, defina claramente o propósito do software, para que as colaborações sejam direcionadas no mesmo sentido.b)	É importante que exista colaboração de codificação. Os usuários finais devem estar engajados, principalmente para apoiar as questões relativas a usabilidade. Por ser um software para uso de usuários finais, motive a participação destes no projeto. Um ponto a ser debatido é a possibilidade do uso de linguagens de programação de alto nível. Não recomendamos usar linguagens pouco conhecidas, mesmo que sejam também livres. Sem massa crítica de colaboradores escrevendo código o software simplesmente não sai do lugar.c)	Utilize adequadamente recursos tecnológicos que permitam facilidade de comunicação e controle como mailing lists, wikis, listas de discussão, softwares de controle de versões e assim por diante. O controle de versões, dos códigos fonte e o rastreamento dos patches a serem aplicados são atividades essenciais ao sucesso do projeto.d)	Defina claramente as posições chave da comunidade. Existirão colaboradores pouco ativos e alguns muito ativos. Não esqueça que são funcionários da empresa e voluntários, e talvez não tenham muita flexibilidade para alocar tempo. É sempre bom contar com apoio da alta administração para estes projetos, inclusive para facilitar o recrutamento de colaboradores.e)	Defina claramente as regras do jogo, os processos de tomada de decisão e resolução de conflitos, e de aceitação das colaborações. As regras de participação devem ser bastante claras e estarem disponíveis a todos os interessados.f)	Defina as necessidades de documentação e procedimentos de teste. Documentação é importante para usuários finais, que não irão recorrer a códigos fonte para tirar dúvidas de como usar o software. Quanto aos testes, pode-se adotar o clássico mecanismo de peer review ou outro procedimento qualquer. Peer review pode ser adotado se houver massa crítica de usuários suficiente para garantir a qualidade das inspeções de código.g)	Definir política de distribuição de versões. Pode-se usar critérios de três níveis, com a versão estável disponível para uso público; uma versão em teste, aguardando a liberação em um próximo release; e a versão em desenvolvimento, instável e liberada apenas para desenvolvedores.h)	Não esqueça que um Open Source é um projeto que não tem fim. Sempre cabe mais uma modificação ou adição de funções.
ctaurion 120000QEUW | | Tags: odf ‎ | 2,587 Views
ctaurion 120000QEUW | | Tags: opensource ‎ | 3,729 Views
Quinta feira, começa o FISL 8.0 em Porto Alegre. Estarei lá mais uma vez e inclusive apresentarei uma palestra abordando modelos de negócios gerados a partir do Open Source. E como Open Source é o tema do evento, nada mais natural que debater o assunto mais uma vez aqui no blog. Vou dividir com vocês a adaptação de um capítulo do meu livro "Software Livre: Potencialidades e Modelos de Negócio", publicado em 2004/2005 pela editora Brasport (www.brasport.com.br). Como o texto é relativamente extenso, vou dividi-lo em dois pedaços, a primeira parte hoje e a segunda no próximo post.
Já sabemos que uma iniciativa de Open Source não é apenas entusiasmo e trabalho pesado nos fins de semana. A utilização profissional e empresarial do desenvolvimento de Open Source demanda um novo método de gerenciamento, com suas características e peculiaridades próprias.Não existem, na prática, metodologias que já tenham sido comprovadas em muitos projetos. As iniciativas de maior sucesso como Linux, Apache, Eclipse e outros não usam as mesmas metodologias e nem mesmas ferramentas de apoio. Por exemplo, alguns têm um único líder que coordena todo o projeto e outros mantêm uma equipe gestora, com decisão em colegiado. Entretanto, podemos analisar pontos em comum entre eles e identificar alguns aspectos que aparentemente os levam a ter sucesso.
Gerenciar um projeto de Open Source é gerenciar pessoas em uma organização virtual, formada por colaboradores voluntários espalhados pelo mundo todo, que trabalham de maneira autônoma e não tem vínculos oficiais entre si, nem com o próprio projeto. Podem sair quando quiserem, sem aviso, simplesmente deixando de colaborar. É um mundo diferente do modelo de gerencia típico de uma organização hierárquica, onde as pessoas estão no mesmo local e obedecem a regras corporativas e a hierarquias bem definidas.
O grupo de colaboradores é diverso em suas competências técnicas (desenvolvedores super-seniores a estudantes), que tomam decisões por si e se engajam por motivos diversos, que vão do ideológico e messiânico ao financeiro, em busca de projeção e novas oportunidades profissionais. Não existe o contato direto nem reuniões de projeto e, portanto ambigüidades de comunicação (línguas e países diferentes, com seus costumes diferenciados) e a falta de uma estratégia bem definida dos rumos do software, além de inexistência de cronogramas e prazos criam toda uma nova dinâmica de gerenciamento de projetos.Basicamente um projeto de Open Source deve, como qualquer outro projeto, gerenciar os processos necessários a desenvolver as tarefas, bem como gerenciar as próprias tarefas.
Um grande desafio a estes projetos é a construção dos mecanismos de controle e coordenação, uma vez que os membros são autodirigidos e controlam por si mesmo seus ritmos e intensidade da colaboração.Assim, um fator crucial no Open Source é criação de motivação e confiança entre os membros do projeto. A colaboração voluntária só acontece quando motivada. Conquista-se a confiança dos colaboradores quando o trabalho individual é considerado adequadamente, os conflitos de opinião são julgados e decididos com base em critérios bem definidos e livres, e todas as informações sobre o projeto estão disponíveis a todos.
A questão da disponibilização livre das informações é muito importante. Quanto mais compartilhadas forem as informações referentes ao projeto, maiores as chances dos colaboradores contribuírem mais eficientemente. Um exemplo é a inspeção de código fonte. Nenhum código deve ser restrito em sua visualização. Qualquer membro da comunidade pode ter acesso a ele e fazer comentários ou modificações. Se for aceito ou não é outra questão, mas o acesso deve ser livre. Um outro exemplo são os processos de tomada de decisão. De maneira geral o mantenedor e seus auxiliares não devem trocar informações e opiniões sobre a aceitação ou não de determinado código, de maneira restrita, mas sim sempre em discussões abertas para a comunidade. É um modelo diferente de projetos convencionais, onde muitas informações são restritas e trafegam apenas entre os gerentes responsáveis. Entretanto, algumas informações podem ser mantidas privadas, como identificação dos membros da comunidade. Salvo por decisão pessoal, os membros identificam-se por e-mails, muitas vezes apenas sob pseudônimos, não cedendo endereços ou telefones para outros contatos.
Os principais meios de comunicação entre os membros do projeto são os eletrônicos, como e-mails, wikis e listas de discussão. São métodos ágeis, mas devido à impossibilidade do contato direto, tornam-se perigosos quando mal utilizados. Em e-mail não existe feedback imediato, não existe comunicação implícita, de se olhar no rosto, ver gestos e se ouvir a entonação da frase.Um texto mal escrito ou uma opinião sucinta e direta demais pode gerar conflitos desnecessários. A situação se agrava sob pressão, quando mais e-mails são direcionados e nem sempre respondidos com a calma e clareza necessária. Os líderes do projeto (mantenedor e seus auxiliares) sofrem bastante com esta pressão, pois concentram em si um volume imenso de mensagens. Respondê-las de forma inadequada pode criar desavenças inconciliáveis entre os membros, chegando a gerar dissidências no projeto.
Os projetos de Open Source devem procurar criar políticas de uso de e-mails (netiquetas) de modo a evitar geração de conflitos desnecessários. Estas políticas geralmente são informais e aceitas pela comunidade. O site do projeto deve explicitar as regras de conduta que a comunidade deseja que os membros adotem. O site deve também definir as regras de participação e como a organização virtual está estruturada, como e quando acessar os seus líderes, como colocar mensagens, como participar de debates e assim por diante.O uso de chats também encontra adeptos, embora não permita a participação de toda a comunidade, pelo simples fato das agendas pessoais (e fusos horários) nem sempre coincidirem.
Existe também o desafio da tecnologia de apoio ao projeto. Algumas ferramentas adicionais são importantíssimas, além dos tradicionais e-mails e listas de discussão. Como o projeto é colaborativo e assíncrono, com diversos desenvolvedores trabalhando simultaneamente na mesma solução, é necessário dispor de ferramentas que permitam este tipo de controle. O gerenciamento das diversas versões (estável, em teste, e instável ou em desenvolvimento) e da versão a ser liberada para uso geral é fundamental em qualquer projeto de Open Source. Não existem regras únicas para esta tarefa e os principais projetos adotam mecanismos diferentes. É necessário definir claramente de quem é a autoridade para liberar a versão para uso e que critérios devem ser obedecidos para que a versão seja liberada publicamente.
De maneira geral, salvo exceções de projetos de grande popularidade, como o Linux, Eclipse ou Apache, os projetos de Open Source são registrados em sites especiais que atuam como espécies de câmaras de compensação (clearinghouses), como o SourceForge (www.sourceforge.net),o FreshMeat www.freshmeat.net e outros. To be continued...[Read More]
ctaurion 120000QEUW | | Tags: web ‎ | 5 Comments ‎ | 4,303 Views
Motoristas mal educados não são privilégio de nossas ruas e estradas. Existem em todas as partes do mundo...Nos EUA começa a ganhar corpo um movimento, impulsionado pela Web, para expor estes mal educados para todo o mundo! Alguns sites como o www.platewire.com , //caughtya.org, www.litterbutt.com e www.rudepeople.com são iniciativas nesta linha. O Caughtya.org registra as fotos, obtidas por celulares ou cameras digitais, dos veículos estacionados irregularmente em vagas destinadas à deficientes. O Platewire.com aponta casos de direção indevida, mau comportamento no trânsito e assim por diante. O LitterButt se concentra em expor na Internet os motoristas que sujam as ruas, jogando latas e cigarros.
Bem, se a moda pegar por aqui, cada site destes vai precisar de servidores de grande capacidade, pois as atualizações online chegarão à casa dos milhões...[Read More]
ctaurion 120000QEUW | | Tags: longtail opensource ‎ | 2 Comments ‎ | 3,500 Views
Estava relendo algumas partes do livro "A Cauda Longa" de Chris Anderson e comecei a pensar na relação deste conceito com a industria de software. A Cauda Longa (The Long Tail) está impulsionando grandes transformações em vários mercados, como o de mídia e o fonográfico. Juntando este conceito ao de Open Source, veremos grandes transformações também na indústria de software. Queria debater com vocês alguma destas idéias...
O conceito de Cauda Longa propõe que determinados negócios podem obter uma parcela significativa de sua receita pela venda cumulativa de grande numero de itens, cada um dos quais vendidos em pequenas quantidades. Isto é possível porque a Internet abre oportunidades de acesso que antes não existiam. É um modelo diferente do mercado de massa, onde poucos artigos são vendidos em quantidades muito grandes. Na indústria de livros, música e de mídia faz todo o sentido. Por exemplo, a Amazon reporta que 57% de sua receita vem de produtos da Cauda Longa que não estão disponíveis (e jamais estariam) nas livrarias tradicionais, limitadas pelos caros espaços físicos das lojas.
E como Open Source e o conceito de Cauda Longa afetam a indústria de software? No Open Source o custo de desenvolvimento de um software é rateado por uma comunidade de desenvolvedores. Não existe um centro de custo único...Portanto o custo individual é muito pequeno.
Assim, softwares que tinham seu projeto cerceado pelo pequeno tamanho do seu mercado potencial (seu custo de produção não gerava retorno financeiro suficiente) podem agora, se desenvolvidos em Open Source, entrar no mercado. Os custos de comercialização destes softwares também tendem a zero, pois não é necessário hordas de vendedores, mas simples downloads e marketing viral (blogs e outros meios de disseminação de informação). O que isto significa? Softwares economicamente inviáveis pelo modelo tradicional, podem agora ser produzidos, baseados em Open Source, mas é claro, desde que consigam gerar também um modelo de negócios.
Temos então campo para explorar o mercado da Cauda Longa no software. E já temos exemplos bem sucedidos disso! Alguns exemplos da aplicação do conceito de Cauda Longa em software são o Eclipse, com seu mecanismo de plug-ins e o Linux. Os plug-ins do Eclipse podem atender a um mercado bem menor, que não seria alcançado caso fosse necessário um caro e sofisticado software monolítico, com 30 a 40 funções de plug-ins aglutinadas. Por exemplo, se vocês visitarem a página http://www.eclipse-plugins.info/eclipse/index.jsp vão acabar descobrindo um plug-in que atenda às suas necessidades, mesmo que elas sejam bastante especificas. Uma consulta que fiz no início de abril me trouxe mais de 1440 plug-ins disponíveis.
A modularização do Linux também permite criar variantes para processadores de pouca disseminação no mercado. Existe algum outro sistema operacional que rode em tantos processadores como o Linux? Claramente o Linux também atende o mercado da Cauda Longa...
O modelo comercial tradicional prende a industria no mercado de grandes volumes. O modelo de massa precisa de base significativa de clientes para se sustentar. E acaba criando excesso de funcionalidades, pois precisa aglutinar muitas funções para atender a uma gama muito grande de clientes.
Este mercado vai morrer? Na minha opinião, absolutamente não! Acredito que conviveremos em um contexto onde os modelos de massa e de cauda longa vão compartilhar os palcos... Continuaremos a ter produtos de software bem abrangentes em funcionalidades, que venderão suficientemente bem para manter um mercado próprio. Mas também teremos muitos outros produtos, baseados em Open Source, que se encaixariam muito bem no contexto da Cauda Longa.
Bem, acho que temos um bom material para discussões...Opiniões prós e contras, por favor![Read More]
ctaurion 120000QEUW | | Tags: fortran ‎ | 4,823 Views
ctaurion 120000QEUW | | Tags: web20 ‎ | 4 Comments ‎ | 4,806 Views
Acabei de ler o livro Conhecimento em Rede, de Marcos Cavalcanti e Carlos Nepomuceno, editado pela Campus/Elsevier. O livro aborda temas bem desafiadores, questionando e respondendo como o conhecimento humano muda em rede, e como se preparar para tantas mudanças.
Aborda também um método de implementação de projetos de Inteligência Coletiva e em seu apêndice, faz uma proposta interessante que chama de "Brasil 2.0: uma proposta de um novo país", onde debate a mudança do conceito tradicional de inclusão digital (onde as pessoas são simplesmente colocadas diante de um canal informativo sofisticado como o computador, mas nem por isso são incluídas na sociedade) por inclusão ao conhecimento, através da criação de comunidades em rede para geração dinâmica da inteligência coletiva.
Os autores também coordenam o desenvolvimento de um projeto de software Open Source para gerenciar Inteligência Coletiva, chamado de ICOX (www.icox.org.br). O ICOX está sendo desenvolvido em PHP, rodando em servidores Linux. O ICOX trabalha nos conceitos da Web 2.0, tendo como ponto de partida a participação ativa dos usuários como responsáveis pelo conteúdo, criando uma relação entre o ambiente de cada um (blog) e do grupo com a comunidade em rede.[Read More]
ctaurion 120000QEUW | | Tags: opensource openoffice ‎ | 3,147 Views
Recentemente li o relatório "IDC and OpenOffice.org Survey", publicado em novembro do no passado. Este relatório, que pode ser acessado emmarketing.openoffice.org/surveys/OpenOffice%20Survey%20Results-Nov%202006.pdf contém uma pesquisa bem detalhada feita com usuários do OpenOffice (foram 5819 pesquisados, que responderam afirmativamente a questão se haviam usado OpenOffice alguma vez no ultimo ano) e gostaria de compartilhar com vocês algumas das informações.
Entre as dezenas de perguntas, destaco:
1)	O sistema operacional mais usado pelos usuários do OpenOffice é o Windows, com 72% dos usuários domésticos e 62% dos usuários que usam OpenOffice no trabalho. Linux aparece em segundo, mas principalmente entre os usuários domésticos (20%).2)	O OpenOffice é mais usado em casa do que no trabalho. Na minha opinião pessoal porque em casa (a maioria dos respondentes são dos EUA e da Europa), o custo zero para seu uso (apenas o tempo de download) quando comparado a uma versão proprietária e paga, é sem sombra de dúvida um grande atrativo. Além disso, a maioria dos usuários domésticos não demanda recursos sofisticados que só existem no Office da Microsoft, como planilhas elaboradas...O OpenOffice atende perfeitamente.3)	Com relação ao uso nas empresas, 14,7% disseram que a utilização do OpenOffice pode ser vista como significante. É um número pequeno e talvez reflita a dificuldade que as empresas enfrentam diante de mudanças culturais... Entretanto, mais de 23% dos pesquisados afirmaram que suas empresas pretendem aumentar o uso do OpenOffice. Bom sinal!
Minhas conclusões: O OpenOffice ainda tem muito espaço a percorrer...Vemos seu uso muito incentivado em governo e em empresas públicas.Nas privadas seu uso está mais concentrado nas empresas de pequeno a médio porte, com raras exceções de empresas de grande porte...Acredito também que seu uso irá aumentar à medida que a padrão ODF se dissemine. O OpenOffice é um dos diversos softwares que suportam o ODF.
Para usuários domésticos é claramente um atrativo, pois não demanda compra de licenças.Entretanto, devido à alta incidência de pirataria no Brasil, as diferenças de custo acabam ficando pequenas...Compara-se um custo zero contra cinqüenta ou sessenta reais de um Office pirata. Aliás, pirataria é uma sombra que paira sobre a indústria de software é a pirataria, prática ilícita, que é simplesmente o uso, ou a cópia e distribuição de produtos comerciais sem autorização. É uma atitude ilegal, mas infelizmente muito popular, ocorrendo com freqüência na indústria de computadores "cinza", montados por empresas de "fundo de quintal".
De maneira geral algumas estimativas apontam que a pirataria no Brasil prejudica fortemente a indústria de softwares de consumo, que deixaria de faturar algumas centenas de milhões de dólares. A diferença entre os softwares instalados (demanda) e o software legal (fornecimento) é igual à estimativa de softwares pirateados. A pirataria é medida como a quantidade de softwares instalados sem licença oficial.
Entretanto alguns estudos apontam que este valor corresponde à expectativa de lucro caso não houvesse nenhuma outra alternativa. No modelo tradicional de software de massa (voltado ao consumidor), a evolução do software é muitas vezes direcionada pelas estratégias de marketing do fornecedor, que constantemente cria novas funcionalidades, nem sempre necessárias aos usuários. Algumas pesquisas de mercado demonstram que uma grande parcela das funcionalidades de softwares de escritório não são utilizadas. O modelo cria também um processo de obsolescência programada, impedindo a aquisição de versões anteriores, mesmo que estas atendam perfeitamente bem as necessidades de um grande contingente de usuários. O modelo não permite a comercialização de softwares usados, como ocorre na indústria automobilística. Outra característica deste modelo é que muitas vezes as decisões de liberação de versões são direcionadas pelas estratégias de marketing, levando eventualmente a liberação de código que não tenha sido devidamente testado, com muitos bugs ainda existentes. Os próprios usuários é que acabam sendo os "testadores" e comunicando aos fornecedores as ocorrências dos bugs.
Com opção de open source, com custos reduzidos de aquisição (ou grátis, caso seja um simples download) uma parcela significativa de usuários não teria interesse em adquirir software proprietário similar. Assim, a perda da indústria seria apenas do valor das licenças que a parcela restante de usuários, ainda interessadas nos softwares proprietários, optasse intencionalmente pela pirataria.
Com um crescente uso de open source no mercado de consumo, o custo total da oficialização das licenças seria bem menor. A conta é simples. Imaginando que o índice de pirataria no Brasil seja de 50%, um esforço legal para combater a pirataria obrigaria a outra metade dos usuários de softwares de escritórios a adquirirem licenças oficiais, afetando a balança de pagamentos. Se o open source fosse adotado como programa substituto no mercado de consumo, a balança de pagamentos não seria tão afetada.
O modelo de open source pode ser uma alternativa bastante interessante no tocante aos acordos comerciais internacionais que são firmados por governos para combate a pirataria de software. Creio que vale a pena pensar nisso...
ctaurion 120000QEUW | ‎ | 1 Comment ‎ | 2,078 Views
Semana que vem estarei participando do FISL 8.0 (Forum Internacional de Software Livre) em Porto Alegre. A IBM é uma das patrocinadoras do evento e estarei apresentando uma palestra lá.
Também, na terça, 10 de abril, em São Paulo ocorrerá um evento gratuito chamado 4Linux Pré-FISL 2007, onde a IBM também é patrocinadora. O evento pode ser visto em detalhes no site da 4linux (www.4linux.combr). No Pré-FISL estarão presentes Jon "Maddog" Hall, Josh Berkus (PostGreSQL), Louis Suarez-Potts (OpenOffice) e Kristian Keilhofner (Asterisk).
Minha palestra será "Renascimento 2.0: sinergia entre inovação e padrões abertos". Nela estarei debatendo como o modelo Open Source está abrindo as portas para um novo pensamento econômico, acelerando os processos de inovação. Falaremos do fenômeno do conhecimento em rede e de seus impactos na sociedade.[Read More]
ctaurion 120000QEUW | | Tags: odf ‎ | 1 Comment ‎ | 4,377 Views
Semana passada estive no anúncio oficial do Chapter Brasil da ODF Alliance. Conversei bastante com seu diretor-geral, Jomar Silva. Jomar é um profissional de grande competência e que alia conhecimento técnico à luta pelo ideal dos padrões e softwares abertos.Acredito que seria muito proveitoso compartilhar com vocês nosso bate-papo informal.
Bem, a primeira coisa que perguntei ao Jomar foi, na sua opinião, qual seria o papel do ODF Alliance no mundo e no Brasil.
Ele me disse que acredita que a principal missão é difundir os benefícios e as oportunidades trazidas pelo ODF. Segundo ele as vantagens e as oportunidades trazidas pelo ODF não possuem limitações regionais, étnicas ou culturais e por isso, encara a ODF Alliance como uma associação única, que trabalha em um mundo que é cada vez mais plano.
Segundo Jomar, aqui no Brasil teremos desafios adicionais, causados pelo caldo de cultura de um único fornecedor de tecnologia. Inclusive ele recordou um fato ainda na faculdade, emblemático desta situação: "Me lembro da revolta que senti quando na faculdade meu professor de "Sistemas Operacionais" apareceu com uma apostila do Windows NT e não com o livro do Tanembaum... no dia em que isso me ocorreu protestei de tal forma que fui convidado a me retirar da sala de aula. Fui para casa mesmo... optei por ficar em casa estudando coisa séria do que ir para a faculdade e escutar mais um catequizador... e olha que este catequizador me perseguiu até o último dia de aula, mas nunca conseguiu me pegar...".
Perguntei depois ao Jomar como ele via o ODF no Brasil.
Ele disse que acredita que o Brasil está no momento de decidir o que quer ser no mundo plano da tecnologia da informação: "Vimos nos últimos anos uma série de iniciativas de fomento ao mercado de software não gerar resultado algum, pois acredito que estamos tomando o exemplo equivocado: Nunca seremos como os indianos...Não temos a religião deles, a sociedade deles e fundamentalmente não temos os valores deles. Isso não quer dizer que sejamos melhores ou piores: somos diferentes, e assim devemos nos ver.Nosso país é aberto por natureza. Em qual outro país do mundo pode-se encontrar mais de dez raças, religiões e culturas distintas almoçando no mesmo restaurante em paz?" .
Segundo Jomar, a interoperabilidade é a base da nossa sociedade e da nossa cultura. Ele entende que a miscigenação de raças existente no Brasil é a tradução da interoperabilidade para o plano físico: "Só aqui as coisas funcionam tão bem desse jeito e por isso acredito que somos o povo ideal para doutrinar o resto do mundo sobre os valores e os benefícios de se viver em harmonia. Sou o exemplo vivo disso, pois tenho sangue português, negro e índio (e muitos bits e notas musicais circulando ali no meio). Sob o ponto de vista da tecnologia, a harmonia vem com a interoperabilidade, com os padrões abertos e no que tange os documentos do dia a dia, o ODF. Brinquei com alguns amigos há alguns anos atrás de que deveríamos criar um movimento intitulado: Brasil: País Aberto - Padrões Abertos (com o Cristo Redentor como garoto propaganda)". .
Jomar considera que o que for feito com o ODF aqui vai ecoar positivamente no mundo todo, pois dadas as nossas dimensões territoriais, a adoção do ODF pelo governo federal pode ser um "case" tão grande quanto a adoção pela comunidade Européia. Um exemplo que ele deu foi que uma adoção no Estado do Paraná pode ser quantitativamente maior do que a adoção por um país europeu, como Portugal.
Bem, aí tive que perguntar qual a opinião dele sobre o OpenXML. Não poderia deixar passar em branco esta questão...
A resposta dele foi bem interessante: "Tenho me dedicado nos últimos anos ao estudo de estratégia. Vejo que o OpenXML é a saída estratégica fundamental para a Microsoft continuar sendo o que é hoje.A maior parte da receita da Microsoft é oriunda do licenciamento OEM do Windows em novos computadores e da comercialização de licenças do Office..Todos nós temos visto a redução ainda tímida, mas muito evidente nas receitas da Microsoft com o licenciamento do Windows. Isso só tende a se tornar mais crítico, uma vez que os usuários tem se frustrado com o Windows Vista (e a Internet já está abarrotada de artigos sobre isso) e tem buscado alternativas. As existentes atualmente giram em torno do Linux, OpenSolaris para os mais aficionadas por tecnologia e performance e o grande ponto de interrogação que se tornou o MacOs.".
E continua : "De forma simplificada, vejo que se a Microsoft mantiver seu formato binário de arquivos, perderá mercado muito rapidamente para soluções baseadas no ODF".
Perguntei o que ele achava das contradições apontadas pelos diversos países com relação ao processo FastTrack do OpenXML. A resposta foi mais uma vez contundente: " A especificação possui simplesmente 6.000 páginas (isso porquê falta um anexo que segundo o ECMA é para ser usado apenas por computadores !!!) e chega a ser impossível acreditar que algum programador na face da terra vai ter a paciência necessária para ler essa coisa inteira e escrever um software (que seja o mais simples possível) que implemente o padrão inteiro. Um dos motivos apontado no relatório da ISO para isso é o fato de que enquanto o ODF é todo baseado em padrões ISO já existentes, o OpenXML redefine uma série de coisas, como o calendário gregoriano, a codificação de cores, identificação de idiomas e uma lista de outras coisas....".
E conclui: "Olhando como um cidadão, acredito que quem tem dois padrões não tem padrão nenhum e considero que, se a Microsoft está realmente preocupada com o legado de documentos e com o futuro da humanidade, que faça como tantas outras grandes empresas fizeram no passado, aderindo e contribuindo com a evolução de um padrão internacional existente, que é o ODF.".
O que posso comentar? Realmente Jomar tem opiniões bastante contundentes e tenho certeza que ele poderá contribuir muito para disseminar o padrão ODF no Brasil.
E para terminar recomendo acessar os sites da ODF Alliance (www.odfalliance.org) e um outro, muito completo que é o //opendocumentfellowship.org . Este último apresenta uma lista de aplicativos que suportam ODF. Muito interessante.[Read More]