Node.js Superará a Java en un Año – InApps 2022

Este artículo es una traducción, podés leer el original acá.

La siguiente entrevista es parte de una serie, llamada Open Source Leaders, donde retratamos líderes de proyecto en la comunidad open source de IT, para aprender más acerca cómo ellos construyen su software y también los desafíos y beneficios que trae llevar a cabo un proyecto open source.

Mikeal Rogers estuvo con la Node.js Foundation desde el primer día. Su trabajo como community manager para la fundación involucró la supervisión de las operaciones, desde comunicación y marketing hasta planeamiento de conferencias y organizar reuniones de la junta directiva. De todas maneras, la contribución más importante de Rogers es la organización y coordinación dentro de la comunidad Open Source de Node.js – particularmente escalando gobernanza y procesos, a medida que el proyecto pasó de una docena de contribuidores a varios cientos.

Rogers habló con InApps para charlar acerca de su experiencia y sus comienzos en el mundo open source, su trabajo en la Node.js Foundation y sobre cómo se convirtió en un gurú de la gobernanza de comunidades open source.

Primero lo primero: ¿no vas a continuar con la Node.js Foundation por mucho tiempo más?

Es cierto — en algunas semanas voy a estar levantando las cosas de mi escritorio. Estuve desde el principio, y las cosas han tomado buena forma. Estoy listo para continuar en algo nuevo, aunque todavía no he decidido exactamente qué o dónde será.

¿Cuál fue tu mayor logro durante estos dos años?

Remediar el fork de io.js — fué un tiempo esencial y difícil para la comunidad, pero emergimos más fuertes. Y seguramente mejor organizados. Entonces decir que estoy orgulloso de eso significa estar orgulloso de incorporar principios de gobernanza modernos a una comunidad diversa que en ese momento estaba creciendo rápidamente.

¿Cómo empezaste con la programación?

Empecé a programar a los 13 – assembler, principalmente, porque quería ser un hacker y necesitabas saber assembler para ser capaz de escribir overflows de buffers. Aprendí principalmente manipulando y cambiando el código de exploits que escribían otras personas. Incluso antes de que el open source fuera tan accesible, nos enviábamos patches en una lista de correo y había una comunidad alrededor de la escena hacker, las personas compartían exploits en IRC y hackeaban sistemas de teleconferencia.

Eso fué en una ciudad muy pequeña al noroeste del estado de Washington, cerca de Seattle. Fué hacia donde me mudé el día después de cumplir 18 para trabajar en diferentes empresas de tecnología. Incluyendo una temporada en Mozilla, trabajando como desarrollador JavaScript y Python en proyectos cómo JSBridge y Mozmill. También en algunas aplicaciones CouchDB.

¿Qué te llevó al mundo open source?

A medida que me involucré más y más en la industria y en la programación fué natural introducirme en la escena open source porque era el mismo tipo de comunidad y usaban los mismos sistemas que en el mundo hacker dónde empecé. Esto fue crucial, porque el open source no era fácil para los principiantes a principios de los 90. Las personas que realmente sabían lo que estaban haciendo colaboraban. Sin embargo la escena hacker era más un montón de jóvenes que aparecían de manera esporádica y te ayudaban.

Hablamos mucho de escalar servidores, pero no tanto de escalar comunidades.

Creo que ahora los roles están intercambiados — la escena hacker se retrajo, se convirtió más cerrada e incluso reservada, mientras que la escena open source se abrió mucho más. Si mirás en la adopción de GitHub y usuarios, y con qué frecuencia están contribuyendo — no es ni siquiera una long tail*, es una fat tail. Más de la mitad de los commits en GitHub son de personas que hacen menos de cinco commits al mes, ellos están contribuyendo activamente pero no dedicándole sus vidas a ello.

Contanos acerca de gobernancia, y cómo es crucial para el open source.

Hablamos mucho de escalar servidores, pero no tanto de escalar comunidades. Es difícil pasar de ser un mantenedor de un proyecto que requiere unas pocas horas a la semana a que tu proyecto logre un crecimiento tal que de repente te encontrás administrando dos trabajos full-time. Es lo que muchas personas anhelan, pero no siempre están preparados para manejar – por eso la idea es escalar la comunidad de forma que pueda soportar y mantener el proyecto cuando ocurre ese progreso repentino. Pero se necesita cierta estructura. El open source tiene una cultura alrededor de cómo se hacen las cosas, y la gobernanza es cómo nos aseguramos de que las cosas continúen creciendo de una forma que funcione.

Estuve realmente influenciado en todo por mi trabajo en el Open Source Applications Foundation (OSAF), que fué fundada (y financiada) por Mitch Kapor, el fundador de Lotus Development Corp y creador del programa de hojas de cálculo Lotus 1-2-3. Es cómo el nuevo Lotus Notes pero para la era moderna, con muchas celebridades trabajando en este proyecto open source, como personas del equipo original de Apple Macintosh.

En OSAF hablamos mucho acerca de los valores e incentivos que creas alrededor de un proyecto, y qué estamos incentivando al hacer las cosas de una forma u otra. Y algunas de las personas más grandes podrían haberse resistido a cambiar la forma en que hacemos las cosas, pero nosotros los jóvenes lo sobrepasamos. No todo es un problema de código, si mirás a los sistemas y procesos como estructuras de incentivación, casi que podés programarlos para producir ciertos resultados. Y si obtenés resultados negativos, podés retroceder los procesos que te llevaron hasta ahí, y después con el tiempo entender qué procesos empujaron a las personas a inclinarse a esta conclusión negativa. El lado positivo de esto es que podés producir sistemas que intencionalmente crean resultados positivos.

Al final OSAF no tuvo éxito. Existe un libro llamado Dreaming in Code por Scott Rosenberg, acerca del fracaso que fué. De hecho yo empecé a trabajar el día después que él dejó de participar en OSAF, y ya podías ver qué cosas no estaban funcionando. Entonces eventualmente Mitch quitó el financiamiento, y yo me moví a Mozilla.

¿Cómo/cuándo empezaste a adoptar Node.js?

Mi amigo Adam Christian (uno de mis amigos más antiguos – éramos los únicos dos hackers en una ciudad muy pequeña) y yo construimos un framework open source para testing, un competidor de Selenium llamado Windmill. Era genial – incluso el creador de Selenium, era mejor que Selenium. Esto es relevante porque la semana que Node.js se hizo público, en Noviembre del 2009, un tweet se dió a conocer preguntando si alguno había escrito un proxy HTTP [aka la primer versión de Node.js] que funcionara con esto. Y nadie lo había hecho, porque había sido hecho público hacía un día. Había estado optimizando Windmill por casi tres años, entonces me dije a mí mismo, “Esto es un gran proyecto de fin de semana”. Me senté y alrededor de dos horas tenía un proxy funcionando. Estaba asombrado que sólo fueran 80 líneas, y cuando comparé su rendimiento, era muchas veces más rápido que el que había pasado años construyendo. En ese momento dije literalmente, “No voy a escribir más Python – el futuro claramente es Node.js”

El creador de Node.js, Ryan Dahl, se mudó a San Francisco poco después, y había una cultura de trabajar con todas las APIs de Node en una forma rápida y dinámica y también hablar acerca de la comunidad que queríamos construir. Por lo que trabajé en el núcleo de Node y también en una de las primeras librerías del ecosistema. Y como una de las primeras cosas de la comunidad, ayudé a empezar NodeConf, que era el centro de gravedad para la construcción de comunidad de Node. Porque todos sabíamos que iba a despegar. En aquel entonces era inconcebible pensar que literalmente superaría a Java en una década, pero estamos en camino a hacer justamente eso. Es mucho que procesar.

¿Qué problemas técnicos o de negocio resuelve Node.js?

Seguimos incrementando los entornos con los que los desarrolladores tienen que lidiar. Si construís un producto, vas a necesitar un frontend web, además de no sólo un backend sino un backend que provea una API, además de una experiencia mobile, una experiencia desktop, podrías tener que conectar dispositivos a Internet (Internet of Things). En un equipo pequeño, es difícil construir en X cantidad de entornos – pero Node te brinda una plataforma universal, con un ecosistema de medio millón de paquetes. No necesitás escribir ese algoritmo – hay más paquetes en el ecosistema Node.js que en cualquier otro. Entonces le permite a los desarrolladores de tu aplicación escribir aplicaciones y no infraestructura. Podés construir más rápido.

Node es enorme, corre básicamente en todos lados, que es como su propio lema.

¿Cuáles son las estadísticas actuales del proyecto?

Estamos ahora en 8 millones de usuarios estimados y todavía creciendo a un 100% anual. Todavía no pasamos a Java en términos de usuarios todavía, pero con el crecimiento actual a esta altura del año que viene, lo superaremos.

Tenemos más de 100 personas que hacen commits en el proyecto – el número activo varía cada semana a medida que se hacen nuevos releases y la gente se entusiasma, pero son bastantes. Supimos tener 3 contribuidores antes del fork de io.js, por lo que definitivamente estamos en un mejor lugar ahora.

¿Qué ocurre con el potencial de monetizar tu involucramiento con el proyecto?

La fundación es nonprofit, por lo que no puedo realmente hablar de monetización open source al nivel de proyecto. Pero personalmente, tuve facilidad encontrando trabajos y negociando salarios gracias a mi trabajo open source.

Todo el mundo que trabaja en el open source termina siendo más atractivo cómo desarrollador. Tenés mucha historia pública más allá del perfil de LinkedIn. Como un CTO buscando contratar, podés darte cuenta de sus habilidades de comunicación escrita, cómo responden a las críticas en un code review, cómo cuando las situaciones se complican logran resolverlas o las convierten en una catástrofe – seguramente es una gran ventaja.

Las personas que contribuyen al open source obtienen más dinero que otros desarrolladores con los mismos títulos – es así de valioso.

¿Unas últimas palabras?

Mi parte favorita del crecimiento de Node.js es que cada año hay la misma cantidad de personas nuevas como personas que ya lo programan. Hay un flujo constante de nueva sangre y nuevas ideas. A medida que continuamos bajando la barrera de entrada estamos abriendo la programación a personas que previamente no podían construir aplicaciones. La facilidad de uso de Node.js es continuamente impulsada por el hecho de que hay tantas personas llegando – en cualquier momento, 50% de la comunidad son personas no sólo nuevas para Node sino también para JavaScript el mismo año – por lo que necesitamos hacer la plataforma fácil para que los recién llegados puedan comenzar a usarla enseguida.

Simplemente amo el alcance, la versatilidad y la accesibilidad. Node.js puede soportar enterprise sin problemas, pero toda esta nueva vida también trae tantos proyectos de arte, ciencia y de cosas creativas. Ninguna otra comunidad allá afuera posee ese tipo de actitud receptiva.

*La “long tail” es un término acuñado por Chris Anderson en el 2004 y se refiera a la posibilidad de que productos con poca demanda o pocas ventas puedan colectivamente generar un mercado que rivalice o exceda el mercado de algunos pocos productos que son estrellas de mercado. Para esto el canal de distribución de estos productos debe ser grande y tener gran alcance.