Java foi criado para TV interativa. O projeto fracassou — Java sobreviveu.

Java não nasceu como uma linguagem para a Web. Nasceu dentro de um projeto para dispositivos inteligentes de consumo e televisão interativa — uma direção de negócio que não funcionou.

No início dos anos 1990, James Gosling e uma pequena equipe da Sun Microsystems iniciaram o que viria a ser chamado de Green Project. Eles tentavam imaginar a próxima onda da computação: televisores, set-top boxes, controles portáteis, eletrodomésticos e outros dispositivos programáveis e conectados.

Gosling criou uma linguagem para esse mundo.

Chamou-a de Oak.

A equipe construiu um protótipo impressionante chamado Star-7, um controlador portátil com tela sensível ao toque capaz de operar televisores e outros aparelhos. Tecnicamente, o projeto funcionava bem o suficiente para demonstrar um futuro surpreendentemente moderno.

Comercialmente, não foi a lugar algum.

A primeira ideia de produto falhou, mas a arquitetura sobreviveu

O ponto mais importante de Oak não era o gadget ao redor.

A equipe tinha um problema mais difícil: empresas de eletrônicos usavam processadores e plataformas diferentes. Uma linguagem presa a uma máquina específica seria pouco útil.

Por isso a independência de plataforma entrou no design desde o início.

Em vez de compilar diretamente para um processador, programas Oak podiam mirar uma máquina virtual. O mesmo programa poderia rodar em aparelhos diferentes desde que cada um tivesse uma implementação daquela máquina.

Essa escolha foi feita para um mercado que não acabou sendo o mercado conquistado por Java.

Mas a restrição se mostrou mais valiosa que o produto original.

A Sun tentou transformar o protótipo em negócio

Depois do Green Project, a Sun criou a FirstPerson para buscar usos comerciais.

Televisão interativa parecia promissora. Empresas de cabo imaginavam set-top boxes oferecendo serviços digitais mais ricos dentro de casa.

A equipe explorou essa direção.

Ela não se tornou o negócio esperado.

Um postmortem comum poderia terminar aí: boa tecnologia, mercado errado, encerrar o projeto.

Mas a linguagem ainda tinha propriedades úteis. Era pensada para redes, podia atravessar hardware diferente, lidava com memória de forma mais segura que C ou C++, e servia para software que chegava dinamicamente em vez de ser instalado uma vez em uma máquina.

Então a Web começou a explodir.

A Web parecia o problema que Oak havia sido construído acidentalmente para resolver

As primeiras páginas eram principalmente documentos estáticos. Navegadores se espalhavam rapidamente, mas a experiência era limitada.

A antiga equipe de Oak percebeu que as mesmas características necessárias para software em televisores e eletrodomésticos também serviam para software viajando pela Internet.

Um programa baixado de um servidor poderia rodar dentro de um navegador em diferentes tipos de computador.

Oak passou a se chamar Java.

A Sun reposicionou a tecnologia para a Web. A Netscape aceitou oferecer suporte a Java no navegador. O que começou como infraestrutura para eletrônicos de consumo encontrou um canal de distribuição muito maior.

A direção de produto fracassada havia produzido um núcleo técnico reutilizável.

A lição não é “todo fracasso leva a algo melhor”

Isso seria arrumado demais.

A maioria dos produtos que fracassam apenas fracassa.

A lição útil é separar a hipótese de mercado da capacidade construída enquanto se testava essa hipótese.

A hipótese do Green Project era que aparelhos programáveis e televisão interativa criariam uma grande oportunidade para a Sun.

Essa hipótese não virou negócio.

Mas a capacidade subjacente — código portátil rodando em uma máquina virtual — continuou valiosa quando o ambiente mudou.

A equipe pôde pivotar porque a tecnologia não era idêntica ao modelo de negócio original.

Equipes frequentemente jogam fora a coisa errada

Quando um projeto falha, empresas tendem a cometer um de dois erros.

O primeiro é apego: continuar empurrando o mesmo produto porque muito já foi gasto.

O segundo é rejeição total: matar tudo porque o plano original não funcionou.

A história de Java sugere uma terceira pergunta.

O que construímos que continua útil mesmo se mudarem cliente, canal de distribuição ou categoria de produto?

Pode ser um algoritmo, um pipeline de dados, uma ferramenta interna, um protocolo, um modelo, um workflow ou uma restrição técnica que importa muito mais em outro mercado.

Um produto fracassado ainda pode conter um primitive bem-sucedido.

O melhor pivot preserva a restrição mais valiosa

Java não venceu porque o time apagou tudo que havia aprendido com dispositivos de consumo.

Venceu em parte porque uma das restrições — hardware diferente por toda parte — ficou ainda mais importante na Web.

Mudou o hardware. Mudou o canal. Mudou o cliente.

O problema de portabilidade ficou.

Uma boa forma de avaliar um pivot não é perguntar apenas o que deve ser abandonado.

É perguntar qual problema foi resolvido profundamente o bastante para que outro mercado já esteja precisando da solução.

A primeira casa de Java nunca virou seu lar verdadeiro.

Mas a engenharia criada para essa primeira casa sobreviveu tempo suficiente para encontrar a Web.

Se o seu produto atual fracassasse amanhã, qual parte da tecnologia ainda valeria a pena manter?

Fontes

• Computer History Museum — James Gosling e o Green Project
• Computer History Museum — Oral History of James Gosling, Part 1
• Computer History Museum — FY2019 Annual Report, história do Java e televisão interativa
• Oracle — Java Virtual Machine Specification, Preface to the First Edition
• Computer History Museum — protótipo Star-7
• Imagem destacada — James Gosling em encontro da SVLUG, foto de Eugene Zelenko, CC BY-SA 4.0 via Wikimedia Commons. Adaptada para uma tela 16:9; a obra derivada permanece sob CC BY-SA 4.0.