Excusas frecuentemente puestas para no liberar software (y su contraargumento correspondiente)

Por oselit@

En estos dos añitos que lleva uno en la OSL, se ha hablado con todo tipo de gente para que liberen la aplicación o librería que han hecho en investigación, docencia o administración. Tal gente ha puesto todo tipo de excusas, que pongo a continuación, junto con nuestro contraargumento. Caveat emptor: unas veces han funcionado, otras no, por lo que si se os ocurren argumentos mejores, me gustará oirlos; así como si hay alguna excusa que no haya puesto aquí.
Las excusas están en orden decreciente de frecuencia, aproximadamente.

No está perfecto todavía: Esta excusa se da muchas veces, incluso en programas que la gente ha usado para su tesis, o que están en explotación con mayor o menor éxito en una web, o que se está usando en docencia. Os voy a revelar un secreto: los programas nunca son perfectos. Por eso existen las versiones: 1.0, 2.0, hasta la 23.0 que es la que tiene emacs. El mejor momento para liberar un programa no perfecto es, por tanto, cualquiera
Es que es un poco chapucero, ¿qué dirán mis alumnos si lo ven?: Esta es una variante del anterior, que se encuentra sobre todo en gente que tiene alumnos y alumnas. Imagínate alguien que da una asignatura de ingeniería del software y libera un programa que ha hecho para un trabajo de investigación sin su diagrama UML correspondiente. O alguien, como yo, que insiste en que no se pongan números mágicos en los programas que se encuentra con declaraciones como $foo=33. O, condenación, ¡un programa sin comentarios! ¿Qué dirán mis alumnos si ven un programa sin comentarios? Bueno, una vez más, apelo a mi propia experiencia: no dirán nada. Por mucha tirria que le tengas a un profesor, no vas a mirarte su código a ver si usa nombres de variable expresivos, y más si está en un lenguaje como el Lua. Y si lo hace y se da cuenta, mira, es software libre, anímate a mejorarlo. Parafraseando la excusa anterior, «No libero software porque no soy perfecto». Jolines, ¿y quién lo es?
Lo documento e inmediatamente lo libero.: Sí, si tengo que esperar a que documentes el software, estamos apañados. La documentación que necesita el software para liberarse son los fuentes y la licencia. Hombre, no voy a decir que no esté bien meter tests unitarios, un interfaz amigable diseñado en gtk, versión móvil, documentación en comic sans y un roadmap para quien lo quiera. Pero no es necesario para liberarlo; el mejor momento para liberar un programa siempre es ahora. Más adelante podrás documentarlo, o incluso puede que alguien te ayude para hacerlo. Pero no es excusa para no liberarlo
Es que esto lo he hecho yo para mi, ¿tú crees que a alguien le interesará un programa que simula el crecimiento de los pelos de las patas de la Epeyra Diadema y el efecto del teñido sobre los mismos?: Precisamente el otro día vi yo a mi Epeyra un tanto peluda y me pregunté cómo quedaría en rubio. Vamos a ver, si es un software con el que has obtenido resultados que has publicado, o has procesado los datos necesarios para el mismo, o te sirve para engancharlo con la web o la base de datos, en resumen, si te ha servido a ti, al menos sabes que le puede servir a alguien. Y el hecho es que el software libre no es un producto monolítico: al liberarlo liberas el conocimiento necesario para hacerlo, lo haces disponible en buscadores y demás, y puede que la subrutina más esotérica (la que aplica el modelo Pantone al tintado de los pelos de la pierna de la Epeyra) pueda aplicarse a otro problema similar o totalmente diferente (el tintado de los pelos del Geyperman, por ejemplo). Por lo que siempre será una excelente idea liberarlo
Es que tenemos una empresa interesada y no queremos tener problemas luego: Esta excusa es una de las más complicadas, porque los argumentos en contra son primero pragmáticos y luego éticos. El primero: ¿en serio que la empresa te va a comprar el software tal cual? No te digo que no vaya a suceder, pero es poco probable. Lo más que conseguirás es que te usen como cárnica para que adaptes ese software a su entorno particular y con sus especificaciones, lo que a) te va a costar mucho trabajo y b) no va a ser nada entretenido. Segundo: puedes vender la aplicación a la empresa, pero con la licencia libre le vas a dar una serie de derechos sobre el fuente, conservando tú también unos cuantos, entre ellos la autoría. Te aseguras con eso que no lo van a convertir en el software cerrado SuperCanquileitor 2000 (sí, también veo Phineas y Ferb de vez en cuando, qué pasa) y no sólo no vas a ver un duro, sino que no vas a tener derechos de autoría. Liberando el software, impides que una empresa se lo apropie. En cuanto al ético, todos vosotros lo conocéis, así que no voy a entrar en él.
Es que no quiero que llegue Toito Lokopio, el investigador bosnio-hercegovino que siempre me copia las ideas, y lo publique él: Todos sabemos que el Dr. Toito es un piernas, y que publica cosas copiadas. Pero si has liberado tu software, la fecha impresa en el repositorio donde hayáis subido el código, que es algo independiente, dirá que tú lo hiciste antes de que él lo publicara, y en caso de que tengáis que ir al Tribunal Supremo de los Plagios Científicos Internacionales, te servirá como prueba
No, si quería hacerlo, peeero no tengo tiempo: Pues vale, eres la oficina de software libre, así que te toca a ti. Ofrécele todas las facilidades: tú le eliges la licencia, lo subes a un repositorio (generalmente será GitHub), lo empaquetas, lo testeas, y lo dejas níquel para la liberación.
Es que no me da la gana: Pues te quedas sin camiseta