Skip to content

El negocio del Software Libre (IV): Hackers frente a académicos

Compartir

Compartir en facebook
Compartir en linkedin
Compartir en twitter
Compartir en pinterest
Compartir en email

Hackers frente a académicos. En mi último artículo sobre modelos de negocio en el Software Libre comentaba las cuentas de las empresas que gestionan las principales redes sociales y, a modo de epífora, repetía que podía ser una casualidad que a mayor implicación en proyectos de Software Libre, mayores eran los beneficios de esas empresas.

Si bien yo no considero que sea una casualidad, tener que escribir ese artículo a modo de preámbulo del presente es algo que me permite ilustrar la sinrazón de los cientificistas que se empeñan en intentar crear modelos reproducibles cuando intervienen humanos.

Los humanos sueñan, los androides, no

Cuando intervienen humanos no se puede crear un modelo capaz de obtener los mismos resultados si la prueba se realiza de la misma forma. Porque no hay dos personas iguales. Y en la economía, el elemento fundamental de estudio es la persona. Igual que en la tecnología.

Entre los muchos puntos en común que tienen la Escuela Austríaca y el Materialismo Filosófico es que ambas escuelas tienen una premisa clara, que es que cuando intervienen humanos todo cambia respecto a si no intervienen humanos y, a partir de ahí, desarrollan metodologías de estudio.

Esta es la verdadera potencia de estas dos escuelas y por la que trituran cualquier cientificismo o cualquier academicismo. Ya sea analizando a través de la praxeología y el individualismo metodológico de la Escuela Austríaca o a través de las metodologías alfa y beta-operatorias del Materialismo Filosófico, vemos que es imposible aplicar modelos matemáticos que devuelvan los mismos resultados cuando al menos una de las variables implica la acción humana.

Sólo Dios conoce el precio matemático

Como ya explicó hace cuatro siglos el Cardenal Juan de Lugo: «Pretium iustum mathematicum licet soli Deo notum» (sólo Dios conoce el precio matemático justo [de las cosas]) o su contemporáneo Baltasar Gracián, quien en su aforismo 26 de Oráculo manual y arte de prudencia dice:

Todos son idólatras: unos de la estimación, otros del interés y los más del deleite. La maña está en conocer estos ídolos para el motivar, conociéndole a cada uno su eficaz impulso: es como tener la llave del querer ageno.

Baltasar Gracián

Y en su aforismo 252:

Entienda el atento que nadie le busca a él, sino su interés en él, o por él.

La actitud del hacker

Eric S. Raymond comienza su apartado «La actitud del hacker» de Cómo convertirse en hacker afirmando:

Los hackers resuelven problemas y construyen cosas, y creen en la libertad y la ayuda voluntaria mutua. Para ser aceptado como hacker, deberás comportarte como si tuvieras esta actitud en tu interior. Y para comportarte como si tuvieras esta actitud, deberás creerte de verdad dicha actitud.

Pero si piensas en cultivar las actitudes de hacker solo como una forma de ganar aceptación en esta cultura, te estás equivocando. Transformarse en la clase de persona que cree estas cosas es importante para ti —para ayudarte a aprender y mantenerte motivado. Como en todas las artes creativas, el modo más efectivo de transformarse en un maestro es imitar la mentalidad de los maestros —no sólo intelectualmente, sino también emocionalmente.

Eric S. Raymond

Software libre

Y aquí es donde está la clave por la que las empresas que desarrollan Software Libre llegan mejor a un mayor público. El principal valor de las empresas es su personal. De nada sirve tener grandes extensiones de terreno fértil si no tienen personal que lo sepa cultivar o de nada sirve tener costosísimas máquinas sin técnicos que operen con ellas.

Las empresas tecnológicas no requieren de terrenos en zonas con una determinada climatología y acequias para regar ni de naves industriales con hornos, prensas y otra maquinaria que requieren de un gran capital para poder desarrollar su actividad, sino que requieren de una inversión en material muy pequeña en comparación con otros sectores, pero, sobre todo, necesitan un personal muy competitivo.

Competencias frente a diplomas

En la selección de personal de las empresas suele haber un conflicto entre primar las titulaciones o las competencias de los candidatos. En las empresas tecnológicas, al ser un mercado menos intervenido, este conflicto es mucho más profundo.

En muchos sectores es necesario tener una titulación, incluso una colegiación, para poder desarrollar una actividad profesional. Ahí, poco conflicto hay: sólo aquellos que tienen tal o cual diploma ejercen esa actividad. Pero a la hora de trabajar en el sector tecnológico, en el que la demanda de personal supera en mucho a la oferta, esa barrera de entrada es inviable.

Enseñanza de la tecnología y la universidad

Es más, la lentitud y burocracia del sistema universitario intervenido ralentiza tanto la adaptación de los temarios que no puede abastecer de personal a las empresas que están demandando personal con unos conocimientos en permanente evolución. El mejor personal en un sector tan cambiante como es el tecnológico no es el que más títulos tiene, sino el que mejor se adapta a cada necesidad, evolucionando sus conocimientos y sus acciones a medida que evolucionan las demandas.

Pero encontrar esos perfiles requiere de un esfuerzo importante por parte de los reclutadores. Si bien es cierto que se le da cierta importancia a los «soft skills» (lo que en español siempre hemos llamado «competencias») en el sector tecnológico, al ser algo tan inherentemente humano, es imposible de parametrizar. Es menos costoso para el que toma la decisión de contratar a una persona mirar el número de títulos que tiene.

Y aquí entran en conflicto los intereses de la empresa con los intereses particulares del tomador de decisión.

Pañoleta como título

Hay diversas fórmulas para saber, o intuir, a priori, si un trabajador tiene determinadas competencias o no.

Aquel que ha sido Scout (o miembro de algún grupo similar basado en las enseñanzas de Lord Baden-Powell), quizá no entendía de niño por qué era bueno para su aprendizaje hacer una marcha de 200 kilómetros en una semana. Yo no entendía por qué tenía que cargar más peso que otros compañeros. De hecho, me molestaba.

Veinte o treinta años más tarde, ves la importancia de eso que aprendías de forma lúdica: si cargabas mucha comida, pesaban mucho las mochilas, pero si cargabas poco, podías quedarte sin comida al cuarto o quinto día. Si no preparabas bien la indumentaria, tenías rozaduras que acababan siendo un suplicio. Si alguien se quedaba rezagado, todo el grupo le ayudaba, porque la consecución del objetivo del grupo dependía de que todos los miembros del grupo lo alcanzasen.

Boy Scout

Ana Sáenz de Miera publicó en Forbes un artículo (Por qué contratar una persona que haya sido Scout) en el que plasmó una serie de competencias que se adquirían en Scouts:

  • Sabe trabajar en equipo.
  • Es creativo.
  • Respeta su escala de valores y su palabra.
  • Sabe liderar y ser liderado.
  • Es empático.
  • Valora el esfuerzo.
  • Sabe ponerse objetivos y evaluarlos.
  • Es generoso.
  • Lucha contra la injusticia.
  • Es una persona “con recursos”.

La academia es el problema, el Software Libre es la solución

Todos los puntos que describe Ana Sáenz de Miera son importantes a la hora de trabajar en equipo en cualquier sector. Pero, en el sector tecnológico, además, hay que tener dos competencias más: saber algo de tecnología y entender algo el mercado. Para el que tiene la actitud adecuada, aprender a programar o a administrar sistemas es extraordinariamente simple:

Aquel que es capaz de estructurar ideas de forma metódica, programar es sólo convertir esas ideas a un lenguaje de programación. Y siempre va a poder ayudarse de la documentación o de programas que le ayuden. Aquel que es capaz de estructurar cómo deben comunicarse los elementos de un sistema informático, administrar sistemas es sólo instalar o programar servicios en máquinas. Y siempre va a poder ayudarse de la documentación o de programas que le ayuden.

Lo importante no es saber todas las funciones de determinado lenguaje, sino cuándo utilizar una u otra funcionalidad. Y por qué unos programas funcionan y tienen muchos usuarios y una gran comunidad de desarrolladores y documentadores y otros no.

Diferencias entre el académico y el hacker

En el Software Libre, en el que el precio no es un hecho diferencial por el que un usuario acaba utilizando uno u otro programa, es donde mejor se puede comprobar la acción humana y la dispersión memética. No hace falta leer a Ludwig von Mises, ni a Richard Dawkins, ni a Daniel Dennett, ni a Susan Blackmore para comprobar que aquellos programas que mejor funcionan son aquellos en los que mejor funciona su comunidad.

El académico lee sobre la comunidad, el hacker vive la comunidad. El académico imagina e idealiza. El hacker materializa. Quizá, después de haber vivido la comunidad, lee sobre comunidades y memes. Pero, como ya tiene una base material, puede extrapolarlo a otros contextos. El hacker construye. Construye en comunidad. Construye para la comunidad. Construye con otras personas, para otras personas. El académico, en el mejor de los casos, escribirá un paper que sólo citarán otros académicos.

El Zen de Python, la clave del éxito del Python

La base del éxito de Python no es su simplicidad, su rápido aprendizaje, que tenga «las pilas incluidas» o su gran cantidad de paquetes de terceros. La base del éxito de Python es su zen:

  • Bonito es mejor que feo.
  • Explícito es mejor que implícito.
  • Simple es mejor que complejo.
  • Complejo es mejor que complicado.
  • Plano es mejor que anidado.
  • Disperso es mejor que denso.
  • La legibilidad cuenta.
  • Los casos especiales no son tan especiales como para romper las reglas.
  • Aunque la practicidad vence a la pureza.
  • Los errores nunca deberían pasarse por alto.
  • A menos que esté explícitamente pasado por alto.
  • En caso de ambigüedad, rechaza la tentación de adivinar.
  • Tendría que haber un — y preferiblemente únicamente uno — camino obvio para hacerlo.
  • Aunque ese camino puede no ser obvio la primera vez, a menos que seas holandés.
  • Ahora es mejor que nunca.
  • Aunque nunca es, en algunos casos, mejor que ahora mismo.
  • Si la implementación es difícil de explicar, es una mala idea.
  • Si la implementación es fácil de explicar, puede que sea una buena idea.
  • Los namespaces (espacios de nombres) son una gran idea — ¡hagamos más de estos!

La importancia de la comunidad

Esta gran aportación de Tim Peters, con su toque de humor (a menos que seas holandés, en referencia a Guido van Rossum) y el hecho de que el humor sea un elemento fundamental en este lenguaje desde su raíz, ya que el nombre de Python viene por la afición de Guido a los Monty Python o que la propia documentación oficial de Python cuente con un apartado de humor es lo que ha hecho que se cree una comunidad tan grande alrededor de Python. Y esa comunidad es lo que ha hecho grande a Python.

Podría poner muchos ejemplos de la importancia de la comunidad del Software Libre, pero me limitaré a dos que han desbordado el campo de la tecnología (y que desarrollaré en futuros artículos):

El primero son los hackatones. Muchos grandes proyectos de Software Libre como Bootstrap o React, nacen de reuniones de hackers. Como los hackathones han demostrado su funcionalidad, en otros ámbitos se ha copiado este modelo de solucionar necesidades.

El segundo ejemplo es que hay proyectos libres, como OpenStreetMap, que crecen gracias a que se reunen hackers para mejorarlos a través de acciones como el State of the Map, el Humanitarian OpenStreetMap Team o el Missing Maps. Modelos similares también se aplican en las comunidades de Wikipedia. los Beers and Blogs, o en las Install Partys, donde la tecnología es la base de partida, pero no el fin de la acción.

Hackers, académicos y redes sociales

Del mismo modo que el niño que recorre 200 kilómetros en una marcha de una semana aprende una serie de competencias y que las interioriza gracias a una experiencia vivencial, el hacker vive la comunidad del Software Libre.

Por eso, las empresas de redes sociales que se nutren de hackers son capaces de desarrollar aplicaciones que generen un marco mínimo de cooperación social. La acción humana desarrolla de forma espontánea todo lo demás.

El académico puede estudiar, analizar e intentar parametrizar las interacciones humanas. Pero la subjetividad no es parametrizable. Con las redes sociales ocurre como con la economía: todo intento de planificación acaba fallando.

Copyleft Fernando Vicente. Puede copiar este texto. Escrito originalmente en Markdown con vi sobre Ubuntu GNU/Linux, usando sólo Software Libre.

Serie ‘El negocio del software libre’

(I) Las instituciones

(II) El caso de Wikipedia

(III) Sólo crecen las redes sociales que liberan código

Para más información sobre las limitaciones de la academia: Alberto Mera: Ciencia fiat



Aún no hay comentarios, ¡añada su voz abajo!


Añadir un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Más artículos

El lenguaje económico (XXXVII): salario

El salario es un precio (información) y también la cantidad de dinero (y otros beneficios no monetarios) que se percibe por realizar un específico trabajo. El trabajo no es una mercancía, pero su precio «se determina en el mercado del mismo modo que se fijan los precios de las mercancías»