Aprisionamento Tecnológico

Aprisionamento tecnológico (ou lock-in, em inglês) é uma prática comercial de caráter questionável, que torna clientes dependentes e reféns de seus fornecedores. Este artigo explica como isso pode acontecer e apresenta algumas medidas que ajudam a evitar este problema.

[ Hits: 8.026 ]

Por: Hugo Cerqueira em 28/06/2017


Introdução



Com frequência, me deparei com tópicos aqui no Viva o Linux que de alguma maneira se relacionam com o tema do aprisionamento tecnológico, também conhecido como lock-in, em inglês. Interpretei isso como um sinal de que estava na hora de escrever um artigo sobre esse assunto, que apresento agora.

No fim do artigo, como sempre faço, coloquei algumas referências relacionadas ao assunto e que serviram de base para este artigo. Recomendo fortemente que sejam lidas.

O que é o aprisionamento tecnológico

O aprisionamento tecnológico é uma estratégia comercial moralmente questionável. Consiste na criação de uma dependência do consumidor em relação ao fornecedor. Essa dependência costuma vir acompanhada de altos custos, relacionados geralmente a reparos, atualizações e melhorias. Em resumo, é uma relação parasitária.

Um exemplo disto é o que está acontecendo em muitas fazendas nos Estados Unidos. Grande parte dos tratores, quando apresentam defeitos, só podem ser reparados pelo próprio fabricante. Os custos de reparo e troca das peças costumam ser altos, e existem barreiras técnicas que impedem que os fazendeiros levem seus tratores a mecânicos independentes. O resultado é um número crescente de fazendeiros hackeando seus tratores para não ficarem reféns dos fabricantes. O problema é que para fazer isso, eles estão recorrendo a programas de origem duvidosa, que são vendidos em um mercado paralelo.

Muitas vezes a escolha de um fornecedor de determinado produto ou serviço pode parecer atrativa, à primeira vista. Entretanto, à medida que se usa esse produto ou serviço, vai se criando uma dependência em relação ao fornecedor, até que se chega em um ponto em que os custos de migração para outra tecnologia ou outro fornecedor tornam-se altos demais. Quando isso acontece, o fornecedor ganha um grande poder de barganha em relação ao consumidor, pois poderá impor condições abusivas ao consumidor sem que este abandone o serviço.

Uma das consequências mais graves do aprisionamento tecnológico é a formação de monopólios. Uma vez que um fornecedor de determinada tecnologia domina o segmento em que atua usando desta prática, fica muito difícil para outros fornecedores conquistarem a sua fatia de mercado. Em outras palavras, a prática do aprisionamento tecnológico cria barreiras para a competição e portanto não é apenas ruim para os consumidores, mas também para possíveis concorrentes.

Aprisionamento da informação

O aprisionamento tecnológico é especialmente crítico quando se lida com informações. A maneira que se escolhe para armazenar informações deve ser feita com muito cuidado, pois à medida que o tempo passa, a quantidade de informações armazenadas tende a aumentar. Isso significa que os custos de uma possível migração no futuro também vão aumentar.

A perda de informações pode significar a ruína de todo um negócio, ou ao menos um grande prejuízo. Muitos fornecedores de produtos ou serviços relacionados à tecnologia da informação se aproveitam disso. Quando a informação é armazenada de forma que seja acessível somente por um produto específico, o dono desta informação fica refém do fornecedor deste produto para continuar tendo acesso às próprias informações.

Porém o que acontece se ele precisar mudar de fornecedor? Inúmeros motivos podem ser elencados para justificar uma migração. Alguns possíveis exemplos são:
  • O fabricante / provedor do serviço pode vir à falência;
  • O custo do serviço / licença pode se tornar inviável;
  • Uma tecnologia mais aderente às suas necessidades pode surgir;
  • O provedor do serviço pode definir novas políticas / termos de uso, com os quais o cliente talvez não concorde;
  • O serviço ou produto pode depender de tecnologias que não são mais viáveis dentro da sua infraestrutura.

Então é importante ter sempre um plano B, isto é, estar preparado para migrações no futuro. Bons gestores sabem quanto tempo, esforço e dinheiro isso pode poupar. E essa regra vale para tecnologias domésticas ou pessoais também, não apenas dentro de empresas. Acontece que certos serviços e tecnologias acabam criando uma bolha da qual é difícil se desvencilhar, o que inviabiliza uma possível migração. Essa estratégia é vantajosa apenas para o provedor do serviço, mas pode se tornar um grande problema para o cliente.

    Próxima página

Páginas do artigo
   1. Introdução
   2. Como evitar o aprisionamento tecnológico
   3. Padrões abertos x Código aberto
Outros artigos deste autor

Entenda o XML - Parte 3

Acessibilidade na Web

Modelos de Negócio para o Software Livre

psql - Conheça o básico

Entenda o XML - Parte 1

Leitura recomendada

Cursos online grátis sobre Software Livre!

Emulando Cisco com Dynamips e Dynagen no Ubuntu

Netstat a fundo (parte 1)

Aulas particulares: Ganhando dinheiro com Linux

Interface Gráfica e Ambiente Integrado p/ Free Pascal

  
Comentários
[1] Comentário enviado por homemsemnome em 28/06/2017 - 17:12h

Parabéns pelo artigo. Perfeito.

[2] Comentário enviado por removido em 28/06/2017 - 17:53h

1. Monopólio e padrões fechados: alguém lembrou de algum exemplo? :-) nem precisa falar ...

2. Padrões fechados e conhecimento retido remetem a propriedade privada ...

3. Um novo paradigma: se a Red Hat quiser mesmo controlar a parada toda através do SystemD, como é que será que se encaixaria esse conceito de domínio tecnológico, isto é, considerando-se realmente verdadeira a hipótese?

[3] Comentário enviado por Freud_Tux em 28/06/2017 - 19:37h

Gostei do texto bem legal.

A grosso modo e de maneira bem resumida, lembra e velha "venda casada".
Um jeito de escapar desse tipo de coisa (no próprio texto diz) é escolher bem na hora da aquisição.
Mas como tudo na vida basicamente é na base do planejamento, tem umas ferramentas que podem ajudar.


-------------------------------------------------------------------------------------------------------------------------------------------------
[b]Noob:[/b] [i]"[...]Sou muito noob ainda usando o terminal, então preciso de ajuda "mastigada", pra operá-lo."[/i]
[b]zhushazang[/b]: [i]"Sou velho e meus dentes desgastados. Estude linux www.guiafoca.org";[/i]

[4] Comentário enviado por removido em 29/06/2017 - 12:15h

Muito interessante o artigo.

A fabricante de tratores citada é a John Deere, correto?
-----------------------------------------------
cd /var/abs/brain/knowledge ; makepkg -si

[5] Comentário enviado por hrcerq em 29/06/2017 - 13:58h


[4] Comentário enviado por erisrjr em 29/06/2017 - 12:15h

A fabricante de tratores citada é a John Deere, correto?


Sim, essa mesmo. Nas referências coloquei o artigo da Motherboard que fala sobre esse caso dos tratores.

---

Atenciosamente,
Hugo Cerqueira

[6] Comentário enviado por RLFontan em 30/06/2017 - 00:29h

Obrigado

[7] Comentário enviado por albfneto em 07/07/2017 - 13:27h

Na realidade, esse aprisionamento ocorre em Indústrias, Escritórios etc...
NO Brasil, ocorre muito, e ocorre com Química, com Eletrônica etc... não é só com TI....
veja na TI por exemplo..... O Systemd obrigatório e o UEFI e Boot Segura, são d ecerta forma, aprisionamentos Tecnológicos, também, pq é usar "Isso ou Isso, é o que tem, tá bom tá, não tá bom, tivesse"!

No tempo antigo, Windows foi Aprisionamento tecnológico.... Windows matou o IBM OS2 Warp, o melhor SO que havia nos 80-90
e olha que era da MS mesmo, junto com IBM, depois só da IBM.

MsOffice antigo, matou o Word Perfect, o melhor editor de textos....
¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨¨
Albfneto,
Ribeirão Preto, S.P., Brasil.
Usuário Linux, Linux Counter: #479903.
Distros Favoritas: [i] Sabayon, Gentoo, OpenSUSE, Mageia e OpenMandriva[/i].

[8] Comentário enviado por hrcerq em 07/07/2017 - 15:20h

Concordo com você. Aprisionamento tecnológico não é algo exclusivo à tecnologia da informação. Coloquei o exemplo dos tratores no início do artigo justamente para ilustrar esse fato. Mas foquei na questão da informação por dois motivos:

1. No Viva o Linux tratamos basicamente sobre sistemas de informação, então faz mais sentido focar nesse tema por aqui
2. Perda de informação costuma ser um problema mais crítico, como expliquei no artigo

Quanto à questão do systemd que você coloca, eu acredito sim que há problemas envolvidos, mas não creio que possa ser caracterizado como aprisionamento, pois sua inclusão não é obrigatória nas distros, isto é, quem monta uma distro não é obrigado a optar pelo systemd, e o usuário final pode escolher distros que não o usam (Devuan, por exemplo). A meu ver, o que falta no systemd, é uma documentação mais clara de como interpretar os logs, que são binários, para que existam outras opções para abrir esses logs, além do journalctl. Ou, melhor ainda, fazer com que esses logs estejam disponíveis em formato textual.

Que há uma predominância muito grande do systemd, isso concordo que há. Porém devemos lembrar que o mesmo pode se dizer do interpretador Bash, e nunca vi ninguém reclamando sobre isso. Também o Xorg foi hegemônico por muito tempo e isso nunca foi visto como uma ameaça aos sistemas Linux.

Resumindo, a predominância de um produto ou software não se configura como aprisionamento tecnológico. Ao menos não necessariamente. O que caracteriza o aprisionamento é dificuldade imposta por determinada tecnologia para que se migre para outra tecnologia.

O risco de perda da informação, ou alto custo de conversão de um formato para outro seria um exemplo disso. Entretanto, uma tecnologia que está predominante mas que poderia ser facilmente substituída por outra não representa esse tipo de problema.

---

Atenciosamente,
Hugo Cerqueira

[9] Comentário enviado por nicolo em 23/07/2017 - 18:32h

O artigo é ótimo, parabéns. Coloco uma observação sobre a ISO, que aparenta ser algo neutro. Não é bem assim. Muitas normas ISO contém forte orientação ideológica vigente no primeiro mundo. É patente por exemplo a guinada da norma ISO 9001 de 1998 para 2008 e adiante, neste caso foi uma purificação. Mais além, a ISO passou a confeccionar normas para a industria naval e offshore. As normas navais são baseadas em normas de organismos privados que tem 200 -duzentos- anos de existência e conquistaram renome e respeito. A ISO emitiu normas navais que são apenas cópias feitas por amadores e deturpadas por forte conteúdo ideológico favorável à ideologia da globalização, algo que interessa aos países ricos em prejuízo dos países pobres. Normalmente há preciosismos absurdos que obrigam à compra de tecnologia do primeiríssimo mundo. Há coisas que nem os U.S.A. adota.

[10] Comentário enviado por hrcerq em 30/07/2017 - 22:35h


[9] Comentário enviado por nicolo em 23/07/2017 - 18:32h

O artigo é ótimo, parabéns. Coloco uma observação sobre a ISO, que aparenta ser algo neutro. Não é bem assim. Muitas normas ISO contém forte orientação ideológica vigente no primeiro mundo. É patente por exemplo a guinada da norma ISO 9001 de 1998 para 2008 e adiante, neste caso foi uma purificação. Mais além, a ISO passou a confeccionar normas para a industria naval e offshore. As normas navais são baseadas em normas de organismos privados que tem 200 -duzentos- anos de existência e conquistaram renome e respeito. A ISO emitiu normas navais que são apenas cópias feitas por amadores e deturpadas por forte conteúdo ideológico favorável à ideologia da globalização, algo que interessa aos países ricos em prejuízo dos países pobres. Normalmente há preciosismos absurdos que obrigam à compra de tecnologia do primeiríssimo mundo. Há coisas que nem os U.S.A. adota.


Agradeço pelos seus comentários. Confesso que não conhecia esse problema da ISO em relação à indústria naval. Na tecnologia da informação esse tipo de coisa é um pouco mais difícil de acontecer, pois o que a ISO endossa são padrões e não implementações desses padrões. Mas acho que a manufatura no geral ainda oferece brechas para esse problema, infelizmente, já que se tratam de "implementações" físicas que requerem técnicas e materiais específicos.

De toda forma, isso não justifica que se prefira algo não padronizado. A solução mais adequada neste caso seria rever o padrão para que ele seja vantajoso para a indústria local, possivelmente tomando como base esses organismos privados que você citou. Organizações de padronização locais, como a ABNT deveriam intervir em favor dos interesses nacionais para casos como este. Organismos privados são excelentes para conceber técnicas e soluções, mas inadequados para manter padrões, pois nunca serão imparciais, mesmo que queiram.

---

Atenciosamente,
Hugo Cerqueira

[11] Comentário enviado por CapitainKurn em 24/08/2017 - 02:50h

Na área de TI/TA não há nada mais hediondo qur o mercado de automação industrial. Trabalhei em em uma empresa onde migrei CLPs Rockwell Compactlogix rodando Windows CE por Raspberries rodando Slackware ARM e Raspbian, Arduínos e ESP8266. Um sucesso.

[12] Comentário enviado por hrcerq em 07/09/2018 - 20:01h


[8] Comentário enviado por hrcerq em 07/07/2017 - 15:20h

[...]

Quanto à questão do systemd que você coloca, eu acredito sim que há problemas envolvidos, mas não creio que possa ser caracterizado como aprisionamento, pois sua inclusão não é obrigatória nas distros, isto é, quem monta uma distro não é obrigado a optar pelo systemd, e o usuário final pode escolher distros que não o usam (Devuan, por exemplo). A meu ver, o que falta no systemd, é uma documentação mais clara de como interpretar os logs, que são binários, para que existam outras opções para abrir esses logs, além do journalctl. Ou, melhor ainda, fazer com que esses logs estejam disponíveis em formato textual.

Que há uma predominância muito grande do systemd, isso concordo que há. Porém devemos lembrar que o mesmo pode se dizer do interpretador Bash, e nunca vi ninguém reclamando sobre isso. Também o Xorg foi hegemônico por muito tempo e isso nunca foi visto como uma ameaça aos sistemas Linux.

Resumindo, a predominância de um produto ou software não se configura como aprisionamento tecnológico. Ao menos não necessariamente. O que caracteriza o aprisionamento é dificuldade imposta por determinada tecnologia para que se migre para outra tecnologia.

O risco de perda da informação, ou alto custo de conversão de um formato para outro seria um exemplo disso. Entretanto, uma tecnologia que está predominante mas que poderia ser facilmente substituída por outra não representa esse tipo de problema.

---

Atenciosamente,
Hugo Cerqueira


Após pesquisa mais aprofundada sobre o systemd, sou obrigado a me contradizer. Hoje penso que o Systemd é mesmo uma causa perdida em termos de se tornar um sistema de inicialização decente. Ele não apenas tem o problema de escrever logs em formato binário, como também dificulta a depuração de problemas na inicialização (que estarão dentro do próprio código-fonte do systemd e não em scripts shell), absorveu funcionalidades que não a da inicialização (como o próprio udev), contrariamente aos princípios de interoperabilidade propostas na filosofia UNIX, e percebe-se que seus desenvolvedores não estão satisfeitos com sua presença hegemônica, como também indicam querer eliminar as demais opções.

A presença hegemônica de um produto não se configura como aprisionamento tecnológico, conforme eu disse anteriormente, porém uma vez que uma distro adota o systemd e começa a depender cada vez mais dele, fica difícil voltar atrás.

A percepção da complexidade criada pelo systemd, da sua falta de interoperabilidade e até mesmo da falta de respeito com outros projetos com sua postura de querer que estes se adaptem às necessidades do systemd me fez abandonar de vez o Fedora (que a propósito foi onde essa aberração foi concebida), em favor do Devuan, que tem se mostrado mais estável que o próprio Debian. Devo dizer que o processo de inicialização ficou muito mais rápido, apesar do difundido mito de que o systemd é mais rápido por paralelizar o processo de inicialização.

Mais informações sobre o tema podem ser vistos aqui: http://without-systemd.org/wiki/index.php/Main_Page


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts