Por qué nos llamamos Nitza Develop
En los años más duros del Período Especial, Nitza Villapol seguía al aire. Llevaba ya cuatro décadas enseñando a cocinar en la televisión cubana, pero en esos años el programa cambió de naturaleza: ya no se trataba de mostrar una receta ideal, sino de resolver con lo que realmente había esa semana. Según recoge NPR, citando el libro Castro’s Final Hour de Andrés Oppenheimer, Villapol llegó a consultar con funcionarios del gobierno cuáles eran las raciones disponibles antes de grabar cada emisión. No enseñaba la receta perfecta. Enseñaba a tomar la receta de la semana anterior, quitar lo que faltaba, sustituirlo por lo que sí había, y explicar el porqué de cada cambio para que quien la viera en su casa pudiera repetir el razonamiento, no solo el plato.
Ese gesto —recibir algo hecho por otro, entenderlo lo suficiente para modificarlo según el contexto real, y devolverlo explicado para que el siguiente no empiece de cero— es prácticamente la misma idea que usa Richard Stallman para explicar qué es el software libre. Y esa coincidencia, más que una curiosidad, es el motivo por el que esta empresa se llama Nitza Develop.
La cocina de Nitza Villapol
Nitza Villapol nació en Nueva York en 1923 y se radicó en La Habana, donde se doctoró en Pedagogía en 1948 antes de dedicarse por completo a la televisión. Su programa, Cocina al Minuto, se estrenó el 3 de julio de 1951 y se convirtió en uno de los espacios más longevos de la TV cubana. En 1958 publicó el libro homónimo, reeditado varias veces con el paso de las décadas, y no es raro encontrarla comparada con Julia Child como divulgadora culinaria televisiva. Murió el 20 de octubre de 1998, después de haber enseñado a cocinar —en el sentido más literal y en el más amplio— a varias generaciones.
Lo que hace memorable su trabajo no es solo la longevidad del programa, sino el momento en que su función cambió: cuando los ingredientes dejaron de ser una elección estética y pasaron a ser una restricción real, Villapol no abandonó el formato de receta. Lo adaptó. Convirtió la receta en una herramienta para pensar con lo disponible, no en un objeto fijo que había que seguir al pie de la letra o descartar por completo.
La receta que usa Stallman para explicar el software libre
Richard Stallman recurre a esa misma imagen —la receta— para explicar el software libre en su discurso Free Software: Freedom and Cooperation, pronunciado en NYU el 29 de mayo de 2001. Describe recibir una receta de un amigo, poder modificarla (quitar un ingrediente, añadir champiñones) y volver a compartirla con quien la necesite. A partir de esa imagen, Stallman construye las cuatro libertades formales que definen el software libre en la Free Software Definition de GNU: usarlo, estudiarlo y modificarlo, redistribuirlo, y distribuir versiones modificadas.
Quien programa reconoce el patrón inmediatamente, aunque nunca haya frito un huevo siguiendo instrucciones: recibes código escrito por otra persona, lo lees hasta entender por qué toma las decisiones que toma, lo cambias para que funcione en tu contexto —tu infraestructura, tus restricciones, tu equipo— y, si tiene sentido, lo devuelves a la comunidad con el cambio explicado. No hay receta perfecta ni librería perfecta. Hay una base razonable y la posibilidad de intervenirla sin pedir permiso.
Dos formas de enseñar lo mismo
Ahí está el punto de encuentro que le da nombre a esta empresa. Villapol enseñó, con recetas, a resolver con lo real en lugar de esperar por lo ideal. Stallman, con esa misma metáfora de la receta, describió un modelo de trabajo donde el conocimiento se comparte, se modifica abiertamente y se devuelve mejorado. No son la misma disciplina, pero comparten el mismo principio de fondo: el valor no está en proteger la receta, está en que circule, se adapte y alguien pueda seguir el razonamiento detrás de cada cambio.
Así queremos trabajar el desarrollo de software en Nitza Develop: no partir de una arquitectura ideal en abstracto y buscar después el proyecto que la justifique, sino partir de lo que el cliente tiene disponible —su stack actual, su equipo, su presupuesto, sus restricciones de tiempo— y construir con eso, intentando documentar el porqué de cada decisión para que el equipo que herede el proyecto pueda seguir el hilo, no solo el resultado final. Es la misma lógica de “cocinar con lo que hay” aplicada a decidir si se extiende un sistema legado o se reescribe un módulo, y la misma lógica de “compartir la receta modificada” aplicada a nuestra intención de dejar código legible y documentado, con licencias claras, cuando corresponde usar o publicar software libre.
Por eso el nombre no es un juego de palabras gratuito. Es una declaración de valores: así intentamos trabajar, con lo real en vez de con lo ideal, compartiendo el razonamiento detrás de cada modificación en vez de entregar una caja cerrada. “Nitza” por la maestra que convirtió la escasez en método sin perder de vista a quien la seguía desde su casa. “Develop” porque ese método, aplicado a código, es el estándar de desarrollo de software que nos proponemos seguir: iterativo, adaptado al contexto de quien lo va a mantener, y abierto a que alguien más lo entienda y lo siga.
Si te interesa cómo pensamos estas decisiones cuando construimos software para un cliente real, síguenos en nuestras redes sociales y cuéntanos qué opinas del paralelismo.