olidroide blog

Estructura social - Modelo de cebolla

No, no os quiero hacer llorar con este post... qué fácil es hacer un chiste malo cuando se incluye una cebolla... Hoy quiero explicar un sistema de estructuración de proyectos de Software Libre. Se llama el modelo en cebolla, denominado así por su similitud a las capas de una cebolla, y este caso, la importancia que tiene según se accede al núcleo.

Esta estructura social es muy común en la mayoría de proyectos de software, en el caso de software libre, existe la oportunidad de llegar hasta el centro, mientras que en software privativo puede que nos quedemos en la capa mas externa siempre. Esto es debido a que en esta estructura, en la capa más externas se encuentran todos los usuarios de un programa. En la siguiente capa mas interna, se encuentran los usuarios activos. Estos empiezan a comprometerse, colaborando en búsqueda de bugs, crear algún parche, traducir... Para que sus modificaciones sean revisadas, deben comunicárselo a la siguiente capa, donde se encuentran lo co-developers, personas que llevan tiempo realizando modificaciones, colaborando, y que tienen un tiempo reservado para realizar este tipo de tareas. Es una capa importante, pues la comunicación y la ayuda entre estas dos capas debe ser la mas intensa, pues la siguiente capa, que es el núcleo, se encuentran los coordinadores del proyecto, y sus desarrolladores.

Podemos ver claramente cual es la dirección que debe tomar cualquier persona que quiera colaborar, y seguir este orden es importante, pues así se mantiene un flujo de pasos que debe seguir para ser parte del núcleo. Esto sirve para explicar la meritocracia, pues según realizas tareas, más posibilidades tienes de ir quitando capas a la cebolla.

Con esta estructura, también se explica la cantidad de personas implicadas en un proyecto de Software Libre, pues cuanto mas externa sea la capa, mayor cantidad de personas hay implicadas. Como suele pasar, el núcleo es muy pequeño, representa a esa minoría, dedicada a que funcione, comparada con la gran cantidad de gente que utiliza ese software.

El modelo en cebolla, brinda a asemejarlo con bastante facilidad a muchas estructuras, a pesar de que ahora mismo nos ocupa la estructura social, podemos también asemejarlo al código, en el que existe una API que se comunica con el exterior del programa, y esta API se comunica con el núcleo, que internamente tiene una serie de funciones divididas en bibliotecas. El núcleo a su vez se comunicará con el hardware. Es un modelo que estructura muy bien cada parte de un programa.

Es importante saber la existencia, y la aplicación de esta estructura social en un proyecto, pues si no estuvieran definidos, puede ser difícil de mantener una gran cantidad de código, listas de correo, parches, etc...

Open Data - Datos abiertos en las administraciones públicas

¿Cuantas veces necesitamos acceder a datos administrativos de tu ayuntamiento?, o datos a nivel demográfico, estaciones meteorológicas o incluso las cámaras de tráfico para ver si hay atasco en un determinado punto kilométrico. Datos que son recogidos, administrados por el organismo competente, para realizar estudios y/o censarlo. Si esos datos, nos conciernen a todos los ciudadanos ¿Porqué no tener acceso a ellos?

Open Data es un movimiento que determinados datos, estén libres a todo el mundo, sin restricciones de copyright, patentes u otro mecanismo de control. Esto no implica únicamente en desarrollar una web, en el que aparezcan un serie de datos. Implica que se deben desarrollar mecanismos de comunicación, accesible, legible, comprensible, estructurado y reutilizable. Esto puede ser mediante una API con el que cualquier aplicación pueda conversar con esos datos. De esta manera no se limita el uso a la aplicación web, si no al de cualquier tipo de aplicación, de escritorio o móvil.

Para cumplir esta serie de requisito, podríamos decir que hacen falta tres conceptos que debe cumplir todo ayuntamiento con datos accesibles:

Transparencia: La administración pública debería permitir el acceso sobre actos que se están realizando y sobre sus planos de actuación. Permitiendo a los ciudadanos poder realizar un control de la acción gubernamental, y poder crear valor a partir de estos datos cedidos.

Colaboración: Estos cambios se realizan para implicar más al ciudadano, empresas, asociaciones y otros agentes, permitiendo realizar un trabajo conjunto.

Participación: Favorece el derecho de la ciudadanía a participar activamente en las actuaciones sobre asuntos públicos de los organismos oficiales del estado.

Aunque el movimiento parece que está estrechamente relacionado con el Software Libre, no quiere decir que a pesar de tener datos abiertos, se utilicen herramientas privativas, para el manejo de los mismos. Un posible ejemplo es la utilización de Google Maps para representar la situación geográfica donde se encuentran las estaciones meteorológicas. A pesar de tener datos abiertos, y Google Maps, que tiene una API abierta, no quiere decir que los datos estén almacenados en sistemas cerrados. En este caso recomendaría el uso de OpenStreetMaps.

Obviamente, hay ciertos tipos de datos que las Administraciones no pueden hacer públicos, como son los datos de carácter personal, los sujetos a propiedad intelectual o aquellos que estén relacionados con la seguridad.

Podemos contar con la experiencia de otras administraciones extranjeras que ya han empezado a dar acceso abierto a sus datos. Como el de Estados Unidos http://www.data.gov/ , el gobierno británico http://data.gov.uk/ , y a nivel nacional, el País Vasco http://opendata.euskadi.net.

Desde Cenatic se ha creado un video en el que Manuel Velardo describe las características de este movimiento.

Creo que si todos los ayuntamientos aceptaran Open Data, como forma de comunicarse con la ciudadanía, mejorarían problemas sociales, económicos o incluso ideológicos. Open Data es la comunicación entre gobierno y ciudadano de la forma más directa y diversa posible.

Más información en el documento realizado por la Junta de Castilla y León:
http://www.orsi.jcyl.es/web/jcyl/ORSI/es/Plantilla100Detalle/1262860952313/1262860952313/1284139023547/Redaccion

Creative Commons

Cuando hablamos de Software Libre, nos referimos a todo aquel software que siguen las 4 libertades básicas descritas por la Free Software Foundation. Pero estamos hablando de software, ¿Podemos aplicar estas libertades a otra cosa que no sea software?

Sí, y para ello se fundó la Creative Commons, mediante nuevas licencias, permite reducir las barreras legales respecto a la creación de contenido creativo, como pueden ser contenido textual, fotográfico, pictórico musical o audiovisual.

Fue fundada en 2001 por Lawrence Lessig, Hal Abelson, y Eric Eldred.Pero hasta Diciembre de 2002 no se hicieron públicas el primer conjunto de licencias. Pero ya existían licencias libres, ¿para qué mas?. Aunque pueda parecer que es una proliferación de licencias, en Creative Commons buscan solucionar ciertos problemas que con el software no se daban.

Crearon una serie de capas visuales, de tal manera que fueran fácilmente identificadas y aplicadas.

CC BY

CC BY-SA

Compartir bajo la misma licencia: Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta.

CC BY-ND

Sin obras derivadas: No se puede alterar, transformar o generar una obra derivada a partir de esta obra.

CC BY-NC

No comercial: No puede utilizar esta obra para fines comerciales.

CC BY-NC-SA

Reconocimiento: Debe reconocer los créditos de la obra de la manera especificada por el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el uso que hace de su obra).
No comercial: No puede utilizar esta obra para fines comerciales.
Compartir bajo la misma licencia: Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta.

CC BY-NC-ND

Reconocimiento: Debe reconocer los créditos de la obra de la manera especificada por el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el uso que hace de su obra).
No comercial: No puede utilizar esta obra para fines comerciales.
Sin obras derivadas: No se puede alterar, transformar o generar una obra derivada a partir de esta obra.

CC 0
Esta licencia permite al autor dejar su obra al dominio público, de esta manera no tendrá ningún derecho sobre la obra, incluso de atribución.

Para aplicar una licencia de Creative Commons, podemos utilizar la herramienta oficial.

Debido a estas diferenciadas licencias, se creó Free Cultural Works, que trata de definir un trabajo cumpliendo las 4 libertades básicas del movimiento del Software Libre. Pero desde Creative Commons se ha asegurado cumplir con esta definición a través de la licencia de Reconocimiento y Reconocimiento-CompartirIgual. El dominio público también cumple con los requisitos de la Free Cultural Works, y para identificar claramente una obra con ésta definición se creó un logo.

Puede que haya licencias que se adecuen a tus necesidades, pero pueden ser un arma de doble filo, puede que no quieras que con tu obra no se beneficie nadie económicamente. Pero puede jugar en tu contra, si alguna vez deseas utilizarlo para una actividad comercial y cobres por ello, o en el peor de los casos, debes competir contra tu misma fuente. Estarías infringiendote a ti mismo. Por supuesto, que esto no se aplica si no hay nadie que acuse de violación de derechos, y nadie se tira piedras a su propio tejado.

Después de analizar las posibilidades que nos ofrece Creative Commons, creo que es interesante utilizar este tipo de licencias, pues incluyen siempre el reconocimiento del autor, protegiendo así del problema que muchos autores se les pasa por la cabeza, el temido plagio.
Ya existen sitios donde puedes comprar, contenido bajo licencias Creative Commons, como Jamendo para la música, Flickr para fotos, o Blip.tv para videos, y actualmente youtube.

Roles en un proyecto de Software Libre

Si planeas empezar con un proyecto de Software Libre desde cero, puede que este apartado sea irrelevante. Parece que los roles empiezan a ser importantes cuando hay una cierta cantidad involucrada. Pero definir y saber qué y quién va ha realizar determinadas tareas, puede ser crucial en ciertos momentos para que el proyecto siga adelante. Es fácil que un proyecto de Software Libre tenga muchos colaboradores, por su propia naturaleza.

En 1975, Fred Brooks definió la Ley de Brooks, decía que cuando un proyecto de software crece, lo hace de manera exponencial, y cuando además está retrasando su salida el Manager tiende añadir a mas gente nueva al proyecto para terminar antes. Esto es un grave error pues esa gente nueva no conoce el modelo y tiene que ponerse al día, y al final acaban picando código alocadamente.

En Software Libre cuando mas grande es el proyecto, más propenso a tener roles. Como una gran orquesta, en la que cada uno debe dar su parte en su debido tiempo. Consiguiendo así una armonía.

Paso a describir una serie de roles básicos en cualquier proyecto:

Desarrolladores

Los creadores de código. Deben informar de sus cambios, no sirve de nada ser un lobo solitario y desarrollar por tu cuenta. Eligen que entorno de desarrollo se va a utilizar, aunque hay casos en los que no hay definido un IDE. Sus objetivos están dirigidos por lo que dicta la comunidad, pero sin llegar a la pasividad. No todos los desarrolladores tienen derecho a commit en el repositorio del proyecto, pues hay casos que deben ser revisados. Una vez realizado ese commit, hay que actualizar la lista de funcionalidades o errores corregidos.

Maintainers

Existen muchas subcategorias:

Patch Manager: Puede que el desarrollador no da a basto con los Bugs, y el Patch Manager debe canalizar esto. Debe acotar los bugs, ver cual es importante o no, si existe el patch que alguien lo revise o ellos mismos.
Manager de traduccion: documentación, código, internacionalización u localización. Portar código de un lenguaje de programación hacia a otro. Los mensajes de la interfaz. Los manuales.

Internacionalizacion trata de adaptar el software para otras culturas y/o idiomas, favorece la protabilidad. Da soporte para distintas monedas, soporte para unicode.
Localizacion son los mensajes de la interfaz de usuario.

Documentation manager: la guia del usuario, es una tarea tediosa. Se pueden vender como guías.
Issue Manager: Parecido al patch manager, pero también atiende a las peticiones. Encaja la oferta con la demanda.
FAQ Manager: Cuando un proyecto es grande es necesario. La tarea es sencilla, leer los foros y wikis en busca de preguntas. Tratar de buscar las mas frecuentes. Se formula bien la pregunta y se responde, y reorganizarlo para que no exista preguntas duplicadas y organizarlo por categorías.
Release Manager: Se encarga de las nuevas release, en Ubuntu son cada 6 meses. Suele ser un cargo que cambia mucho de persona, porque es una tarea agotadora. Tiene en la cabeza el RoadMap, tiene que cumplirlo, y si se desvía, trata de que haya consenso. Coordina todo para que haya homogeneidad.

Documentation writer

Lo que más importa es que escriba bien y no mucha cantidad. Lo mas conciso posible, con posibilidad de crear una guia del desarrollador. Un buen ejemplo GNOME Project system-admin-guide. También debe escribir/revisar la documentación de Man.

Distribution Developer

Se encarga de la homogeneidad del proyecto de paqueteria. Revisa las licencias.

Traductores

Hasta que el desarrollador no termina, no empiezan a traducir. Esto es debido porque puede haber cambios finales, en el que se muestre o se deje de mostrar un mensaje por pantalla. Por lo que tienen un esfuerzo extra antes de la siguiente release, pues siempre se están cambiando código contiuamente.

Tester

Personas encargadas de probar el programa, su correcto funcionamiento, o incluso forzar para que de errores. El skill de estos tester no es meramente técnico, cade vez es más social y útil por que da una visión más amplia del usuario final.

Community Manager

Construir, alimentar y expandir la comunidad, son las prioridades de esta persona. Que exista buen ambiente, proporciona atajos para encontrar a la persona que quieres, pues si alguien se quiere incorporar a realizar una tarea muy específica, es preferible que tenga contacto con las personas que han desarrollado o modificado esa parte de código. Al final puede acabar como un relaciones publicas. Cualquier proyecto colaborativo es necesario este rol, no solamente en proyectos de software. Ayudan a encontrar fuentes de ingresos. No se encarga directamente en todo, delega todo. Tiene un rango multidisciplinar. Son gente hiperactiva. Escuchan. Ayuda la colaboracion entre varios roles. Periodicamente hacen brainstorming, conferencias, para aportar nuevas ideas. Recomendaciones y guias de buena conducta.

Project Leader

Persona mas relevante o influencia en el proyecto, o por ser el fundador o porque te lo hayas ganado (Meritocracia). Por ser el fundador es fácil, por estar desde el principio y puso las reglas, el ejemplo mas claro es Linus Torvalds. Por meritocracia, es más difícil, se pueden equivocar sin tantos problemas como el fundador, pues el fundador lo debe conocer mejor que nadie. A veces se encuentran dictadores benevolentes, cuando se detecta que hay opiniones enfrentadas, se pide la actuación del dictador benevolente y se aplica su decisión.Capturan la esencia de la motivación del proyecto.

Todos estos roles no tienen porque ser obligatorios. Aunque muchos de ellos son indispensables, como los desarrolladores y un community manager que promocione el proyecto. Incluso se pueden crear nuevos roles, como los encargados del diseño de la aplicación, como su iconografía y darle un resultado vistoso. Antes este rol no tenía mucho sentido, pero poco a poco, la interfaz del usuario ha ido tomando un papel importante en el desarrollo de software. Por otro lado, llegar a conseguir uno de estos roles en ciertos proyectos, puede ser muy fácil en algunos casos o todo lo contrario. En el proyecto Apache tiene un proceso fuerte para incorporar a nuevas personas.

La finalidad de estos roles, es saber lo que tiene que hacer cada persona, en cada momento. También ayuda a involucrar a más gente el proyecto, que no tienen skill de programador, pero quieren colaborar igualmente. Nunca hay que rechazar una colaboración ;)

La Catedral y el Bazar

Cuando hablamos de este ensayo, estamos también hablando de Eric S. Raymond. En 1997 se le consideró una figura líder del movimiento Open Source. Fue cofundador de la OSI (Open Source Initiative). Contribuyó a la liberación del navegador web Netscape. Como programador coordino el cliente de correo Fetchmail, colaboró en Emacs, y Ncurses.

Y gracias a la colaboaración de este software, lo que le llevo a escribir un ensayo sobre dos modelos opuestos de desarrollo, la catedral es el modelo que utilizaban la mayoría de fabricantes de software, y el bazaar, más parecido al Software Libre.

Durante el ensayo, analiza 19 lecciones sobre su experiencia en estos dos modelos de desarrollo.

Todo buen proyecto de software comienza con la necesidad personal del programador.
Comienzan como su proyecto mascota, que cuidan y miman, pues es su obra. Al contrario que ocurre con el software privativo, en el que el programador realiza una tarea impuesta guste o no. Esta motivación explica grandes proyectos como el núcleo Linux.
Los buenos programadores saben qué escribir. Los mejores, que reescribir (y reutilizar).Absolutamente importante en el Software Libre, Linus Torvalds no empezó desde cero, cogió partes de Minix. Aunque finalmente reescribió el código, fue fundamental para comenzar con el proyecto.
"Contemple desecharlo; de todos modos tendrá que hacerlo." (Fred Brooks, The Mythical Man-Month, Capítulo 11). No se entiende el problema hasta que lo implementas por primera vez, por eso es recomendable, empezar de nuevo alguna vez.
Si tienes la actitud adecuada, encontrarás problemas interesantes.
Eric se encontró con un cliente de correo popclient interesante escrito por Carl Harris, pero lo tenía abandonado. Eric debía tomar la decisión de cogerlo y empezar a coordinarlo por su cuenta.
Cuando se pierde el interés en un programa, el último deber es heredarlo a un sucesor competente.
Antes de abandonar un proyecto de Software Libre, hay que encontrar un sucesor, que lo trate como si fuera de la mascota que tratábamos en el primer punto. Como bien dice el eslogan "No los abandones, ellos no lo harían", siempre hay alguien dispuesto a asumir ese cargo.
Tratar a los usuarios como colaboradores es la forma más apropiada de mejorar el código, y la más efectiva de depurarlo.
Y qué mejor ejemplo que el núcleo Linux. Cualquier persona tiene acceso al código y/o cambiarlo, encuentra fallos, y los puede arreglar, y en caso de no saber arreglar, lo puede comunicar al resto.
Libere rápido y a menudo, y escuche a sus clientes.
Totalmente necesario, y es fomentado gracias al sistema de canales de software. Se pueden mantener tres lineas de proceso, una estable, en la que se mantiene para implementar con gran cantidad de fallos testeados. Las nightly versiones previas a una estable para que los testeadores empiecen a probar posibles errores y corregirlos para la versión estable. Y un canal diario, en el que cambio que sea realice, cambio que está disponible al mundo. De esta manera estimulamos tanto a desarrolladores, usuarios entusiastas, y usuario s finales.
Dada una base suficiente de desarrolladores asistentes y beta-testers, casi cualquier problema puede ser caracterizado rápidamente, y su solución ser obvia al menos para alguien.
O definir la Ley Linus "con muchas miradas, todos los errores saltarán a la vista". En este punto se diferencia la catedral, con meses de revisión exhaustivos para alcanzar el máximo número de errores. Por eso se tarda tanto en aparecer nuevas versiones.
Por otro lado, el bazar, asume que los errores son evidentes cuando se muestra a desarrolladores entusiastas. Por consecuencia se libera más a menudo por incluir los cambios de estos.
Las estructuras de datos inteligentes y el código burdo funcionan mucho mejor que en el caso inverso.
Un problema universal es la dificultad de entender el código que otra persona a escrito. Realizar diagramas o definir las estructuras de datos utilizadas, permiten comprender mejor el funcionamiento del programa.
Si usted trata a sus analistas (beta-testers) como si fueran su recurso más valioso, ellos le responderán convirtiéndose en su recurso más valioso.Tal y como cuenta Eric, en su experiencia con Fetchmail, creo una lista beta para todos los que le preguntaron por la implementación. Anunciaba nuevas releases para estimular a que la gente lo probara. Escuchaba las opiniones de estos usuarios primerizos. Como consecuencia, dar importancia a estos recurso hará que tu software sea más práctico al final.
Lo más grande, después de tener buenas ideas, es reconocer las buenas ideas de sus usuarios. Esto último es a veces lo mejor. Obtener las opiniones de los usuarios es lo mas enriquecedor que debes tener en cuenta.
Frecuentemente, las soluciones más innovadoras y espectaculares provienen de comprender que la concepción del problema era errónea.Esto me recuerda mucho al punto 3, en algún momento, gracias a haber atendido a las sugerencias de los usuarios, podemos encontrarnos que el camino o las soluciones que se proponen son erróneas. Parar, dar marcha atrás para coger otro camino, es duro, pero merece la pena.
"La perfección (en diseño) se alcanza no cuando ya no hay nada que agregar, sino cuando ya no hay algo que quitar."Cuando el código va mejorando y se va simplificando, es cuando se hace lo correcto. Respecto a la interfaz de usuario, creo que pasa lo mismo. Para mi un claro ejemplo es Gnome, pasó de un entorno de escritorio para hackers, ya que cada componente tenia gran cantidad de configuración, a pasar a ser un escritorio multidisciplinar, se fue aligerando la interfaz de usuario, quitando opciones innecesarias.
Toda herramienta es útil empleándose de la forma prevista, pero una *gran* herramienta es la que se presta a ser utilizada de la manera menos esperada.Aquí juega un papel importante la innovación, dar al usuario esa manera de usar un programa que incluso mejora las expectativas.
Cuándo se escribe software para una puerta de enlace de cualquier tipo, hay que tomar la precaución de alterar el flujo de datos lo menos posible, y ¡*nunca* eliminar información a menos que los receptores obliguen a hacerlo!Puede parecer un comentario único para el proyecto en el que trabajaba Eric, pero creo que tiene importancia en la manera que si tienes un programa, que debe leer una entrada estandarizada, y después sacarla por pantalla o tratarla para una salida, debe mantener el mismo estándar.
Cuando su lenguaje está lejos de un Turing completo, entonces el azúcar sintáctico puede ser su amigo.
Un sistema de seguridad es tan seguro como secreto. Cuídese de los secretos a medias.

Estas dos lecciones son propias del proyecto Fetchmail, habla sobre el sistema de seguridad de la aplicación, cómo guardar y encriptar las contraseñas.
Para resolver un problema interesante, comience por encontrar un problema que le resulte interesante.Es la única forma de no abandonar un proyecto, como le ocurrió a Carl Harris. Hay muchos motivos para motivar a un desarrollador, en el Software Libre, mayormente no es económico, es mas bien una satisfacción de su ego y su reputación entre desarrolladores.
Si el coordinador de desarrollo tiene un medio al menos tan bueno como lo es Internet, y sabe dirigir sin coerción, muchas cabezas serán, inevitablemente, mejor que una.
Cuando Eric escribió esto, aún estaban empezando a dar sus frutos el Software Libre como movimiento. Creo que hoy en día está claro el éxito de un producto libre.

Tras estas 19 lecciones, tengo que recordar que es un ensayo, carece de rigor. Trata de generalizar todos los proyectos de Software Libre, aplicándole un modelo de bazar. Esto puede ser confuso, pues proyectos cómo el núcleo Linux pueden aparentar más un modelo de catedral, con un dictador benevolente a la cabeza que es Linus Torvalds. Quizá el bazar no es la definición mas correcta para definir un proyecto de Software Libre. Puede que el modelo de catedral y bazar de Eric se viera influenciado por los acontecimientos que se vivían por aquel entonces.

En cualquier caso, el mejor modelo que define el Software Libre es aquél que garantice las cuatro libertades.

PYMES ¿Cómo le afecta que el software sea libre o privativo?

Existe un momento en toda empresa, en el que se debe informatizar. Ya sea para gestionar la contabilidad, las facturas, hacer caja, escribir documentos o incluso publicitarse mediante un blog... Para manejar estos datos es importante decidir que software se va a utilizar para dicha tarea. Existe multitud de programas para ayudarnos en cada propósito. Entre ellas hay gran variedad de Software Libre. Pero, ¿en qué medida nos beneficia utilizar este tipo de software?

Interoperabilidad

Cuando elegimos Software Libre, aceptamos que tenemos libertad para utilizar el código fuente. Gracias a esta característica, sabemos cómo el programa procesa los datos, cómo se comunica con el hardware y la manera de introducir nuevos cambios para adaptarlo a cada necesidad en particular. Aunque no sea intrínseco, en la mayoría de los casos, el Software Libre cumple con estándares. Un claro ejemplo es del navegador web Firefox, incluye características del estándar de HTML, CSS o JavaScript. Pero también trae efectos de renderizado propios de Firefox y que no se incluye en ningún otro navegador. Esto ocurre con Internet Explorer, pero la diferencia es que, en Firefox al tener acceso al código, pueden incluirse como estándar de HTML5.

Control de los datos

No hay puertas traseras. Puede haberlas, pero sería dejarlas a conciencia o por error. Con el acceso al código, podemos trazar por donde entrar los datos, y donde deben acabar. Puede que para empresas pequeñas que manejen poca cantidad de información, ésto no importe, pero ahora que muchos datos están en la nube, hay que tener en cuenta empresas como Google, deben cumplir con leyes Americanas, que podrían obligar a tener puertas traseras con la NSA para cumplir la seguridad nacional. En el peor de los casos, hay proveedores en la nube que permiten la realización de backups en dispositivos locales.

Independencia del proveedor

En muchos casos, el software se hace a medida para solventar ciertas necesidades únicas en cada empresa. El acceso al código es fundamental para que podamos cambiar a otro proveedor de software y éste lo pueda entender. Aunque hay casos como Liferay, que a pesar de ser Software Libre, son el único proveedor en España.

Ahorro de licencias

El Software Libre es comúnmente "vendido" por suprimir por completo el coste de las licencias. Hay programas en lo que esto no es una realidad, porque no existe una alternativa a la altura. Sí... los que usen AutoCAD para arquitectura, deberán seguir utilizando su licencia, porque Blender es más especifico para la animación. Pero en otros ámbitos, existen alternativas totalmente viables, como LibreOffice como suite ofimática. Pero el ahorro de licencias no quiere decir me guardo ese coste desde el principio. Si veníamos de utilizar software privativo, hay que adaptarlo a la alternativa con Software Libre, hay casos mas fáciles y otros más complejos. Si nunca se ha usado el nuevo software, hay que enseñar a los usuarios a utilizarlo. Puede que un principio haya que reinvertir el mismo gasto en adaptarse a este cambio, pero en cualquier caso, es un gasto que irá en decremento.

Decisiones de adquisición

Puede ser nulo, eres libre de probar un nuevo software, comprobar si se adapta o poder adaptarlo a tus necesidades. Con software privativo no podemos hacer esto, pues aunque existan versiones de prueba, en algunos casos son con características capadas o por una duración determinada que no permite exprimir lo suficiente para tomar una decisión.

Gestión de instalación, más seguro de virus.

Es parte de la cultura del Software Libre, todo el mundo quiere la última versión. Y el sistema de paquetes ayuda a este hecho. Hay proyectos que actualizan cada 6 meses, como Ubuntu. En otros casos, puedes asociarte al canal de desarrollo de Firefox, y utilizar las últimas versiones compiladas dia a dia. Esto puede ser un engorro para más de algún administrador de sistemas que necesite comprobar la retrocompatibilidad, pero esta característica hace que el software siempre esté corrigiendo errores o incluyendo nuevas características. Actualmente hay ordenadores de oficina que tienen un Sistema Operativo de hace 10 años, me refiero a Windows XP. Aunque hayan sacado actualizaciones, hay que recordar que es un software que se creó hace ya bastante tiempo y eso puede acarrear muchos problemas de seguridad.

Creo que estos son unos puntos a tener en cuenta necesariamente, cuando vayamos a implementar software en una empresa. No debemos olvidarlos, pues muchas decisiones que se toman al principio, son cruciales para el futuro de esa información.

Software Libre

Dentro de poco hará un año que empecé con el Máster en Software Libre en la Universidad Rey Juan Carlos. Cuando empecé apenas llevaba tiempo usando Software Libre. No sabía exactamente que implicaba el uso legal de este tipo de software, cómo influye en la sociedad o si existían modelos de negocio detrás de este movimiento.

Para empezar a entender todos los entresijos, hay que remontarse a este personaje, Richard M. Stallman que por culpa de una impresora, a la que no podía hackear para hacerla funcionar con sus ordenadores, porque su fabricante no le envió el código fuente, empezó a idear el manifiesto GNU. A principios de los 80, por el MIT y otras instituciones, no temían si el código del programa que estaba desarrollando lo cogiera otra persona, por aquel entonces se ayudaba entre programadores compartiendo código. Entonces empezaron a obligar a los empleados de estas instituciones a firmar un acuerdo de no divulgación. Este par de hechos, hicieron ver a Stallman que había que conservar esa comunidad de Hackers, en la que el código, como conocimiento básico era transmitido sin ningún problema.

En 1983 Stallman anunció el Proyecto GNU, pero no fue hasta 1985 cuando se publicó el manifiesto, del que se pueden extraer las 4 libertades fundamentales.

Libertad 0, ejecutar el programa para cualquier propósito.
Libertad 1, estudiar/modificar el programa para aprender o usarlo como quieras. Se requiere del código fuente de forma legible para realizar esta acción.
Libertad 2, redistribuir copias para ayudar al prójimo.
Libertad 3, distribuir las versiones modificadas.

En este mismo se año también se creo la Free Software Foundation. Fundación encargada de eliminar las restricciones de copia, redistribución, modificación o manejo dél código.

Tal y como se dicta, son libertades y no obligaciones. Esto quiere decir que si realizas modificaciones de un software que sea libre, no tienes la obligación de distribuir esos cambios realizados en ese software.

Esto es lo que ocurre cuando un programa no tiene licencia. La licencia dicta lo que se puede, y se debe hacer con ese código. Para ello el autor debe poner claramente, bajo qué licencia publica su código. Pues si no pone nada, no se sabe si es libre o no.

Para solucionar este problema se creo la GPL. Básicamente lo que obliga esta licencia es a preservar que un programa sea siempre libre, de tal manera que las versiones modificadas, cuando sean publicadas deberán ser también GPL.

Ahora que estaban sentadas las bases del Software Libre, en abril de 1991 empezó a crearse Linux, el núcleo de un sistema operativo desarrollado por Linus Torvalds con 21 años, bajo licencia GPLv2.

Mientras Linux crecía de manera exponencial, se crearon multitud de empresas que utilizaban y apoyaban este movimiento. Pero poco a poco se vio que los ideales de la Free Software Foundation, eran demasiado restrictivos para el mundo empresarial/comercial. En 1998 se creó la Open Source Initiative, a raíz de la liberación del navegador web Netscape. Por aquél entonces Eric S. Raymond publicó La catedral y el bazar, analiza dos modelos de crear software libre, son las guías para el desarrollo de un proyecto libre. Junto con Bruce Perens, crearon esta iniciativa.

Entre todas las empresas que aparecieron, hay que dar una mención especial a Red Hat, ya que demostró que el uso de Software Libre puede hacer funcionar a una empresa económicamente. En agosto de 1998 salió a bolsa obtuvieron una gran posición.

Para mí, estos son los grandes, primeros hitos de la historia del Software Libre. Creo que con esto se demuestra la filosofía con la Free Software Foundation, la aplicación con el núcleo Linux, la GPL y la OSI, y los beneficios que puede tener una empresa como RedHat.

Como recomendación para ampliar más información, recomiendo este documental REVOLUTION OS y la publicación de Richard M. Stallman Free as in freedom.