void life(void)

Acredito que muita gente já está sabendo no dia 1 de junho a Oracle anunciou a doação do código fonte e da licença de marca do OpenOffice.org para a Fundação Apache. Inicialmente o projeto foi recebido pela incubadora da Apache, e logo após o anúncio a discussão começou por lá.

Eu estou acompanhando e participando das discussões na lista da incubadora da Apache desde o primeiro dia, e me inscrevi como commiter do projeto logo no início. Para terem uma ideia melhor do que significa “acompanhar” a lista de discussões da incubadora da apache, tivemos um pico de quase 400 e-mails por dia durante o primeiro final de semana de discussões (sim, quase 800 e-mails para ler em um final de semana).

Após alguns dias de discussão, na última segunda feira (13/06) o projeto foi aceito por ampla maioria na incubadora da Apache e é agora um projeto incubado (chamado de podling dentro da Apache), e temos muita gente trabalhando bastante por lá para que ele se torne um projeto graduado em breve. A proposta de projeto pode ser acessada aqui, e a página do projeto incubado aqui. Como podem ver, ainda estamos acertando toda a infra do projeto por lá, e muitos dos commiters citados na proposta ainda não efetivaram suas contas, processo que deve levar mais alguns dias (a minha mesmo está na etapa final).

Gosto de ver que temos atualmente no projeto muita gente nova e disposta a ajudar, mas também muita gente que trabalha no software desde os anos 90, ex funcionários da Star Division (onde o StarOffice foi criado), Sun e Oracle, agora contribuindo de forma individual. São pessoas que passaram grande parte da sua vida trabalhando neste projeto e portanto para eles este não é “mais um” projeto… Acredito que o compartilhamento e o nivelamento de conhecimentos por lá será grande, e isso vai reduzir bastante a curva de aprendizado para os “novatos” como eu no projeto.

Não vou discutir aqui a decisão da Oracle de doar o código para a Fundação Apache ao invés de entregar a outra fundação qualquer (como a The Document Foundation, que mantém o LibreOffice), muito menos sobre a especulação de que a IBM está por trás desta iniciativa (estes foram tópicos mais do que debatidos durante os primeiros dias de discussão, dado que muita gente foi pega de surpresa pelo anúncio).

Não entro nestes detalhes, pois acredito que seja perda de tempo discutir o passado, e prefiro encarar as coisas desta forma:

- A Oracle doou o código e a licença de marca à Apache, e isto é um fato.

- Pelo que sei sobre a estrutura decisória dentro da Oracle, a única lei que vale por lá é a “Lei de Ellison” e portanto duvido que IBM ou qualquer outra empresa tenha tanto poder de influência assim sobre eles.

Falando em Ellisson, escrevi um artigo há alguns meses com minhas impressões sobre ele e sobre o “mal” que ele poderia fazer a todo o eco sistema FLOSS, e vejo que a doação agora em questão minimiza um pouco este dano. Se olharmos as possibilidades, a Oracle podia muito bem ter decidido simplesmente enterrar o projeto e sua licença de marca.

Deixando de lado o passado, evitando discussões que literalmente não vão nos levar a nada e só nos causar perda uma de tempo e de talento enorme (além de deixar algumas cicatrizes complicadas), quero falar um pouco aqui sobre os motivos que me fazem acreditar que o Apache OpenOffice.org pode sim ser uma excelente notícia para toda a comunidade.

Um dos artigos que resume muito bem algumas coisas que penso a este respeito foi escrito pelo Rob Weir em seu blog, e o recado lá pode ser resumido de forma bem rápida:  A real disputa de mercado não é entre a suíte de escritório em FLOSS A, B ou C, mas entre as suítes de escritório em FLOSS e a suíte de escritório proprietária que ainda reina absoluta no mercado. No final das contas, a disputa aqui é entre a proliferação e adoção maciça do padrão ODF versus os padrões proprietários e o nosso velho amigo OpenXML (que aliás está agora em uma fase bem complicada, uma vez que a Microsoft perdeu o processo para a i4i na Suprema Corte Norte Americana há alguns dias).

Eu acredito que o Apache OpenOffice.org (AOOo a partir de agora neste texto) possa se tornar em breve algo como um “kernel” de suíte de escritórios que poderá ser reutilizado por diversas empresas e organizações em pessoas no mundo todo. Poderá ser utilizads como está, ou  complementada com outras funcionalidades.

Imagino um futuro do AOOo, muito parecido com o próprio kernel Linux, mantido e desenvolvido de forma colaborativa por uma fundação, utilizado por comunidades e empresas no mundo todo para a criação de “distribuições” específicas para cada necessidade ou nicho de mercado.

Não vou entrar aqui na discussão filosófica sobre a Licença Apache V2 versus a GPL, pois como já disse, o OOo na Apache é fato consumado, mas entendo que o resultado de mercado será a participação de mais empresas no ecossistema e a volta real de competitividade na indústria de suítes de escritório.

Isso para mim é algo inédito na indústria de TI, pois devido ao monopólio de fato de mercado vivido na área, pode-se considerar que a indústria de suítes de escritório praticamente foi extinta há alguns anos, e foi o OpenOffice que de fato evitou a extinção deste setor. A ida do projeto para a Apache, na minha opinião, vai agir como um catalizador e permitir que a competição realmente volte a existir neste setor, que agora renasce das cinzas através de um “core” em Open Source.

Olhando finalmente para o projeto, eu acredito que o código fonte do AOOo poderá ser reestruturado para que possamos ter uma arquitetura que permita sua reutilização por outros projetos (como o próprio LibreOffice) de forma bem modularizada. É como uma loja de componentes eletrônicos, onde você escolhe os componentes que quer (ou precisa) utilizar, integra-os de forma a atender às suas necessidades (ou às necessidades de seus usuários) e faz o que bem quiser com o produto final. Gosto da licença permissiva da Apache de, pois na realidade a imensa maioria dos desenvolvedores que estão por lá querem na verdade uma única coisa: Que o software seja utilizado no mundo todo !

Com base nesta ideia de modularizar o software, eu elaborei o diagrama abaixo que é a minha visão de onde poderemos chegar um dia com o projeto. Reforço aqui que esta é a minha visão e de forma alguma a visão dos demais membros do projeto, e uma vez que uma das regras por lá é “é mais fácil pedir desculpas do que autorização”, publico a minha ideia aqui no meu blog sem ter discutido ela com ninguém por lá.

 

Acredito que termos um core com as funções primordiais das aplicações da suíte é algo extremamente óbvio, e também é óbvio imaginar que este core não é um bloco monolítico como representado neste diagrama, mas a ideia aqui é mostrar que todos os objetos e funções de processamento dos documentos em memória fiquem centralizados em um único local.

Gosto da ideia de separar a interface gráfica do projeto (GUI) do restante, pois podem existir requisitos ou casos de uso onde uma interface simplificada ou diferenciada seja necessária.

A existência de um mecanismo para extensões e plug ins bem definido é fundamental para que se possa complementar o software com qualquer extensão necessária, e normalmente estas extensões atendem a requisitos de um grupo de usuários específicos, como o verificador gramatical da Língua Portuguesa. É através deste mecanismos que veremos inovações serem incorporadas ao projeto com a velocidade da luz, e tenho plena confiança de que a comunidade de FLOSS vai se beneficiar disso, uma vez que o conhecimento técnico e o tempo necessário para escrever uma extensão são infinitamente menores do que o conhecimento e tempo necessários para modificar o “core” da suíte de escritório.

Linguagens de script são muito utilizadas hoje em dia, e tenho certeza que a linguagem de script da moda daqui a cinco anos ainda não foi criada. Por isso mesmo eu acredito que um mecanismo de suporte a scripts seja interessante, pois através dele será possível a utilização de scripts em diversas linguagens manipulando objetos e funções dentro do AOOo.

O Ooo já possui o UNO, um conjunto de APIs muito utilizado por diversos desenvolvedores, e acredito que ele deve ser continuado e complementado, dado que existem atualmente diversos casos de uso onde sua utilização é fundamental (um deles: usar o Ooo como servidor para conversão de documentos).

Gosto de ideia de ter o ODF Toolkit desenvolvido junto com o OOo dentro da Apache, mas esta decisão ainda não foi tomada por lá. Para quem não conhece, o ODF Toolkit é um conjunto de ferramentas e bibliotecas desenvolvidas há alguns anos para a manipulação de documentos ODF sem a dependência de uma suíte de escritório.

Para que possamos ler e escrever os documentos, os filtros são mais do que necessários, e vale a pena lembrar de que funções como Assinatura Digital e Criptografia podem ser feitas nesta camada.

Temos ainda a necessidade de ter a documentação do projeto bem elaborada, de manter o suporte nele a diversos idiomas e gosto da possibilidade de podermos fazer um “rebrandind” do software todo. Esta ideia do “rebranding” é basicamente centralizar todas as strings com o nome do produto (ex “Apache OpenOffice.org”) em um único local, pois se amanhã eu quiser utilizá-lo para gerar o “Jomar’s Office” ou a TDF decidir usa-lo como base do “LibreOffice”, tudo seja feito de forma simplificada.

Quando pensei nesta proposta de arquitetura, pensei ainda na forma pela qual poderemos organizar o desenvolvimento do software, uma vez que em cada uma destas caixinhas existem conhecimentos e expertise específicos e com isso, poderemos manter desenvolvedores focados em pontos específicos do desenvolvimento (cada um dá o seu melhor naquilo que gosta e é capaz de fazer), e ainda conseguiremos manter tudo funcionando de forma integrada.

Não coloquei ali nenhuma atividade referente a marketing, treinamento e suporte, pois acredito de verdade que estas são três funções específicas de cada país e para cada caso de uso da suíte, sendo funções muito dependentes da cultura local, e portanto, defendo o modelo onde os projetos nacionais sejam mantidos “como sestão” e que tenham representantes trabalhando de verdade dentro da Apache. O mesmo raciocínio vale para os esforços de localização do produto.

Para concluir, eu acredito que estamos nos arrumando na nova casa para poder trabalhar nas próximas décadas com o OpenOffice, e acredito que toda a indústria vai se beneficiar deste novo arranjo. Entendo e respeito a chateação de algumas pessoas e grupos neste processo de transição, mas não tenho dúvidas de que o bom senso vai prevalecer e que vamos unir as forças para continuarmos nossa batalha.

Algumas pessoas já me perguntaram o que exatamente eu quero fazer por lá, e a resposta é simples: quero fazer o que eu PUDER e o que o projeto PRECISAR. Ajudar é atender à necessidade do outro, e não agir de acordo com a sua própria vontade (se conseguir conciliar ambos, perfeito !)

Estarei palestrando no FISL 12 no final deste mês, e não consegui um espaço na grade do evento para tratar do Apache OpenOffice.org especificamente, mas estarei por lá durante todo o evento pronto para discutir o projeto com quem tiver interesse em participar. Estou também à disposição aqui no Blog para qualquer esclarecimento necessário, e convido a todos a participar conosco neste projeto.

PS.: Não vou responder questões filosóficas nem sobre os “por quês” do passado nos comentários. Se pensa em tocar nestes assuntos aqui, por favor leia isso antes. Já aprendi uma lição valiosa na Apache: por lá, troll ganha crachá bem rápido !

ATUALIZAÇÃO: A página com as informações sobre como participar do projeto pode ser encontrada aqui. Bora trabalhar !

Share/Save/Bookmark

I believe that most people already know that on June 1st, Oracle announced the donation of the OpenOffice.org source code and trademark to the Apache Foundation. Initially the project was received by the Apache incubator, and the the discussion started there shortly after the announcement.

I’m following and participating in discussions since the first day at the Apache Incubator mailing list, and I signed up as a committer early in the project. To have a better idea of what it means to “follow” the discussion list of the Apache incubator, the list had a peak of nearly 400 emails per day during the first weekend of discussions (yes, almost 800 emails to read over a weekend).

After several days of discussion, on last Monday (06/13) of the project was accepted by a large majority at the Apache Incubator and it’s now an incubated project (named podling at Apache), and we have many people working hard out there for it to become a graduated project. The project’s proposal can be accessed here, and the incubated project page here. As you can see, we’re still setting up all the infrastructure of the project over there, and many of commiters cited in the proposal doesn’t have yet their accounts, a process that should take a few days to be concluded.

I’m happy to see that we now have many “new people” in the project and willing to help, but also many experienced contributors, working with the software since the 90’s, former employees of the Star Division (where StarOffice was created), Sun and Oracle, now contributing individually. These are people who spent much of their lifes working on this project and therefore it isn’t “just another project” for them… I believe that the level of knowledge sharing will be very high, and this will greatly reduce the learning curve for “newbies” in the project (like myself).

I will not discuss here the Oracle’s decision to donate source code and trademark to the Apache Foundation rather than to any other foundation (such as The Document Foundation, which maintains LibreOffice), much less on speculations that IBM were behind this decision (these topics were discussed during the first days of discussion at the Incubator mailing list, mostly because many people were caught “off guard” by the announcement ).

I’ll not enter on these details, because I believe that, at this point, discuss the past it’s a waste of time and I prefer to look at things this way:

- Oracle has donated the OpenOffice’s source code and trademark to the Apache Foundation, and that’s a fact.

- From what I know about the decision-making structure within Oracle, the only law that applies there is the “Ellison’s Law” and therefore I doubt that IBM or any other company has as much power of influence over them.

Speaking of Ellison, I wrote an article several months ago with my impressions about him and “evil” that he could do the whole FLOSS ecosystem, and for me the donation made here minimizes the damage. If we look at the possibilities, Oracle might well have decided to simply bury the project and its trademark.

Leaving the past aside, avoiding discussions that literally will lead us to nowhere and  cause us a loss of time and talent (and leave some complicated scars), I would like to talk a little bit here about the reasons that makes me believe that Apache OpenOffice.org may indeed be good news for the whole community.

One article that pretty much sums up some things that I think about the whole issue, was written by Rob Weir in his blog, and the message there can be summarized quite rapidly: A real market dispute isn’t in between the FLOSS office suite in A, B or C, but between the FLOSS office suites and the proprietary office suite that still reigns in the market. Ultimately, the dispute here is between the proliferation and worldwide adoption of the ODF standard versus proprietary standards and our old friend OpenXML (which incidentally is now at a very complicated stage, since Microsoft lost the i4i law suit at the US Supreme Court a few days ago).

I believe that Apache OpenOffice.org (AOOo for now on on this blog post) may soon become something like an office suite “kernel” the that can be reused “as is” or complemented with other features by people in various companies and organizations around the world.

I can imagine AOOo in a future acting much like the Linux kernel itself, maintained and developed collaboratively by a foundation, used by communities and businesses worldwide to create “distributions” for each specific need (or market).

I will not here enter into the philosophical discussion about the Apache License versus the GPL because as I said, OOo in Apache is a fait accompli, but I understand that the market outcome of that will be the participation of more companies in the ecosystem and the return of the real competitiveness at the office suites industry.

BTW, this is to me something inedited at the IT industry, because due to the de facto monopoly actually lived at the market, we can consider that the office suite industry was almost extinct a few years ago, and OpenOffice was probably “the thing” that avoided the complete extinction. OpenOffice.org move to Apache, in my opinion, will act as a catalyst on this process and will enable the real competition again in this sector, now reborn from the ashes through a Open Source “core”.

Finnally looking at the project, I believe the AOOo source code can be restructured so we may have in the future an architecture that allows reuse by other projects (as the LibreOffice) in a modularized fashion. It’s like an electronics store, where you choose the components you want (or need) to use, integrates them to meet your needs (or the customr’s needs) and do whatever you want with the final product. I like the Apache license permissive approach, because the vast majority of developers who are out there working at the project actually want just one thing: See the software being used worldwide!

Based on this idea of a modularized software, I worked out the diagram below that is my vision of where we can go one day with the project. I’ll reinforce here that this is my view and in no way the view of other members of the project, and once one of the rules at Apache is “is easier to apologize than to ask permission” I’ll publish my idea here in my blog without have discussed it with anyone there.

Jomar’s idea on a possible Apache OpenOffice.org architecture

I believe a core with the core capabilities of the office suite is extremely obvious, and it is also obvious to imagine that this core is not a monolithic block as represented in this diagram, but the idea here is to show that all functions and objects of the document processing remain centralized in one location.

I like the idea of separating UI design (GUI) of the rest, since there may be requirements or use cases where a simplified interface or a different one is needed.

The existence of a mechanism for extensions and plug-ins is critical to complement the software with any extent necessary, and usually these extensions meet the requirements of a specific group of users, such as the Portuguese language grammar checker. It is through this mechanism that we will see innovations being incorporated into the project with the speed of light, and I have full confidence that the FLOSS community will benefit from this, since the technical knowledge and time required to write an extension is infinitely smaller than knowledge and time needed to modify the “core” of the office suite.

Scripting languages are widely used today, and I’m sure the scripting language “on fashion” in five years hasn’t yet been created. For this reason I believe that a mechanism for scripting support is interesting, because it will be possible through the use of scripts in various languages to manipulating objects and functions within the AOOo.

The UNO is already at OOo, a set of APIs widely used by many developers, and I believe it should be continued and complemented, as there are currently several use cases where its usage is crucial (eg: use OOo as a server for documents conversion).

I like the idea of having the ODF Toolkit developed within the Apache OOo, but this decision has yet been taken there. For those unfamiliar, the ODF Toolkit is a set of tools and libraries developed to handle ODF documents without relying on an office suite.

In order to read and write documents, filters are more than necessary, and it is worth remembering that functions as a Digital Signature and Encryption can be done in this layer.

We still need to have a well prepared project documentation, to keep the multiple languages support and I enjoy the possibility of having an easy way to do the “rebrandind” of the software. This idea of “rebranding” is basically to centralize all strings with the product name (eg “OpenOffice.org Apache”) in one place, and if tomorrow I want to use it to generate the “Jomar’s Office” or if the TDF decide to use AOOo as the basis of “LibreOffice,” everything is done in a simplified manner.

When I thought about this architecture proposal, I also thought in how we organize the software development, seeing that each of these boxes there are specific knowledge and expertise needed and thus, we can keep developers focused on specific points of development (each one gives his best where they fell comfortable and capable to work) and we still being able to keep everything running seamlessly.

I didn’t put there any activity related to marketing, training and support, because I believe that these are specific functions of each country and each use case of the suite, being  features heavily dependent on local culture and language, and therefore I think in a model where national projects are kept “as is” and they could have liaisons working within the Apache. The same reasoning applies to localization efforts of the product.

To conclude, I believe that we are arranging the new house to be able to work in the coming decades with OpenOffice, and I believe that the entire industry will benefit from this new arrangement. I understand and respect the annoyance of some people and groups in this transition process, but I have no doubt that common sense will prevail and we will join forces to continue our battle.

Some people have asked me what exactly I want to do there, and the answer is simple: I’ll do what I can and what the project needs. To help means to meet the needs of others and not act according to our own will (if you manage to achieve both, perfect !).

I will be speaking at FISL 12 later this month in Brazil, and I couldn’t get a space in the event to handle the Apache OpenOffice.org specifically (timing issue), but I’ll be there throughout the event ready to discuss the project with those interested in participating. I am also available here on the blog for any necessary clarification, and I invite everyone to join us in this project.

PS.: No, I will not answer philosophical questions about the “whys” of the past in the comments. If you plan to touch on these issues here, please read this before you do. I’ve learned a valuable lesson in Apache: there, troll wins a cool badge real quick!

UPDATE: The page with the instructions for people that would like to join us on the project can be found here.

Share/Save/Bookmark

Nos últimos anos eu acompanho o desenvolvimento e a adoção de padrões abertos internacionalmente, e de alguns meses para cá, comecei a notar algumas estranhas movimentações e por conta delas decidi escrever este texto.

Existem dois fatos inegáveis no mundo da tecnologia da informação hoje em dia, que muitas vezes acabam sendo esquecidos no nosso dia a dia:

Empresas são monopolistas por natureza e a dependência tecnológica é a base do modelo econômico da indústria de tecnologia da informação.

O desenvolvimento de padrões tende sempre a comoditizar a indústria e por isso mesmo usualmente são desenvolvidos pelas empresas que dominam os mercados, e o fazem de forma preventiva. Quando estas não tomam a iniciativa da padronização, acabam vendo suas concorrentes mobilizando a cauda longa para que desenvolvam em conjunto o padrão e este quadro alternativo costuma ser o cenário típico do desenvolvimento de padrões abertos.

Os governos do mundo todo usualmente são os grandes demandadores da indústria de tecnologia da informação e seu poder indutor nesta indústria é crucial.

Foi assim que vimos um boom no desenvolvimento de padrões abertos, em grande parte demandado por governos do mundo todo (com destaque à União Européia), que perceberam o elevado grau de aprisionamento em que se encontravam e em que colocavam grande parte das empresas e cidadãos em seus países.

A indústria agiu rapidamente e tivemos inúmeros comitês nos últimos anos trabalhando no desenvolvimento de padrões abertos em tecnologia da informação, o que ocasionou verdadeiras guerras de padrões no mundo todo.

Em alguns países, a adoção de padrões abertos se deu de forma mais acelerada enquanto outros ainda debatem sobre quais padrões adotar, e como sempre este atraso no debate atende a interesses econômicos importantes.

O que noto com grande tristeza, é que existe uma sensação no ar de “batalha vencida” por parte de diversos governos e isso tem levado-os a não considerar mais a adoção dos padrões abertos como algo prioritário, mas como uma atividade corriqueira, como se tudo já estivesse concluído. Não canso de ver gente falando por aí: Isso aí é batalha ganha…

O resultado deste sentimento na indústria, é que muitas empresas já não tratam também o desenvolvimento de padrões abertos como algo prioritário e portanto, corremos o sério risco de ver padrões que levaram anos para ser desenvolvidos e adotados serem abandonados nos próximos anos.

A alegação que mais ouço das empresas sobre isso é que os governos deveriam trabalhar para a manutenção e o desenvolvimento dos padrões, e do lado dos governos, tenho ouvido com frequência que esta é uma função primordial da indústria… É assim que estamos caminhando a um perigoso jogo de gato e rato !

Por este motivo, eu alerto aos governos do mundo todo que cobrem cada vez mais a utilização de padrões abertos pela indústria de tecnologia da informação, e que cumpram com seu papel de fomentar o desenvolvimento de padrões abertos, principalmente através de casos de uso e de demandas do mundo real.

Lembro-lhes que as empresas em geral só enxergam lucro financeiro, enquanto os governos deveriam se preocupar com o lucro social, e sem a adoção de padrões abertos em TI, o acesso igualitário à informações e serviços públicos por meio eletrônico não são possíveis.

É importante ainda lembrar que em tempos de computação em nuvem, os padrões abertos são mais essenciais do que nunca, uma vez que a armadilha de aprisionamento aqui está na saída e não na entrada.

Desenvolver padrões abertos demanda muito mais tempo e recursos do que desenvolver padrões proprietários, além de comoditizar a indústria, dificultando o lucro fácil e imediato. Se deixarem esta decisão na mão das empresas, não se surpreendam com o resultado final.

Share/Save/Bookmark

In recent years I’ve been  following  the development and adoption of open standards internationally, and few months ago, I began to notice some strange movements and on behalf of them decided to write this article.

There are two undeniable facts in the information technology industry today, which often end up being forgotten in our day by day activities:

Corporations are monopolistic by nature and technological dependence is at the base of the  information technology industry  economic model.

The development of standards always tends to commoditize the industry and this is why they usually are developed by companies that dominate the market, and they do so in a preventive manner. When they don’t take the standardization initiative, they end up seeing their competitors mobilizing  the “long tail” to jointly develop the standard and this alternative scenario tends to be the typical scenario of the open standards development.

Governments around the world are usually represent the largest demand at the information technology industry and their inductor power in this industry is cruscial.

That’s how we saw a boom on the open standards development in the past years, demanded by many governments around the world (with emphasis on the European  Union), who realized the high level of lock in that they were in, and put in most companies and citizens on their countries.

The industry moved quickly and we saw several committees in recent years working on open standards development in IT world, which led to real worldwide standards wars.In some countries, the open standards adoption were more accelerated while others still debating about which standards to adopt, and we all know that this delay on the debates serves some important economic interests.

What I note with great sadness is that there is a “Battle Won” feeling in the air of several governments and this has led them to not consider further the open standards adoption as a priority,but as a commonplace activity, as if everything had been completed. I’m tired of seeing people talking out there: This is a won battle …

The result of this feeling in industry, is that many companies don’t treat  the development of open standards as a priority anymore and therefore, we run the serious risk of seeing standards that took years to be developed and adopted to be abandoned in the next years.

The claim that I most hear from companies about this, is that governments should work for the maintenance and development of standards, and from the government side,  I often hear that standards development is a primary function of the industry … This is how we are going to a dangerous cat and mouse game !

For this reason, I would advise the governments around the world to demand even more the adoption of open standards from the IT industry, and also fulfill the governmental role of promoting the development of  open standards, mainly sharing use cases and real world demands with open standards development bodies and committees.

I remind you that companies usually only care about financial profits,  while governments should care about their social profit, and without the adoption of open standards in IT world, the equal access to public services and information through electronic means aren’t possible.

It’s also important to remember that in times of cloud computing, the open standards are more essential than ever, since the imprisonment trap here is at the exit door.

The development of truly open standards demands more time and resources than the development  of proprietary standards, and they also commoditize the industry, making it difficult to get easy and immediate profits. If you leave this decision to corporations, do not be surprised with the final outcome.

Share/Save/Bookmark

En los últimos años he estado siguiendo el desarrollo y la adopción de estándares abiertos a nivel internacional, y hace unos meses, empecé a notar algunos movimientos extraños y en nombre de ellos he decdido escribir este artículo.

Hay dos hechos innegables en la industria de tecnología de la información hoy en día, que a menudo acaban siendo olvidados en nuestras actividades del día a día:

Las corporaciones son de monopólicas por naturaleza y la dependencia tecnológica está en la base del modelo económico de la industria de tecnología de la información.

El desarrollo de los estándares siempre tienden a generar comoditización en la industria y por eso que en general los estándares son desarrollados por empresas que dominan el mercado, y lo hacen de manera preventiva. Cuando no toman la iniciativa de normalización, terminan viendo a sus competidores hacer la movilización de la “larga cola” para desarrollar conjuntamente el estándar y este escenario alternativo tiende a ser el escenario típico del desarrollo de estándares abiertos.Los gobiernos de todo el mundo representan la mayor demanda en la industria de tecnología de la información y su poder inductor en esta industria es cruscial.

Por eso hemos visto un boom en el desarrollo de estándares abiertos en los últimos años, exigidos por la grand parte de los gobiernos de todo el mundo (con énfasis en la Unión Europea), que se han dado en cuenta su el alto nivel de lock-in tecnológico, para lo cual han alistado la mayoría de las empresas y los ciudadanos en sus países.

La industria se movió rápidamente y vimos varios comités en los últimos años trabajando en el desarrollo de estándares abiertos en el mundo de TI, lo que hasta ha conduzido algunas guerras de estándares en todo el mundo.

En algunos países, la adopción de estándares abiertos fué más acelerada, mientras que otros siguen debatiendo acerca de cuales normas a adoptar, y todos sabemos que este retraso en los debates sirve a intereses económicos importantes.

Lo que observamos con gran tristeza es que hay una sensación de “batalla ganada” en el aire de varios gobiernos y esto los ha llevado a no seguir con la adopción de estándares abiertos como una prioridad, sino como una actividad común, como si todo se había terminado. Estoy cansado de ver a la gente hablando por ahí: Esta es una batalla ganada …

El resultado de este sentimiento en la industria, es que muchas empresas no consideran más el desarrollo de estándares abiertos como una prioridad y por lo tanto, corremos el grave riesgo de ver los estándares que han llevado años para ser elaborados y adoptados, ser abandonados en los próximos años.

La afirmación que más escucho de las empresas acerca de esto, es que los gobiernos deben trabajar para el mantenimiento y desarrollo de normas, y desde el lado del gobierno, a menudo escucho que el desarrollo de estándares es una función primaria de la industria… Así es como vamos a un peligroso juego de gato y el ratón!

Por esta razón, yo aconsejaría a los gobiernos de todo el mundo para exigir aún más la adopción de estándares abiertos de la industria de TI, así como cumplir con la función gubernamental de promover el desarrollo de estándares abiertos, principalmente a través del intercambio de casos de uso y de las exigencias del mundo real con los organismos y comités que desarrollan estándares abiertos.

Les recuerdo que las empresas por lo general sólo se preocupan con sus lucros financieros, mientras que los gobiernos deben preocuparse por sus lucros sociales, y sin la adopción de estándares abiertos en el mundo de TI, la igualdad de acceso a los servicios y las informaciónes públicas a través de medios electrónicos no son posibles.

También es importante recordar que en tiempos de la computación en nube, los estándares abiertos son más esenciales que nunca, ya que la trampa de aprisionamiento aquí está en la puerta de salida.

El desarrollo de estándares verdaderamente abiertos exige más tiempo y recursos que el desarrollo de las estándares privativos, y también promoven la comoditización en la industria, haciendo con que sea más difícil obtener lucros fáciles e inmediatos. Si dejan esta decisión a las empresas, no se sorprendan con el resultado final.

Share/Save/Bookmark

O ODF 1.2 está concluído !

March 29th, 2011

No último sábado foi anunciada oficialmente a aprovação da versão 1.2 do ODF (OpenDocument Format) pelo OASIS ODF TC, comitê internacional que desenvolve o padrão ODF. A próxima etapa é a aprovação da versão 1.2 pelo OASIS, votação que deverá ser iniciada nos próximos dias.

Pelos processos do OASIS, uma especificação primeiro deve ser aprovada pelo comitê que a produziu para que possa posteriormente ser votada por todo o OASIS. Além da especificação aprovada, é necessário ainda que se tenha ao menos 3 declarações de empresas de que o padrão está sendo utilizado por elas de forma interoperável. Até o presente momento, contamos com declarações da IBM, Oracle, KDE e Novell.

As principais novidades em relação a versões anteriores do padrão estão relacionadas ao suporte à assinaturas digitais, web semântica e finalmente um padrão para armazenamento de fórmulas em planilhas (OpenFormula).

Este anúncio marca o término do ciclo de desenvolvimento do ODF 1.2 pelo ODF TC, depois de 4 anos de trabalhos. Eu participei de 3 destes 4 anos e gostaria de compartilhar aqui com vocês algumas das lições que aprendi.

A primeira delas, é que participar do desenvolvimento de uma especificação como o ODF, que será utilizada por milhões de pessoas em todo o mundo para o armazenamento de suas informações é algo extremamente gratificante, mas é também uma imensa responsabilidade.

Para mim o grande desafio colocado aos desenvolvedores é o balanceamento adequado entre a necessidade de especificar da melhor forma possível os elementos da norma, sem que isto impacte na capacidade de inovação da indústria.

Qualquer restrição adicional colocada na especificação pode ter como impacto uma restrição no momento da sua implementação, o que significa neste caso que restrições em excesso podem acabar engessando as possibilidades de utilização de documentos eletrônicos.

Por este motivo, muitas vezes somos obrigados a colocar uma recomendação onde o mais adequado poderia ser uma obrigação, e entender os impactos disso dá bastante trabalho e normalmente gera muita discussão dentro do comitê, e discutimos até que se tenha consenso sobre a decisão tomada. Por isso mesmo é importante que existam dentro dos comitês não apenas representantes de empresas de software, mas também representantes de usuários dos softwares, pois são estes os que sofrerão as consequências de um “deve” mal colocado.

O segundo grande desafio que enfrentei é a falta de suporte às minhas atividades de desenvolvimento da especificação. Acredito que parte disso seja culpa da minha teimosia por insistir em continuar um trabalho que infelizmente não é NADA valorizado em nosso país.

Podem entender isso como um desabafo pessoal, mas ‘tapinha nas costas’ não paga as contas e infelizmente as empresas brasileiras ainda não entenderam que para ter lugar no mercado global não basta ser um bom usuário de padrões, mas ser um bom desenvolvedor de padrões.

Como sou teimoso, passei por momentos extremamente complicados na minha vida pessoal (e financeira) durante os últimos anos e não foram poucas as vezes em que tive vontade de jogar a toalha e ser mais um sentado no sofá reclamando de como o império domina a colônia.

O que me motivou a continuar foi a receptividade e o respeito que sempre tive dentro do comitê do ODF, que me mostrou que de fato o Brasil e os profissionais brasileiros têm muitas portas abertas e oportunidades no mundo da tecnologia e o que falta mesmo é força de vontade para encarar o desafio e seguir em frente. Não existe empresa no mundo que invista de verdade aqui sem que sejamos capazes de mostrar a eles que temos competência e que podemos de verdade participar do desenvolvimento de tecnologia. Fiz a minha parte e posso dizer que a sensação de dever comprido paga tudo.

Gostaria ainda de lembrar-lhes que por mais que tenhamos feito muito e avançado com a TI em nosso país, com raríssimas exceções, ainda somos uma nação de usuários e não importa aqui se o produto em questão é livre ou proprietário… nossa posição cômoda de usar e reclamar é que nos faz ficar estagnados onde estamos (e sim, estamos estagnados) e mudar este quadro não depende apenas de política, interesse comercial e financiamento. Depende de atitude de pessoas como você e eu, e se você quer mesmo mudar isso: mexa-se !

Pretendo continuar trabalhando no comitê do ODF, e pretendo também continuar o trabalho dentro da ISO, onde participo do grupo de trabalho que trata da adoção do ODF na ISO (depois de aprovado pelo OASIS, o ODF 1.2 deverá ser enviado à ISO). A teimosia é forte por aqui, e gostaria de ver mais teimosos ao meu lado neste trabalho.

Entendo também que a conclusão do ODF 1.2 pelo OASIS encerra um ciclo profissional em minha carreira e em minha vida pessoal e por isso mesmo eu gostaria de agradecer a todos aqueles que me ajudaram nestes anos de batalha. Agradeço por tudo, principalmente pelos ‘tapinhas nas costas’ que inúmeras vezes foram responsáveis por me fazer seguir em frente :)

Gostaria de deixar um agradecimento especial àqueles que me deram a oportunidade de trabalhar com o ODF ainda lá em 2007, e outro aos que têm me apoiado durante os últimos doze meses. Vocês sabem quem são e agradeço de verdade por tudo o que fizeram e por tudo o que tentaram fazer por mim.

Não posso deixar de agradecer aqui também a um grupo especial de brasileiros teimosos que insistem como eu em continuar trabalhando no SC34 da ISO. Só nós sabemos o que passamos e quanto nos custou o trabalho que fizemos até hoje. Com vocês ao meu lado, qualquer batalha é “vencível”.

Para finalizar, gostaria de deixar aqui a frase que tem me motivado a seguir em frente quando as coisas ficam ruins de verdade:

“Seja a mudança que você quer ver no mundo.”
Gandhi

Share/Save/Bookmark

ODF 1.2 is finished!

March 29th, 2011

It was officially announced on last Saturday the approval of the ODF 1.2 Committee Specification by the OASIS ODF TC, the international committee that develops the ODF (OpenDocument Format) Standard. The next step is the approval of the ODF 1.2 by OASIS, and that ballot should be initiated in a few days.

By OASIS processes, a specification must first be approved by the committee that developed it to be voted by the entire OASIS. In addition to the approved specification at the TC level, it is also necessary to have at least three statements of companies that the standard is being used by them in a interoperable way. We have so far received statements from IBM, Oracle, KDE and Novell.

The major improvements on ODF 1.2 are related with the support for digital signatures, semantic web, and finally a standardized way to store formulas in spreadsheets (OpenFormula).

This announcement marks the completion of the development cycle of ODF 1.2, after 4 years of work. I attended three of these four years and would like to share with you some of the lessons learned.

The first one is to participate in the development of a specification like ODF, which will be used by millions of people around the world is extremely rewarding, but it is also a huge responsibility.

For me, the big challenge for standards developers is to find the balance the need to clearly specify the elements of the standard, with the impact on the innovation at the industry.

Any additional restriction placed on the specification may have an impact as a constraint in project implementation, which means in this case that a misplaced “shall” would restrict  the use cases of electronic documents.

For this reason, we are often obliged to make a recommendation where the most appropriate would be an obligation, and understand those impacts demands a lot of work and usually generates a lot of discussion inside the committee, and we usually discuss until the consensus is reached. Because of that, I believe that it is extremely important to have at committees the representatives of software companies but also representatives of users of the software, because they are the ones who suffer the consequences of a misplaced “shall”.

The second major challenge I faced is related with the lack of support for my strandard development activities in Brazil. Unfortunately this kind of activity has almost ZERO value in Brazilian IT&C industry and the little I could do was based on a lot of stubbornness with a high personal cost.

Anyway, I don’t like to be “another one” sitted at the sofa complaining about how the “developed world” rules over developing countries and my choise was to work without thinking about the profit that my work would bring me (right now, the profit is null and de debt is high).

What motivated most to “keep walking” was the receptivity and respect that I always received from the OASIS ODF TC members, who showed me that Brazil and the Brazilian professionals really have many open doors and opportunities in the technology world and it is up to us to prove that we really can work with technology development. I did my part and the accomplished duty feeling simply pays everything.

I intend to continue working with the ODF TC, and I also intend to continue working at SC34, where I’m a Brazilian expert at the working group that is handling the ODF maintenance at JTC1 (SC34 WG6).

I also understand that completion of the ODF 1.2 closes a cycle in my professional career and in my personal life, and therefore I would like to thank all those who helped me during the past years.

Finally, I would like to end with a quote that motivated me to move on when things get really ugly here:

“Be the change you want to see in the world.”
Gandhi

Share/Save/Bookmark

ODF 1.2 está listo!

March 29th, 2011

Se anunció oficialmente en el sábado pasado la aprobación del ODF 1.2 por el OASIS ODF TC, el comité internacional que desarrolla el estándar ODF (OpenDocument Format). El siguiente paso es la aprobación de ODF 1.2 por OASIS, y la votación debe ser iniciada dentro de unos días.

En los procesos de OASIS, una especificación debe ser aprobada por el comité que la desarrolló para ser votado por la totalidad de OASIS. Además de la especificación aprobada en el nivel del comité, también es necesario tener por lo menos tres declaraciones de empresas que la norma está siendo utilizada de una manera interoperable. Hasta ahora hemos recibido declaraciones de IBM, Oracle, KDE y Novell.

Las mejoras principales en ODF 1.2 se relacionan con el soporte a firmas digitales, web semántica, y finalmente, una forma estandarizada para guardar fórmulas en hojas de cálculo (OpenFormula).

Este anuncio marca la finalización del ciclo de desarrollo de ODF 1.2, después de 4 años de trabajo. Asistí a tres de estos cuatro años y me gustaría compartir con ustedes algunas de las lecciones aprendidas.

La primera de ellas es que participar en el desarrollo de una especificación como ODF, la cual será utilizada por millones de personas en todo el mundo es muy gratificante, pero también es una gran responsabilidad.

Para mí, el gran desafío para los desarrolladores de los estándares es encontrar el equilibrio entre la necesidad de especificar claramente los elementos de la norma, con el impacto sobre la innovación en la industria.

Cualquier restricción adicional colocada en la especificación puede tener un impacto como una restricción en la ejecución del proyecto, lo que significa en este caso, que un ‘debe’ fuera de lugar puede limitar los casos de uso de documentos electrónicos.

Por esta razón, por veces somos obligados a hacer una recomendación cuando el más adecuado sería una obligación, y entender los impactos de cosas como estas demanda una gran cuantiad de trabajo y genera mucha discusión dentro del comité, que por lo general discute hasta que se llegue al consenso. Por eso, creo que es muy importante tener en los comités representantes de empresas de software y también representantes de los usuarios del software, ya que ellos son los que sufren las consecuencias de un ‘debe’ fuera de lugar.

El segundo gran desafío que he enfrentado se relaciona con la falta de apoyo a mis actividades de desarrollo del estándar en Brasil (y creo que lo mismo se pase en otros países suramericanos). Desafortunadamente este tipo de actividad tiene casi valor CERO en la industria brasileña de TI y C y lo poco que pudo hacer fue echo con grand testarudez a un costo personal elevado.

De todos modos, no me gustaría ser “más otro” sentado en el sofá, quejándose acerca de cómo el “mundo desarrollado” reglas sobre los países en desarrollo y mi opción fue a de  trabajar sin pensar en el lucro que mi trabajo me podría traer (ahora mismo, el lucro es nulo y de la deuda es alta).

Lo que más me motivó a “seguir caminando”, fue la receptividad y el respeto que siempre he recibido de los miembros del OASIS ODF TC, que me han mostrado que Brasil y los profesionales brasileños realmente tiene muchas puertas abiertas y oportunidades en el mundo de la tecnología y que depende de nosotros demostrar que realmente podemos trabajar con el desarrollo tecnológico (pienso nuevamente que lo mesmo se aplica a todos los sudamericanos). Yo hice mi parte y la sensación de deber cumplido paga por todo.

Tengo la intención de seguir trabajando con el ODF TC, y también la intención de seguir trabajando en SC34, donde yo soy un experto brasileño en el grupo de trabajo que se está encargando del mantenimiento de ODF en JTC1 (SC34 WG6).

También entiendo que la realización del ODF 1.2 cierra un ciclo en mi carrera profesional y en mi vida personal, y por lo tanto me gustaría dar las gracias a todos los que me ayudaron durante los últimos años.

Por último, me gustaría terminar con una cita que me motivó a seguir adelante cuando las cosas realmente se complicaron por aquí:

“Sé el cambio que quieres ver en el mundo.”
Gandhi

Share/Save/Bookmark

Papel de parede ODF

September 24th, 2010

Já faz bastante tempo que quero fazer um papel de parede com o logo do ODF para meu smartphone, mas como não tenho a habilidade necessária, nunca consegui nada que não passasse do tosco…

Outro dia eu estava procurando na Internet para ver se achava algum legal, e encontrei um logo do ODF muito bem feito no site andy.fitzsimon.com.au. Entrei em contato com o Andy e pedi autorização para ele para usar o logo e ele além de autorizar me enviou ainda um arquivo SVG com mais uma série de ideias…

Com base neste arquivo que criei o papel de parede abaixo, em duas versões: BlackBerry (que também serve para desktops e outros smartphones com teclado) e Android (que pelas dimensões da tela teve o logo principal reduzido).

ODF Walpaper Small

Disponibilizo ainda o arquivo em SVG com o logo, na esperança que alguém com mais talento gráfico por aí faça um logo mais legal.

Divirtam-se e distribuam livremente o material !

Share/Save/Bookmark

ODF Wallpaper

September 24th, 2010

I’ve spend a lot of time on the past years trying to make a wallpaper with the ODF logo for my smartphone, but as I don’t have the necessary graphical skills, I never got anything that could be useful…

Few weeks ago, I was searching the Internet to find some cool ODF logos, and finally found one very well done on a site andy.fitzsimon.com.au. I contacted Andy and asked his permission to use the logo. He authorize me and even send me an SVG file with other ideas…

Based on this file I created the wallpaper below, in two versions: BlackBerry (which also fits on desktops and other smartphones with keyboards) and Android (which by the size of the screen had the main logo reduced).

ODF Walpaper Small

I’m also publishing here the SVG file with the wallpaper, in the hope that someone out there with more talent could make a better wallpaper.

Enjoy the material and distribute freely!

Share/Save/Bookmark

Proudly powered by WordPress. Theme developed with WordPress Theme Generator.
Creative Commons License