Aviso: Si quieres contribuir y no estás aún registrado, por favor, crea una cuenta. Si ya estás registrado y deseas seguir contribuyendo, podrás hacerlo si has confirmado tu dirección de correo; por favor, accede con tu usuario y contraseña y ve a Especial:Preferencias. Si lo haces, todas tus ediciones serán atribuidas a tu nombre de usuario, además de disponer de otras ventajas. Muchísimas gracias por tu colaboración.
Warning: If you want to collaborate and you are not joined the Epistemowikia yet, please do not hesitate to create an account. If you are already a registered user and you wish to continue sharing your knowledge, you may, provided that you confirm your email, do it; please, log in with your username and password and browse to Special:Preferences. If you do this, your edits will be attributed to your username, along with other benefits. Thank you very much for your collaboration.

Epistemowikia
Revista hiperenciclopédica libre y abierta
Tercera Época, Año XII
Vol. 11, Núm. 1: de enero a marzo de 2017
Epistemowikia es parte de
Logotipo de CALA Virtual
CALAALA | Communitas | Evolvere
Editio | Epistemowikia | Exercitatio | Fictor | Flor

Inicio | La revista | Índex | Hemeroteca | Búsquedas | Publica

Software Libre desde la Teoría de Juegos

De Epistemowikia
Saltar a navegación, buscar

Creado por


   Asignatura: Lógica y computabilidad (Universidad de Extremadura) 
   Nombre del grupo: Software Libre desde la Teoría de Juegos
   Curso: 09/10
   Integrante del grupo:  Ángel Vivas Vivas

Resumen

Mediante el presente documento se pretende realizar un estudio del software libre desde el punto de vista de la teoría de juegos. Ya hay varios documentos e informes al respecto que explican de una forma muy clara y concisa cómo funciona el software libre visto desde esta perspectiva, pero la intención de este trabajo es ahondar en la profundizar en el tema y plantear varias dudas al respecto, sobretodo en la temática más próxima a la lógica y a la computabilidad.

Concretando, la teoría de juegos tiene una amplia relación con la computabilidad, de hecho explica cómo influyen la colaboración y el egoísmo en los resultados obtenidos en algunos procesos, que generalmente reciben el nombre de juegos. Esto, a día de hoy es aplicable a cuestiones como el paralelismo, donde el hecho de que varios procesos e hilos colaboren entre sí, da lugar a que el rendimiento de una aplicación se incremente notablemente[1]. El comportamiento de los jugadores, por lo contrario, se podría asociar con la lógica, y más concretamente con la psicología cognitiva.

El por qué de usar el software libre como objeto de estudio es puro interés personal. Me interesa el software libre debido a que me parece que aporta cosas muy interesantes a la sociedad -tanto desde el punto de vista social, como desde el técnico-, y creo interesante aportar algunas conclusiones y/o reflexiones desde mi humilde punto de vista.

A la hora de realizar el presente trabajo se ha partido de la consideración de que ha existen otros trabajos sobre la misma materia, y se ha tratado de averiguar cuáles fueron los puntos débiles de dichos trabajos según las diferentes evaluaciones que dieron los compañeros para ver qué se podía mejorar, y qué aspectos son mejorables.

Introducción

Uno de los aspectos mejorables era que se hablaba de muchos conceptos sin definirlos de forma clara, y que podría haber gente que no conociese dichos conceptos, así que una de las mejoras que he decidido añadir es una introducción dónde se definen de forma sencilla los conceptos más importantes y que puede que no sean conocidos por el lector.

Entre dichos conceptos, los más importantes son Software Libre, Teoría de Juegos, Licencias tipo GPL y BSD, y los tipos de desarrollo Bazar y Catedral.

Posteriormente pasaremos a ampliar el análisis que se realizó en varios estudios, entre ellos otro TFA de la asignatura, aunque ya se habrán ido entrelazando y dejando ver la relación entre ambos campos y cómo influye la actitud de los participantes.

Por último, se finalizará con algunas conclusiones sobre el trabajo, y cómo he tratado de aplicar algunos de los principios del software libre en mi propio trabajo.

Software Libre.

El software libre es básicamente aquel que ofrece a sus usuarios la posibilidad de ser usado para cualquier propósito, estudiarlo, modificarlo y distribuir tanto la versión original como las modificaciones.

En general, esto se suele definir como las cuatro libertades, que pasarán a exponerse:

Las cuatro libertades.

Libertad Significado
0 Usar el programa con cualquier propósito.
1 Estudiar cómo funciona y adaptarlo a las propias necesidades.
2 Distribuir copias.
3 Realizar mejoras y hacerlas públicas a la comunidad.

Además, dependiendo de la visión personal de muchos de los involucrados en estos movimientos, la definición de libertad puede variar, y a partir de ahí surgen dos conceptos y/o comunidades alrededor de los cuales se vertebra toda la comunidad. Hablamos de Software Libre, que es defendido por la Free Software Foundation, y de Open Source -la traducción al castellano por algunos de sus defensores es Software de Fuentes Abiertas- que es defendido por la Open Source Initiative.

Software libre (FSF) vs Open Source (OSI)

Partiendo de dos definiciones oficiales procuraré aclararlo haciéndolas un tanto más relajadas -para que puedan ser entendidas por personas no iniciadas en la materia-. Las definiciones originales se pueden encontrar en:

  1. Definición de Software Libre
  2. Definición de Open Source

Se podría decir que aunque teniendo una base común, y muchos de sus principios son (casi-)iguales, las principales diferencias surgen dependiendo de si se entiende la libertad desde el punto de vista del software, o desde el punto de vista de los hackers/hacktivistas.

La visión de la FSF: El software ha de seguir siendo libre.

La Free Software Fundation es una asociación que promueve la defensa del software libre, y fue creada en otoño de 1985 por Richard M. Stallman. Aunque actualmente están enfocando sus esfuerzos en la defensa jurídica y en el “márketing”, entre sus primeros objetivos estaban la creación del Sistema Operativo GNU, que actualmente en conjunción con el kernel Linux es bastante popular en este entorno, y aún hay gente trabajando en el kernel Hurd

Para la FSF, el software es libre cuándo las modificaciones que se hacen sobre el software se siguen distribuyendo al menos igual de libres. Generalmente se suele solicitar que las versiones modificadas se difundan con la misma licencia, de ahí que se diga que las licencias son virales.

Es decir, el enfoque planteado por el concepto de software libre es siempre la libertad del software, y respetar la licencia que ha decidido usar el creador original.

La visión de la OSI: El hacker ha de tener derecho a elegir qué hacer con el software.

Sin embargo, para unos cuantos hackers, muchas empresas no se decidían a involucrarse en el movimiento del software libre por la confusión a la que el término “free” puede dar lugar. Significa tanto libre como gratuito. De ahí, que Richard Stallman suela decir “free as in freedom” (libre como en libertad) contraponiéndolo con “free as a free beer” (gratis como en una cerveza gratis).

Algunos de ellos, decidieron tener una reunión para ver cómo reaccionar teniendo en cuenta que el navegador Netscape había decidido adoptar el modelo bazar en 1998 -por aquel entonces era líder tecnológico en la guerra de navegadores-, y estimaron que era un momento estratégico y querían orientarlo de forma que pudiese ser mejor introducido en el mercado, y que no tuviese tanta carga político-social, que en cierto modo asustaba a las empresas.

En aquella reunión, entre otros se encontraban Eric S. Raymond -conocido hacker, y presidente de la OSI hasta 2005-, John Maddog Hall -de Linux International- ó Bruce Perens -por aquel entonces DPL, líder del proyecto Debian-.

Según ellos, la libertad debe recaer en el lado del usuario, y si el decide realizar una modificación y licenciarla bajo otro tipo de licencia, aunque ésta sea más restrictiva, no debería existir ningún problema para ello.

Conclusiones

Para finalizar una definición básica, pondré enlaces a varios artículos que pueden ayudarnos a comprender mejor las diferencias, y están escritos por auténticas autoridades en estos temas.

  1. Por qué el código abierto pierde el punto de vista del software libre de Richard Stallman.
  2. Live and let license de Joe Barr.
  3. Diferencias entre las licencias BSD y la GPL de Pablo Usano. Pablo Usano era abogado y hacktivista de la FSF.

La Catedral y el Bazar

Otra de las cosas que se hablaba en el anterior trabajo era la diferencia entre los modelos de desarrollo tipo catedral y tipo bazar. Dichos conceptos se deben a la obra del hacker Eric S. Raymond. Por si el lector se siente interesado, también está disponible su página personal.

Sólo he podido acceder a una traducción de su obra por José Soto Pérez, que no parece ser realmente la obra entera, sino un resumen de la misma en castellano dónde resumen los conceptos más importantes, pues obra parece contar con más de 200 páginas y la versión en castellano no llega a 100.

Aún así, para lo que se pretende es más que suficiente. Además, ha sido también bastante interesante encontrar en Biblioweb de SinDominio una crítica a la misma por François-René Ridau.

En dicha obra Eric realiza una analogía entre el método de construcción de software privativo y la construcción de la mayor parte de las catedrales orientales, por un lado. Esto se debe a que está realizado por un grupo muy selecto de gurús. Dicho grupo suele ser muy pequeño y bastante escogido. En dichos procesos, no suele ser conveniente agregar personal, si el proyecto se encuentra bastante avanzado, pues más que reducir el tiempo restante de desarrollo, el resultado más probable es que lo aumente.

El equipo de desarrollo suele tener una estructura piramidal bastante notable y la persona encargada de la gestión de dicho equipo debe tener nociones bastante importantes y consolidadas tanto de análisis como de diseño de software, pues generalmente a los desarrolladores únicamente se les proporcionará un listado de funciones a desarrollar y su especificación.

Para evitar que en caso de que haya errores sean visibles a los potenciales clientes, se liberan pocas versiones -casi nunca su código-, y cuando ya están en un estado muy avanzado. Los errores, se depuran al final del ciclo de desarrollo, y suelen ser bastante difíciles de encontrar.

Por otro lado, realiza otra analogía entre una gran parte del proceso de desarrollo de gran parte de los proyectos de software libre y el funcionamiento de los bazares orientales. En estos proyectos, no existe una organización tan clara como ocurre en los de tipo catedral. Más que una arquitectura ran piramidal, nos encontramos ante una estructura mucho más plana. Además, debido a la gran expansión de internet, se suele dar el caso de que gran parte de los grupos de desarrollo suelen estar distribuidos.

Se decía en el anterior caso que si se agregaban personas a un proyecto de software, se podía ralentizar el proyecto, por lo que no se suelen incorporar personas una vez iniciado éste. Sin embargo, en los modelos de tipo bazar es mucho más difícil definir y tener clara la duración y dedicación de una persona en el desarrollo de software.

Suele darse el caso de que en cuanto se puede liberar una versión se libera. Es más, existen proyectos como Debian donde nos encontramos con tres ramas diferentes: estable, en pruebas e inestable. Dónde nos encontramos con diferentes versiones del software dependiendo de las pruebas que hayan pasado, y de su integración en el mismo.

Al liberar cuanto antes, y al haber más personas, se suelen encontrar antes los errores. Es mucho más difícil que un error se propague durante mucho tiempo en el ciclo de desarrollo. Generalmente, cuantas más personas haya en un proyecto de este tipo mejor, pues más fácil será encontrar errores. Este de debe en gran medida, a que el código es abierto y/o libre, y cualquiera puede leerlo.

Generalmente los proyectos de software/conocimiento libre están asociados a la metodología de los bazares, y los proyectos de software privativo a la metodología de construcción de las catedrales medievales.

Algunas conclusiones sobre el modelo de desarrollo

Según Eric Raymond, las conclusiones positivas que extrajo del modelo bazar son[2]:

  1. Todo trabajo de software comienza a partir de las necesidades personales del programador. No es lo mismo trabajar para un proyecto a cambio de un salario que trabajar gratis en algo en lo que se encuentra una satisfacción personal o se cubre una necesidad. Lo segundo motiva más.
  2. Los buenos programadores saben que escribir. Los mejores que reescribir (y reutilizar). Es más fácil partir de una solución aunque sea incompleta y mala que de cero. Linus lo que hizo no fue construir un sistema operativo desde la primera línea de código hasta el final (probablemente aún estaría en ello), en lugar de eso, tomó como punto de partida Minix. Por tanto, una forma de iniciar un proyecto puede ser buscar un proyecto similar ya hecho y tomarlo como guía.
  3. Contemple desecharlo, de todas formas tendrá que hacerlo. Al final todo el código de Minix fue reemplazado, pero mientras existió fue un armazón a partir del cual pudo ir cambiando partes. El código de partida no es importante, de hecho seguro que tiene un montón de errores y no es adecuado a nuestras necesidades, solo sirve para comprender el problema.
  4. Si tienes la actitud adecuada, encontrarás problemas interesantes.
  5. Cuando se pierde el interés en un programa, el último deber es dejarlo en herencia a un sucesor competente.
  6. Tratar a los usuarios como colaboradores es la forma más apropiada de mejorar el código, y la más efectiva de depurarlo.
  7. Publique rápido y a menudo, y escuche a sus clientes.
  8. Dada una base suficiente de desarrolladores asistentes y beta-testers, casi cualquier problema puede ser caracterizado rápidamente, y su solución ser obvia al menos para alguien.
  9. Las estructuras de datos inteligentes y el código burdo funcionan mucho mejor que en el caso inverso.
  10. Si usted trata a sus analistas (beta-testers) como si fueran su recurso más valioso, ellos le responderán convirtiéndose en su recurso más valioso.
  11. Lo más grande después de tener buenas ideas es reconocer las buenas ideas de sus usuarios. Esto último es a veces lo mejor.
  12. Frecuentemente, las soluciones más innovadoras y espectaculares provienen de comprender que la concepción del problema era errónea.
  13. La perfección (en diseño) se alcanza no cuando ya no hay nada que agregar, sino cuando ya no hay algo que quitar.
  14. Toda herramienta es útil empleándose de la forma prevista, pero una ``gran herramienta es la que se presta a ser utilizada de la manera menos esperada.
  15. Cuando se escribe software para una puerta de enlace de cualquier tipo, hay que tomar la precaución de alterar el flujo de datos lo menos posible, y nunca eliminar información a menos que los receptores obliguen a hacerlo.
  16. Cuando su lenguaje esté lejos de uno Turing-completo, entonces las “ayudas” sintácticas pueden ser su mejor amigo.
  17. Un sistema de seguridad es tan seguro como secreto. Cuídese de los secretos a medias.
  18. Para resolver un problema interesante, comience por encontrar un problema que le resulte interesante.

Teoría de Juegos

La teoría de juegos es un rama de las matemáticas que se encarga de estudiar cómo las políticas de colaboración o egoísmo influyen en el rendimiento obtenido en algunos procesos o situaciones, que son conocidos como juegos.

Podríamos resumirlo con que, estudia la elección de la conducta óptima cuando los costes y los beneficios de cada opción no están fijados de antemano, sino que dependen de las elecciones de otros individuos, y tiene una base muy fuerte de probabilidad, estadística y programación lineal.

El primer estudio de dichos juegos fue realizado por John von Neumann(Biografía I,Biografía II) y Oskar Morgenstern (Biografía I, Biografía II) durante la década de los 40, y que dió lugar a la publicación del libro “Theory of Games and Economic Behavior”.

En su momento, se pensó como una herramienta que fuese útil para estudiar la economía, pero a día de hoy es ampliamente utilizada en otros muchos campos, entre los que podemos citar ciencias políticas, estrategia militar, ética, filosofía, inteligencia artificial o cibernética.

Juegos de suma cero y de suma no cero.

La clasificación de los juegos que más nos interesa para nuestro caso es entre juegos de suma cero y juegos de suma no cero, ya que es la forma más cercana y similar a como se ven el mundo de los negocios en la industria del software.

Podemos definir como juegos de suma cero aquellos en los que para que uno de los participantes obtenga algún tipo de beneficio, el otro ha de perder. Pensemos, por ejemplo, en la partición de un delicioso postre. Para que uno de los comensales se coma más de la mitad del postre, el otro ha de comerse menos, por lo tanto saldría perdiendo. Ejemplos de ello, son el go, el ajedrez o el poker.

Por contra, los juegos de suma no cero, son aquellos en los que puede ocurrir que alguno de los participantes salga beneficiado, y el otro no tiene por qué salir perjudicado. Es más, incluso pueden salir todos los participantes beneficiados. El ejemplo más claro de este tipo de juegos es el dilema del prisionero.

Profundizando.

Si deseamos estudiar un poco más sobre teoría de juegos podemos consultar algunos de los siguientes enlaces:

  1. Teoría de Juegos
  2. Introducción a la teoría de juegos (Manual básico de economía)
  3. Introducción a la teoría de juegos (Blog de Raúl Bajo)

Análisis del software libre desde la teoría de juegos.

Existen excelentes documentos estudiando el software libre desde la perspectiva de la teoría de juegos, y creo conveniente, tal y cómo decía Eric S. Raymond, que lo interesante no es saber qué escribir, sino qué reutilizar.

Algunos de los documentos más importantes, completos e interesantes que he encontrado han sido los que paso a enumerar a continuación:

  1. Software libre: Una aproximación desde la teoría de juegos. (Juan Antonio Martínez)
  2. Análisis del Software Libre mediante la teoría de Juegos. (David Domínguez Martín y Carlos Aguado Fuentes).
  3. Cooperación sin mando: una introducción al software libre. (Miquel Vidal).

Ahora, lo interesante sería estudiar los distintos tipos de estrategias que se pueden producir, y cómo se pueden dar dentro del Software Libre. Debido a ello, se explicará cómo influyen en la comunidad del software libre dichas estrategias.

Egoísta

Generalmente una persona que defrauda siempre, no suele obtener durante mucho tiempo el respaldo de la comunidad, y al final suelen ser apartadas o se les hace el vacío. No son pocas las compañías que son duramente criticadas por su actitud “parasitaria” ante la comunidad.

Un ejemplo bastante claro son los comentarios que profieren algunos geeks hacia algunas distribuciones que son derivadas de otras y no aportan nada a la original, o hacia sistemas operativos que incluyen código con licencia BSD, aún cuando es algo legítimo.

Altruista

Es la actitud más valorada en la comunidad. En este caso, suelen ser hackers o compañías con un gran apoyo por parte de la comunidad. Suele darse el caso de que suelen tener una gran cantidad de feedback, y suele ser fácil que más personas se le unan.

Uno de los mayores problemas que se le achacan es que esta actitud al final suele ser utilizada por otras personas sin ningún tipo de escrúpulos, aprovechándose de ellas, y gran parte de las personas involucradas suelen sufrir burn-out. Puede estar propiciado por licencias tipo BSD en las que se permite que otras personas utilicen software licenciado como libre, en proyectos de software privativo sin aportar nada a la comunidad.

Tit for tat

Es una de las actitudes más comunes y lógicas. Las personas empiezan colaborando, y en función de la respuesta que obtengan suelen actuar a posteriori. Suele ser también conocido como ojo por ojo.

En cuestión de rendimiento y eficiencia suele ser la mejor valorada. En general suele ser conocida como una actitud amable, ya que nunca suele ser la primera en defraudar. Debido a ello, suele ocurrirle como a la actitud altruista, que genera mucho feedback, y suele ser de las que más colaboradores acaba teniendo.

Aplicándo los principios del SL al presente documento.

Quizá de las cosas más interesantes a nivel extra-académico ha sido aprender cómo compartiendo el conocimiento se puede llegar mucho más lejos. Entre otras cosas, porque este TFA pretende seguir la línea ya planteada por otro anterior, y eso me permite ser capaz de ver algo más allá.

Si he visto más lejos que otros hombres es por que me he aupado a hombros de gigantes.

Sir Isaac Newton

  1. Existen casos en los que al contrario de lo que se pudiera pensar, emplear hilos reduce el rendimiento de una aplicación. Cómo no es la temática del presente estudio, solamente se mencionará que el lenguaje de programación Python emplea un mecanismo denominado GIL, que entorpece el paralelismo. Si le interesa el tema puede consultar Understanding the Python GIL de David Beazley
  2. Conclusiones extraídas del libro de Eric S. Raymond: La Catedral y el Bazar

Licencia

Heckert GNU white.png
Esta obra está publicada con la licencia Licencia de Documentación Libre de GNU 1.2 (GNU FDL 1.2), sin secciones invariantes, sin textos en portada ni contraportada.
Puedes consultar una traducción no oficial aquí.
Los autores de esta obra están de acuerdo en su relicenciamiento a: «GNU FDL 1.3, o posterior».