Uno de los principios de la sociedad abierta que tanto nos ha beneficiado como sociedad moderna, es la división del trabajo. Así lo describía Adam Smith al inicio del primer capítulo de La Riqueza de las Naciones
El mayor progreso de la capacidad productiva del trabajo, y la mayor parte de la habilidad, destreza y juicio con que ha sido dirigido o aplicado, parecen haber sido los efectos de la división del trabajo.
Luego de Smith, el premio nobel de economía 1974, Friedrich Hayek amplió el concepto de división del trabajo a división del conocimiento, y en su conocido trabajo “El uso del conocimiento en la sociedad” (trabajo que siempre recomiendo leer y estudiar a todos mis consultores). En dicho trabajo, el austríaco plantea que no hay forma que ningún ente central se haga con la información de lugar y circunstancia que tienen los actores dentro de un sistema económico y que en ninguna circunstancia esa información está dada.
En tiempos recientes la innovación tecnológica ha sido llevada de la mano con el desarrollo de tecnologías basadas en el desarrollo disperso de iniciativas, siguiendo las premisas del movimiento de software libre. Una de las premisas del software libre (open source) es que “Todo el mundo podrá obtener un buen sistema de software libre, el código fuente estará disponible para todos y cualquier persona que quiera modificarlo, podrá hacerlo. Nadie es el propietario del código, sino que es de todos ‘Copiar todo o parte de un programa es tan natural para un programador como respirar, además es productivo. Debería ser libre'”. El manifiesto GNU va mas allá: “Extraer dinero de los usuarios de un programa limitando su uso es destructivo porque las restricciones reducen la cantidad y las formas en que el programa puede ser utilizado. Esto reduce la cantidad de beneficios que la humanidad obtiene del programa”.
Pero, y a partir de esas premisas, nos hemos acostumbrado continuamente a no darle valor a los programas desarrollados en diversas plataformas. La confusión entre libre y gratis ha hecho que personas y empresas consideran que el software “está ahí”, disponible para usarlo, y que no hay que pagar por ello. Y como no hay que pagar por ello, tampoco hay responsabilidad de quien creó o modificó el software.
Recientemente me encuentro en un post de LinkedIn una historia de un programador, a quien, para un proceso de selección laboral le habían pedido desarrollar, como parte del proceso de selección, una rutina en un lenguaje de programación abierto (deduzco yo que Python, pero puede ser cualquiera). El programador en cuestión relataba que las especificaciones eran tan detalladas que él sospechaba que la empresa contratante usaría la rutina para un ambiente productivo, y aunque el programador les advirtió que no podían hacer eso, la empresa contratante terminó usando la rutina desarrollada en un ambiente productivo. En el mismo post, el programador en cuestión cuenta que dentro del programa él le había dejado una rutina interna (y lo relataba como una gracia, que había dejado una ‘sorpresa’) que le informaba cada vez que la rutina era usada y que le permitía deshabilitarla a voluntad.
La actuación de ambas partes refleja una falta ética indudable. Pero la actuación de la empresa es resultado de llevar a sus últimas consecuencias las premisas del software libre. Si es software es libre, no tiene propietario y se incentiva a no cobrar por el software per se, al no haber derechos claros de propiedad ni posibilidad de exclusión, se presenta lo que en economía se llama “el problema del gorrón” (que se dan sobre bienes económicos que tienen características de bienes públicos, y los medios digitales tienen esa característica), es decir, aquellos actores que se aprovechan de los beneficios de los bienes compartidos sin aportar para sufragar los costos de su mantenimiento.
Del lado del programador en cuestión, la situación es más complicada. A todas luces actuó con dolo al dejar una rutina escondida dentro del código instalado. Y esto me lleva a señalar los riesgos que existen en el ecosistema de librerías compartidas que son habituales en ambientes de programación (en lenguajes como python, R, scala, entre otros).
En primer lugar, el tema de la seguridad. Con el movimiento a la computación en nube, la discusión en las empresas se ha dirigido al tema de ciberseguridad, pero enfocado en los ataques externos. La discusión no ha abarcado a la cantidad de programadores que están desarrollando rutinas a lo interno de la empresa que pueden dejar instalado este tipo de rutinas “gusanos” que no simplemente notifiquen uso de rutinas, sino que extraigan datos de las bases de datos ya colocadas en los ecosistemas de nube, poniendo en riesgo la privacidad de personas y empresas.
En segundo lugar, la responsabilidad. En su afamada novela Jurassic Park, Michael Crichton usa a su personaje Ian Malcolm para advertir el riesgo del uso sin responsabilidad del conocimiento científico. Eso mismo pasa con todas las rutinas y paquetes disponibles en el ecosistema, están disponibles, y la mayoría de la gente (programadores, científicos de datos, ingenieros de datos) solo las usan, muchas veces sin entender lo que hacen, solo buscando un resultado rápido a un problema. Y si ocurre algo, nadie es responsable, sobre todo apoyado en las licencias tipo MIT, en donde el software es entregado tal cual, sin ningún tipo de responsabilidad (la licencia MIT dice explícitamente: EL SOFTWARE SE PROPORCIONA “COMO ESTÁ”, SIN GARANTÍA DE NINGÚN TIPO, EXPRESA O IMPLÍCITA). Y como los programas son de todos, nadie es responsable (o todos, como en el famoso cuento Fuenteovejuna).
En tercer lugar, la transferencia de conocimiento. La mayoría de los lenguajes de programación asociados al desarrollo de paquetes distribuidos están basados en ese desarrollo disperso (en manifiestos de desarrollo de lenguajes, tal como Python, se habla de un cambio de paradigma en donde se ve a la programación como un “esfuerzo social”) y en un cambio generacional importante. Los programadores o quienes usan las rutinas y paquetes distribuidas son de nuevas generaciones, que, no todos tienen el interés por indagar a profundidad que hacen esos paquetes, y dentro de las empresas, los supervisores muchas veces no tienen forma de verificar el funcionamiento de las rutinas programadas en estos nuevos lenguajes. Toca un trabajo titánico de diversas áreas para conocer y retener a lo interno el conocimiento utilizado desde diversas fuentes.
Aunque el desarrollo descentralizado de rutinas y paquetes para resolver distintos problemas en el ecosistema de software libre sobre el internet es un ejemplo de como el conocimiento disperso y la división del trabajo (tal como planteaban Hayek y Smith) logran muchísimo más que si este conocimiento quisiera centralizarse, la inexistencia de responsabilidad sobre la creación y uso de programas, pone en evidencia riesgos en los procesos de automatización.
En esta sociedad posmoderna, en donde lo que importa es el resultado rápido, sin importar los efectos que puedan producir ni asumir responsabilidades, es importante que los implementadores de tecnología, cuiden su uso sin que ello signifique frenar la innovación. Es necesario que las empresas empiecen a mirar desde nuevas normas éticas al momento de la contratación de personal relacionado a la programación, a medidas restrictivas en las diversas plataformas que garanticen la seguridad de los datos.
