NPM e o problema com o Kik

[lucasbento]

Ontem eu vi esse post e hoje esse, mostrando como a NPM se posicionou em uma solicitação e "tomou conta" de um projeto de um desenvolvedor, ele então removeu todos seu 250 projetos e um deles sustentava boa parte de outros projetos.

Gostaria de ouvir a opinião de todos não sobre NPM assumindo o problema da empresa Kik mas sim como as aplicações JavaScript são extremamente frágeis hoje, só de alguns cliques que eu dei já vi vários desenvolvedores gritando à Deus por ajuda por causa de uma pessoa que, em um momento de raiva, removeu todos seus projetos.

[fdaciuk]

Isso é um problema que estamos sujeitos a ter a todo momento, mas acredito que é a minoria que faz esse tipo de coisa.

Acho que ele poderia ter tentando negociar com o NPM de alguma forma, ao invés de remover tudo de lá, mas enfim..

Já compartilharam essa CLI que verifica se você está usando algum dos módulos do azer no seu projeto, e ao menos saber se algo quebrou por isso.

PS.: o cara que criou esse módulo não é brasileiro, mas o nick dele é piada pronta :P

[bernardodiasc]

Pra quem tem os recursos necessários, o esquema é hospedar um repositório privado de modulos mesmo: http://stackoverflow.com/questions/7575627/can-you-host-a-private-repository-for-your-organization-to-use-with-npm

[felipefialho]

@bernardodiasc Para grandes aplicações isso faz todo o sentido do mundo.

Mas como disse o @fdaciuk, acho improvável esse tipo de atitude.

[kazzkiq]

O mundo de repos JavaScript é extremamente desregulamentado. E assim como qualquer mercado desregulamentado e aberto (maior parte do mundo open-souce), quem dita as regras são os próprios clientes, ou usuários.

Tendo dito isso, eu entendo a atitude da npm, Inc. Como empresa privada que são, eles resolveram tomar uma atitude naquele momento como forma de evitar possíveis problemas judiciais. POREM esta atitude veio com um custo. A empresa passou uma clara mensagem de que qualquer package, por mais "famoso" que seja, não está blindado contra agentes externos, e caso eles assim queiram, podem intervir nos pacotes alheios sem muito rodeio. Se essa atitude é juridicamente legal? Provavelmente sim (afinal, o serviço é deles). Agora, se é ética? Definitivamente não.

Esta conduta invasiva e imediata foi o que provavelmente revoltou o @azer a ponto de tomar a decisão de remover todos seus packages de lá. Mas apesar da atitude drástica, e até um pouco egoísta, eu acho que a atitude dele foi mais uma forma de protesto do que revolta propriamente dita. Foi uma maneira de dizer pra galera: "Tomem cuidado, se não respeitaram o meu package com milhões de downloads, o que faz vocês pensarem que os seus estariam seguros?", e pelo que a npm mostrou, este questionamento é bem válido.

Qual lado está certo? Boa pergunta. Só sei que a empresa Kik, apesar de ser extremamente babaca por ter problematizado em cima do nome de um package JavaScript, acabou ajudando a abrir os olhos para a fragilidade da comunidade nos dias de hoje. E isso é ótimo, porque como disse lá em cima, em um mercado desregulamentado, quem dita as regras são os usuários, e se o mercado encontra um problema, ele eventualmente vai se moldar para resolvê-lo de acordo com a demanda dos próprios usuários. Usuários estes que agora estão muito mais espertos e talvez pensem duas vezes antes de importar uma biblioteca de terceiros sem avaliar a possibilidade de escrever o código por si próprios. Usuários estes, que como clientes, podem vir a cobrar alguma solução ou postura adequada da npm, Inc em casos futuros, ou mesmo acabarem migrando para outra plataforma de publicação de código mais confiável (jspm tá aí aceitando packages direto de repos Git e tudo mais).

[kazzkiq]

E por falar em mercado se moldando para resolver problemas, a primeira possível alternativa já está aparecendo na área:

ipmjs

[bernardodiasc]

hehehe a internet propondo alternativas também dá nisso:
https://gist.github.com/rauchg/5b032c2c2166e4e36713

ou ainda melhor:
http://left-pad.io/

[tcelestino]

Não vi o problema com o desenvolvedor, mas sim com a NPM que acatou sem ao menos procurar o desenvolvedor o pedido de uma empresa. Ou seja, não vi a atitude do desenvolvedor como ruim, até porque mesmo hospedado na infra estrutura da NPM, quem é o responsável é o desenvolvedor e não a empresa.

Isso abriu diversos procedentes: como confiar em uma empresa que não utiliza o "bom senso" e apenas a visão "corporativa"?

[renanvaz]

Galera, acho que vcs estão esquecendo de algo muito importante e que parte disso já foi discutido no tópico #17

Provavelmente alguns de vcs são desenvolvedores backend e já tiveram contato com gerenciadores de pacotes das linguagens que usam. O NPM é o gerenciador de pacotes do NodeJS, porém a comunidade utilizou ele de uma forma mais global, não apenas utilizando para gerenciar pacotes NodeJS (já que a plataforma NodeJS utiliza a linguagem JavaScript). Esse mal entendimento da comunidade (minha opinião) fez com que muitos pacotes tanto de NodeJS (ferramentas, libs e frameworks) e de frontend estivessem no mesmo gerenciador. Isso claramente vai gerar vários problemas de nomes de packages (que não possuem relação). O risco disso é o NPM começar a ficar bagunçado e as pessoas automaticamente vão começar a buscar alternativas tanto para hospedarem quanto para utilizarem pacotes mais semânticos em questão de nomenclatura.

Vai chegar um momento que escolher o nome do seu package vai ser mais difícil do que registrar um nome disponível de igreja.

Com base nisso, entendo o fato de a NPM botar o dedo para escolher quais são os packages com maior relevância para se manter um índice de pacotes de qualidade.

Claro que o cara foi prejudicado, mas pelo o que vi, ele não quis colaborar para chegarem em alguma alternativa que fosse legal para ambos os lados. Ele simplesmente não quis conversar só pelo fato do package dele estar lá primeiro. Não tenho como saber como a história real aconteceu, isso vai depender de quem contar. Mas só pelo fato do cara ter tirado os seus packages de lá, ele perdeu a razão (se é que realmente tinha).

[kazzkiq]

Esse caso também me lembrou de um problema parecido que aconteceu uns anos atrás com uma biblioteca JavaScript de scroll. O cara deu o nome de iScroll pra biblioteca dele (por simular aquele efeito elástico de scroll nativo do iOS), aí veio uma empresa minúscula de mesmo nome e ameaçou processar o cara por causa do uso do nome.

Na época ele tinha até avisado a comunidade que o projeto teria que ser renomeado e tal, mas aparentemente o nome ainda continua o mesmo, então não deve ter dado em nada.

@renanvaz
Enquanto eu pessoalmente também não goste da ideia de misturar bibliotecas front-end com as do Node.js, não acho que isso tenha sido o problema neste caso do Kik. Até porque muitos dos projetos que tiveram o build quebrado eram back-end. O problema foi que o npm caiu de tal forma nas graças do povo que a galera acabou começando a usar pra tudo, e a empresa aceitou isso de boa.

Se a própria empresa aceita o deploy de outros tipos de pacotes, e o mercado não oferece nenhuma alternativa à altura (ainda), é de se imaginar que a galera vá acabar migrando com força pra lá mesmo. A única alternativa front-end que era popular era o Bower, que aparentemente morreu (ou tá na UTI, sei lá o que que tá rolando com a equipe dele).

Eu mesmo tenho um projeto 100% CSS que está publicado no npm, tamanha a demanda da galera pra poder usar ele por lá. Se eu acho bonito publicar um projeto CSS em um gerenciador de pacotes originalmente para Node.js? Não. Mas existe uma demanda muito forte, e a própria empresa já disse que permite qualquer tipo de pacote lá, então não vejo porque não fazê-lo.

[renanvaz]

@kazzkiq concordo com vc quanto ao caso do NPM. Eles mesmos permitem isso (pois dá visibilidade). O lado negativo é esse caso dos nomes (pois existe uma concorrência maior de pacotes) e pode chegar um dia em que vc não saiba se o pacote que vc está baixando é backend ou frontend. Mas parece que a NPM está tranquila quanto a isso, a comunidade tb (ou não pensaram sobre). Então não deve ser um problema (ainda).

O lance da competitividade de gerenciadores, acho que não é tanto quanto a qualidade e sim falta de conhecimento da galera. Conheço muitos desenvolvedores frontend que não sabem que existem outros gerenciadores de pacotes, e nem que isso é uma prática comum em linguagens backend. Um gerenciador que conheci a pouco tempo é o JSPM, ele é próprio para pacotes frontend, e para quem já está acostumado a utilizar transpilers e module bundlers, é uma puta ferramenta que já une tudo. O que falta nele é visibilidade, pois em funcionalidade (específica) ele dá de 10 a 0 no NPM.

[danjesus]

A fragilidade do NPM ficou evidente, os gerenciadores de pacotes de outras linguagens lidam muito melhor com isso, no rubygems por exemplo você remove a gem mas ela continua disponível para quem já fez o download, no composer do php você não consegue remover um pacote com muitos downloads.

Além da atitude dos caras ter sido no mínimo equivocada de liberar um pacote de um user para outra empresa, ainda tem esse ponto ai da plataforma.

[bernardodiasc]

http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy