O Ambiente de Trabalho Linux Empresarial Segue um Roteiro Que a Sua Empresa Não Pode Vetar
As empresas escolhem Linux para ganhar controlo. Mas a interface que cada colaborador usa todos os dias segue uma visão de design definida a montante, sem direito de veto para o cliente, e a direção atual aponta cada vez mais para um tablet.
Pergunte a um diretor de sistemas de informação porque razão a frota corre Linux e, num minuto, ouve a palavra «controlo». Sem redesenhos impostos. Uma interface que a organização pode moldar às suas necessidades. Eis a parte incómoda: no ambiente de trabalho Linux empresarial moderno, a camada que cada colaborador toca o dia inteiro é precisamente aquela sobre a qual a organização tem menos controlo. A interface é definida por um projeto de design a montante, segundo um calendário a montante, e nenhum contrato de aquisição do mundo lhe dá direito de veto sobre ela.
Isso seria uma abstração tolerável se a direção a montante fosse pouco interessante. Não é. O GNOME, o ambiente de trabalho que a maioria das distribuições Linux comerciais entrega por definição, tem vindo a construir há anos uma simplicidade opinativa e orientada ao toque, e di-lo publicamente. Os programadores do GNOME Shell descreveram um projeto financiado para levar o GNOME Shell a telemóveis, apoiado no trabalho de gestos e navegação tátil já disponível para os utilizadores de computador. Coloque essa direção lado a lado com o iPadOS e a semelhança de família não é subtil. A vertente da personalização visual é igualmente pública: dezenas de programadores de aplicações GNOME assinaram uma carta aberta a pedir às distribuições que deixem de aplicar temas de terceiros às suas aplicações, argumentando que alterar o aspeto de uma aplicação sem envolvimento do respetivo programador a danifica. Em ambos os casos corre o mesmo instinto: temas, personalização profunda e os controlos ao nível de administração que davam aos ambientes de trabalho Linux uma sensação de posse são tratados como problemas a eliminar por design, não como funcionalidades a preservar.
Releia isto com calma. A capacidade de configuração que justificava escolher código aberto ao nível da interface é exatamente aquilo que o próprio roteiro da interface está a eliminar por engenharia.
Quem controla realmente o ambiente de trabalho Linux empresarial?
Siga o mecanismo. Um fornecedor de distribuição empacota um ambiente de trabalho. O ambiente de trabalho segue a sua própria liderança de design. Essa liderança responde perante os objetivos do projeto e a sua própria ideia de utilizador ideal, não perante o seu plano de implementação. As distribuições comerciais podem fixar versões e manter correções, o que atrasa o futuro um ou dois ciclos de suporte. Raramente o redirecionam. Quando uma visão de design chega à imagem-padrão da sua empresa, todas as decisões que importam já foram tomadas várias camadas a montante, por pessoas que nunca ouviram falar da sua organização e que não têm qualquer obrigação de o fazer.
Os incentivos explicam a direção. Os designers a montante são recompensados pela coerência: uma única experiência que conseguem manter e defender. Cada tema, ponto de extensão e opção de preferência é superfície que têm de suportar e uma variável para a qual não conseguem desenhar. Vista de dentro dessa estrutura de incentivos, eliminar a personalização parece higiene. Mas a década de hábitos consolidados da sua frota não é a sua base de utilizadores, e nenhuma boa vontade muda de quem passa a ser o problema quando o fosso se abre.
As extensões parecem a válvula de escape e, para um entusiasta isolado, são-no de facto. À escala de uma frota são dívida de manutenção: tudo o que é acoplado fora da visão de design vive à mercê dessa visão, e cada nova versão a montante tem o direito de o quebrar. Construir a imagem padrão do seu ambiente de trabalho sobre essa base é construir sobre a tolerância de outra pessoa.
Copiar a interface de um rival é mais seguro do que parece
Se o destino se parece com o de Cupertino, poderia a Apple opor-se? A história sugere que não. A Apple passou o início da década de 1990 a tentar apropriar-se judicialmente do «look and feel» e acabou por estabelecer precisamente o contrário. Em Apple Computer, Inc. v. Microsoft Corp., um processo de direitos de autor decidido pelo Tribunal de Recurso do Nono Circuito em 1994, a alegação da Apple de que o Windows infringia o aspeto e o comportamento da interface do Mac falhou quase por completo: o tribunal considerou que os elementos de interface em disputa estavam cobertos por uma licença anterior ou, simplesmente, não eram protegíveis por direitos de autor. Décadas depois, esse desfecho mantém-se válido. Um paradigma de interface pode ser imitado na íntegra e a exposição é reputacional, não jurídica.
Isto importa aqui por uma razão estrutural fria. Se a imitação implicasse responsabilidade legal, a convergência para a linguagem de design de uma única empresa teria um travão. Não tem. As únicas forças que impedem um projeto de ambiente de trabalho de se tornar uma cópia devota são o bom gosto e a pressão da comunidade, e a pressão da comunidade tem um histórico fraco contra uma equipa de design determinada e com acesso de submissão ao código.
Quanto custa um redesenho quando a empresa não pode dizer que não
Agora, calcule o custo. Trata-se de categorias orçamentais e não de valores observados, porque cada frota é diferente, mas as categorias em si são teimosamente previsíveis: reciclagem de formação em todos os postos quando o paradigma muda; revalidação de cada fluxo de acessibilidade afinado às funcionalidades atuais; documentação, capturas de ecrã, materiais de integração e guiões de suporte, tudo silenciosamente invalidado; e, por baixo disto tudo, o imposto de produtividade não medido de milhares de pessoas a reaprender onde as coisas estão. As empresas reconhecem este perfil de custo, porque é exatamente o aspeto de um redesenho imposto por um fornecedor proprietário. A diferença pela qual pagou, afinal, era o controlo do código-fonte, não o controlo do roteiro.
Sim, pode sempre bifurcar o projeto (fazer um fork). Diga essa frase a quem já manteve um fork de um ambiente de trabalho e repare na expressão da cara. A prova está à vista: quando o GNOME 3 abandonou o modelo de ambiente de trabalho do GNOME 2 em 2011, a reação produziu o MATE, a continuação do GNOME 2, e o Cinnamon, que a Linux Mint montou a partir de componentes do GNOME. Ambos só sobrevivem porque os respetivos responsáveis mantêm equipa permanente e um encargo de segurança que se acumula à medida que o projeto a montante se afasta, há mais de uma década. O direito a bifurcar é real. Como mecanismo de controlo para uma empresa que implementa o sistema, é tão prático quanto o direito de construir a sua própria autoestrada.
Como gerir uma dependência a montante que a empresa não pode vetar?
Comece por lhe chamar aquilo que é. A camada de interface da sua frota é uma dependência de cadeia de fornecimento com vontade própria, e pertence ao mesmo registo de risco que qualquer plataforma proprietária que examinaria antes de se comprometer. É praticamente isto que queremos dizer quando defendemos que a estratégia técnica é a disciplina de calcular o custo das dependências que a empresa não controla, e o mesmo raciocínio aplica-se a qualquer decisão de plataforma cujo roteiro está fora dos seus muros.
Depois, escolha a sua postura de forma deliberada. Fixar versões de suporte alargado compra anos, não resultados: o redesenho acaba sempre por chegar, com juros. Financiar e contribuir a montante compra influência, que vale a pena ter mas continua a não ser controlo. Migrar para um ambiente de trabalho cuja governação se ajuste melhor às necessidades da empresa é uma opção real, com custos de mudança reais. E, se a empresa ficar onde está, deve orçamentar já a gestão da mudança, no momento da renovação, enquanto ainda é uma rubrica orçamental e não uma emergência.
Nenhuma destas opções devolve o direito de veto, porque esse veto nunca existiu. O código aberto dá-lhe o código-fonte. Nunca prometeu dar-lhe o volante.
Perguntas frequentes
O GNOME está mesmo a eliminar a personalização e os temas?
A direção sinalizada no seu trabalho de design de longo prazo favorece predefinições opinativas em detrimento da personalização profunda e dos temas de terceiros, e vários dos seus próprios programadores de aplicações já pediram publicamente às distribuições que deixem de aplicar temas de terceiros. Trate isto como risco de roteiro, não como facto já concretizado: verifique o comportamento da versão atual antes de tomar decisões sobre a frota, mas planeie partindo do princípio de que a capacidade de personalização vai encolher, não crescer.
Pode uma empresa impedir um redesenho do ambiente de trabalho que não deseja?
Não. Pode atrasá-lo fixando versões de distribuição de suporte alargado, influenciá-lo financiando ou contribuindo a montante, ou evitá-lo migrando para um ambiente de trabalho com outra governação. O que não pode é vetá-lo, pelo que a medida realista é orçamentar a formação e a gestão da mudança antes de o redesenho chegar.
É legal que uma interface de ambiente de trabalho imite o iPadOS?
Em termos gerais, sim. Em Apple Computer, Inc. v. Microsoft Corp. (1994), uma decisão de direitos de autor sobre o «look and feel», o Tribunal do Nono Circuito considerou os conceitos gerais de interface praticamente impossíveis de proteger, pelo que a exposição para quem imita é reputacional e não jurídica. Para as empresas que implementam estes sistemas, a consequência prática é que nada de estrutural impede a convergência das interfaces.
Relacionado
- Epic vs. Google: a cláusula do catálogo que entrega o fosso competitivo aos rivais
- Os preços da memória inverteram. Renegoceie o contrato de fornecimento antes da próxima renovação.
- Como a IA Deixa Chefes Ruins Ainda Piores: a Máquina de Bajulação na Sala da Diretoria
- Digital Business
Escrito por uma persona editorial de IA do sistema editorial proprietário da Abyshire e revisto pela nossa equipa.