Un clon, por si las moscas

Que ciertas empresas pueden traicionar (o defraudar) a la comunidad sin previo aviso es algo que muchos sabemos desde hace mucho tiempo. Desgraciadamente, aun sabiéndolo, solemos olvidarlo o restarle importancia.

Uno de los ejemplos históricos más claros fue el de Sun Microsystems, que aunque impulsó fuertemente el software libre, también hizo lo contrario en los últimos años antes de ser fagocitada por Oracle. Y Oracle, claro está, fue peor aún. Otro ejemplo no tan recordado fue EyeOS, de mi “queridísimo” Pau García Milà (me robaba la comida en la oficina, aparte de programar como un chimpancé y enseñarnos el culo cuando se dignaba a pasar por las oficinas de Bananity).

Recientemente ha habido otro caso muy sonado, en el que Apple ha hecho desaparecer sin previo aviso los repositorios completos de FoundationDB en Github. Este no será nunca el caso de ColorSharp, ni el código es tan apetecible para una macrocorporación, ni yo permitiría que algo así sucediera. Sin embargo, visto lo visto, es mejor tomar precauciones: Github podría perder sus datos por un accidente, cerrar por algún problema económico (aunque no es creíble a corto plazo), censurar algunos repositorios (como de hecho sucedió, por tener que aplicar ciertas leyes estadounidenses)…

Por eso mismo he decidido mantener un mirror del proyecto en Gitlab: https://gitlab.com/Litipk/ColorSharp . Puntualizo, aunque el código de Gitlab es libre (a diferencia del de Github), me fío tanto de ellos como de los primeros. Que el código sea libre no los hace menos vulnerables a los problemas que he mencionado. Este clon no es para saltar de Github a Gitlab, sinó mas bien asegurar que habrá como mínimo un mirror. Y me estoy planteando crear otro en Bitbucket.

Anuncios

Apuntes y reflexión breve

Buenas.

Desde hace unas dos semanas no ha habido demasiado movimiento en el desarrollo de ColorSharp. Sin embargo han sucedido suficientes cosas como para que valga la pena escribir sobre ello.

En la entrada anterior comenté como había realizado algunos esfuerzos para ponérselo fácil a la comunidad y que alguien se animara a contribuir al proyecto. A lo que comenté, debo añadir que también creé una lista de correo para quien quiera discutir sobre lo que sea más pausada y organizadamente de lo que permite un chat tipo IRC.

De momento, tanto la sala de chat como la lista de correo están completamente muertas. Es normal, el proyecto sigue sin ser conocido y es de nicho, además de estar relativamente verde todavía. Considero que la estructura y el plan de desarrollo permitirán que la biblioteca supere en flexibilidad y funcionalidad a las otras bibliotecas de conversión de color que existen para .NET (de hecho ya las supera en algunos puntos), pero de momento lo conseguido sigue siendo insuficiente.

Continuando con el asunto de la actividad, por suerte no ha sido todo malo. Añadí mi proyecto a la página de Up for Grabs, y, oh casualidad, al día siguiente tenía un “pull request” pendiente de revisión para ColorSharp 🙂 . Debo decir que aun no lo he integrado porque tengo que hacer más pruebas, pero debería darme brío para no desanimar al colaborador recién llegado. Además, me sorprendí viendo en mi buzón dos emails de dudas relativas a ColorSharp, aunque fueron enviados a titulo particular y no a la lista de correo. El asunto de los canales de comunicación debe ser tratado.

Otro punto que tenía pendiente hasta hace nada era la documentación. Finalmente he rellenado la wiki con explicaciones sobre la estructura de ColorSharp y como usar el proyecto.

Si nos fijamos en los artículos anteriores, podemos ver que mucho de lo que he comentado y me he propuesto sigue en el limbo. La creación de comunidad y asegurar que la experiencia “out of the box” es buena han sido los puntos que más han centrado mi atención la mayor parte del tiempo.

Parece mentira, pero pequeñas sutilezas pueden marcar una diferencia enorme en la actividad del proyecto y en la percepción que se tiene de él. Por ejemplo, actualmente tengo una lista TODO en un fichero dentro del repositorio, desde luego eso es mejor que nada, pero por muchos motivos es subóptimo.

Mi próximo movimiento, antes de tocar una sola línea de código, será mover toda esa información al bugtracker de Github. Esto servirá no solo para visibilizar la necesidad de “mano de obra” sino también para obtener una mejor visión sobre el progreso del proyecto.

Saludos!