La reciente decisión de Apple de liberar mediante licencia Apache uno de los principales componentes diferenciales de su sistema operativo Snow Leopard, recién salido al mercado, nos permite hablar de la gestión tecnológica en la era open source, uno de los temas que suele generar mejores discusiones en algunos de mis cursos.
La tecnología liberada, Grand Central Dispatch (GCD), permite gestionar el desarrollo de tareas en paralelo en procesadores de núcleos múltiples, mejorando así el rendimiento del sistema. Vendido como una de las grandes ventajas de Snow Leopard – que no es un nuevo sistema operativo sino una serie de mejoras sobre el anterior, de ahí que no se cambie completamente de felino en su nombre – su liberación puede resultar sumamente chocante para todo aquel que no termina de entender este tipo de dinámicas: ¿qué lleva a una empresa a poner a disposición del resto del mundo algo que vende como una de sus principales mejoras? ¿No deben las empresas, siguiendo la conocida resource-based view of the firm que se estudia en todas las escuelas de negocio, proteger celosamente las fuentes específicas de sus ventajas competitivas? La discusión de este tema resulta interesantísima para todos aquellos que ven una empresa como un sitio en el que debe reinar el más absoluto secreto, y que suelen caer en el estereotipo de mirar a las comunidades de desarrollo de código abierto como a una especie de pandas de hippies comunistas que responden a esquemas diferentes a los suyos y de los que bajo ningún concepto se puede uno fiar.
La respuesta es la misma que recoge Don Tapscott en el capítulo 3 de su muy recomendable Wikinomics utilizando el ejemplo de IBM: no necesariamente. En muchas ocasiones, liberar una tecnología puede suponer pasar a extraer de ella un beneficio notablemente superior. En el caso de IBM, el efecto se produce en los dos sentidos: por un lado, la empresa colabora con horas hombre en todos aquellos proyectos de código abierto definidos como importantes para la compañía. Por otro, libera todos aquellos desarrollos internos en los que espera que la colaboración de programadores externos aporte un progreso más rápido y eficiente. La estrategia proporciona a IBM ganancias muy sustanciales en la productividad de su I+D, pero no es en absoluto tan sencilla como aparenta. La participación en comunidades de desarrollo externas exige a IBM una muy cuidadosa gestión tanto de personal como de proyectos. En muchos casos, los programadores de la compañía se encargan del desarrollo de aquellas partes del proyecto consideradas menos vistosas o con menos glamour de cara a la comunidad, pero que alguien tiene que hacer: entre contribuir al desarrollo de una parte fundamental del programa y programar un conjunto de drivers de impresora, por ejemplo, hay una gran diferencia, que provoca que en muchos casos, la funcionalidad de un proyecto no se complete fácilmente por la escasez de personas en la comunidad que se encarguen de esas partes menos interesantes. En todos los casos, los programadores de la compañía tienen que adaptar sus actitudes a las de la comunidad: no se trabaja igual en la jerarquía de una empresa que inmerso en la muchas veces mayor laxitud y voluntarismo de una comunidad de desarrollo. Y sobre todo, requiere una cuidadosa gestión a la hora de decidir qué partes de los desarrollos internos liberar y con qué tipo de licencia hacerlo, no solo por la decisión de qué partes ceder al conocimiento público, sino también por las posibilidades que dichos desarrollos tienen de resultar atractivos a la comunidad. De nada sirve liberar un código que es recibido con indiferencia por la comunidad, o que nadie está dispuesto a trabajar para mejorar. La decisión de liberar un código responde al interés por extender y popularizar su uso, al de dar origen a un ecosistema cuyo desarrollo progrese a mayor velocidad, etc. y responde a criterios competitivos que deben examinarse con criterio.
En el caso de Apple con GCD, la decisión de liberar un componente que supone una de las mayores mejoras de Snow Leopard responde, entre otras cosas, a la intención de Apple de incrementar el atractivo de su plataforma más allá de sus propias máquinas, hacia sistemas basados de tipo cluster o superordenadores, así como al intento de estandarizar otras herramientas dentro de las plataformas de desarrollo. En el caso de Apple, el equilibro entre ser una plataforma minoritaria y mantener el interés de los programadores por generar herramientas para ella o trabajar con ella resulta crucial. Liberar GCD escogiendo además para ello una licencia Apache, que no requiere la redistribución del código cuando se desarrollan versiones modificadas, es un intento por provocar una popularización de su herramienta en la comunidad de desarrollo, algo que de otro modo sería difícil que ocurriese, al restringir la utilidad de dichas herramientas a la plataforma Mac. La decisión, por tanto, parece muy bien tomada y responde a un análisis muy cuidadoso, como lo fue en su momento la liberación de Webkit, gracias a la cual se ha convertido en una de las plataformas más dinámicas existentes en el mercado. En el caso de Google, otra de las empresas que se caracteriza por una gestión cuidadosa de lo que mantiene abierto y cerrado, tenemos ya muchos casos similares: la apertura de Android, por ejemplo, pretende generar una plataforma de desarrollo que lleve a un número cada vez mayor de fabricantes de terminales a adoptar Android como una base sobre la que pueden crear elementos propios que posibiliten una diferenciación en el mercado, algo que por el momento parece estar sucediendo razonablemente bien.
En la era open source, como en tantas otras cosas, el secreto para una gestión adecuada está en la medida. No todas las empresas liberan todo y de manera inmediata, ni tiene necesariamente que ser así. Liberar algo es un trabajo en sí mismo, y obliga además a una fuerte disciplina de documentación y limpieza en el desarrollo, lo que de por sí supone ya un importante beneficio. Para una empresa, desarrollarlo todo en modo “como si fuese a ser liberado inmediatamente” es una disciplina que, convenientemente implantada, puede generar importantes ventajas en costes de mantenimiento, y que puede además abrir la puerta a muchos beneficios más. En el caso de Apple, cuya tecnología se basa en gran medida en código abierto, el equilibrio es enormemente importante, y se escenifica con decisiones como ésta.
(Enlace a la entrada original - Licencia)
0 comentarios:
Publicar un comentario
ATENCIÓN: Google ha metido en Blogger un sistema antispam automático que clasifica como spam casi lo que le da la gana y que no se puede desactivar.
Si después de hacer tu comentario este no aparece, no se trata del espíritu de Dans que anda censurando también aquí, es que se ha quedado en la cola de aceptación. Sacaré tu mensaje de ahí tan pronto como pueda, si bien el supersistema este tampoco me avisa de estas cosas, por lo que tengo que estar entrando cada cierto tiempo a ver si hay alguno esperando. Un inventazo, vaya.