días ha surgido un interesante debate sobre la naturaleza de la producción de software libre que confronta dos modelos: uno basado en amateurs y profesionales que donan su tiempo libre a proyectos de software libre, y otro en que son las contribuciones de programadores pagados por empresas para este fin se convierten en el núcleo fundamental de estos proyectos. Siendo interesante el debate creo que simplifica excesivamente la cuestión al pasar por alto algunas importantes cuestiones:
- Confundir la creación de “conocimiento abstracto”, como hacen muchas redes propias de la web 2.0 (desde la Wikipedia hasta la propia blogosfera), con “conocimiento operativo”, que genera un producto que debe constituir un todo funcional (como es el caso del software libre). Pero, al contrario de lo que pudiese parecer lógico, es en el caso del conocimiento operativo en él que las comunidades sin ánimo de lucro funcionan mejor, como veremos más adelante.
- Olvidar la coevolución de programadores sin ánimo de lucro y empresas. El fenómeno del software libre es muy reciente y en contínua evolución. Por tanto ambas visiones no son incompatibles, si no más bien ambas son correctas y han marcado diferentes etapas en el desarrollo de las comunidades y del propio software. Si inicialmente, los grupos de programadores trabajaban en su inmensa mayoría al margen de las empresas de software, éstas (como consecuencia del éxito de los productos nacidos al margen del mundo corporativo) se incorporaron paulatinamente a las comunidades aportando tiempo de programación o, directamente, financiación. Este ha sido un proceso distribuido con innumerables proyectos lanzados de los que solo unos pocos han acabado en productos finales operativos (y exitosos). De este modo, el modelo abierto ha permitido un proceso de ensayo y error a una escala antes desconocida que se ha constituido en el motor de la intensa innovación que se ha generado (otro ejemplo de la destrucción creativa).
- Así llegamos a un ecosistema de modelos organizativos extremadamente flexible. No sólo entran en juego individuos sin ánimo de lucro y empresas; existen toda una serie de capas intermedias ocupadas por boundary organizations (muchas de ellas fundaciones o similares) que juegan un papel clave. [El papel de estas organizaciones es analizado por Shioban O’Mahony en una serie de papers]. Esta flexibilidad ha dado lugar, por ejemplo, a híbridos tan interesantes y existosos como Ubuntu.
En síntesis, lo radicalmente importante del software libre sería la flexibilidad organizativa y las sinergias que se crean entre los diferentes actores. Tratar de identificar a los contribuidores más relevantes puede ser un ejercicio un tanto inútil o incluso perverso (si desvía la atención de las razones profundas del éxito). Así por ejemplo, posiblemente en muchos proyectos actuales las empresas juegan un papel muy relevante, pero dentro de un modelo organziativo y productivo consecuencia de las aportaciones de programadores independientes. De este modo, si quisieramos lanzar un nuevo proyecto replicando lo que observamos hoy en día en otros proyectos olividándonos de su contexto y evolución, estaríamos eligiendo un diseño organizativo erróeno.
Pero vamos a revisar los elementos del debate, que lanzó Chris Anderson con su post The awesome power of spare cycles. Un primer elemento a considerar es que no se refiere en realidad al software libre. Anderson reflexiona el poder de las multitudes ociosas que empiezan a participan en proyectos colaborativos en Internet propios de la web 2.0, como la propia blogosfera o la Wikipedia.
People wonder how Wikipedia magically arose from nothing, and how 50 million bloggers suddenly appeared, almost all of them writing for free. Who knew there was so much untapped energy all around us, just waiting for a catalyst to become productive? But of course there was. People are bored, and they'd rather not be…
Web 2.0 is such a phenomena because we're underused elsewhere. Bored at work, bored at home. We've got spare cycles and they're finally finding an outlet. Tap that and you've tapped an energy source that rivals anything in human history.
A Anderson le responde Scott Gilbertson en Compiler (uno de los blogs de la red de Wired). En Money, not spare cycles, drives open source plantea que la hipótesis de Anderson no es extensible al software libre, o al menos a los grandes proyectos:
While Anderson’s theory may explain smaller open source projects and web 2.0 sites like Flickr, big open source projects, like the Linux kernel, are built not by the mythical open source volunteer, but by paid programmers working for large corporations.
Para ello se basa en algunas evidencias que muestran como diferentes proyectos de software libre, y especialmente el núcleo de Linux, dependen a día de hoy de las aportaciones de código, parches y documentación de programadores de grandes compañías. Por otra parte también argumenta que, tal como sucede en la mayor parte de sitios y redes sociales, la proporción de usuarios activos que contribuyen a la red es muy baja (por ejemplo menos de un 2% escribe código en la comunidad de OpenSUSE).
Enrique Dans utiliza este debate para plantear El mito del programador en sus ratos libres y alinearse con Gilbertson, alabando las bondades de un modelo mixto que combina programadores contratados por sus empresas con otros que donan su esfuerzo sin ánimo de lucro, funcionando todos ellos bajo un modelo de código abierto. Pero al hacerlo reconoce el papel clave, a día de hoy, de las empresas. Un comentario de Victor Ruiz al post de Enrique matiza las evidencias de Scott Gilbertson utilizando datos de una encuesta del FLOSS Project que analiza otros proyectos además del del núcleo de Linux:
… el estudio de las contribuciones al núcleo de Linux es una buena aproximación pero me parece que extrapolarlo es tirarse al vacío y sin paracaídas. La Unión Europea sí que hizo una macroencuesta, el FLOSS Project donde podemos constatar datos más generales.
- El 86% de los encuestados tiene una carrera relacionada con las Tecnologías de la Información, y el 16% son estudiantes.
- El 65% de los contribuyentes de software libre son trabajadores y el 45% lo hacen por el amor al arte.
- Además, solo un 12% está en la comunidad de software libre para hacer dinero. Con estos datos en mano, dar por muerto el mito del programador en sus ratos libres no es algo cercano a la realidad.
- Concretamente, el estudio dice que el software libre es más bien un hobby «Although there is evidence of a strong professional background, for most of the developers in the sample developing Open Source / Free Software is rather a hobby than a profession». Solo el 14% de los encuestados le dedica entre 11 y 20 horas al desarrollo de software libre, un 9% entre 21 y 40 horas, y solo el 7% le dedica más de 40 horas semanales
Alfonso Romay constribuye a desmontar el mito de los Radicales libres:, pero introduciendo la perspectiva “evolutiva”:
Bienvenidos al siglo XXI, señores. Los radicales libres (sin segundas intenciones, disculpen) ya no son tan libres. Y es lógico y razonable que sea así, pues por mucho que la buena voluntad de muchos colaboradores ayude a mejorar estos proyectos, es necesaria cierta financiación económica para llevar adelante los proyectos.
Por otro lado, coincido con Dans en que puede ser incluso positivo, la eliminación de ese halo de heroismo techie alrededor del software libre y dotarlo de un carácter más profesional. Tomen la pastilla roja, y verán cómo es posible darle una visión empresarial aprovechando sus posibilidades.
Dado que buena parte de este debate nace de un post que no hablaba de software libre, puede que sea interesante tener en cuenta los análisis realizados sobre los sistemas de peer production de conocimiento abstracto y su comparación con los paradigmas del software libre (que en muchas ocasiones se han utilizado como prueba de su viabilidad). Esto es lo que hizo Paul Duguid en First Monday en Octubre de 2006 en su artículo Limits of self-organization: Peer production and “laws of quality”. Mediante un análisis de casos observados en Project Gutenberg, Gracenote o Wikipedia, llega a la conclusión de que los paradigmas del software libre (las leyes que garantizan su calidad) no son aplicables a estos otros proyectos. Las leyes de calidad se refieren a la capacidad de las multitudes para resolver problemas cuando trabajan bajo un sistema “darwiniano” (en el sentido de ser meritocrático y funcionar como un mercado, entendido éste en un sentido amplio):
In the spirit of constructive critique, I begin by suggesting that many claims about the quality of peer production rely on two notions generalized from software which I call the “laws” of quality. The writ of these laws may perhaps run within the bounds of software production; we should be cautious before assuming they run beyond…
Two ideas are often invoked, either directly or indirectly, to defend the quality of peer production. The first is “Linus’s Law” (Raymond, 1998). This holds that “given enough eyeballs, all bugs are shallow.” (The name is a tribute to Linus Torvalds, who initiated the Linux project). The idea that any problem is ultimately trivial comes from software development where, according to this law, the number of people contributing to a project provides a useful indication of its quality. Hence Linus’s Law neatly bridges the gap between the quantitative assessments the Internet facilitates and the qualitative judgments people tend to make …
The second implied law of quality comes from Paul Graham who claims that “The method of ensuring quality” in peer production is “Darwinian ... People just produce whatever they want; the good stuff spreads, and the bad gets ignored” (Graham, 2005).
Por otra parte, y esta puede ser la idea quizás más contra-intuitiva, una de las razones principales del éxito de los proyectos de software libre es que deben lograr un producto “funcionante” y por tanto de calidad homogénea y estrictamente coordinado en sus partes. Esta restricción hace que los proyectos de software se conciban como modulares y granulares (constituido por numerosas piezas casi autóonomas que son posteriormente ensambladas en el producto final). Pero, sólo aquellos proyectos que puedan hacerse suficientemente modulares y granulares son susceptibles de seguir el modelo del software libre:
… underlying parallel between projects like Wikipedia and Open Source software. As Benkler (2002) points out, Open Source projects are modular — made up of quasi–autonomous pieces on which people can work more or less independently. All being well, the compiler then gathers these together into a coherent program. But, as Benkler also notes, ideally these modules are granular, too. That is, these quasi–independent parts should be small. All three projects outlined here are modular to a degree. Gracenote is made up of tracks for individual albums; Project Gutenberg, of individual books; and, Wikipedia, of individual entries. Yet each has problems with granularity.
Esta restricción ha dado lugar a un modelo organizativo que unido al modelo open source ha acabado facilitando el desarrollo de productos de software de gran calidad. Con estos elementos Duguid, como ya hizo Steven Weber, propone un modelo de producción de software libre más complejo que una estructura horizontal totalmente auto-organizada. Estos proyectos operan en una doble dirección, con un componente bottom-up y otro top-down que introduce una cierta jerarquía en la coordinación y en el diseño de la “meta-estructura” del producto final:
My underlying argument is that the social processes of Open Source software production may transfer to other fields of peer production, but, with regard to quality, software production remains a special case. As Weber (2004) has argued, Open Source software development itself is not the self–organizing system it is sometimes imagined to be. Not only is it controlled from below by the chip on which code must run, but projects are also organized from above by developers and maintainers whose control and authority is important to the quality of the outcome. Thus, for software, Linus’s Law and Graham’s Law exist with other, significant constraints that do not necessarily obtain elsewhere. If we are to rely on peer production in multiple different spheres of information production, as Benkler (2006) suggests and I hope, we need to look for other ways to assure quality.
Por otra parte, el que los proyectos colaborativos de conocimiento abstracto no sigan las leyes de calidad del software no significan que no puedan ser exitosos, pero sus modelos organizativos no tienen por que (ni deben) diseñarse a imagen de las comunidades de software libre:
Having gone on so long, this is not the place for me to turn to the question of producing quality in any depth, but let me offer some suggestions in outline. First, protagonists of the sorts of peer production projects discussed here should reflect on the extent to which, explicitly or implicitly, they rely on the laws of quality. If they don’t, they should ask themselves what they do rely on. Second, projects should be mature enough now for participants to admit their limitations. Project Gutenberg and Wikipedia are tremendous achievements. That does not entitle them to a free pass. Both, because free, tend to get some of the condescending praise given a bake sale, where it’s deemed inappropriate to criticize the cakes that didn’t rise. Third, they should draw closer to their roots in Open Source software. Software projects do not generally let anyone contribute code at random. Many have an open process for bug submission, but most are wisely more cautious about code. Making a distinction between the two (diagnosis and cure) is important because it would suggest that defensive energies might be misplaced...
En resumen, 1) si existen razones por la que las comunidades de “programadores ociosos” podrían crear software de alta calidad y 2) por supuesto las empresas juegan hoy en día un papel clave como no podría ser de otro modo al jugar en un mercado en que entra un producto más eficaz y creado de un modo más eficiente que los suyos propios. Por eso, discrepo de este último comentario del post de Enrique:
El mito de “cómo confiar en un programa escrito por cualquiera en su tiempo libre” es algo que me encuentro de manera habitual en mis cursos y conferencias. Dotarlo, a nivel de conocimiento de calle, de una imagen de racionalidad económica, de materia de estudio en las escuelas de negocios, creo que es algo sumamente positivo.
Efectivamente, el software libre es racional desde el punto de vista económico, pero esto no se debe, en mi opinión, al “mito del programador ocioso”. Bien al contrario, son esos usuarios ociosos, y enormemente creativos, lo que han originado ese software que ya funcionaba antes de la entrada de las empresas. Las comunidades actuales (que ya incorporan empresas pero fuera de un modelo corporativo de innovación cerrada), enormente flexibles y adaptadas a las necesidades de los productos, son la mejor garantía de software más eficaz e innovador que el que pueda generar una empresa dentro de su sede corporativa. Lo mismo podríamos decir de las comunidades de “conocimiento abstracto” (pensemos en la Wikipedia respecto a la Britannica o las redes de blogs respecto a los medios tradicionales) siempre que no nos empeñemos en replicar las comunidades de software libre.
