Artículos cortos…
Esta página contiene artículos cortos que he escrito en un momento u otro. Como autor, no quiero gastar tiempo tratando de que alguien los publique. Ese sería el trabajo que deberían realizar las agencias de publicación, si no estuvieran en nómina de los monopolios del copyright.
Por lo tanto, la publicación o distribución de mis artículos es libre bajo los términos de la versión 2 o posterior de la Licencia General de uso Público de GNU (GPL).
Debe tenerse en cuenta que estos artículos no son en forma alguna traducciones de los que he escrito en francés a menudo sobre temas completamente distintos.
Indice de materias
(bueno, de acuerdo, en esta ocasión sólo hay un artículo)
Sobre los artículos de Eric S. Raymond's (escrito el 23-mayo-1998).
Notas sobre "La catedral y el bazar" y otros escritos de Eric S. Raymond…
Lo que sigue son unas pequeñas anotaciones sobre defectos que se han deslizado en los, por lo demás excelentes y justamente bien conocidos, artículos de Eric S. Raymond . Se las envié a él en primer lugar, pero decidió, y estaba en su pleno derecho, no tenerlas en cuenta. Dado que creo que esto hace que sus artículos difundan unos cuantos conceptos notablemente incorrectos como parásitos de las importantes ideas que en ellos se exponen, me creo obligado a publicarlas aquí; quizá logre al menos de esta forma que ESR incluya los enlaces correspondientes a ellas en su página (escrito entre el 23 y 25 de mayo de 1998).
Eric S. Raymond, un respetado "hacker" (en el sentido del término), se ha hecho famoso como "predicador del software abierto", desde que escribió su influyente artículo "La catedral y el bazar", que cuenta ya con algunas secuelas (por el momento sólo "Colonizando la Noosfera").
Leí "La catedral y el bazar", poco después de que se publicara, antes de que se hiciera tan famoso como lo es en este momento, y se modificara por razones de mercado al sustituir la expresión "software libre" por "software abierto". Es un gran artículo, no pretendo negarlo; de hecho, no puedo sino estar fervientemente de acuerdo con la mayor parte de lo que en él se dice, pues contiene por cierto hallazgos importantes sobre la dinámica del desarrollo del software. Hallazgos que son, como creo que Jonathan Eunice hace notar si bien de forma poco apropiada, casi totalmente (aunque no por completo) independientes de toda consideración sobre si el software es libre o apropiable. I como teorizador sobre el software libre, mis observaciones tratarán sobre la no tan escasa diferencia entre ese "casi totalmente" y aquel "no por completo".
Mi primera observación (poco importante) se refiere a la siguiente sugerencia que aparece al final del artículo de la catedral:
Quizá al final la cultura del software abierto triunfe no porque la colaboración sea moralmente "buena" y la posesión avara del software "mala" (suponiendo que creas esto último, algo que ni yo ni Linus hacemos), sino simplemente porque el mundo comercial no puede ganar una carrera de armamentos frente a comunidades de software abierto capaces de movilizar cantidades de tiempo de personal cualificado algunos órdenes de magnitud superiores a la hora de resolver un problema.
Si bien estoy de acuerdo con la última parte de la frase, no lo estoy con la primera. ¿Qué mejor argumento moral que el software libre esté intrínsecamente mejor dotado para producir a largo plazo software fiable y de buena calidad?. Desde luego, no es un argumento metafísico; pero no hay razón para basar la moral en dogmas de este tipo; al contrario, la ética resulta más adecuada si las consideraciones a manejar provienen de la vida real.
En un correo privado, Eric me explicó que, si bien estaba de acuerdo con mi observación, no modificaría su artículo pues temía confundir a los lectores con nociones sobre si los aspectos éticos eran consideraciones a-priori o a-posteriori, que están fuera del contexto del artículo y requerirían una explicación demasiado larga para resultar inteligibles. Bueno, tal consideración no es al menos ajena a su conclusión, por lo que, si deseaba ajustarse de forma tan precisa al contexto, también hubiera podido eliminar directamente la conclusión. Y, cuando menos, una nota al pie con un enlace a alguna otra página de otro tipo hubiera podido contribuir a poner las cosas en claro para todo el mundo. También hubiera podido buscar una formulación más precisa o neutral, sin mayor explicación. Por miedo a "confundir" a los lectores con una "excesiva" precisión, Eric contribuye a un aumento de la confusión ya existente sobre asuntos éticos de importancia.
En la secuela al artículo de la catedral y el bazar, "Colonizando la Noosfera", otro artículo muy interesante, Eric introduce una confusión más esencial que está en el origen de todas las contradicciones aparentes que el artículo intenta despejar, en concreto, pensar que los programas son de alguna forma apropiables.
Si debiera ubicarme en uno de los modelos de ideologías de hacker descritos por Eric, probablemente me situaría en el tipo integrista anticomercial. Pero creo que su división de los tipos de hacker es parcial, en parte como consecuencia de un intento consciente de provocar mediante el humor, y en parte como resultado de la propagación de malentendidos habituales. En primer lugar "anti comercial" es simplemente un concepto incorrecto: los hackers del tipo de la FSF no están en absoluto en contra de hacer negocio; apoyan ardientemente la idea de que los servicios de software deben ser remunerados, y que debe haber un mercado libre para tales servicios; con lo que no están de acuerdo es con la idea de que el software pueda ser poseído y los malos hábitos asociados a las licencias comerciales.
Finalmente, "integrista" es un término obviamente parcial; yo más bien diría que alguna gente tiene más o menos tendencia a realizar compromisos si se presenta la oportunidad de apropiarse ellos mismos de un software dado, y de promover o dificultar tales compromisos en los otros, dos aspectos por lo demás independientes. El extremismo y el fanatismo no son atributos exclusivos de los puritanos del software libre que rechazan cualquier compromiso, sino que pueden encontrarse entre gente de cualquier opinión: no están unidos a una opinión particular, sino al hecho de que las opiniones se mantengan de forma dogmática o no.
En cuanto al pragmatismo, no es ciertamente un atributo que deba ser otorgado a nadie en virtud de su disposición a aceptar compromisos. Aceptar compromisos degradantes a largo plazo se llama "realpolitik", y ha demostrado ser una estrategia inútil frente a enemigos descaradamente inmorales (vease la historia del facismo o el comunismo), mientras que el rigor se ha manifestado a menudo como una actitud ganadora (por ejemplo, frente a la segregación en Sudáfrica). No estoy sugiriendo en absoluto que no deba realizarse jamás compromiso alguno, sino que deben tenerse en cuenta sus implicaciones a largo plazo como una parte más de los costes generados al aceptarlo, y no debe caerse en la ceguera de considerar tan sólo sus beneficios a corto plazo. El artículo de la catedral, manteniendo la observación anterior, es la mejor demostración de que el modelo de desarrollo de software libre del GNU constituye de hecho la aproximación más pragmática posible (otra confirmación de que GNU es el modelo más adecuado es la constante división observable en los proyectos regidos por licencias del tipo BSD, tales como las variantes de BSD Unix o el proyecto X).
El punto fundamental en que Eric se equivoca consiste en que, por miedo a asustar a unos accionistas poco educados, parece avergonzarse de la idea de que el software no es apropiable y trata desesperadamente de evitarla hasta el punto de no mencionarla como el axioma central de las teorías sobre software libre de la mayor parte de la gente (en aquellos casos en que la tienen, por supuesto).
Esta idea surge de forma natural a partir de las mismas fuentes de liberalismo clásico y antropología que Eric invoca como inspiración de su artículo: la propiedad se justifica sobre recursos físicos escasos como la única forma de controlar de manera fiable uno de tales recursos sin introducir luchas permanentes entre la gente; pero el software, al ser un tipo particular de ideas, no tiene similitud alguna con los recursos: un número arbitrario de personas puede tener una idea sin privar a nadie de tenerla a la vez, y es la prohibición de actuar de acuerdo con una idea dada (con una copia mental particular de la misma) la que introduce los conflictos y la falta de libertad.
Esta justificación de que las ideas, la información, y el software no son apropiables apoya la aparición de un mercado en los servicios comerciales que tratan con ideas, información o software en tanto en cuanto tales servicios implican la utilización de recursos físicos. Tales servicios incluyen la búsqueda (no el hallazgo) de nueva información, la caza de errores, la mejora y puesta al día de la información existente, el soporte técnico, los cursos de formación que ayudan a manipular la información entregada, la entrega de harware físico o de medios de soporte de tal información, la garantía de disponibilidad, relevancia, y/o precisión de la información, asegurar frente a los riesgos relacionados con su uso, etc. No puedo sino incluir una referencia a mi propia página WEB (en francés) sobre software libre, y mi "Manifiesto de la información libre" (que se ha traducido parcialmente al inglés) para aquellos a los que interese una discusión más profunda de tales temas.
Con tales conceptos en mente se desvanecen todas las dificultades con que topa Eric en su artículo sobre la colonización.
En primer lugar, las divergencias entre las actitudes frente al software libre no son contradicciones, sino meras diferencias; cada cual tiene su actitud particular, que no necesariamente contradice la de ningún otro; del mismo modo en que cada programador escribe programas (es de suponer) diferentes a los de cualquier otro sin contradecirlos. Cuando se considera que el desarrollo y el uso del software libre requiere recursos humanos escasos en cuanto a tiempo de desarrolladores y usuarios, se puede caer en la tentación de considerar cada diferencia como una contradicción potencial. Sin embargo, esto no hace las diferencias relativas al software libre más contradictorias entre sí de lo que lo son las que aparecen con el software propietario; de hecho, mucho menos: el software libre no puede sino hacer aparecer las incompatibilidades esenciales entre programas que intentan captar los mismos recursos (de computación, humanos); mientras que el software propietario introduce también oposiciones entre monopolios que intentan excluirse mutuamente con barreras artificiales consistentes en costes de utilización y desarrollo y la asuencia de las fuentes del programa.
En segundo lugar, Eric ve una contradicción entre la teórica proclama de libertad en las licencias del software libre, que permite que todo el mundo pueda modificar cualquier cosa, y la práctica gragaria por la cual los hackers siguen reglas estrictas de conducta al compartir el código. Pero no constituye mayor contradicción que el hecho de que en aquellos países en los que existe libertad de asociación los individuos no crean docenas de asociaciones con ellos como únicos miembros. La libertad es un asunto de derechos civiles. ¡El derecho a hacer algo dentro de unos límites dados no significa que todas las cosas que puedan realizarse dentro de ellos se lleve a la práctica!. Lo cual quiere decir que la gente ya tiene bastantes dificultades al tratar con las limitaciones naturales del mundo físico y social, y no desea sufrir la molestia adicional de artificiosas reglas humanas más allá de lo que definen los límites mutuos de libertad.
Los tabús que Eric señala pueden por tanto explicarse en función de las limitaciones humanas que afectan a las actividades relacionadas con la programación, de las que en su mayor parte ya hemos hablado: mientras los programas no son apropiables y nunca lo serán, el desarrollo de los programas, al igual que el trabajo relacionado con el software, como su nombre indica, implica un gasto de recursos, y aquellos hackers que vean sobrevivir a sus trabajos serán los que optimicen la utilización de recursos escasos.
La programación implica en primer lugar conocimiento y comprensión de los fines y medios de los programas, que pueden a su vez subdividirse en fines externos (observables por usuarios no programadores) e internos (perceptibles por programadores que mantienen, mejoran o simplemente modifican el programa). Tal conocimiento y comprensión no son por supuesto apropiables, y la libertad es el régimen bajo el cual serán maximizables. Pero adquirir y coordinar el conocimiento requiere el uso de canales de comunicación y el acuerdo sobre los protocolos a usar; y los canales de comunicación fiables de alta velocidad son un recurso escaso.
La parte de costes de tecnología hardware está disminuyendo con rapidez, como pone de manifiesto la aparición de Internet, que ya ha jugado de hecho un papel importante en la difusión de la información que ha hecho posible la cultura del software libre; este coste hardware de la comunicación ha sido siempre una preocupación crucial antes o fuera de Internet; e incluso en ella, la parte WWW, a pesar de sus limitaciones, ha jugado un papel importante en la dramática reducción del coste tecnológico relacionado con la creación de centros de difusión identificables con fiabilidad. Por supuesto, la predominancia de los costes tecnológicos en la difusión de información útil fuera de Internet ha ayudado a ocultar el coste de la apropiación de dicha información más allá del ocasionado por su difusión, de modo que los monopolios de la información se establecieron sin que el público se preocupara o incluso se diera cuenta de tal hecho, y sin que se considerara su (temible) impacto sobre el avance tecnológico.
Pero con Internet, el coste de distribuir software se ha aproximado a cero, y el coste predominante en la difusión es el factor humano. Ya que los humanos disponen de un tiempo limitado para leer y escribir información; necesitan referencias que los guíen en el océano de la información disponible; necesitan referencias sobre su distribución, sobre las que puedan descargar su preocupación de encontrar información fiable; necesitan centros de contacto para intercambiarla, en los que puedan confiar para obtener información útil, y tomar en consideración las posibles respuestas. Una densa red de tales puntos de contacto, en la que los programadores puedan intercambiar sus contribuciones, es lo que se denomina un proyecto de programación. Un proyecto tiene una existencia bastante física, lo que se opone a los meros objetos de programación que son ante todo información inmaterial. Un proyecto dado puede lanzar (con mayor o menor regularidad) objetos, pero no debe identificarse con ellos; tales objetos lanzados pueden olvidarse, compartirse por millones de unidades, o reutilizarse de manera divergente por diferentes proyectos aislados en el tiempo y el espacio del proyecto original que los produjo.
Los objetos de software no son jamás asimilables con la propiedad, independientemente de lo que uno lo intente. Las ideas no pueden poseerese. La propiedad de algo es natural cuando, y sólo entonces, algo tiene la propiedad intrínseca de la mutua exclusión. Que es el caso de los objetos físicos y los servicios, pero no de las ideas. Por otra parte, los proyectos de software son tan apropiables como cualquier bien físico; tienen una identidad en el mundo físico, independientemente de las partes de la noosfera que ya hayan sido exploradas o que se pretendan explorar más adelante; consumen recursos físicos (el trabajo de los hackers).
El aspecto principal no percibido por Eric en su artículo sobre la colonización es por tanto que la combinación de interés y fama que yace en un proyecto, lo que hace que la gente invierta su tiempo de programación, lo que él llama su promesa, constituye el bien escaso que interesa a los que desarrollan software libre.
Como ejemplo de que los proyectos de software libre generan recursos y valor por sí mismos, sin necesidad de recurrir al uso artificial de la apropiación del software, podemos echar un vistazo a RedHat software, que sólo escribe software libre (todas las versiones de redhat, que son software, son libres) y sin embargo vende un número de copias suficiente de su Official RedHat CD como para prosperar, ya que incluyen el interés, el empuje y la fama que constituye la esencia del proyecto RedHat, identificado en su marca comercial.
De hecho, si en el artículo de Eric sustituimos cualquier referencia a la propiedad de programas por referencias a la propiedad de proyectos (el mismo Eric usa en ocasiones esta expresión más adecuada), el resultado es casi totalmente correcto. En consecuencia, no puede decirse que los programadores colonicen la noosfera, la esfera de los programas, ya que es falso; los programas son algo inmaterial y no es posible mediante esfuerzo colonizador alguno u otra actividad cualquiera traspasar una "mágica" frontera y crear una propiedad en la noosfera. En su lugar los programadores colonizan una "imagen de la noosfera", la esfera de los proyectos de programación, que constituyen exploraciones físicas de la noosfera inmaterial (lo que da a la publicación de las "páginas principales" de un proyecto un valor de ocupación del territorio más que metafórico). Lo siento por la autoestima de Eric al haber encontrado otro eslogan de dos palabras de lo más aparente: "colonizando la noosfera". Pero la corrección de las ideas es más importante que los eslógans de impacto, y estoy seguro de que es también capaz de encontrar un buen eslogan que refleje las ideas correctas en lugar de las erróneas.
Tras corregir esta confusión, todo lo demás en el artículo de Eric resulta una consecuencia inmediata de las consideraciones anteriores, y las dificultades desaparecen. La gente puede poseer y de hecho posee proyectos que son más o menos prometedores; y la dinámica de su posesión es esa cosa fluida que Eric describe con precisión, pues la teoría de la colonización se aplica perfectamente a los proyectos en el campo del software.
Un proyecto no se bifurca de forma arbitraria ya que la división implica una división de su capital, de su "promesa", en varias partes, lo que significa un menor retorno a la inversión en programación a menos que existan otras causas (tales como el reagrupamiento de otros proyectos distintos, o la desaparición de un desacuerdo interno importante) que hagan que uno de los proyectos resultantes aumente su atractivo por encima del que tenía el proyecto original. Aunque puedan limitarse los perjuicios ocasionados por una bifurcación del proyecto a base de compartir código entre las partes resultantes, existen costes proporcionales al grado de divergencia de los proyectos (lo que justifica la ruptura), por lo cual lo anterior es tan sólo un atenuante .
El simple hecho de que los proyectos puedan bifurcarse prueba que no pertenecen a la noosfera, ya que la bifurcación resulta un concepto escasamente aplicable a ideas platónicas inmutables. Los dos (o más) proyectos resultantes de una bifurcación parten de los mismos programas en la misma posición de la noosfera, lo que resulta incompatible con la posesión de los programas que una vez más requiere la idea de exclusión mutua; pero que es sin mebargo compatible con la idea de possión de proyectos que exploran la noosfera, si bien con recursos diferentes y una historia pasada y/o futura asimismo distinta.
Respecto a lo que Eric considera el segundo "tabú" del software libre, la oposición a realizar modificaciones fuera de la coordinación reconocida en un proyecto, puede considerarse un simple corolario del anterior, pues todo aquel que realiza modificaciones de este tipo actúa como lo haría dentro de su propia bifurcación del proyecto, aunque unos pocos parches no oficiales puedan ser incorporados (eventualmente) a las fuentes del proyecto oficial.
Podemos por tanto cuestionar que el software libre implique una economía basada en el regalo. Para empezar, la misma noción de "regalo" es confusa cuando se aplica al software tal como hace Eric en su artículo, por cuanto el software no es poseíble, pero resulta completamente significativa si la aplicamos a los proyectos y al tiempo de programación. Por tanto, podemos ver que de hecho mucho del software libre que se escribe y distribuye actualmente se realiza durante el "abundante tiempo libre" de los hackers que de esta forma regalan un tiempo de programación precioso sin recibir a cambio una compensación monetaria. Es decir que sí, que puede ser cierto que el el software libre actual sea principalmente una cultura basada en la donación. Pero en ese caso el acaparamiento del software, al desplazar los ingresos desde los desarrolladores a los monopolizadores, del trabajo legítimo a la rapiña, distorsiona completamente el mundo del software: el capital se orienta hacia privilegios económicos artificiales y se emplea en imponer o utilizar leyes injustas, en lugar de invertirse en actividades útiles. Como resultado, los programadores capaces que se dedican al software libre no obtienen un reconocimiento de tipo económico, y el desarrollo de la mayor parte del software libre (o abierto) debe realizarse de forma gratuita, lo que explica porqué los hackers que se mueven en el mundo del software libre se ven forzados, quiéranlo o no, a la donación de sus obras: la razón no es otra que los mecanismos de apropiación los excluyen casi totalmente de la economía predominante en el mundo del software. La gente que participa en el desarrollo de software libre puede en cierta medida involucrarse en una "cultura del regalo", algo que no se opone a una cultura de la competición; pero las reglas del juego han sido cambiadas y la competición se desarrolla entre recursos disponibles pero escasos, no entre recursos que son o bien inalcanzables o abundantes. En caso de que la ley se corrigiera y dejara de apoyar la apropiación del software al reconocer la artificialidad de la "posesión" en la noosfera, creo que el desarrollo del software así liberado llevaría a un floreciente mercado libre de los servicios relacionados con el software que tendría poco que ver, para bien o para mal, con una economía del regalo.
El fenómeno con el que cabe comparar de forma adecuada el desarrollo del software libre es la investigación científica teórica. De hecho, ambos proceden del mismo fenómeno general: la creación sistemática de nueva información. Y comparten un mismo origen histórico, ya que el mundo del software libre nació en universidades conectadas a través de Internet y fue creado por estudiantes y profesores en ciencias de la computación, matemáticas, física, química, y demás. En tales campos, la gente explora un espacio compuesto por objetos de información puros, que no pueden ser poseidos, aunque se pelee por la fama y por atraer el interés de otras personas a un campo de trabajo particular, de forma que los problemas que nos afectan puedan ser resueltos o puedan captarse fondos adicionales. Todo lo que digamos sobre la cultura del software libre es aplicable asimismo a la ciencia teórica y viceversa.
La comparación resulta perfecta en lo que concierne a la evaluación por iguales: ésta es la única forma aceptada de juzgar la calidad tanto en ciencia como en el software. De hecho, llegaría hasta extender la afirmación anterior a cualquier intercambio de información: es el juicio entre iguales el que asegura la mejor calidad de cualquier información, ya sea científica, técnica, financiera, o relacionada con cualquier aspecto de la vida, incluyendo los asuntos más comunes del día a día. Es éste mecanismo el que establece los precios en un mercado libre, en función de la información disponible. Y es por esto por lo cual la libertad de información resulta esencial para mantener el equilibrio en una economía de mercado, y por lo que la revisión entre iguales debería extenderse a todos los campos del conocimiento, para lo que sería necesaria la abolición de los privilegios actuales relacionados con la información, ya sean secretos, patentes, acuerdos de no difusión, o derechos de propiedad intelectual y de copia. Sin embargo, en aras de la brevedad, me centraré tan sólo en este artículo en el tema del software.
La noción de que el reconocimiento de la autoría debe ser respetado, de que se conserve la pista de cómo se creó la información, que constituye el tercer "tabú" del software libre percibido por Eric, está también presente en Ciencia. En primer lugar, tal seguimiento resulta sumamente útil cuando se investiga en campos que analizan procesos históricos, o se exploran temas relacionados entre sí. Y, de manera más prosaica, es necesario para asegurar un reconocimiento adecuado a los autores, de modo que sean ellos los que logren la fama o la vergüenza asociada a su trabajo, y se dediquen inversiones adicionales a proyectos que lo merezcan (que los proyectos que tienen reconocida una "promesa" dada se beneficien de recursos adicionales proporcionales a su mérito). Aquellos que borran tales huellas, que no les costaría nada mantener, causan a otros las molestias derivadas de la privación de una información útil, o les obligan a gastar recursos valiosos en su reconstrucción, a la vez que minan el proceso de la evaluación entre iguales. Tal actitud puede por tanto asimilarse al vandalismo gratuito o al robo cuando se realiza por interés; y es por lo que la costumbre lo desaprueba con firmeza y por lo que quizá debería ser incluso punible por ley.
No tengo más objeciones importantes al resto de los artículos de Eric S. Raymond. Terminaré diciendo que todas las confusiones y parcialidades que aparecen en sus artículos son típicos de su elección de la "política real" como principio de actuación en su activismo en pro del software libre. Un ejemplo de esta elección es haber cambiado con efectos retroactivos en sus artículos y conferencias el término "software libre" por "software abierto". No discrepo de la noción de ser eficaz promoviendo el software libre. Pero me opongo a acciones que pueden resultar atajos válidos a corto plazo y causar perjuicios a la larga, ya que en estos casos, en la búsqueda de un éxito puntual, se opta por apoyar fenómenos esencialmente erróneos en lugar de combatirlos.
Las leyes actuales han creado la noción artificial de "propiedad intelectual", y han hecho uso de ella como único modo de defender la necesaria validación de la información en un sistema de revisión por iguales. Estas leyes han corrompido completamente las instituciones económicas, ya que muchas corporaciones dependen de un modo crucial del monopolio de la información, también en el origen de grandes fortunas, más que de ser pagadas a cambio de la prestación de servicios reales. No deben realizarse compromisos con estas leyes, y debe lucharse contra su justificación, habitualmente errónea. Este es el principio fundamental de la filosofía del software libre. Lo menos que Eric podría hacer es evitar tales justificaciones, en lugar de apoyarlas. Es difícil luchar contra prejuicios que sirven para justificar enormes intereses financieros, por supuesto. Hace falta ser muy estricto precisamente porque la tearea es muy dura.
Faré . François-René Rideau