Sobre desenvolvimento de software livre, o caso LibreOffice

Hoje caí numa página com uma entrevista do Linus Torvalds sobre gerência de projetos em software livre. Fiquei muito satisfeito por ver que minha experiência com a industria de software e do software livre em particular está em fase com a dele.

Cito aqui os trechos mais relevantes. Diz o Linus: 

"A primeira coisa é pensar que basta jogar na rede suas coisas e pedir ajuda das pessoas". No software livre, ele afirma: "Não é assim que funciona. Você pode publicar, mas assuma que será você a fazer todo o trabalho, para depois pedir sugestões sobre o que fazer, e não o que as pessoas devem fazer. Talvez elas até ajudem, mas você deve iniciar com a premissa que será você o mantenedor, e quem fará praticamente todo o trabalho". Torvald continua: "Se você começar muito animado pensando que pessoas de todo o mundo se juntarão para fazer um mundo melhor trabalhando em seu projeto, com certeza você não irá muito longe".

Tenho quase 10 anos de vivência no software livre, e iniciei com o OpenOffice.org, na área que eu podia contribuir relacionada a localização do software para o português do Brasil. Hoje eu sei que se algo está para ser feito em software livre, melhor saber fazê-lo por conta própria do que depender da boa vontade das pessoas. Não se trata de desmerecer o colega ou o voluntário. Trata-se de ter a noção real de que software demanda muita energia e entender que é natural que as pessoas tenham suas prioridades, quando estão colaborando. Se fossem contratadas, seria outra história.

Nesse ponto seu projeto tem de acomodar os riscos de não poder contar com a mão de obra que inicialmente se ofereceu para ajudar. Trabalhar com prazos em software livre, com voluntários e sem uma gerência de projeto e de recursos que acomode a deficiência de produtividade de voluntários, é arriscado demais.

Seu projeto de software livre precisa de controlabilidade.

A segunda afirmação de Linus Torvalds refere-se aos usuários e aos desenvolvedores:

 " A outra coisa - algo relacionado - que as pessoas parecem não entender, é pensar que somente o código delas importa", diz Linus. "Não. Mesmo que você escreva 100% do código, e mesmo que você seja o melhor programador do mundo e não precisar da ajuda de mais ninguém. a coisa que realmente importa são os usuários de seu código. O código em si não importa; o projeto só é útil se as pessoas assim o acharem".

Minhas palavras para essa observação são as seguintes: O que determina o sucesso de um software livre ou fechado é sua base instalada. E sua base instalada é uma consequência do fato que seu software agradou aos usuário e agregou valor na ponta.

Interessante como esse conceito se aplica ao LibreOffice. A base instalada do LibreOffice é muito grande, prova de seu valor para os usuários. Nesse primeiro ano de existência da The Document Foundation, o LibreOffice sofreu modificações internas que o tornaram muito mais rápido e com melhorias na sua usabilidade. Mas é observando a lista dos desenvolvedores e lendo suas opiniões e trabalho que vejo as palavras de Linus mais aguçadas: temos um time de desenvolvedores de alto calibre, muito ansioso por trabalhar em detalhes, mas que vejo com preocupação o distanciamento das reais necessidades dos usuários.

Tenho visto muitas contribuições para com a velocidade e a facilidade da compilação, algo de muito complexo no processo de desenvolvimento e que visa torná-lo mais simples e acessível a desenvolvedores novatos, mas que nada acrescenta ao produto final e que não chega ao usuário, pelo menos diretamente. Outra posição um tanto mais arrogante talvez, refere-se a pedidos de melhoria ou de novas funcionalidades: os desenvolvedores terminam por chutar a bola de volta para que o usuário consiga por conta própria implementar a funcionalidade ou contratar seu desenvolvimento. Não é uma posição simpática, mesmo sendo realista.

Precisamos romper com o autismo endêmico dos desenvolvedores. Ouvir os usuários e para eles trabalhar.

http://h30565.www3.hp.com/t5/Feature-Articles/Linus-Torvalds-s-Lessons-on-Software-Development-Management/ba-p/440

Colar conteúdo no Lotus Notes

Para colar dados copiados do LibreOffice para o Lotus Notes, precisamos estar atentos a uns detalhes internos do seus sistema, caso seu padrão de edição do Lotus Notes for em texto rico (rich text).

Ao copiar e colar dados do libreOffice no Notes você perceberá que o resultado pode não ficar bom. Isso é devido a forma como os dados são enviados para a área de transferência do Windows e posteriormente colados no Lotus Notes.

Mas há como colar satisfatoriamente os dados na sua mensagem do Notes.

Basta utilizar o recurso Colar Especial do Lotus Notes. Ao acionar este comando, utilize a opção HTML ou Bitmap para colar.

A opção HTML mantém a formatação e permite editar a informação colada.

A opção Bitmap, mantém a formatação, mas o que você estará vendo é uma figura que não pode ser alterada.

Escolha a sua melhor opção.

Até mais.

LibreOffice e OpenOffice.org

Não sou dos que compartilham o entusiasmo com a criação do projeto OpenOffice.org pela fundação Apache. Algumas coisas não batem.

Como sabem, sou membro do Steering Commitee da The Document Foundation e por ser atuante no trabalho feito dentro da TDF, a cessão do código levantou muitos questionamentos que não vi esclarecidos na enxurrada de e-mails e discussões que encheram minha caixa de entrada. Conhecendo o concorrente comum e quase monopólio no mercado, dividir esforços nessa hora não me pareceu adequado.

Não vou contestar o direito da Oracle em ceder o código, marca etc... a quem quer que seja, mas convenhamos, a The Document Foundation era uma candidata a receber o código com muito mais naturalidade do que a Apache Foundation, isso pelo ponto de vista da comunidade de usuários e desenvolvedores e até pelo momento especial. Mas entendendo que a Oracle e a IBM são empresas que participam da “concorrência colaborativa” ou “colaboração concorrencial”, é natural entender que as duas empresas tem acordos comerciais confidenciais de intercambio ou tréguas sobre patentes, trocas de tecnologias e de oportunidades de mercado que as colocam tanto em oposição aqui quanto em colaboração ali. Isso explica o ferrenho empenho da IBM em apoiar o gesto da Oracle, além do óbvio que é utilizar o código do OpenOffice no Lotus Symphony, que lembremos, não é um produto com lista de preços.

Agora que o Apache OpenOffice está em incubação, não me compete mais discussão sobre a decisão. Em alguns aspectos é até positivo que seja incubado. Veremos o resultados da incubação. Mas ficam algumas questões em aberto que a comunidade em geral deve ponderar.

A primeira que vejo e das diferença de licenças. Em resumo, a TDF estipula para o LibreOffice a licença LGPLv3 + MPL (Mozilla Public License) e a Apache Foundation estipula para o OpenOffice a licença Apache V2. As duas são livres mas a Apache V2 permite que qualquer empresa empacote o software desenvolvido em um produto proprietário e faça dele a melhor comercialização que desejar. Já a licença do LibreOffice não permite fechar o código, e ele sempre será eternamente livre. Fica a pergunta aos contribuintes de código se se sentem bem em ter seu trabalho voluntário alavancando ganhos das empresas como IBM que, possivelmente não tem qualquer obrigação em retribuir para a comunidade os desenvolvimentos feitos em regime fechado.

Depois temos de considerar que, segundo a enxurrada de e-mails, a diferença de licenças permite ao projeto LibreOffice absorver qualquer desenvolvimento do Apache OpenOffice. No sentido inverso, isso não será possível visto que qualquer pedaço de código do LibreOffice não poderá ser relicenciado pela licença Apache V2 e não poderá ser incorporado ao OpenOffice.

As discussões também abordaram a linha de tempo. Ressalto que o afluxo de novos desenvolvedores ao LibreOffice permitiu uma enorme faxina no código do LO, notadamente na modernização de muitas partes do código que vinham de priscas eras, algumas com comentários em alemão que foram devidamente traduzidas e refatoradas. Os desenvolvedores do LibreOffice listaram uma coleção de “easy hacks” que atraiu grande contingente de novos colaboradores e com resultados notáveis na melhora de desempenho e de funcionalidades. Infelizmente este trabalho terá de ser refeito pela AF caso ela opte pela mesma linha de tarefas de faxina. Talvez eles publiquem uma lista de “easy hacks” similar.

Sobre a mesma linha de tempo, o LibreOffice já incorporou todas as novidades do antigo projeto OpenOffice na versão 3.4. O código cedido para a Apache Foundation ainda deverá ser incubado e não há previsão de lançamento da próxima versão. Fala-se de seis a doze meses de incubação para depois ser aprovado para release. Não sei dos detalhes de uma incubação, mas esse atraso acontecer, irá forçar ainda mais a separação dos produtos, resultando em dois softwares cada vez mais diferentes, pelo menos por dentro. Fica a pergunta sobre qual dos dois dará mais vantagens ao usuário, pressupondo que cada nova versão é melhor que a anterior, com bugs resolvidos.

Sobre a Apache Foundation desenvolver um “kernel” do OpenOffice, pergunto aos meus botões sobre a utilidade de um kernel sem as devidas aplicações e polimentos. Qual seria então o produto gerado pela Apache Foundation e o que faria um usuário com aquilo? Claro que essa situação cai como uma luva para qualquer empresa que queira fechar o “kernel-OOo” agregando penduricalhos para que seja vendável.

Fato é que, a meu ver, o ato de ceder o OpenOffice.org à fundação Apache e com sua licença Apache V2, junto com a estratégia do “kernel” irá levantar a barreira de entrada ao mundo OpenOffice.org, por criar um segmento de mercado de suites Office concentrado em empresas de grande porte como IBM ou outras capazes “produtizar” o software, ao que a licença do LibreOffice, por ser inapropriável, criará um segmento pulverizado e capilar de empresas de menor porte e indivíduos a fazerem negócios mundo afora, em com um produto já pronto pra uso e fácil interação com o desenvolvimento. Tudo dependerá do produto Apache OpenOffice.org e seu formato final. Mas a conclusão será: ou é mais da mesma coisa, ou haverá concentração de mercado do lado do Apache.

Essa concentração foi a pedra de toque da separação da comunidade do projeto OpenOffice.org, reagrupada no projeto LibreOffice. Na visão da The Document Foundation, o LibreOffice deve ser “vendor-neutral”, não privilegiando qualquer empresa ou ator na definição da condução do desenvolvimento e da fundação.

Mas minha ansiedade me atiça mais questionamentos: Senão vejamos, em que o modelo de negócios ao redor do Apache Ooo difere do modelo usado no StarOffice e no Oracle Open Office? Não tratavam do mesmo “kernel” com penduricalhos anexados? Eram as fontes e clip-arts extras? O suporte ao Adabas D? ou o suporte comercial da empresa ao usuário? Por que a Oracle não conseguiu sustentar o desenvolvimento próprio do Oracle Open Office e optou por se desfazer dele? Em que as empresas de software que fecharão o código e venderão o OpenOffice.org farão de melhor que a SUN ou a Oracle?. A resposta pode não estar em repetir o modelo e no usuário final, mas com certeza estará nas “enabling technologies” que serão embutidas nos produtos de empresas como IBM, invisíveis aos usuários finais. Um Apache Cloud seria uma possibilidade.

Resta-nos avaliar a evolução dos acontecimentos ao redor do tema da comunidade. Neste particular sabemos que qualquer software fechado ou aberto, depende de sua base instalada. Uma base instalada grande é sinônimo de sucesso e gerador de oportunidades de negócios dos mais diversos. Também foi muito debatido o tema da familiaridade da Apache Foundation com uma tecnologia destinada ao usuário final como uma suite office e sua adequação ao tratamento deste mesmo usuário. A linha de software da Apache sempre foi para os sysadmins. Mas como sou um indivíduo que não aposta na incompetência dos outros (as vezes me surpreendo desagradavelmente), devo considerar que haverá uma estrutura para gerar e gerenciar uma comunidade, qualquer que seja seu tamanho. A ver então, vis-a-vis do tema da concentração do mercado.

Dito isso, concluo ressaltando que a The Document Foundation já incorporou seu Engineering Steering Committee (comitê diretor de engenharia) e recentemente anunciou seu Advisory Board (comitê consultivo), que como anunciado, inclui a participação da SUSE, RedHat, Canonical, Google e Novell. Não é nada, não é nada, quem sabe isso é uma indicação de que pelo menos, o mundo Linux já fez uma escolha?

LIbreOffice 3.4 Beta 4

Caros Membros da Comunidade

A The Document Foundation anuncia o quarto pacote beta do LibreOffice 3.4. A versão 3.4 será o segundo release importante do projeto LibreOffice, e virá com muitos novos recursos. Note que o LibreOffice 3.4 Beta4 ainda não está pronto para utilização em produção, e recomendamos utilizar o  3.3.2 para esta finalidade.

O release beta está disponível para Windows, Linux e Mac OS X a partir de nosso servidor de teste em

  http://www.libreoffice.org/download/pre-releases/

Ao encontrar algum bug, relate-o no FreeDesktop Bugzilla:

  https://bugs.freedesktop.org

Para contribuir e se envolver com esse projeto e oferecer melhorias no código:

  https://www.libreoffice.org/get-involved/developers/

Ou para nos ajudar com fundos e doações

  http://challenge.documentfoundation.org/

Uma lista de problemas conhecidos pode ser vista em nosso wiki:

  http://wiki.documentfoundation.org/Releases/3.4/beta4

Uma lista novidades no LibreOffice 3.4 Beta4 está aqui:


http://download.documentfoundation.org/libreoffice/src/bugfixes-libreoffice-3-4-release-3.3.99.4.log

Gostaríamos de dar um grande *MUITO OBRIGADO* a todos os que contribuíram com o projeto LibreOffice. Este release não seria possível sem sua ajuda.

Atenciosamente

O Conselho de Administração da The Document Foundation

Trad: Olivier Hallot

O resgate da Tabela Dinâmica

Com a próxima versão do LibreOffice, os usuários brasileiros terão de volta a sua tabela dinâmica no Calc.

Até a versão 3.3.2 do LibreOffice, a nossa querida tabela dinâmica estava escondida sob uma falsa identidade, como se buscasse se esconder de algum crime, algum passado tenebroso ou pura discriminação. Pobre tabela dinâmica... Não merecia tamanha falta de consideração!

Assim, anunciamos que na versão 3.4 do LibreOffice, o desconhecido e misterioso Assistente de Dados agora assume sua real identidade: a formosa Tabela Dinâmica que todo mundo adora e preza.

Novo membro da The Document Foundation

Prezados amigos

É com imensa alegria que comunico que a Eliane Domingos é agora membro da The Document Foundation, passando pelo seu seletivo processo com crivo meritocrático.

Os que a conhecem sabem que isso era mais do que merecido. Mas para aqueles que não a conhecem, vale ressaltar as atividades que a levaram a ser aceita no seleto time de colaboradores da TDF e do LibreOffice:

- Seu empenho na Revista do BrOffice (até fevereiro de 2011) e sua colaboração na Revista Espirito Livre,

- Sua dedicação em ajudar-me na administração da finada BROffice.org, e sua garra na criação da ALTA, Associação Libre de Tecnologias Abertas,

- Sua dedicação voluntária na condução da comunidade LibreOffice no Encontro Nacional do BrOffice, no FISL, na LatinoWare, no FLISOL, Hack'n Rio, Campus Party, etc...

- Sua dedicação em promover o LibreOffice como solução viável em treinamento do CISL, palestras em eventos, entrevistas com a imprensa especializada, e participação ativa nas listas e portais,

- Sua energia única em agregar sempre mais ao pequeno e aguerrido time de profissionais de software livre, de boa vontade, que querem o melhor para seus pares em todos o Brasil.

Parabéns a Eliane. Bem-vinda a bordo.

LibreOffice 3.4 - Novo estilo de texto

Devido a um bug antigo de tradução que afetou várias línguas, o LibreOffice 3.4 vem com uma novidade nos estilos de documento de texto que merece a atenção dos editores de documentos grandes.

De fato, as palavras inglesas “Heading” e “Title” foram traduzidas em muitos idiomas pelo mesmo nome “Título”. Este erro ocultou um estilo importante nos documentos de texto que impediu a disponibilidade na interface do usuário do estilo “Título principal”. Até a versão 3.3.2, ao acessar o estilo “Título” só era possível acessar o estilo cujo nome em inglês era “Heading” e que define o estilo raiz de capítulos e subcapítulos de um documento de texto.

Ao traduzir o estilo “Title” para “Título principal” e “Heading” para “Título”, ganhamos um novo estilo que foi concebido para dar o título a um documento como uma monografia, relatório técnico ou livro.

Experimente esse novo estilo em sua monografia!