archivo

Archivo de la etiqueta: software libre

Llevo unos cuantos artículos haciendo reflexiones sobre el hecho de que el desarrollo de software tiene un precio y que cuando se oferta (y se acepta) hacerlo por menos del mismo sin que exista una justificación para esa reducción del importe o que cuando se pone un presupuesto de ejecución inferior al que debería ser, el proyecto entra en una situación de alto riesgo para que se desarrolle con unos niveles de calidad aceptables o para que simplemente se ejecute. Hay que huir, por tanto, de ofertas imposibles y presupuestos insuficientes.

Esa situación ha hecho y está haciendo mucho daño a nuestra profesión porque al final todos pagamos justo por pecadores cuando un proyecto y otro también no alcanza unos niveles mínimos de calidad.

Sin embargo, por encima del Departamento TIC de una organización se encuentra la dirección de la misma que es la que hace el reparto de presupuesto entre los diferentes departamentos de la misma. Si al Departamento TIC se le asigna X y en realidad necesita 2*X o 3*X para poder ejecutar sus competencias, es necesario hacer ajustes y ese ajuste llega también a los presupuestos de los proyectos porque lo que suele suceder es que el recorte económico no suele ir acompañado por una rebaja de competencias, es más, en algunos casos va de la mano incluso con más tareas.

Ante esto, ¿qué se puede hacer?

1) Pelear hasta donde se pueda porque el presupuesto que te asignen sea el máximo posible acorde a las tareas que tienes que realizar. El éxito de esto dependerá muy mucho de la consideración y posición que tenga el Departamento TIC en la organización. Si no está bien posicionado, será complicado conseguir algo, pero por lo menos, hasta donde se pueda hay que intentarlo.

En uno de los primeros artículos que escribí comenté lo necesario que resulta que el responsable TIC de una organización ocupe un puesto directivo en la misma, de lo contrario está vendido. También he comentado que el presupuesto TIC debe ser gestionado integramente por el Departamento TIC ya que así se conseguirá un mejor rendimiento de la inversión económica y una mejor planificación.

2) Gastar mejor.

Esto empieza por priorizar ya que no todo es igual de importante ni todo es igual de urgente. La priorización implica prescindir de tareas que no son necesarias. Si nos ponemos a analizar hay muchas modificaciones en sistemas de información (generalmente evoluciones funcionales), alcances de muchos desarrollos u otras tareas dentro del Departamento TIC que son prescindibles. En todos estos casos, menos es más.

Si hay una solución que funciona, ¿para qué sustituirla por otra? (salvo que su coste total de propiedad sea superior al que tendría si se desarrollase de nuevo).

3) Mejorar la productividad de los propios equipos. Siempre es posible afrontar esta mejora y en estas situaciones donde el presupuesto y el trabajo es el que es es cuando hay que intentar mejorar la eficiencia del trabajo desarrollado. No se trata de trabajar más, sino de trabajar mejor.

4) Adaptar los procesos a la realidad presupuestaria.

5) Elegir el proveedor más adecuado para cada trabajo. No hay un proveedor universal que sea el mejor en todo, hay especialistas que hacen mejor una serie de tareas que otros. La elección de un proveedor que sea especialista en un área probablemente te pueda proporcionar mejores condiciones económicas con un nivel de calidad aceptable que otros. Como puede haber diversos especialistas sobre una materia, lo mejor es ir hacia una concurrencia competitiva y que gane el que mejor solución proponga, sin que el precio sea el factor principal para realizar la elección.

6) Tender al producto sobre el desarrollo a medida, cuando las condiciones sean mejores, que lo serán en la mayoría de los casos. Si además, la solución es libre, mejor (siempre y cuando el servicio que se te ofrezca sea competitivo frente a la alternativa propietaria).

7) Aplicación de estrategias ágiles en el desarrollo y mantenimiento de software.

Estas son algunas posibilidades que se pueden aplicar y permitirán optimizar tu presupuesto, sin embargo, no son los ingredientes de una receta que te permitan conseguir imposibles, si el desequilibrio entre lo que se puede gastar y los servicios a ofrecer son importantes, la calidad de los mismos se verá mermada.

No hace mucho un proveedor me comentó que el negocio del desarrollo a medida no era sostenible de cara a un futuro, tanto para ellos como para los clientes.

Para ellos porque les resultaba muy complicados hacerlos rentables y más con los recortes presupuestarios que existen en la actualidad y para los clientes porque tarde o temprano no iban a poder permitirse ese tipo de proyectos si la situación económica general no daba un giro radical.

En su opinión, el presente y el futuro es la orientación a productos: “Este es el producto que hace lo que hace y si quieres que haga lo que necesitas hay que personalizarlo”, te cobro por la licencia del producto o te la regalo, pero en cualquier caso te cobro por el soporte y/o por el desarrollo o lo hace un partner.

Comparto su visión en que los clientes tenemos que dejar de pensar en estar reinventando la rueda constantemente y que si hay productos que pueden resolver nuestras necesidades con ciertas adaptaciones, tender a utilizarlos. Ahora bien, evitando ser cautivos del proveedor en la medida de lo posible, por eso, en el caso de que se opte por la orientación a productos habría que priorizar aquellos basados en licencias libres siempre y cuando reúnan unas condiciones mínimas de partida (si la solución propietaria es mucho mejor y adaptar la libre cuesta mucho o por mucho que nos gastemos (dentro de nuestras posibilidades) no consigue siquiera aproximarse, la idea es optar por la propietaria).

Desarrollos a medida seguirán existiendo porque hay muchas procesos de negocio que son muy concretos y para los que no resulta rentable invertir en el desarrollo de un producto (salvo que te hayas especializado en ese tipo de procesos) pero lo que sí es cierto es que los desarrollos serán más exigentes, en el sentido de que, como he comentado antes, los presupuestos no serán como los de antaño, la competencia es mayor y las exigencias del cliente son cada vez más elevadas (se mira más por el dinero que se gasta y se presta más atención a la calidad del proceso de desarrollo y a la calidad técnica del producto, algo que si no se tiene asumido en el proveedor como parte de sus métodos de desarrollo, les provocará un mayor coste).

Linus Torvalds dijo (traducción libre): “con un número suficientemente de observadores, todos los errores se convierten en obvios”, es una cita simple, pero con mucho contenido:

– Es considerada por muchos como la explicación más sencilla de por qué los productos basados en software libre evolucionan más deprisa que los basados en software propietario, ya que tanto sus funcionalidades como su código se expone al exterior, a la vista de una audiencia potencialmente enorme que detecta errores y mejoras y proporciona ese feedback necesario a los desarrolladores para continuar con la evolución del producto.

No es el único motivo por el cual el software propietario tiene ciclos de revisión más amplios (su carácter comercial (necesidad de amortizar versiones anteriores, hacer llegar a los clientes las nuevas versiones, necesidad de garantizar un determinado nivel de calidad, etc…) es a mi juicio el principal motivo, aunque la propia “informalidad” del software libre es también una causa importante.

Cuando hablo de “informalidad” no hablo de falta de calidad (es decir, no tiene un sentido peyorativo), sino de no requerir (en la mayoría de los casos) unos circuitos tan burocráticos para sacar a la calle el producto, de hecho cuanto antes llegue (aunque sea vestido de versión alfa, beta, release candidate o incluso de versión estable) antes se detectarán errores, se recogerán mejorar y se desarrollará la siguiente versión del mismo.

– Este principio también resulta válido para el software que se desarrolla para determinados departamentos de una organización. Partiendo de la base de que el desarrollo del software perfecto no existe tanto a nivel de calidad documental, de código o funcional siempre llegarán errores a producción. Cuanto mayor sea el número de usuarios mayores quebraderos de cabeza proporcionará el software de manera que un software mejor acabado pero con una audiencia elevada puede dar más problemas que un software mal rematado pero con un menor número de usuarios. Por este motivo por cuantas más manos pase el software antes de ponerse en producción mejor llegará (se seguirán colando incidencias, pero serán menos).

Ahora que se está intentando recortar gastos por todos los lados tanto en las organizaciones públicas como privadas creo que ha llegado el momento de empezar a mirar con más detenimiento, si cabe, al software libre.

Es un problema intentar hacer los deberes ahora, con prisas, ya que una migración de determinados componentes software que utiliza una organización a una solución libre es algo que requiere hacerse de manera meditada y siguiendo un plan. En muchos casos, si la organización es grande el proyecto puede ser muy complejo y durar bastante tiempo hasta que se ejecute completamente. En cualquier caso, siempre existe la posibilidad, cada uno acorde a sus posibilidades de empezar a implantar soluciones libres, sobre todo es más fácil en el caso de la implantación de productos nuevos o si ya se tiene previsto y programado la sustitución de un determinado software por otro.

No se trata de meter el software libre con calzador, habrá determinada infraestructura software de una organización que sencillamente no podrá ser migrada a software libre, ya sea por coste o por el riesgo que puede suponer toda migración (para una organización grande, una migración no satisfactoria de un componente software tipo núcleo puede costar cientos de miles o millones de euros), la idea es entender las ventajas que te ofrece, que van más allá del coste, no obstante, en este artículo me centraré principalmente en los aspectos económicos que es lo que a día de hoy se entiende mejor porque la falta de peso en el bolsillo agudiza los sentidos. Recuerdo que el software libre no tiene que ser gratis (aunque si es GPL probablemente no será muy complicado encontrar una versión sin coste totalmente legal), pero incluso teniendo un coste será por regla general más barato que su equivalente propietaria y si preocupa el soporte, existe multitud de empresas que pueden dar ese servicio para la mayoría de las soluciones libres a un coste muy razonable.

Antes de enfocar la mirada al software libre, hay que hacer inventario, es decir, determinar cuáles son los componentes software y aplicaciones de mi organización, cuánto me cuesta mantenerlas ya sea por licencia, soporte, etc…, cuáles son más estratégicas, cuál es el estado del ciclo de vida de cada una, qué impacto puede tener sustituirla por otras y qué medidas habría que aplicar (a alto nivel) para poner en su lugar una solución basada en software libre.

Cuando se haga ese inventario probablemente se vean oportunidades para sustituir aplicaciones u otro componente por una alternativa libre y se podrá presupuestar los beneficios económicos que traería esa medida. Esos miles, decenas o centenas de miles de euros que se pueden ahorrar puede suponer un respiro importante para la organización.

La migración a software libre tiene un coste, por lo que en muchos casos la pescadilla se morderá la cola y entre ese coste y el miedo al cambio (más o menos justificado) muchos proyectos o deseos de implantar soluciones de software libre esperarán a mejores tiempos. Si ese coste es asumible y el proyecto es viable y puede suponer un ahorro real, ¿por qué no intentar aplicarlo?, ¿por qué no dar la oportunidad por lo menos a estudiar más o menos a fondo si es posible ahorrar costes aplicando una estrategia orientada al software libre?.

Hace unos días publicaba un artículo en el que expresaba las intenciones de mi organización de prescindir de Internet Explorer 6. Pues bien, poco después en una presentación del prototipo de una aplicación, se comentaba por parte de la empresa desarrolladora que podría ser una buena estrategia que los ficheros de entrada a la herramienta (se trata de un sistema de adquisición de datos de diversas fuentes para su posterior tratamiento) sería que estos fueran OpenOffice.org Calc. Como era de esperar, algunos usuarios comentaron que ellos trabajaban con Excel, que tenían mucha información grabada en ellos y que salvo que en la organización se plantease prescindir de Microsoft Office, ellos iban a seguir utilizándolo.

Tras la presentación estuve charlando con el equipo de proyecto y me comentaron si realmente era tan difícil migrar a OpenOffice.org en mi organización. Y les comenté que pese a que es algo que se tiene en mente es algo que no podemos esperar a corto plazo por una serie de razones:

– La decisión no dependía de ninguno de los que estabamos allí, es algo que dependía de los responsables de mi departamento y de sus superiores y que dada la coyuntura actual, existían otros problemas que probablemente les resultaban más prioritarios.

– En mi organización, pese a que existe un gran número de sistemas de información, existe todavía una gran utilización de soluciones ofimáticas, basadas principalmente en el uso de Access y Excel. Si se prescinde del paquete Office hay que darles a los usuarios una alternativa. Es cierto que se pueden ofrecer esas alternativas, pero dada la gran cantidad de recursos de este tipo que hay, será necesario un proceso planificado para llevarlo a cabo que pasa por una evaluación de todos los ficheros de este tipo que hay, estudiar cuáles podrían ser cubiertos por sistemas de información ya existentes, para cuáles habría que construir una nuevo y cuáles tendrían que ser migrados a las nuevas soluciones que se elijan. También será necesario un plan de formación para aquellos usuarios que lo necesiten, así como tal vez un soporte durante los primeros meses de uso de los nuevos productos. Todo esto requiere su tiempo y tiene un coste económico, por ese motivo es necesario planificar este proyecto, dedicándole el esfuerzo y la atención que se merece.

Mi opinión sobre este asunto, es la que ya he expresado en otros artículos de mi blog, es decir, en todos aquellos aspectos donde exista una solución libre con iguales o mejores prestaciones que una solución propietaria hay que tender a sustituir los segundos por los primeros. Si a esto le sumamos además que el software libre y la liberación de nuestros productos es una política de mi organización, tenemos todavía existen más condicionantes para llevar a cabo este tipo de actuaciones. Por tanto, soy totalmente partidario de que sustituyamos Office por otras soluciones, pero eso sí, teniendo en cuenta de que dada la situación actual es necesario planificar muy bien el proyecto, que cuente con el respaldo de la alta dirección de la organización (ya que todo cambio, por muy sencillo que pueda parecer siempre encuentra rechazo, que puede ser más o menos minoritario, pero que siempre crea ruido y consume muchas energías), tener en cuenta que el proceso puede requerir una inversión económica que habría que evaluar y que es algo que se tendría que llevar sin prisas pero sin pausa.

Como ya he comentado en otros artículos estoy totalmente a favor del uso de software libre en entornos corporativos y particulares y que tanto las administraciones públicas como las empresas privadas deberían tener entre sus estrategias la progresiva utilización de este tipo software mediante la sustitución de su equivalente propietario en todos aquellos casos en los que el nuevo software proporcione unas funcionalidades iguales o mejores que el anterior.

Digo progresiva, porque la sustitución de unos productos por otros (y esto es extensible a cualquier sustitución de un software por otro, por tanto es un caso general y que no depende que el nuevo software sea libre) requiere de una planificación y de un proceso de gestión del cambio (e incluso en muchas ocasiones de soporte) que en muchos casos es costoso, sobre todo si el cambio afecta a un buen número de empleados, es decir, no se puede de la noche a la mañana pasar de utilizar un producto a utilizar otro, ya que puede afectar entre otras cosas a la productividad de los empleados. También digo progresiva porque si se van a sustituir varios componentes software por otros y hay que hacer para cada uno de ellos el proceso que acabo de indicar, en muchos casos será conveniente realizar la sustitución de forma escalonada. También es necesario tener en cuenta que existirán organizaciones que por sus características particulares sea bastante complicado el cambio de un software por otro y que provoque que el mismo se realice de forma muy pausada o bien que se descarte.

Pero una cosa es eso y otra olvidar que los Departamentos de Informática deben dar un servicio al resto de la organización y que ese servicio debe ser lo más óptimo posible, es decir, hay que evitar la experimentación en circunstancias que afecten a la productividad y por tanto si se va a sustituir un producto por otro, y centrándonos en concreto en la sustitución de un software propietario por uno libre, se debe tener claro (además de que es necesario un proceso de transición como el que se indicó en el párrafo anterior) que el nuevo producto permite proporcionar un servicio igual (o casi igual) o mejor que el anterior. Si no es así, salvo circunstancias que habría que estudiar caso por caso (por ejemplo, el coste de licencia de un producto propietario es muy grande y su sustitución por un producto de software libre, provoca una pérdida de algunas funcionalidades importantes que afectan, por ejemplo a alguna de las siguientes variables: disponibilidad, seguridad, productividad, etc…, pero el impacto de las mismas traducido en términos económicos es menor que el pago de las licencias del producto propietario), lo mejor es quedarse con el software propietario que se esté utilizando del cual sabemos que está dando un servicio y lo está haciendo haciendo bien.

Comenta el blog Genbeta, el “mal rato” que pasó Steve Ballmer en la reunión anual de accionistas de Microsoft, por las preguntas que le hicieron determinados accionistas.

Estas preguntas estaban centradas en la necesidad de mejorar en marketing para intentar relanzar la imagen de la compañía.

Creo que para todos es evidente que Microsoft tiene un grave problema de imagen, ya que se le ha asociado la imagen de enemigo del software libre, de elaborar productos más orientados a los resultados de la compañía que a los usuarios, de haber perdido capacidad innovadora (los dos factores anteriores, da un imagen como una empresa que desarrolla productos de una generación anterior), de ser un látigo para la competencia, etc…

A todo lo anterior hay que sumarle otros aspectos como el mal sabor de boca que han dejado algunos productos suyos como es el caso de Windows Vista o Zune.

En lo que respecta al problema de imagen Microsoft no ha sido víctima de nada, sino que esta misma empresa no ha enfocado nada bien sus campañas de marketing, ya que se han olvidado de que tienen competencia (este es el problema de quien está dominando de manera clara un determinado sector, como el de los sistemas operativos, desde hace muchos años). De esto, como he comentado en diferentes artículos se han aprovechado todos sus competidores. Un ejemplo de todo esto lo tenemos con la imagen de enemigo del software libre de Microsoft, tras la cual se han parapetado todas las actuaciones que han realizado gigantes como Apple, Google, Oracle, etc…, que aunque participen o subvencionen algunos proyectos de software libre, sus productos estrella y la línea principal de sus negocios se basan en software propietario puro y duro, que además lo seguirán siendo, salvo sorpresa, por muchos años.

El marketing es fundamental siempre y más en un entorno tan competitivo como en el que se mueve Microsoft. Apple ha sabido manejar muy bien los tiempos del marketing (de hecho tener algo que sea de Apple, se ha asociado a tener algo guay) y lo ha acompañado con productos sensacionales e innovadores, lo cual ha tenido un impacto muy importante en el mercado y, en consecuencia, en el balance de la compañía.

Microsoft debe reaccionar y no sólo en marketing, el entorno ha cambiado y ahora tiene competencia real y fuerte en todos los sectores, hasta incluso en el de los sistemas operativos, con productos de gran calidad y tremendamente innovadores. Si Microsoft no reacciona lo puede pasar muy mal, ya que lo más lógico es que dada la competencia que tiene, por ejemplo, en los sistemas operativos (Mac OS, Linux, próximamente Chrome OS), lo normal es que pierdan cuota de mercado, ya que hay más donde elegir y esa pérdida de cuota de mercado tendrá resultados directos sobre los balances de la compañía.

Yo espero que Microsoft reaccione, ya que necesitamos a esa empresa, necesitamos que exista una competencia viva en el sector, que proporcione innovación y cada vez mejores productos.

En cualquier caso y esto es importante, todo software que sea desarrollado para la administración pública debe ser liberado con una licencia libre (lo ideal sería que se acogiera a alguna auspiciada por la Free Software Foundation). En España y en algunas de sus Comunidades Autónomas se han dado avances significativos en este sentido, pero lejos, muy lejos todavía de que el mayor porcentaje de software desarrollado para las mismas sea accesible libremente. Aqui queda mucho por mejorar y no solo en lo anterior, sino en la participación de las administraciones ya sea económicamente, a través de empresas de desarrollo de software o con personal interno en comunidades de desarrollo de software libre, seguro que darían un impulso importante a bastantes proyectos que son de gran interés y por supuesto una alternativa tan buena o mejor que las soluciones propietarias que se puedan adquirir y más baratos y efectivos que soluciones que la administración quiera desarrollar desde cero.

También soy partidario de que las administraciones (con su debido plan de migración y gestión del cambio correspondiente y sin precipitaciones) deben abordar una paulatina incorporación de soluciones libres dentro del ámbito del puesto de trabajo. Por supuesto que no es nada sencillo un plan de estas características, por supuesto que es necesario analizar caso por caso, por supuesto que puede requerir mucho tiempo hacerlo, por supuesto que habrá componentes software que no serán recomendables migrar (y no se deberán por tanto migrar), pero creo que es un ejercicio de responsabilidad por lo menos intentar esta evolución y no lo digo solo por el ahorro de costes, por motivos de seguridad, etc…, sino como una forma de apoyar a una causa justa y que lleva consigo unos beneficios muy importantes para la sociedad.

Eso sí, hay una cosa en la que no estoy de acuerdo y es en la proliferación del desarrollo y mantenimiento de distribuciones Linux (aún basadas en otras) en las distintas comunidades autónomas. La iniciativa de acercar Linux a las aulas, de promocionar este sistema operativo me parece fantástica a la par que necesaria, pero no necesariamente el camino debe ser el desarrollo de distribuciones particulares, ya que existen suficientes distribuciones Linux para que no sea necesario utilizar este tipo de estrategias. Ese dinero que se invierte en el desarrollo de estas distribuciones, perfectamente podría ser utilizado para fomentar otros proyectos de software libre, para formación en la materia o si se quiere para ayudar o contratarle soporte a la comunidad, empresa u organización que ha desarrollado la distribución Linux elegida.

Lo comentado sobre el uso del software libre en las administraciones lo extrapolo al conjunto de instituciones privadas, ya que si los deberes se realizan adecuadamente, se identifica que es migrable, que no es migrable, se establece un plan para hacerlo, una gestión del cambio adecuada y se elige un momento óptimo a partir del cual comience este proceso (que puede durar años) no tendría necesariamente que provocar problemas a la empresa y los beneficios aplicables al uso de esta estrategia no tardarán mucho en llegar. ¿Por qué digo que las administraciones deben migrar y con las empresas no soy tan tajante? Pues porque en el primer caso pago yo y asumo por tanto mi margen de responsabilidad y en el segundo porque las empresas se nutren de capital privado y ellas mejor que nadie saben qué es lo que tienen que hacer con su dinero y cuáles son sus prioridades.

Desde siempre se ha considerado a Microsoft como el enemigo público número uno del software libre, como suele pasar, estas calificaciones no se regalan. En este caso tuvo muchísimo que ver la actitud y visión comercial de Bill Gates y el comportamiento del gigante de Redmond a lo largo de los años. No obstante, como he indicado en algún post anterior, Microsoft es sólo uno de tantos y son esos tantos los que están sacando una gran tajada de que la atención y la “mala fama” se la lleve esta empresa, ya que gran parte del éxito de una empresa lo da su imagen.

Para muchos la visión de la “pureza de sangre” del software libre (o todo libre o nada) hacen que la Free Software Foundation y Richard Stallman sean considerados unos extremistas. Yo no comparto completamente su doctrina (una cosa es que entienda que el concepto de software libre sea estrictamente ese y otra bien distinta es que considere que aunque el software libre sea la meta (tal vez utópica) a la que debemos llegar, no tenga en cuenta otras alternativas) y hago uso de software no libre tanto en sistemas operativos libres como en sistemas operativos no libres, así como puedo llegar a entender (y compartir) estrategias comerciales de empresas de desarrollo de software que no se basen en software libre. Más adelante explicaré mis razones. Pero independientemente de eso, veo necesaria la existencia de personas e instituciones que defiendan el software libre, su progresiva expansión y nos prevengan de riesgos próximos y futuros sobre la integridad y accesibilidad de la información, sobre la continuidad de la filosofía del software libre, etc… que pueden ser provocados por diferentes tecnologías, tendencias o concepciones. Además, como bien argumenta Stallman, la lucha por el software libre, debe ser constante y sin bajar los brazos. Su organización, él, personas que llevan años aplicando esta filosofía y participando activamente en la comunidad tienen la fuerza, la constancia y la fé necesaria para luchar por esta idea, yo no tengo su experiencia personal, ni tampoco una visión tan preclara como ellos, como para adaptar mi forma de utilizar o concebir el uso del software 100% a su manera.

Alguno pensará, y con razón, que no predico con el ejemplo y es cierto, como comenté en el párrafo anterior en la práctica hago uso de software no libre (o no extrictamente libre, ya que si un software tiene algún componente propietario ya no es libre al necesitar esa pieza necesariamente para funcionar (aplicando el principio de que toda cadena es tan fŕagil como el más débil de sus eslabones)), al fin y al cabo ejerzo mi libertad individual para hacerlo, ¿por qué? pues tal vez en la mayoría de los casos sea por comodidad, este es el programa que estoy acostumbrado a utilizar y no se me apetece buscar una alternativa completamente libre (o no me pongo a analizar su nivel de pureza), en otros casos (los menos) porque la solución propietaria es mejor o no hay alternativa.

También comenté que puedo entender y compartir estrategias empresariales o de negocio basadas en la creación de software no libre (de la misma manera que no puedo compartir, bajo ningún concepto estrategias empresariales o de negocio que no se basen en sistemas abiertos), ¿por qué? pues porque desgraciadamente las personas no somos justas, sobre todo si hay o puede haber dinero de por medio. En ocasiones para proteger y recuperar la inversión en una determinada solución es necesario aplicar prácticas de software propietario y aunque existen prácticas basadas en software libre, desde vender la solución hasta cobrar por servicios, siempre puede aparecer la empresa buitre de turno coger tu código y quitarte negocio o incorporarlo a su solución propietaria (aunque incumpla la licencia y por tanto no sea lícito) y ni te enteres. Esto que comento ha pasado, pasa y pasará en el mundo real, no podemos tener vendas en los ojos, por mucho que tengamos en consideración el software libre. Otra cosa bien distinta es que apoye que un software sea eternamente propietario, desde mi punto de vista, una empresa que ya ha obtenido el retorno de la inversión y unos beneficios aceptables debe liberar el código, llámese como se llame la empresa y por mucho que ese software sea el núcleo central de su negocio (por lo menos, si no quieren liberar la última versión, deberían liberar versiones anteriores, como forma de devolver a la comunidad de usuarios y clientes, lo que esa comunidad de usuarios y clientes le ha dado). Yo lo veo así, evidentemente mucha gente estará en un completo desacuerdo conmigo y seguro que tienen sus razones, tanto en un lado como en otro, ya que los responsables de una empresa que desarrolla soluciones software propietarias, me dirán que hablo así porque no me estoy jugando mi dinero o mi trabajo y yo le contestaría que es posible, pero que también entre el negro de la no liberación del software como libre y el blanco del libera todo y ya, hay una gama interesante de alternativas, además de que la empresa ha podido desarrollar otros productos u otras líneas de negocio gracias a los beneficios obtenidos que permitan seguir otra senda (sin necesariamente tener que perder la abierta con el producto software que han liberado).

Tal y como comenta la Free Software Foundation, un software se considera libre si para los usuarios verifican los siguientes principios:

– Tiene la libertad de ejecutar el programa para cualquier propósito.
– Tiene la libertad de adaptar el programa de acuerdo a sus necesidades.
– Tiene la libertad para redistribuir copias, tanto gratis como por un precio.
– Tiene la libertad para distribuir versiones modificadas del programa, de modo que la comunidad pueda beneficiarse de sus mejoras.

Para que se cumplan estas premisas es necesario el acceso al código fuente del programa. Un aspecto muy importante es diferenciar el concepto de Open Source respecto al de software libre, ya que aunque resulten parecidos tienen un enfoque diferente, a grandes rasgos un software que sea libre es Open Source (por definición), pero todo software que sea Open Source no tiene por qué ser libre. La diferencia está en que el Open Source se basa en la accesibilidad al código fuente, pero no asegura los cuatro principios enumerados anteriormente.

La Free Software Foundation se desmarca del concepto de Open Source, no lo critica abiertamente, ni lo considera un enemigo (como podréis ver en el enlace, para la FSF el enemigo es el software propietario), al contrario, considera que muchas aportaciones del movimiento Open Source han sido beneficiosas para el movimiento del software libre. No obstante, el hecho de que dentro del concepto de Open Source pueda entrar software libre, software semilibre y software propietario, provoca importantes recelos, ya que se considera que para que la filosofía del software libre se imponga el concepto no puede verse contaminado por interpretaciones inexactas o incorrectas del mismo.

Otro aspecto que ha hecho daño al software libre es la asociación del término inglés free con gratis, ya que un software gratis no tiene por qué ser libre, ni un software libre tiene por qué ser gratis. La confusión gratuidad/software libre, ha provocado y provoca que muchas personas consideren software freeware, incluso shareware, como software libre, además de otras modalidades de licencia que distan de las cuatro premisas del software libre.

Puede resultar paradójico, pero una de las cosas que más daño ha hecho al software libre es la aparición de soluciones software propietarias y gratuitas, ya que el software libre requiere un compromiso mayor, la libertad, y esa visión de libertad se pierde cuando tenemos la posibilidad de utilizar una buena solución tecnológica de forma gratuita (aunque sea propietaria). Es como si nos dejásemos vencer por el reverso tenebroso de la fuerza. Es por eso que hay muchas voces dentro del movimiento del software libre que muestran su temor hacia la orientación a la nube de los servicios software, ya que la mayor parte de esos servicios son gratuitos y además propietarios y están viendo como diariamente su número de usuarios crece de forma exponencial. Por mucho que Google y otras empresas del sector financien software libre (lo que evidentemente es de agradecer), en esencia son empresas cuyo funcionamiento gira alrededor del software propietario.

Para proteger el software libre de un uso inapropiado del mismo (la adición de componentes propietarios) o malicioso (la apropiación de dicho software dentro de soluciones propietarias), Richard Stallman desarrolló el concepto de copyleft a través de la licencia GPL (General Public License) de GNU. A grandes rasgos el copyleft viene a decir que todas las modificaciones que se puedan incorporar a un programa que sea software libre deben estar basadas en soluciones libres y que la distribución de la aplicación resultante debe ser también copyleft.