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

Por: Hugo Cerqueira em 28/06/2017


Como evitar o aprisionamento tecnológico



A melhor maneira de evitar os problemas decorrentes do aprisionamento tecnológico é buscar tecnologias e serviços que prezem pela interoperabilidade e pela portabilidade. Em grande parte, o que torna isso possível são os padrões abertos e a descentralização.

Em geral, os produtos de software seguem alguma especificação, que determina como eles estruturam as informações com que trabalham e como disponibilizam essas informações para manipulação e visualização.

Uma especificação passa a ser considerada um padrão, quando há um acordo entre várias partes sobre como deve ser essa especificação. Isso significa que a especificação em questão deve passar por um processo de adoção em massa. Esse processo pode acontecer por vários motivos: por obrigação legal, por ser a especificação de um produto que é dominante em seu segmento ou talvez até mesmo por acaso.

Porém, seja como for, se este padrão é definido por uma única pessoa ou por uma única empresa, isto pode representar um risco para os consumidores de produtos que trabalhem com este padrão. Uma empresa pode definir este padrão de maneira que seja favorável às suas implementações e desfavorável às implementações alheias. Esta prática desfavorece a competição honesta e facilita a criação de monopólios.

Entretanto, padrões podem ser criados por instituições isentas, com foco na indústria como um todo, e não em fornecedores específicos. Um exemplo de instituição deste tipo é a International Organization for Standardization (ISO), uma instituição internacional, sem fins lucrativos, cujo propósito é definir padrões para diversos segmentos, dentre eles a indústria do software.

Esta instituição abrange diversas outras, específicas de cada segmento e/ou cada país. Um exemplo destas é a Associação Brasileira de Normas Técnicas, que é uma instituição membro da ISO, que atua no âmbito brasileiro.

Outro tipo de organização que define padrões são consórcios de empresas e indivíduos, que por meio do consenso constroem os seus padrões. Um exemplo destas organizações é a World Wide Web Consortium (W3C), responsável pela definição de padrões para a Web, como HTML, CSS e XML.

A Web só se tornou viável porque os padrões definidos pela W3C são padrões abertos. Não há impedimentos técnicos ou legais para a criação de páginas Web ou navegadores Web, no que diz respeito à utilização destes padrões. A W3C tem forte atuação no Brasil e trabalha na definição de padrões para a infraestrutura brasileira.

A W3C Brasil criou o decálogo da Web brasileira, que determina algumas diretrizes para nortear a nossa infraestrutura. Dentre elas, está a organização em padrões, que devem ser abertos e interoperáveis. Esta diretriz é a base para várias outras.

Outro exemplo de organização que é um consórcio e define padrões com base no consenso é a Organization for the Advancement of Structured Information Standards - OASIS. Dentre vários outros padrões, esta organização é responsável também pelo OpenDocument Format (ODF), usado para documentos de texto (odt), planilhas (ods), apresentações (odp) e diagramas (odg).

Página anterior     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

psql - Conheça o básico

Entenda o XML - Parte 1

Modelos de Negócio para o Software Livre

Leitura recomendada

Escreva para o VOL - Contribua você também!

Configuração básica do Conky para mostrar informações sobre a sua máquina no Desktop

Como fazer o seu servidor Linux enviar avisos em seu celular Claro sem custo

Distribuições GNU/Linux que você talvez nunca queira experimentar!

Backup remoto usando SSH

  
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