Software, Open Source, SOA, Innovation, Open Standards, Trends

Semana passada a ABNT, na pessoa de seu diretor de normalização, Eugenio de Simone decidiu pelo voto “NO with coments”, com relação à proposta da Ecma de aprovar o OpenXML como padrão ISO. O voto No que significa que o Brasil entendeu que o padrão ainda não está maduro o suficiente para se aprovado como está e que os comentários ou melhor, condicionantes, devem ser analisados e resolvidos antes de ser resubmetido à apreciação da ISO.

A decisão foi técnica e absolutamente lógica. O GT que analisou a proposta era composto por profissionais de grande competência e conhecimento do OpenXML, tendo entre outros Fernando Gebara da Microsoft, Jomar Silva da ODF Alliance, Avi Alkalay da IBM, Vitorio Furusho da Celepar e Leandro Goulart da Unesp, que inclusive apresentou palestra sobre OpenXML na Sucesu SP. Todos participantes dos GT e CE puderam ter acesso a centenas de documentos que circularam e ainda circulam pela Internet (este blog teve humilde participação levantando posts e links para muitos destes documentos...). Além disso empresas como Sun, IBM e Microsoft criarem grupos de estudo internacionais para melhor avaliar as questões técnicas e disseminaram estas informações. Portanto ninguém envolvido nas discussões ficou sem ter conhecimento adequado e suficiente para avaliar e definir suas posições. Também ninguém poderá alegar que não conhecia as diretrizes do ISO/IEC, que são públicas: “A purpose of IT standardization is to ensure that products available in the marketplace have characteristics of interoperability, portability and cultural and linguistics adaptability. Therefore standards, which are developed shall reflect the requirements of the following Common Strategic Characteristics:InteroperabilityPortabilityCultural and linguistic adaptability”.

Bem, as alternativas de voto seriam abstenção, sim ou não. Abstenção pode acontecer quando a entidade não se sentir competente tecnicamente (ou não tiver tido tempo suficiente) para avaliar o padrão de forma adequada. Não foi o caso. A equipe do GT analisou em profundidade o OpenXML e inseriu mais de 200 comentários. Também pode ser usado quando a CE não chegar a um consenso. Mas todos da CE concordaram que haviam problemas técnicos. Em tempo a reunião foi gravada para se evitar futuros problemas de “disse-me-disse”. A questão era saber se estes problemas seriam graves o suficiente para serem impeditivos ou não. Um voto “yes” significaria que a entidade está aceitando o padrão como proposto e que os únicos problemas encontrados são meramente editoriais, como vírgulas e pontos fora de lugar. Também não foi o caso. Este voto implicaria que todo o exaustivo trabalho de meses do GT seria simplesmente ignorado...

A desaprovação ou voto “não” com condicionantes significa que foram encontrados erros técnicos ainda não resolvidos. Este voto, com comentários anexados, indica que o padrão poderá vir a ser aceito desde que os problemas sejam corrigidos da forma sugerida. Supondo que o padrão não seja aceito na votação de 2 de setembro, provavelmente terá outra chance em fevereiro quando ocorrerá o Ballot Resolution Meeting. Nesta reunião os comentários anexados aos votos “no” são analisados e se avalia se podem ser resolvidos de forma adequada pela entidade que propôs o padrão.

A própria Microsoft em nota oficial disse que “os comentários técnicos que foram objeto de consenso (...) devem contribuir para o aperfeiçoamento do padrão OpenXML”. E ainda “o fato de ter havido consenso técnico representa efetivamente uma oportunidade de evolução da norma, como parte do processo natural de elaboração de qualquer norma técnica”. É sabido que qualquer software ou norma complexa (o OpenXML tem mais de 6.000 páginas) não fica pronto de imediato. Agora mesmo a Microsoft está disponibilizando um pacote de correções para o Windows Vista, com 680 MB (que é mais de 30% maior que uma instalação completa do XP...). Ora, uma aprovação imediata (“as is”) do OpenXML, com seus claros problemas técnicos, inconsistências, dependência de uma única plataforma, e mesmo questões de propriedade intelectual não resolvidos, seria ignorar a realidade de uma proposta ainda imatura e carente de aperfeiçoamentos para se tornar um padrão ISO. Quem leu pedaços da proposta viu, além de problemas técnicos, inúmeros erros ortográficos, inúmeros erros sintáticos nos exemplos XML, muita informação redundante, erros editorais crassos, etc, etc, etc. O padrão ainda não está pronto e na minha opinião não seria sensato ignorar tudo isso.

É importante lembrar: a Ecma não é uma entidade internacional de padrões, mas uma entidade (associação) privada. Para ser considerado um padrão, o OpenXML deve ser submetido à uma entidade assim reconhecida como a ISO. Por isso o OpenXML foi encaminhado à apreciação dos membros da ISO. Para ser aceito deve cumprir uma série de requisitos que garantam que não privilegia nenhuma empresa, não imponha restrições para seu uso, permita sua implementação por qualquer um, sem necessidade de consentimento expresso de nenhuma empresa, e assim por diante.

Vamos a alguns fatos: O OpenXML só está implementado e ainda de forma parcial no Office 2007. A proposta não apresentou o necessário mapeamento entre o formato binário e o OpenXML para garantir compatibilidade com o legado, como na sua especificação original. Também algumas questões de propriedade intelectual ainda não foram devidamente esclarecidos. A proposta também não utiliza padrões ISO já existentes como ISO 8601 (calendário gregoriano), ISO 639 (códigos de idiomas), ISO/IEC 10118-3 (criptografia), ISO 15948 (PNG), ISO 15836:2003 (Dublin Core) e ISO/IEC 15445:2000 (HTML). Uma parcela signficativa das 6.000 páginas é devido a este fato de não reutilizar padrões abertos já definidos, mas em propor padrões próprios. Por exemplo a proposta de usar o VML (que o W3C não aceitou, optando pelo SVG), que curiosamente a própria Microsoft pretende substituir por DrawingML, implicou em mais de 600 páginas da especificação (quase o mesmo tamanho da especificação ODF...)!

E o ODF? Já existe um padrão aberto aprovado pelo ISO, que é o ODF. Na minha opinião um único padrão maximiza os benefícios pelo efeito de rede (externalidade de rede), incentiva a inovação, aumenta a competição e amplia as oportunidades de escolha por parte do usuário. O argumento que dois (e porque não três ou quatro?) padrões aumenta competição é uma falácia. Se cada fornecedor cria seu próprio padrão “aberto” o resultado é simples: na prática não existirão padrões...Os clientes querem competição entrre produtos compativeis com o mesmo padrão e não competição entre padrões. Porque não todos, inclusive Microsoft, não investem na evolução do ODF? O mercado como um todo sairia ganhando...



[Read More]

Sistemas embarcados são o coração da maioria das máquinas e equipamentos que estão no nosso dia a dia. Entretanto, muitas vezes não reconhecemos estes equipamentos como computadores. Os chips e os sistemas que operam dentro deles estão, na maioria das vezes, escondidos dentro das funções básicas dos equipamentos. Operam de forma invisível para nós e seus contatos com o mundo exterior acontecem através de sensores e atuadores.

Muitos destes sistemas trabalham em tempo real, onde não pode haver demoras ou imprevisibilidades do tempo de resposta. E o que isto significa? Um sistema de tempo real opera sob requerimentos críticos de resposta, ou seja, se uma tarefa não for completada em um período determinado de tempo ela simplesmente terá falhado. Um exemplo simples pode ser um robô em uma linha de montagem. Se o seu sistema de controle não reconhecer determinado objeto em um instante preciso, quando ele estiver passando exatamente pelo ponto da solda, o objeto seguirá sem ter sido soldado e a operação terá falhado. Não existe possibilidade de recomeçar, recuando a esteira para reposicionar o objeto na posição correta e tentar uma segunda vez.

Para garantir esta resposta imediata, em um sistema operacional de tempo-real, um processo de alta prioridade assume o controle do processador de imediato, sem espera. Processos de alta prioridade não esperam por processos de prioridade inferior. Este escalonamento é chamado de escalonamento determinístico (deterministic scheduling). É um mecanismo diferente dos sistemas de uso geral.

Neste contexto temos o Linux crescendo em popularidade. Claro, que para operar em tempo real são necessárias algumas modificações no kernel, para torná-lo determinístico. Bem, e além do sistema operacional? Não podemos esquecer a própria aplicação. O desenvolvimento de sistemas embarcados em tempo real apresenta desafios que não são encontrados nos sistemas tradicionais. Um fator essencial é desempenho. Uma aplicação em tempo real deve operar sob rígidas limitações de desempenho. Como estes sistemas estão cada vez mais complexos, o fator produtividade torna-se também essencial. Devido a estas características, aliadas à maior capacidade dos processadores, começamos a deixar de lado Assembly, Ada e C, adotando C++ e Java. Java, por exemplo, como podemos ver em http://www.tiobe.com/ é uma linguagem cada vez mais disseminada. Ah, e falando em Java, recomendo a revista Mundo Java (www.mundojava.com.br), onde mantenho a coluna “Tendências em foco”. A publicação é realmente de altíssimo nível.

Mas, como esta dupla Linux e Java opera em tempo real? É realmente possível? Bem, temos um caso concreto para mostrar que funcionam bem, que é a implementação pela IBM e Raytheon dos sistemas de controle (incluem-se command-and-control, navegação, deteção de alvos, controle de armas e sistema de radar) da nova geração de destroyers da US Navy, a série DDG 1000. Este sistema é baseado em servidores blade, operando WebSphere e Java, em cima de Linux, em tempo real!

Uma novidade muito interessante é a adaptação de Java e do WebSphere para operar em tempo real. Com uso de Java aumenta-se em muito a produtividade e amplia-se a base de desenvolvedores aptos a desenvolver novas e mais complexas aplicações em tempo real. Não é mais necessário contratar-se experts em Ada, C ou Assembly...Uma descrição da aplicação desenvolvida para o DDG 1000 pode ser vista em http://www-03.ibm.com/press/us/en/pressrelease/21033.wss.

Também sugiro a leitura de alguns papers interessantes que descrevem como o WebSphere e Java foram adaptados para operar em tempo real. Acessem http://www-306.ibm.com/software/webservers/realtime/ para obterem estes papers. Um destes papers é “IBM WebSphere Real Time: Providing Predictable Performance”, que pode ser obtido em ftp://ftp.software.ibm.com/software/webservers/realtime/pdfs/WebSphere_Real_Time_Overview.pdf. Este paper descreve os componentes do ambiente Java em tempo real da IBM (IBM WebSphere Real Time).

Outro paper que recomendo ler é “Creating Predictable-performance Java Applications in Real Time”, obtido em ftp://ftp.software.ibm.com/software/webservers/realtime/pdfs/WebSphere_Real_Time_Technical_Overview.pdf . Neste paper vocês podem ver em detalhes como a J9 (Java Virtual Machine) da IBM funciona e o que foi necessário para adaptar uma JVM para operar em tempo real.

Bem, e não é só: acessem http://www.alphaworks.ibm.com/topics/realtimejava para mais informações sobre Java em tempo real, inclusive uma descrição técnica do Metronome, componente de Garbage Collection do Java em tempo real da IBM.

E, para finalizar, vocês conhecem a WebSphere Global Community? Se não, recomendo enfáticamente acessar www.websphere.org. Lá vocês encontrarão muitas informações e grupos de usuários, inclusive no Brasil (RJ, SP, RS, SC, DF, CE e GO).[Read More]

Nesta última quarta feira participei um debate sobre Convergência Digital na RioSoft. É um assunto que gera muita polêmica, inclusive porque a fantástica velocidade das inovações tecnológicas está gerando disputas acirradas entre setores de negócio antes isolados em seus mundos. A convergência digital (confluência entre voz, Internet e vídeos) está gerando uma verdadeira divergência entre as concessionárias de telefonia fixa e as operadoras de TV por assinatura. Vemos as teles entrando no mercado de vídeos e as operadoras de TV paga entrando na telefonia e banda larga. Todos estão brigando para conquistar um espaço no mundo convergente que está ainda se delineando. Pouco se sabe aonde chegará, mas com certeza a convergência digital vai mudar em muito os modelos de negócio atuais. E está claro que a rapidez das inovações tecnológicas já tornou obsoletas as leis e regras vigentes.

Na minha opinião precisamos rever rápido os aspectos regulatórios para permitir liberalização do mercado, único meio de se obter concorrência e incentivar inovações e conseqüentemente maiores benefícios para os consumidores, que são os que geram o mercado.

E em cima disso tudo temos a TV digital aberta, que adiciona sua dose de divergência...Especificamente quando falamos em TV digital aberta no Brasil entramos em um território ainda nebuloso. Não se tem uma idéia precisa dos preços dos conversores (set-top-boxes), falando-se em valores que variam de 100 a 800 reais. Existem muitas discussões sobre a possibilidade de se implementar o bloqueio de gravações, baseado na tecnologia DRM e já aparecem dúvidas quanto a eventuais problemas nas antenas coletivas instaladas nos condomínios. Será que os condomínios terão que fazer ajustes (leia-se despesas extras) nas suas antenas coletivas? Parece que sim, uma vez que os canais abertos são transmitidos em VHF e os canais digitais o serão em UHF.

Por sua vez, a questão do bloqueio gera um debate acirrado, temperado com pitadas de ideologia e, claro, defesa de grandes interesses comerciais. A idéia proposta é que este bloqueio venha instalado de fábrica, e permita apenas uma primeira gravação, impedindo gravações posteriores. Com isso não seria possível repassar o conteúdo a outros equipamentos, inclusive da mesma residência, como um PC.

Bem, tenho minha opinião pessoal: implementar este bloqueio impede o consumidor de decidir o que fazer do conteúdo que recebeu. Entendo que o bloqueio mantém o modelo de negócio da TV tradicional, mas tenho dúvidas quanto a sustentabilidade deste modelo a longo prazo. A indústria fonográfica lutou contra os novos modelos que surgiram com a Internet e está agora aceitando que a derrota é inevitável. O que vemos? As grandes gravadoras adotando a máxima “se você não puder vencer o inimigo, junte-se a ele...”

Além disso, este bloqueio inibirá inovações e dificultará o surgimento de novas aplicações e novos modelos de negócio. Cada vez mais as inovações acontecem no lado do consumidor e depois é que chegam às empresas. Bloquear conteúdo vai inibir esta máquina geradora de inovações. Tem uma frase do magnata da mídia, Rupert Murdoch, que diz isso claramente: “Power is moving away from the old elite [...] into the hands of a new generation of media consumers”. Qualquer medida de proteção de conteúdo para ter sucesso deverá ter como foco a visão do usuário. Brigar contra o mercado não é salutar!

E vamos falar um pouco mais sobre novos modelos de negócio possibilitados pela convergência digital. Hoje mais pessoas assistem diariamente aos vídeos do YouTube que aos quatro programas de maior audiência da TV americana juntos (ou dos 15 programas mais assistidos da televisão britânica, também somados juntos)! Claro que isto gera um conflito entre a mídia tradicional (conteúdo proprietário, de distribuição controlada) e as novas mídias que surgem com a convergência digital, com conteúdo gerado pelo usuário e distribuição aberta. Analisando este contexto podemos ver que esta é uma grande diferença entre os modelos. A nova mídia tem seu conteúdo gerado pelo usuário (o YouTube é um agregador de conteúdos gerados pelos usuários, ele por si, não gera nenhum vídeo), distribuídos por plataformas abertas, sem restrições de acesso. A mídia tradicional gera seu próprio conteúdo e controla sua distribuição.

E é interessante ver a divergência de visões...Um estudo da IBM mostrou este conflito de visões de forma bem clara. A visão de um professor de midia europeu: “Content creators are currently not fully using the community’s creativity. There are great fan communities that can write and even produce new episodes of favorite shows. They know the whole history of the content by heart”. Já na visão de um executivo da mídia tradicional: “We will never rely on user content. We are never going to be YouTube…never be in the upper right at all”.

Bem, temos aí um belo conflito de interesses. Como será o futuro? Sinceramente não sei, mas sabemos que quando há um conflito, existem vencedores e perdedores...A mídia tradicional contnuará atendendo a uma parcela de consumidores que querem continuar vivendo suas experiencias atuais com a TV (telespectador passivo), como também teremos muitos demandando uma maior interatividade e interação social. Assim, entre estes dois extremos, novos e inovadores modelos de negócio irão surgir.[Read More]

Aplicações mashup começam a despertar bastante atenção. Já vemos muitos eventos debatendo o tema e um evento que vale a pena participar é o MashupCamp, que vai ocorrer em setembro na Europa (http://www.mashupcamp.com/). A IBM é patrocinadora deste evento. Aliás, estamos investindo intensamente neste conceito. Vejam a iniciativa IBM Mashup Hub no Alphaworks, acessando http://services.alphaworks.ibm.com/mashuphub/.

Aplicações mashup estão no cerne do modelo Web 2.0. As primeiras aplicações mashup que apareceram, muitas delas usando Google Maps, ainda são a ponta do iceberg. Nós estamos dando os primeiros passos em um novo mundo, onde usuários e parceiros de negócios desenvolverão aplicações em cima das nossas próprias aplicações.

Mas, para fazer isso, precisamos adotar o conceito de visualizar nossas aplicações como plataformas, onde o mundo externo poderá acessá-las via APIs abertas e publicadas. Se olharmos com atenção, veremos, na prática, que estamos falando da junção dos mundos SOA e Web 2.0. Bem, vou explicar melhor...

Para começar vamos ver alguns casos práticos. Começando com o eBay. Quando o eBay foi criado, a chave para o sucesso do comércio eletrônico era criar um site na Web. Com este modelo o eBay tornou-se um dos maiores sucessos da era da Internet. Mas, hoje, a ação está onde os usuários a criam, ou seja, em páginas de relacionamento MySpace, em vídeos no YouTube ou em seus blogs. Portanto, para o eBay se manter bem sucedido, tem que estar em todos estes lugares. Como fazer isso? Abrindo APIs que ofereçam serviços que permitem às pessoas comprar itens do eBay fora de seu site central. Por exemplo, permitir acessar o eBay de dentro do Facebook ou MySpace. Nas declarações de seus executivos, nos recentes eventos para investidores ficou claro a estratégia futura: o eBay não será apenas um site, mas um provedor de serviços que reforce o comercio eletrônico em toda a Internet.

Outro exemplo é a Amazon. O seu fundador e CEO, Jeff Bezos, disse recentemente: “We´re all building this thing together”, ao comentar a estratégia da empresa em incentivar desenvolvedores externos a acessarem os serviços da Amazon e os embutirem em outros sites e aplicações. E embora muitas empresas ainda tenham receio de abrir seus dados proprietários, a Amazon é clara: “The more data that we’re able to put in the hands of external developers, the more interesting tools, sites, applications will be built, and the more of those that exist, the greater the return to Amazon. We’re going to see more traffic, more clicks, and ultimately we’ll see more purchases. So it’s definitely not like a science experiment”.

Querem um terceiro exemplo? Google! Abrindo APIs para suas aplicações, incentivam a inovação e novas aplicações. Um executivo do Google disse recentemente: “We expect new and creative ideas to come out of this that we haven´t thought of yet”. Que estas empresas estão fazendo? Abrindo seus sistemas via APIs para que parceiros externos criem novas e inovadoras aplicações, integrando os processos de negócios. O acesso às APIs Google Maps pode ser enncontrado em www.google.com/apis/maps/ .

Mais ainda? Bem, que tal olhar o Zillow.com (www.zillow.com) ou a JetBlue Airways, onde seus passageiros podem acompanhar a posição do avião, usando GoogleMaps, na tela de seu assento, sintonizando o canal 13. Aliás a JetBlue permite a cada um acompanhar a situação de cada vôo em tempo real, acessando seu site (www.jertblue.com) e clicando nas opções Manage your flights/Track a flight. Que nem aqui...

E, para não cansar, um último exemplo... Vejam o AccuWeather (www.accuweather.com), que implementa aplicações mashup usando a tecnologia QEDWiki da IBM. Vejam em http://www-03.ibm.com/press/us/en/pressrelease/20731.wss e http://www-03.ibm.com/developerworks/blogs/page/Turbo?entry=today_s_weather_mashed_up. Também tem um video interessante no YouTube sobre o uso desta tecnologia, que pode ser acessado em http://br.youtube.com/watch?v=ckGfhlZW0BY .

Bem, e se quiserem dar uma olhada nas inúmeras APIs para Web 2.0 disponíveis, visitem //programmableweb.com. Vale a pena.

Qual é a mensagem que estes exemplos estão nos passando? Abram suas plataformas de negócios para incrementar a velocidade, escopo e ritmo da inovações. Manter as aplicações fechadas vai restringir a inovação aos limites de criatividade da sua própria equipe de profissionais. E isto não se aplica apenas ao Google, Amazon ou eBay, mas a bancos, empresas aéreas, seguradoras, industrias automotivas, órgãos públicos (que tem imensas bases de dados, muitas vezes subutilizados pela sociedade), etc, etc, etc...

OK, mas como colocar estas idéias em prática? De um lado temos as comunidades com tecnologias que permitem criar aplicações mashup. Mas do lado da empresa? Como abrir APIs para a parafernália de aplicações com problemas de integração e diversidades tecnológicas? A resposta, no meu entender, está na proposta do SOA. Porque não criar uma camada, que chamaremos de plataforma de negócios, em cima das aplicações da empresa? Esta plataforma abriria à comunidade de usuários e parceiros de negócios os serviços que as aplicações internas oferecem (quando falamos em aplicações, falamos em processos de negócios) via APIs abertas e publicadas.

A plataforma se encarregará de acessar as aplicações internas, sejam elas novas, ou legadas, estas encapsuladas, via SOA, expondo-as publicamente. Ou seja, desenhamos dois componentes na arquitetura de aplicações da empresa: uma voltada para interação com os usuários (a plataforma aberta, acessada por APIs, permitindo aos usuários criarem suas aplicações mashup) e outra, para suportar internamente os serviços de negócios. A camada de serviços de negócio é constituída de componentes ou aplicações que implementam os processos de negócio. A cola entre estes dois mundos é SOA.

Fácil de visualizar, não é? O difícil é colocar em prática. Desenvolver aplicações para Web 2.0, que são por natureza dinâmicas e baseadas no conceito de serviços, demanda muitos ajustes nas técnicas e processos de desenvolvimento de software que as empresas atualmente adotam. Demanda novos skills de programação, com ênfase em Ajax (www.openajax.org) e scripting languages, como Perl, PHP, Python e Ruby. Exige técnicas (lightweight ou simplified programming models) e processos de desenvolvimento mais rápidos (Agile Software Development). Uma introdução superficial ao assunto pode ser vista em http://en.wikipedia.org/wiki/Agile_software_development . E demanda também um cuidado muito maior nos projetos de interfaces com os usuários.

Não se chega lá de um dia para o outro, mas se compreendermos as vantagens competitivas desta estratégia, que nos abrirá explorar inúmeras oportunidades de inovação, temos que começar logo a dar os primeiros passos. Porque não pensar em SOA como estratégia de transformação dos negócios, acoplando-a ao conceito da Web 2.0 e aplicações mashup? Fica aqui a idéia para uma reflexão mais ampla.

[Read More]

Na próxima quinta feira, 9 de agosto, teremos uma importante reunião da CE (Comissão de Estudo) da ABNT que debate a questão da aprovação ou não do OpenXML como padrão ISO. O Brasil é o único país da América Latina que é membro P da ISO, ou seja, ele é o único que tem direito a voto. Os demais países são membros O, de observador.

O voto brasileiro será adicionado a de outros países, no dia 2 de setembro, quando a ISO decidirá pela aprovação ou não do OpenXML. A questão da sua aprovação ou não como padrão ISO é de extrema importância para toda a sociedade. As implicações desta decisão são muito amplas: será definido que tipo de software usaremos nas próximas décadas, o grau de liberdade para se acessar no futuro os documentos armazenados hoje, bem como causará grande impacto na industria de suítes de softwares de escritório, hoje dominado pela Microsoft, que possui mais de 90% da base instalada. Interoperabilidade e portabilidade são palavras chave. A sociedade informatizada atual troca documentos a todo instante, entre cidadãos, funcionários e governos. Um formato de arquivos que não permite livre trânsito ou que não garanta seu acesso no futuro torna-se um grande problema.

Mas como as entidades de padrões votam na ISO? As diretivas do JTC1 da ISO (onde a votação acontecerá) dizem claramente: “The period for fast-track DIS (or DAM) voting shall be six months, consisting of a 30-day JTC1 National Body review period followed by a five-month ballot period. NBs may reply in one of the following ways:. Approval of the technical content of the DIS as presented (editorial or other comments may be appended);. Disapproval of the DIS (or DAM) for technical reasons to be stated, with proposals for changes that would make the document acceptable (acceptance of these proposals shall be referred to the NB concerned for confirmation that the vote can be changed to approval);. Abstention.”.

OK, vamos traduzir isso. As entidades de padrões só devem votar pela aprovação se tiverem certeza que o padrão proposto não contém erros técnicos. Um voto “yes” significa que a entidade está aceitando o padrão como proposto e que os únicos problemas encontrados são meramente editoriais, como virgulas e pontos fora de lugar. A desaprovação ou voto “não” com comentários significa que foram encontrados erros técnicos e existem questões de propriedade intelectual ainda não resolvidos. Este voto, com comentários anexados, indicam que o padrão poderá vir a ser aceito desde que os problemas sejam corrigidos da forma sugerida.

A entidade também poderá votar “Abstain” quando não se sentir competente tecnicamente (ou não tiver tido tempo suficiente) para avaliar o padrão de forma adequada.Também pode ser usado quando sua CE não chegou a um consenso quanto a votar “yes” ou “no”. Entretanto, ao votar pela abstenção, não terá garantias que seus comentários serão devidamente considerados na reunião de avaliação do padrão, quando os votos serão computados e os comentários analisados.

Ah, vamos falar desta reunião de avaliação, chamada de Ballot Resolution Meeting. Nesta reunião os comentários anexados aos votos “no” são analisados e se avalia se podem ser resolvidos de forma adequada pela entidade que propôs o padrão. O padrão só será aceito se os problemas identificados pelas entidades de padrões dos países puderem ser resolvidos adequadamente.

A decisão que as entidades dos países vão tomar vai definir com clareza se vale a pena ter um ou dois padrões para especificação de documentos (textos, planilhas e apresentações).

Já existe um padrão aberto aprovado pelo ISO, que é o ODF. Na minha opinião um único padrão maximiza os benefícios pelo efeito de rede (externalidade de rede), incentiva a inovação, aumenta a competição e amplia as oportunidades de escolha por parte do usuário, eliminando o aprisionamento forçado causado por um padrão proprietário. A proposta OpenXML, especificação desenvolvida pela Microsoft e apresentada via Ecma (European Computer Manufacturers Association), caso aprovada pelos órgãos de padrões dos países membros do ISO, vai gerar uma competição entre padrões, produzindo um efeito inverso ao de um único padrão. Dois ou mais padrões provocam uma tendência de agruparem-se ofertas de produtos em torno de um ou outro, diminuindo as alternativas e aumentando os preços no mercado. No decorrer do tempo, todos os usuários saem perdendo...Um exemplo é a Web: se além do padrão aberto HTML tivéssemos também um HTML# a Web teria esta amplitude hoje?

Venho pesquisando o assunto há bastante tempo. E tenho uma opinião formada. Primeiro estamos falando de uma proposta de mais de 6.000 páginas que devem ser analisadas com cuidado em um curto período de seis meses (a um ritmo de 1.000 páginas por mês ou mais de 30 por dia!), o que já impede uma análise mais criteriosa. E mesmo assim, muitos erros e inconsistências (inclusive várias dependências a tecnologias proprietárias da Microsoft) foram encontrados, todos amplamente divulgados na Internet. Já coloquei vários posts neste blog com estas informações, como vocês podem ver pesquisando as tags ODF e OpenXML.

É interessante obervar que no primeiro período de avaliação e envio de contradições (30 dias), 10 países, como Canadá, Austrália, Alemanha e Reino Unido, com ampla experiência em padrões, disseram que devido a erros e inconsistências, o OpenXML não deveria continuar sendo analisado por fast-track.

Depois, é importante lembrar que a proposta do OpenXML, segundo o documento da Ecma diz claramente: “Produce a Standard which is fully compatible with the Office Open XML Formats”. Isto quer dizer que um determinado software é que está direcionando o padrão e não o padrão que está direcionando as implementações de softwares...Ou seja, na prática ninguém poderá fazer mudanças no padrão (mas não é aberto?), se a Microsoft não aprovar.

Fica em aberto uma questão: alguma empresa de software poderá desenvolver uma suite 100% compatível com OpenXML? Quanto tempo necessitará para desenvolve-la (analisando 6.000 páginas) e quanta documentação específica de produtos Microsoft deverá absorver (se for factível) para conseguir esta proeza? Pensemos também no fato que, mesmo que OpenXML seja aceito pela ISO, devido a tantas inconsistências e problemas já identificados, a Microsoft e a Ecma levarão um bom tempo para sanar estas deficiências. Podemos falar em um ano? E quando sanarem ficará claro que o padrão OpenXML Ecma atual não será o mesmo de um eventual OpenXML ISO. Ora, durante este período de tempo dificilmente alguma sofware house desenvolverá um produto, para assim que estiver pronto ser refeito em grande parte. Na prática existe a imensa possibilidade da Microsoft ser a única desenvolver suporte para OpenXML. Aliás, alguns padrões Ecma são adotados apenas pela Microsoft. Basta lembrar o C#, que é um padrão Ecma, mas que só existe na implementação da própria Microsoft.

O assunto merece uma reflexão bem ampla. Temos um padrão aberto e já adotado por diversos softwares que é o ODF. Existe uma proposta de um segundo padrão, com claras inconsistências e problemas técnicos, com forte predomínio de um único fornecedor. Para mim está muito claro que o voto mais adequado deverá ser “no” com comentários.

[Read More]

Nesta próxima quinta estarei em Belo Horizonte, na edição mineira do Linux Park. Para informações sobre este excelente evento vejam www.linuxpark.com.br . A palestra que farei abordará o tema Economia do modelo Open Source.

Quando começamos a falar com mais intensidade em Open Source, não havia muita compreensão dos seus aspectos econômicos, havendo mesmo a suposição que seria uma economia intangível, “gift economy”, com desenvolvedores voluntários desenvolvendo programas sem nenhum compromisso econômico. Esta visão fez com que alguns críticos imaginassem que o Open Source não poderia ser sustentável a longo prazo, pois não haveriam valores monetários para sustentar o ecossistema que eventualmente fosse criado em torno de seus projetos. Também empresas de software com modelos de negócio baseadas em licenças mantiveram distância e chegaram mesmo a propor que este modelo seria anti-econômico por natureza.

Hoje, temos razoável maturidade e experiência prática para analisar a economia do Open Source sob outro ângulo. Sim, existe dinheiro em torno dos projetos Open Source, só que ele não está diretamente ligado ao código, mas ao seu redor, no seu ecossistema.

Indiscutivelmente que Open Source mudou as regras do jogo da indústria de software. É um risco como oportunidade para as empresas já estabelecidas. A grande inovação do modelo é o processo de desenvolvimento colaborativo, que dilui os custos de produção do software por vários atores. Não é que o custo para desenvolver um software aberto seja zero. Ele pode ser tão elevado quanto um software proprietário, mas está diluído por toda uma comunidade. Por exemplo, em http://www.dwheeler.com/essays/linux-kernel-cost.html e http://www.dwheeler.com/sloc/ podemos ver algumas estimativas de custo de desenvolvimento do kernel do Linux. Segundo esta estimativa, se este kernel (no caso 2.6) fosse desenvolvido a partir do zero teria custado mais de 600 milhões de dólares. E uma distribuição completa Linux como a Debian custaria mais de oito bilhões de dólares. Mas, ninguém arcou com este custo sozinho!

Este novo modelo de desenvolvimento colaborativo é que permite desenvolver novos modelos de negócio, onde o preço final do software em si pode ser mínimo. Um software proprietário joga nas costas do seu fabricante todo o custo e o risco de insucesso do projeto. O fabricante precisa de capital, pois a lucratividade vem muito tempo depois, uma vez que um software complexo leva anos para ser concluído, além do tempo necessário para vender cópias suficientes para amortizar o imenso investimento inicial empatado no seu desenvolvimento. Outro grande custo adicional é o marketing e a força de vendas necessários para que o produto seja comercializado com sucesso. No Open Source as regras são outras. Cada participante da comunidade adiciona uma pequena parte ao projeto e recebe em troca um software completo. E quando se disponibiliza o software para acesso via downloads, corta-se outra grande despesa, que são marketing e distribuição.

Bem, e como o ecossistema em torno de um projeto Open Source gera valores monetários? Vamos analisar dois lados da questão: o do integrador e o do produtor de software. Para integradores, que buscam entregar soluções que envolvam hardware e software para seus clientes, cada real a menos que ele precisa dispender em licenças de software é ou um real a mais em lucratividade ou uma redução de preços nos serviços, o que lhe abre mais opções de mercado.

E a indústria de software? Bem, se a empresa não tem um produto líder de mercado, com poucas chances de disputar uma parcela maior do market share, abrindo seu código fonte ele dilui os custos de evolução e amplia as chances de criar um ecossistema de negócios. Com um novo modelo de comercialização, ele passa a ter potencial para afetar a posição das empresas líderes. Claro que para isso é necessário criar uma comunidade abrangente e entusiasmada, e um ecossistema saudável que gire em torno do software.

Mas, não é só...Open Source abre oportunidades de expansão de negócios e entrada em mercados antes inatingíveis (olha aí o conceito da Cauda Longa), além de incrementar inovação, com a sinergia criada com as comunidades.

E a IBM, como se situa neste contexto? Estamos neste negócio de Open Source desde fins dos anos 90 (quando foi liberado o código fonte do Jikes, compilador Java) e já escrevi um post sobre este tema aqui no blog (IBM e Open Source, em 18 de maio). Os objetivos da IBM com Open Source são: aumentar o ritmo e velocidade das inovações, incentivando o “caldo cultural” de inovação nas comunidades (inteligência coletiva), ser um contribuidor ativo das comunidades e não apenas consumidor, capturar e transformar inovações Open Source em valor para nossos clientes (como exemplos o uso do Linux nos hardwares IBM e a tecnologia Rational fundamentada no Eclipse) e alavancar modelos de negócios baseados em Open Source para entrar em novos mercados e expandir oportunidades de negócio. É, portanto uma estratégia e não um simples oportunismo para explorar uma onda , ou uma reação forçada pela pressão do mercado.

[Read More]

Na quinta feira dia 9 aconteceu mais uma reunião na ABNT da CE (Comissão de Estudo) que debate se o Brasil apoiará ou não a proposta do OpenXML se tornar um padrão ISO. Infelizmente foi uma reunião muito tumultuada e pouco produtiva...E dentro de duas semanas acontecerá a reunião final, onde a Comissão definirá o voto brasileiro.

Bem, na minha opinião os membros da Comissão só deveriam votar YES se tiverem certeza que o padrão proposto não contém erros técnicos. Um voto YES significa que a entidade brasileira está aceitando o padrão como proposto e que os únicos problemas encontrados são meramente editoriais, como vírgulas e pontos fora do lugar. A desaprovação ou voto NÃO, com comentários, significa que foram encontrados erros técnicos e existem questões de propriedade intelectual ainda não resolvidas. Este voto com comentários anexados indica que o padrão poderá a vir a ser aceito desde que os problemas sejam corrigidos da forma sugerida.

Pode haver também um voto ABSTAIN, quando a entidade não se sentir competente tecnicamente ou não tiver tido tempo suficiente para avaliar o padrão. Também pode ser usado quando a CE não chegou a consenso quanto a votar YES ou NO.

Acredito que para uma decisão consciente por um voto YES ou NO é necessário um sólido background de conhecimentos sobre o assunto. Afinal, estamos falando do voto brasileiro para adoção ou não de um padrão. Claro que ninguém teve condições de ler as mais de 6.000 páginas, pois esta é uma tarefa impossível de se cumprir nos seis meses que estavam disponíveis para análise. Mas, inúmeros blogs e documentos que circulam na Web mostram centenas de problemas técnicos. O GT (Grupo de Trabalho) na ABNT que está analisando a situação do OpenXML no Brasil também detetou e registrou um número muito grande de problemas.

Na minha opinião, o voto é “NO with comments”. Além das várias razões para isso, como levantadas nos diversos posts anteriores sobre o assunto (vejam as tags ODF e OpenXML), cito a questão da compatibilidade com documentos legados, um dos principais motivos alegados para a criação de um novo padrão. No documento enviado pela Ecma está claramente explicitado isso: “OpenXML was designed from the start to be capable of faithfully representing the pre-existing corpus of word-processing documents, presentations, and spreadsheets that are encoded in binary formats defined by Microsoft Corporation. The standardization process consisted of mirroring in XML the capabilities required to represent the existing corpus, extending them, providing detailed documentation, and enabling interoperability. At the time of writing, more than 400 million users generate documents in the binary formats, with estimates exceeding 40 billion documents and billions more being created each year”.

Mas, o padrão apresentado não apresenta um mapeamento entre os formatos binários proprietários e o novo formato OpenXML. Sem este mapeamento, ninguém é capaz de escrever um software que garanta esta compatibilidade, a não ser a própria Microsoft que tem acesso aos fontes que descrevem os binários. Ora, se a compatibilidade não é garantida, para que apresentar este novo padrão? É muito mais racional então aglutinar esforços para evoluir o padrão já existente, o ODF.

Ter mais de um padrão sempre gera problemas. Um recente relatório feito pela PEGSCO (Pan-European eGovernment Services Committee), que pode ser lido em http://ec.europa.eu/idabc/servlets/Doc?id=26971 diz “Member State experts have identified the perceived compatibility problems between ISO 26300 (ODF) based products and the commercial applications that dominate the offices of today´s administrations as the main barrier for the use of document exchange and storage formats. The potential arrival of a second international standard for revisable documents may mean that administrations will be required to support multiple formats leading to more complexity and increased costs. Although filters, translators and plug-ins may theoretically enable interoperability, experience shows that multiple transformations of formats may lead to problems, especially as there is no complete mapping between all features of each of the different standards”.

Quem analisou as questões técnicas viu que existem inúmeros problemas na proposta atual do OpenXML, como inconsistências com padrões ISO já existentes (“paper sizes”, “dates and times”, “HTML colour names”, e outros) , inconsistências com recomendações da W3C (Uso do DrawingML ao invés do padrão SVG, como também não usa o padrão MathML). Várias seções da especificação fazem referência ao comportamento de uma aplicação sem definir a natureza deste comportamento. Por exemplo, “autoSpaceLikeWord95”. Como o Word95 é proprietário, torna difícil a outras empresas, que não a Microsoft, implementarem softwares baseados na especificação OpenXML.

E mais: não existe especificação para linguagem macro, embora o Office 2007 suporte macros VBA. Como VBA é uma linguagem proprietária, seu uso é restrito. Além disso, existem elementos dos formatos de arquivos Office 2007 que não estão documentados na proposta Ecma atual. O resultado é que existem grandes possibilidades de ocorrerem problemas de interoperabilidade.

Mesmo o uso de plug-ins não é tão simples assim. Demanda mais um componente de software a ser instalado e gerenciado (imaginem milhares de máquinas), bem como obriga a que os usuários envolvidos na troca de documentos mantenham plug-ins compatíveis entre si!

Portanto, temos uma decisão importante a tomar. Que deve ser tomada com consciência.

Bem, e quais são os cenários futuros? Um pouco de especulação…Supondo que a proposta Ecma não seja aprovada como padrão ISO, é muito provável que continue sendo mantida pela Microsoft. Se tornará um padrão “de facto”. Os softwares de escritório serão obrigados a suportar estes dois padrões, com os inevitáveis problemas de compatibilidade e interoperabilidade já citados. E pior, caso estes problemas se avolumem, pode-se ter uma reversão no processo de evolução para XML, com os usuários preferindo manter o formato binário, que acabará se perpetuando…[Read More]

Terça próxima, dia 21, teremos reunião na ABNT, no Rio de Janeiro, onde estaremos decidindo o voto brasileiro com relação à aprovação ou não da proposta da Ecma de tornar o OpenXML um padrão ISO.

Um dos mais atuantes membros da Comissão de Estudo (CE) que analisa o OpenXML é Jomar Silva, diretor da ODF Alliance no Brasil. Conhece profundamente ODF e OpenXML e pode falar com conhecimento de causa. Devido a importância do assunto, conversei longamente com ele sobre suas opiniões e gostaria de compartilhar esta conversa com vocês.

A primeira questão foi exatamente saber como, na opinião dele, estão os trabalhos no GT da ABNT relativos ao OpenXML.

Segundo Jomar, “o GT que cuida da análise do OpenXML já analisou mais de 150 comentários (de 234 postados até o momento), e com base neles já discutiu entre 30 e 40 comentários técnicos que já estão preparados de acordo com os formulários da ISO para a análise da CE e eventual envio à ISO. A diferença entre os números se deve principalmente ao fato de houveram comentários apresentados que tinham conteúdo semelhante e por este motivo foram agrupados (caso típico de erros na especificação dos atributos em uma seção do documento, que afeta a seção toda). Este grupo conta atualmente com aproximadamente 15 técnicos, e grande parte dos comentários foram postados por apenas 4 pessoas.

O ideal seria a possibilidade de que cada um dos participantes do GT pudesse fazer uma análise detalhada das 6.000 páginas, mas em 5 meses isso é impossível. Por este motivo, dividimos o trabalho de análise do documento em algumas partes (entre aqueles dispostos a comentar efetivamente a especificação) e além disso recebemos contribuições de comentários enviadas por técnicos do mundo todo. Desta forma, cada um dos participantes (que postaram comentários) relataram os problemas encontrados por eles próprios e fizeram ainda a análise dos problemas a eles encaminhados dentro de cada parte do documento.

Foi um trabalho extremamente cansativo e que espero seja recompensado pela utilização dos problemas encontrados para o debate e a deliberação do voto brasileiro que, como insiste a ABNT, deve ser uma análise técnica e não política ou comercial”.

Uma segunda questão foi: fala-se muito que ODF e OpenXML tem objetivos diferentes e que o OpenXML foi feito para garantir compatibilidade com o legado. Analisando a documentação do OpenXML em detalhes, como vocês fizerem, esta alegação procede?

Segundo Jomar, “esta informação não possui nenhum embasamento técnico sólido na especificação e por isso acredito que esta alegação não seja tecnicamente válida.

Em outras palavras, a especificação não trata em nenhum momento a conversão dos arquivos binários para o novo formato, se limitando apenas a definir o novo formato baseado em XML, que diga-se de passagem é exatamente a mesma coisa que faz a especificação do ODF. Sem este mapeamento de binário para o novo formato, fica inviabilizada a comprovação técnica de que o ODF não suporta o legado e portanto a necessidade do OpenXML é questionável.

Gostaria apenas de recordar que já aprendemos nos últimos anos que a existência de diversos produtos similares ou equivalentes faz com que o preço final ao consumidor seja reduzido (lei da oferta e da procura). Por outro lado, a existência de dois padrões para uma mesma finalidade acaba por elevar o preço dos produtos ao consumidor final, como por exemplo os dois níveis de tensão elétrica em uso no Brasil e os diversos tipos de tomadas elétricas. Tudo isso funciona com adaptadores, que acabam encarecendo tanto o custo do produto final quanto o custo de utilização do próprio produto (afinal de contas, quem nunca queimou um equipamento elétrico por liga-lo a uma tomada incompatível ? Ou que nunca cortou o pino de terra de uma tomada de computador para poder utiliza-lo em tomadas convencionais ?)”.

Bem, e claro, não podia deixar em branco a reunião da próxima terça feira, quando se decidirá o voto brasileiro. E, claro, perguntei o que ele espera desta reunião.

Jomar foi bem objetivo: “dada a seriedade e competência trabalho realizado pelo GT e investimento feito por todos que contribuiram com ele (custo de deslocamentos e viagens, horas alocadas e "brain power", muito "brain power"), eu realmente espero que os problemas técnicos encontrados sejam analisados com cautela pela CE e que a decisão desta comissão seja feita com base no rigor técnico que é esperado de uma comissão da ABNT.

Se cabe aqui um comentário pessoal, como Técnico em Eletrônica e Engenheiro Eletrônico, eu sempre vi a ABNT como "a referência técnica" no Brasil e sempre admirei muito o trabalho realizado pelas suas comissões. Este foi um dos principais pontos que me motivou a me dedicar da forma pela qual me dediquei á discussão, podendo assim contribuir para o avanço da padronização no setor de TI no Brasil, além de finalmente colocar o Brasil no mapa das decisões internacionais de padronização de software. Sem esta representatividade internacional, é muito difícil para nosso país conquistar e manter uma sólida posição internacional como produtor de software.

Espero honestamente que esta oportunidade não seja disperdiçada por interesses comerciais ou políticos e que sejamos capazes de provar para o mundo todo que os técnicos, empresas e instituições brasileiras possuem a competência, o comprometimento e a seriedade necessária para participar e contribuir de uma discussão técnica internacional de tamanha relevância como esta, colocando os aspectos técnicos á frente de quaisquer outros interesses envolvidos. É a nossa primeira votação importante no JTC1 da ISO e o mundo todo aguarda ansiosamente o posicionamento brasileiro”.

OK, e depois da decisão da ISO, que deve ocorrer dia 2 de setembro? Que ele acha que acontecerá? A resposta foi clara: “depois desta data, espero honestamente que os proponentes do OpenXML mostrem a todo o mundo que compreendem que o mundo mudou, que a era do aprisionamento e do "vendor lock-in" em padrões de armazenamento de documentos já acabou e que tomem a iniciativa se se unir às dezenas de empresas que trabalham na evolução do ODF, para que possam ter suas contribuições recebidas de braços abertos por esta comunidade. A era dos padrões abertos já chegou e cada vez mais a comunidade internacional de TI sabe indentificar com clareza um padrão verdadeiramente aberto. Pelo menos para isso esta discussão internacional sobre o OpenXML foi produtiva”.

Muito bem, e quanto ao ODF... Como está seu processo de aprovação, como Norma Brasileira, pela ABNT?

Segundo ele, “por ser uma norma ISO, já discutida e aprovada internacionalmente o ODF está atualmente sendo traduzido para o Português do Brasil pelo Grupo de Trabalho 1 da Comissão de Estudos (CE) 21:34 da ABNT. Este grupo trabalha sob minha coordenação e nesta semana iremos receber as últimas traduções. Será então realizado um trabalho de revisão da tradução, estimado em 30 dias, para que o documento traduzido possa ser apresentado à CE da ABNT, que após a aprovação da tradução irá encaminhar à ABNT.

Segundo orientação da ABNT, ao receber uma tradução de norma de um grupo de trabalho ela coloca a norma em consulta pública durante um período de 30 dias, permitindo que qualquer interessado faça a revisão da tradução e envie seus comentários (não existe aqui avaliação de mérito técnico da questão, uma vez que ela já é uma norma internacional). Após o período de 30 dias, os comentários recebidos serão analisados pelo Grupo de Trabalho e serão feitas as eventuais complementações ou correções no texto, finalizando assim o Draft que será apresentado em uma reunião com a presença da Comissão de Estudos e de todos aqueles que enviaram os comentários, que irão deliberar sobre sua aprovação.

Após a aprovação, o documento será encaminhado para a ABNT publicá-lo como norma brasileira (NBR) através dos seus processos internos. Nossa espectativa é que este processo todo seja realizado antes do término deste ano.

Segundo a orientação da ABNT, a tradução para português se faz necessária pois de acordo com a legislação vigente, todas as normas técnicas brasileiras devem ser publicadas neste idioma”.

[Read More]

Quarta, 22 de agosto apresentei uma palestra na sessão magna de tecnologia do CONARH 2007, o maior congresso de RH da América Latina e um dos maiores do mundo. Vejam www.conarh.com.br. Foi uma experiência profissional gratificante, falar para cerca de 3.000 pessoas. O tema foi “Existe vida dentro dos chips?”, onde abordei as mudanças que a tecnologia tem causado nas pessoas e na sociedade e como modificam as relações empresa-funcionários. O tema principal foi, como não poderia deixar de ser, a Web 2.0 e suas tecnologias como redes sociais, YouTube e Virtual Worlds, focando mais precisamente o Second Life.

Falando em SL, no início do ano parecia ser a “next big thing” sendo inclusive capa de muitas revistas semanais. Mas, recentemente surgiram vários artigos questionando sua validade. Um dos mais comentados foi “How Madison Avenue is Wasting Millions on a Deserted Second Life”, publicado na Wired de 15 de agosto (http://www.wired.com/techbiz/media/magazine/15-08/ff_sheep). O artigo aponta que muitas iniciativas no Second Life tem sido decepcionantes, atraindo muito pouco público e que 85% dos avatares criados já foram abandonados. Aqui na IBM, o nosso Business Center no SL, criado em maio, atraiu até agora cerca de 10.000 visitantes, um número ínfimo quando comparado com os mais de 250 milhões de visitantes anuais do site tradicional (www.ibm.com). A própria iniciativa da loja virtual da Sears, criada pela IBM para o SL, atrai cerca de 200 a 300 visitantes por dia, um número bem pequeno quando comparado com os acessos aos sites Web.

Isto significa que o SL é um fracasso? Vamos olhar por outro prisma. Estamos na fase de exploração, tentando aprender o que é explorar a Internet 3D e quais as mudanças provocadas pela experiência de uma interação tridimensional e imersiva com a web. Também temos que considerar a possibilidade de exploração dos conceitos de cauda longa, que não significa o fim do conceito dos blockbusters, mas sim o fim do monopólio dos blockbusters. Recomendo ouvir a entrevista de Chris Anderson, autor do livro Long Tail em http://www-128.ibm.com/developerworks/podcast/. Nesta entrevista ele diz claramente que: “one of the biggest misunderstanding of the theory hopefully not by people that read the book it´s the end of the hit, it´s the end of the blockbuster. And it´s nothing of the sort. It´s the end of the monopoly of the hit and of the blockbuster”. Ou seja, além dos modelos tradicionais, de massa, podemos explorar interações pessoais de forma diferente do que podíamos fazer antes. Sabemos fazer? Ainda não...Estamos falando de um salto quântico em conceitos...

O usuário em um mundo virtual controla seu ambiente, expressa sua personalidade e modo de viver, interage com outras pessoas em tempo real, em cenários diferenciados e únicos. É um contexto dinâmico onde as interações e regras são criadas pelos próprios visitantes. Uma experiência em um mundo virtual (seja SL ou algum outro) é diferente da tradicional experiência de navegar pelas estáticas páginas que povoam a Internet 2D.

Imaginem um cenário onde seu avatar vai a um shopping center durante o horário do almoço, interage com colegas do mundo inteiro e caso ele tenha sido criado com as medidas de seu corpo, experimenta roupas e mostra a seus amigos/amigas. Isto tudo sem sair de sua mesa de trabalho... Ou que tal visitar um evento virtual, navegando por corredores e parando em frente a stands de expositores. Ele pode interagir com executivos do expositor, assistir filmes e palestras, além, é claro, de trocar idéias com outros visitantes que estão como ele, visitando o mesmo stand. Quem sabe o CONARH 2008?

Parece futurologia, mas o Gartner Group recentemente afirmou que em 2011, 80% dos usuários da Internet e as grandes corporações terão avatares ou réplicas virtuais de si mesmos, para trabalho ou diversão online.

Estamos engatinhando neste cenário. Na IBM já existem projetos para conectar os diversos mundos virtuais, criando um universo virtual, onde seu avatar poderá navegar do SL para outro software (por exemplo, o World of Warcraft ou o There.com) de forma rápida e transparente, e assim sucessivamente. Que tal começarmos a falar em Web-of-Worlds?Um parêntesis: olhem a importância dos padrões abertos...São absolutamente necessários para que esta interoperabilidade entre os diversos mundos virtuais aconteça! Visitem o site do W3D Consortium (http://www.web3d.org/) para informações adicionais sobre projetos de avatares interoperáveis.

O próprio uso do SL ainda é incipiente. Muitas das iniciativas apenas emulam a Web tradicional, sem maiores explorações do potencial da 3D. Uma recente pesquisa (http://www.fetscherin.com/UserAcceptanceVirtualWorlds.htm) mostra que 90% dos usuários no SL tem menos de uma ano de experiência. É um mundo desconhecido para usuários e empresas que querem usá-lo.

Na minha opinião a Internet 3D não vai eliminar a Web como a conhecemos, mas será plenamente possível nos movimentarmos entre sites da Internet e os mundos virtuais. A Internet é excelente para buscas de textos (evoluindo para a Web semântica e a exploração da Deep Web, como debati em posts anteriores, vejam http://www-03.ibm.com/developerworks/blogs/page/ctaurion?tag=Deepweb) e a Internet 3D criará experiências de imersão onde nossas atividade da vida real poderão ter uma contraparte virtual. A pesquisa que mencionei antes é muito clara quando diz “virtual worlds are not just games, as there no levels, no scores and there is no game over. They exist in real time where individuals communicate, cooperate and collaborate with each other, like in real world”.

Portanto, mundos virtuais não devem ser considerados simples jogos. Não devem ser descartados por que alguns artigos dizem que os acessos são raros, como também não devem ser supervalorizados, como fizeram algumas mídias. O resultado será positivo ou negativo dependendo de quanto de valor adicionado agregará à experiência virtual do visitante. Embora até agora ninguém tenha realmente convertido suas iniciativas no SL ou em outro projeto de mundos virtuais em um canal de vendas efetivo e rentável, nada impede que um dia isto não aconteça.

Estamos no início de uma longa viagem, criando um novo mundo. Não vamos descartá-lo de imediato, nem devemos imaginar que os resultados virão de um dia para o outro.[Read More]