Aprisionamento Tecnológico

hrcerq

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.354 ]

Por: Hugo Cerqueira em 28/06/2017

14 0

Denuncie Favoritos Indicar Impressora

Padrões abertos x Código aberto

É comum a confusão entre os termos "padrão aberto" e "código aberto", entretanto eles não significam a mesma coisa. O padrão aberto é uma especificação a ser seguida. O código aberto é uma das implementações desse padrão. A implementação de um padrão aberto não tem que obrigatoriamente ser de código aberto.

Um exemplo que ilustra melhor essa diferença é a relação entre a linguagem de marcação HTML e os navegadores Web. O HTML é um padrão aberto, mantido pela W3C. Porém os navegadores Web são os responsáveis por ler documentos HTML e apresentar as informações desse documento ao usuário.

Existem inúmeros navegadores Web, alguns são de código aberto, como o Firefox e o Chromium, outros são de código fechado, como o Edge, o Safari e o Chrome. Entretanto, o que todos esses navegadores tem em comum é que eles aderem ao padrão HTML, o que permite que o usuário possa escolher qual navegador utilizar, sem medo de que as páginas Web não sejam apresentadas corretamente.

Outro exemplo é a linguagem SQL, um padrão mantido pela ISO. Existem diversos sistemas gerenciadores de bancos de dados relacionais, como MySQL, PostgreSQL, Oracle e DB2. Os dois primeiros são de código aberto, e os outros dois são de código fechado. Porém em todos eles é possível usar a linguagem SQL para criar e manipular os dados.

Conclusão

O aprisionamento tecnológico é um grave problema que abrange tecnologias dos mais diversos segmentos. No segmento da informação, porém, ele é especialmente crítico, já que a perda de informação pode ser um desastre fatal para a maioria das organizações, e o acúmulo de informações tende a aumentar com o tempo.

Para evitar o aprisionamento tecnológico é prudente adotar tecnologias que trabalhem com padrões abertos. Na indústria do software, o uso de tecnologias que não trabalhem ou não ofereçam suporte adequado a padrões abertos e que privilegiem padrões fechados pode levar ao aprisionamento da informação.

Por isto, os programas de computador que trabalham com padrões abertos devem ser priorizados sempre que possível, o que não significa que eles devam obrigatoriamente ser de código aberto. Afinal, programas de código aberto podem trabalhar com padrões fechados, e programas de código fechado podem trabalhar com padrões abertos.

Referências

Aprisionamento Tecnológico:

Padrões abertos:

Fazendeiros hackeando seus tratores:

Por que fazendeiros americanos estão hackeando seus tratores

Instituições de normatização e padronização:

W3C Brasil:

Decálogo da Web Brasileira

Página anterior

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

Modelos de Negócio para o Software Livre

Acessibilidade na Web

Entenda o XML - Parte 1

psql - Conheça o básico

Entenda o XML - Parte 3

Leitura recomendada

Gravando um CD multiseção

Usando OpenBSD como desktop

O Ser e o Ter no Linux

Embutindo legenda e fazendo autoração de um vídeo para DVD

SliTaz: pequeno, rápido, estável e fácil de utilizar!

Comentários

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

Parabéns pelo artigo. Perfeito.

2 0

[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?

4 0

[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]

1 0

[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

1 0

[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

0 0

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

Obrigado

0 0

[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].

1 0

[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

1 0

[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.

1 0

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

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

0 0

[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.

1 0

[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

0 0