El modelo de Linux frente al de OpenSolaris

Es una máxima bien conocida en política que se puede dejar al legislador dictar las leyes que quiera siempre y cuando le deje a uno escribir el reglamento de cómo aplicarlas.
Algo en esa línea describe Michael Dolan en su post Comparing “open source” projects? en el cual invita en primer lugar a pensar porqué existe el proyecto para entender su naturaleza. El argumento de Dolan es que un proyecto no sería libre si no existiese una justificación económica para ello. De modo que, aunque no la entendamos, tiene que haberla.
Es significativo también que Dolan emplee el término “open source” entre comillas, síntoma de lo gastado y distorsionado que empieza a estar en la mente de los usuarios.
Yo discrepo de la tesis principal de que si OpenSolaris es abierto debe ser necesariamente porque Sun obtiene un mayor beneficio con ello que si es privativo. Opino que Sun ha sido antaño una empresa ferozmente propietaria y que abrieron el fuente de OpenSolaris porque o lo abrían o moría.
No sólo son un puñado de programadores locos los que se han lanzado alegremente a escribir Software Libre sin tener un modelo de negocio. Algunas empresas (no todas) también se apuntaron al carro del Open Source con catastróficos resultados (sobre todo en los noventa).
En ocasiones un paradigma puede arrastrar a toda una industria hacia el éxito o hacia el desastre.
Dolan dice que dos contribuidores de OpenSolaris (Juergen Keil y Richard Lowe) suman el 40% de las contribuciones, y que en total hay menos de 100 contribuidores, la mayoria de ellos con aportaciones nimias como correcciones de errores tipográficos. Y compara esta cifra con la de miles de contribuidores al kernel de Linux.
El caso es que una licencia libre es condición necesaria pero no suficiente para crear una Comunidad. La licencia es como la ley, pero luego viene el reglamento, que, para que se forme una Comunidad requiere:
1º) El propietario del código debe estar dispuesto a perder al menos parte del control sobre su evolución. La Comunidad puede tener interesés en que el código evolucione por líneas diferentes a las que más convienen al propietario. Si no se permite cierta libertad a los contribuidores de la Comunidad, normalmente estos se enfadan y dejan de contribuir.
2º) La estructura interna del producto debe ser lo bastante modular como para que se puedan añadir extensiones en pequeños trozos.
3º) Debe existir un proceso de aprobación de contribuciones transparente, justo y eficiente. Si alguien contribuye una pieza de código y dicha contribución es ignorada o rechazada injustificadamente, tal persona no sólo no contribuirá nada más sino que, además, desanimará a otros y hará que tampoco contribuyan.
4º) El proyecto debe tener un buen grado de buzz y hype. La gran mayoría de los usuarios, incluídos los programadores, en realidad no tienen un criterio técnico muy fino para distinguir un producto de otro y simplemente tiran al bulto. La gente contribuirá más al producto más conocido, simplemente porque es el más conocido.
Artículo relacionado: Communities, Then Customers (Forrester on OpenSolaris) (Jhonathan Schwartz)
Post relacionado: Cómo mover a la gente a que participe.