Criadora do Protocolo Spanning-Tre (STP), o algoritmo que em 1985 deu origem à Internet conectando os pacotes de dados das primeiras redes, a americana Radia Perlman não se considera a mãe da Internet, como muitos a chamam.
Muito pelo contrário, trinta e quatro anos depois de uma invenção que ainda hoje não foi substituída para navegar pela Internet, Perlman prefere falar da criação de “uma pequena peça que acrescentou ao resto” para conectar muitas redes. “Eu estava no lugar certo, na hora certa”, simplificou Perlman.
Em uma conversa com LACNIC News, ela se opôs ao estabelecimento de cotas de participação feminina para reduzir a lacuna de gênero no mundo digital e considerou um erro realizar conferências ou atividades exclusivamente para mulheres. “Se melhorarmos o ambiente para todos, também será melhor para as mulheres”, enfatizou.
Sabemos que em muitos lugares você é conhecida como a mãe da Internet. Você sabe por quê?
Aconteceu que eu estive no lugar certo, na hora certa, desde o alvorecer da criação das redes. E consegui inventar grande parte dos níveis mais baixos da Internet. Alguém que me entrevistou para uma revista decidiu chamar-me assim porque há todo tipo de homens que dizem “eu inventei a Internet”, mas ninguém diz que foi uma mulher quem fez isso. Na verdade, eu não teria escolhido, porque a Internet não foi inventada por uma única pessoa, mas é composta de muitas partes diferentes. Além disso, se eu não tivesse inventado o que eu inventei, alguém teria feito isso. Como fui eu quem fiz, gosto de pensar que o resultado é mais simples e limpo, mais fácil de usar e mais robusto do que se outra pessoa tivesse feito. Mas é possível fazer que quase qualquer coisa funcione. É uma honra que me chamem assim, mas eu nunca usaria esse apelido.
Como surgiu a ideia de criar um protocolo que permita às redes de computadores se comunicarem entre si? (STP- Spanning Tree protocol)
Bem, isso em particular foi uma parte muito pequena da minha carreira. A única razão pela qual o precisávamos era porque as pessoas achavam que a Ethernet era igual a qualquer rede, quando na verdade era apenas um link. Como pensavam que se tratava de uma rede, eles deixavam de lado a parte do software de rede e o host que colocaria os dados “dentro de um envelope” para poder enviá-los pela rede —pensavam que apenas os nós que estavam na mesma Ethernet gostariam de falar entre si—. Assim como foi originalmente inventada, a Ethernet só podia ter umas poucas centenas de nós e esses nós tinham que estar em uma distância muito pequena, portanto era simplesmente uma maneira de conectar máquinas dentro de um mesmo prédio. Eu lhes disse que não fizessem isso, que deviam incluir a parte extra de software no aplicativo que estavam criando para poder interagir com um roteador —isso significa colocar o outro “envelope” que o roteador compreende para que possa transportá-lo entre links diferentes—. Mas eles me ignoraram, como era habitual naquela época da minha carreira. De modo que criaram uns aplicativos que eram muito bons, mas que teriam sido igualmente bons se o tivessem feito corretamente, quer dizer, colocando os dados dentro de outro envelope. Anos mais tarde, meu gerente levantou o problema de descobrir como mover os pacotes, mesmo que sua origem e destino não soubessem nada sobre o cabeçalho adicional necessário para transportar pacotes através de uma rede. Portanto, na realidade, eles já tinham o conceito básico de como mover os pacotes, ou seja, que cada porto escuta cada pacote e o salva, e depois, quando a tecnologia de enlace o permite, esse pacote é enviado para outro porto. Isso está muito bom, mas deve haver alguma forma de os pacotes retornarem ao seu lugar de origem ou o processo nunca irá parar. Em um protocolo que é projetado para ser levado de link a link, há um campo adicional chamado hop count que muda com cada reenvio, pelo que acabará percebendo que foi reenviado muitas vezes – que deve tratar-se de um loop – e pode descartar o pacote. Mas a Ethernet não tinha capacidade para fazê-lo, já que esse campo não existia nesse cabeçalho, não porque as pessoas que inventaram a Ethernet não o soubessem, mas porque a intenção da Ethernet não era transportar de um link para outro. Esse é o motivo pelo qual não tinha esse campo. Foi assim que meu gerente me pediu para inventar algo que não requeira trocar os nós finais. No entanto, no cabeçalho da Ethernet não havia campos sem usar e, além disso, havia um limite de tamanho inamovível. O engraçado desta história é que essa ordem me foi dada na sexta-feira e depois ele desapareceu por uma semana. Isso foi antes de lermos o e-mail em forma permanente, quando não tínhamos celulares, de modo que não pude me comunicar com ele durante suas férias. Além disso, me fez outra sugestão absurda: ele queria que a quantidade de memória para executar o algoritmo não crescesse à medida que a rede crescesse, e não havia nada que se comportasse dessa maneira. Acontece que naquela noite percebi que não apenas sabia como fazê-lo, mas que podia demonstrar que funcionava e, além disso, a quantidade de memória não aumentava com o tamanho da rede, algo que eu nunca tinha visto antes. Com enorme entusiasmo, escrevi a especificação entre segunda e terça-feira. Era um protocolo tão simples e a especificação era tão completa que os implementadores conseguiram que funcionasse muito rapidamente sem me fazer uma única pergunta. Tudo esteve pronto para a quarta-feira, mas eu não podia me concentrar em mais nada, porque tinha que alardear perante meu chefe, que não estava disponível. Foi assim que passei o resto da semana escrevendo o poema, que é um resumo do trabalho onde publiquei o algoritmo.
Eu ainda achava que estava fazendo algo errado, queria que consertassem os computadores conectados à Ethernet, que tivessem o software adicional para poder colocar o envelope e passar pelos roteadores projetados para essa tarefa. Mas com isso ganhariam alguns meses para fazê-lo.
Por que você acha que 33 anos depois esse protocolo ainda é usado?
Há muitas formas de responder a essa pergunta. Além de ser boa em matemática, ciência e lógica, eu não encaixava no estereótipo de um engenheiro. Este estereótipo é realmente muito ruim para a indústria, de muitas formas diferentes. A equipe ideal é composta por pessoas com diferentes habilidades. As mulheres acreditam que não serão boas engenheiras porque imaginam que um engenheiro é alguém que, do nada, se joga na água e começa a criar e construir coisas, e elas não se veem assim. Ou acham que não vão gostar porque imaginam uma pessoa extremamente introvertida que se sente muito desconfortável ao falar com outras pessoas e se limita a escrever código em seu cubículo. Não queremos uma equipe assim. Podemos ter algumas pessoas assim, mas também precisamos de pessoas que possam se comunicar, que sejam amigáveis o suficiente para fazer perguntas, que tenham uma visão artística do que pode tornar um produto atraente para os usuários.
É uma combinação de mulheres que pensam que não vão gostar porque não percebem as diferentes dimensões da carreira e de mulheres que pensam que não serão boas porque não se encaixam no estereótipo. E as pessoas encarregadas das contratações de uma empresa acham que existe apenas um tipo de engenheiro —alguém que se parece com eles— e não percebem o quanto essas outras habilidades são importantes para a equipe.
Isso, quem sabe, pode causar alguma controvérsia, mas muitas das coisas que a indústria está tentando fazer para ajudar, na verdade não estão ajudando. Organizar conferências especificamente para mulheres que trabalham em informática definitivamente reforça o estereótipo de que as mulheres sempre recebem tratamento especial, que se você for mulher basta com se aproximar a qualquer empresa de alta tecnologia e dizer “Contrate-me”.
Organizar uma conferência só para mulheres não ajuda muito: pode que compartilhem como fazer para compatibilizar o fato de ter filhos com uma carreira, mas os homens têm as mesmas preocupações.
Se, em vez de nos concentrarmos no que podemos fazer pelas mulheres, tentamos melhorar o ambiente para todos, as melhorias também serão para as mulheres.
Veja a apresentação de Perlman aqui.
