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
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).

CC BY-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).
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
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).
Sin obras derivadas: No se puede alterar, transformar o generar una obra derivada a partir de esta obra.


CC BY-NC
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.

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.

  1. 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.

  2. 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.

  3. "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.

  4. 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.

  5. 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.

  6. 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.
  7. 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.
  8. 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.
  9. 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.

  10. 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.
  11. 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.
  12. 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.

  13. "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.

  14.  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.

  15. 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.
  16. Cuando su lenguaje está lejos de un Turing completo, entonces el azúcar sintáctico puede ser su amigo.
  17. 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.
  18. 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.
  19. 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.

KDE


Kool Desktop Environment, así es una de las grandes alternativas al de entorno de escritorio para Linux. La famosa K proviene de CDE de Sun Microsystem, el que hasta entonces era lo que se usaba.


KDE es Software Libre, es obligatorio que toda aplicación incluida en KDE sea libre. Este concepto lo tienen muy claro, porque KDE se basa en el toolkit gráfico Qt, básicamente porque el creador , Matthias Ettrich, estaba trabajando con esta tecnología. Cuando empezó a crearse este proyecto, Qt era propiedad de TrollTech, y por entonces el código no era libre. Después fue comprado por Nokia y lo volvió a licenciar bajo LGPL. En el tiempo que no era Software Libre, es cuando apareció el proyecto Gnome, buscando esa libertad que no tenían con KDE.



No solamente KDE es un entorno de escritorio, son aplicaciones y además con capacidades multiplataforma, pudiendose usar tanto en Windows, Mac OS X o Linux. Por supuesto que esto aumenta la complejidad de la aplicación, pues cuando se desarrolla pensando en multiplataforma, hay que tener en cuenta los elementos característicos de cada Sistema Operativo. En Windows, el sistema de ficheros tiene como raiz en la mayoría de los casos C:/ pero esto no es viable en Linux, en el que la raiz es /. Por eso hay que utilizar las herramientas de la API creadas para todos los Sistemas Operativos compatibles, y realizar llamadas a esas funciones, que ya se encargará de reconoce en que sistema se encuentra y qué parámetros deberá utilizar. 
También hay que recordar que como plataforma compatible están Maemo y Meego, Sistemas Operativos para dispositivos móviles, impulsadas por Nokia, sobretodo Maemo, del que existen en venta unos pocos terminales.

Matthias Ettrich
KDE empezó en Octubre de 1996, por  Matthias Ettrich. Un año después, en Agosto de 1997, se realizó el primer meeting para organizar todo lo creado hasta entonces, KDE ONE. Poco después se consolidó KDE e.V. asociación sin animo de lucro que sirve para coordinar las subvenciones y donaciones recibidas. Posee la única empleada de todo KDE.
En Abril de 1998 se crea la KDE Free Qt Foundation, cuya principal misión es si alguna vez Nokia decide cerrar Qt, esta fundación de mantener un fork de la última versión libre bajo licencia BSD.
En Julio de 1998 aparece KDE 1.0 y en Septiembre del mismo año, se libera Qt bajo GPLv2.
en Octubre de 2000 aparece KDE 2, después de otros dos años, en Octubre de 2002 aparece KDE 3. Por lógica parece que en el 2004 debería aparecer KDE 4, pero no fue hasta el 2008 cuando apareció KDE 4. Cada versión ademas corresponde a una nueva versión de Qt, y en el último cambio fue muy drástico, pues Qt cambió mucho internamente, y tuvieron que trabajar mucho para cumplir con estos cambios. A pesar de su esfuerzos, KDE 4 se la recuerda por sus numerosos fallos, que posteriormente fueron corrigiendo en siguientes versiones.
La numeración de las versiones tienen el modelo KDE x.y.z donde:

  • x pertenece a un gran cambio.
  • y un cambio menor.
  • z versiones parcheadas.
La licencia que tiene hoy dia KDE son  LGPLv2, BSD, MIT, X11 y su documentación está en FDL. Qt   mantuvo durante mucho tiempo la filosofía de su licencia propietaria QPL, que permitía usar sus librerías, siempre y cuando no comercialices tu software, si deseas comercializarlo debías pagar la licencia y te daban soporte.



La comunidad realiza varias actividades, entre ellas las KDE Developer Meetings, cada año se realiza una, desde 1997. Con el tiempo paso a llamarse aKademy. También se hacen meetings de subgrupos como por ejemplo el de KDEEDU. Se destaca el aKademy de 2009 por realizarla conjuntamente con Gnome.
Como en otros proyectos similares, existe la meritocracia, pero dejan de lado la figura del dictador benevolente. Existen listas de correos, foro y chat en irc.freenode en el canal #KDE, para una buena comunicación con gente interesada en el proyecto.
Para obtener el derecho a commit, no es tan estricto como en otros proyectos. Aqui hace falta una persona que te avale dentro del proyecto, y también hayas contribuido previamente con parches.
No solamente necesitan programadores, pues también necesitan traductores, artistas gráficos, testers, escritores para documentar o promotores para dar marketing.

Existen empresas que gracias a KDE realizan su labor, como por ejemplo Kolab Konsortium que desarrollan un servidor de tipo LDAP, para compartir contactos , correo...

Toda esta información fue extraida gracias a la charla de Aleix Pol González que pertenece a KDE España, que dio en el Máster en Software Libre 2010/2011. Podéis ver los videos de la charla en los siguientes enlaces:

The Corpora - Qbo


The corpora es una empresa robótica de España, creada en el 2006 por Francisco Javier Paz entusiasta de los robots y experto en seguridad informática, vino a una sesión del Máster en Software Libre a presentarnos su proyecto, Qbo.
Francisco Javier Paz - Qbo
Qbo quiere romper con el modelo que se está siguiendo hasta ahora sobre la comercialización de robots. Actualmente, las empresas que se dedican a la fabricación o el desarrollo de robots asumen todo el gasto generado para crear el robot. 

El material con el que se fabrica es muy caro, el molde para crear una pieza en producción tiene un coste aproximado de 30000€, en el caso de Qbo, tiene 35 piezas. Cierto es que para el desarrollo se utilizan prototipado rápido con una calidad muy inferior a la final. Por otro lado tenemos el coste en I+D, los ingenieros encargados de que todo eso no sea solamente un montón de hierros con circuitos, creando la lógica y cómo se va desenvolver con el entorno. Estos costes incrementan el valor del producto, para que sea rentable y causa que mucha gente no compre un robot, solamente por el precio final en el mercado, como es el caso de Sony con el robot-perro Aibo con un coste final alrededor de 3500€.

Con Qbo se plantea un nuevo modelo de mercado, solamente venden la caja, esto puede ir dirigido a fabricantes que quieran incluir sus modificaciones y su lógica para después venderlo, o para usuarios finales, que deseen crear un robot a su medida.



El hardware está basado en Arduino, tiene una gran comunidad trabajando detrás. Permite adaptar todo lo que queramos. Se basa en un chip con un lenguaje de programación (Basado en C) y a partir de este chip, se van añadiendo componentes, como por ejemplo una webcam, GPS...

 
Por software lleva Linux como núcleo. ROS como sistema de control, framework. Festival para el habla sintética. Julius como reconocedor de voz, aunque le falta un modelo acústico y se ha creado VoxForge para colaborar con tu propia voz en el proyecto. OpenCV es una libreria para el reconocimiento espacial, reconoce objetos y su profundidad, de esta manera hace slam alrededor de donde se encuentra y crea un mapa interno.

Aparte de utilizar componentes libres y software libre, donde reside toda la "magia" del proyecto es en su sistema para gestionar la base del conocimiento. Esta base es la que se encarga de la lógica del robot, donde va a consultar ante cualquier elección que deba tomar. Su modelo en especial es que está en la nube, por lo que todo lo que aprenda un robot, o le enseñen, estará a disposición del resto de robots, pudiendo tener el mismo conocimiento al mismo tiempo.

Este modelo es totalmente innovador y muy útil. Pongámonos en el papel de ASIMO este robot tiene un desarrollo lógico que está creado por CMLabs. Ellos programan la lógica, pero ¿Que pasa si hay un caso de uso que no habían pensado?, se quedarían todos los robots sin ese conocimiento hasta que no recibieran una actualización por parte de ellos. Y lo peor de todo es que hay otras empresas como esta, que crean su lógica y no la usan nada mas que para un dispositivo en concreto.

La idea es clara, un modelo cerrado en el mundo de la robótica, no da y no ha dado sus frutos. Este cambio fomentará al uso de estas tecnología, a mejorarla entre todos (Crowdsourcing), y a un precio asequible. Por que no es lo mismo desarrollarlo sin tener el hardware que con él.

Los videos de la presentación los podéis encontrar en:

Gnome, historia y comunidad


Para entender el porqué de la existencia de este gran proyecto de Software Libre, que ha creado un modelo a seguir y del que aprender debemos remontarnos al principio de sus orígenes.



1995, apareció Windows 95. Fue el gran éxito de Microsoft, consiguieron llevar a casi todos los ordenadores del mundo su escritorio.
1996, empieza Matthias Ettrich a crear KDE por la necesidad de crear un entorno de escritorio para Unix
1997, se anuncia Gnome.

A pesar de que existía una herramienta de escritorio, KDE tenía problemas de licencia. Todo depende de Qt, una librería gráfica usada en este entorno de escritorio, por aquel entonces no era Software Libre, pertenecía a Troll Tech, y posteriormente pasó a Nokia y ahora... ¿Microsoft? Con Gnome, querían mejorar y crear una alternativa de interfáz gráfica de escritorio carente en UNIX. Hasta entonces se utilizaba X-Window de tal manera que cada aplicación quedaba muy aislada, manteniendo una interfaz poco homogénea.
También se buscaba integrar aplicaciones tal y como hace Windows, que viene integrado un reproductor de video y audio, gestor de correo, buscaminas... :P

                
Federico Mena
Miguel de Icaza
¿Y quienes empezaron con todo este lio? Uno de los responsables fue Miguel de Icaza, por aquel entonces tuvo cierto contacto con Microsoft donde le fascinó tecnologías como ActiveX. Quería transladar esta tecnología al mundo UNIX, asi que se juntó con su compañero de estudios Federico Mena.

Para comenzar este gran proyecto, se intentó no partir desde cero, ya que jugaban con gran desventaja, KDE y Windows llevaban mas tiempo cuando esto todavía no había empezado. La reutilización es uno de los paradigmas del Software Libre, así que decidieron contactar con Troll Tech para que cambiaran la licencia de Qt. No recibieron respuesta...

Necesitaban un toolkit gráfico, Federico trabajaba en el proyecto The Gimp, este software tiene su propio toolkit, asi que manos a la obra, separaron este componente del resto de la aplicación y nació GTK Gimp ToolKit.

A partir de entonces empezó a expandirse, en Agosto de 1997 se anuncia oficialmente a la comunidad. fueron sacando versiones en las que destaco la 0.20 por ser la primera en poder distribuirse. La versión 0.99 apareció casi un año después de anunciar en Noviembre de 1998, y poco después en Marzo de 1999 apareció la versión 1.00, fue un desastre porque por aquél entonces, tenían una guerra de versiones, en la que Gnome era la que menor versión tiene y creían que podría parecer un software inferior. Por esto emprezaron a utilizar el nombre de los meses como identificador de versión, October Gnome... pero al pasar un año, vieron que esta estrategia no era muy factible.


En Marzo de 2000 se celebra la primera Guadec en Paris. Un punto de encuentro  de usuarios y desarrolladores de Gnome.
Agosto de 2000  se crea la fundación Gnome apoyada por grandes empresas como IBM, Red Hat, Sun Microsystem (Oracle) y otras fundaciones como la Free Software Foundation.
Ya en Abril del 2001 se celebra la segunda Guadec en Copenague, y sale la versión 1.4 que traía novedades como Nautilus como gestor de ficheros, Evolution como cliente de correo, Abiword y Gnumeric como herramientas ofimáticas.



A pesar de todos los esfuerzos para crear un entorno para el usuario, aún era un entorno de escritorio demasiado hacker, demasiadas configuraciones, que para un usuario normal puede asustarle. Se realizaron estudios de usabilidad, accesibilidad para personas con discapacidad puedan usarlo, por ejemplo, utilizar un teclado en braile. Este estudio lo llevo acabo Sun Microsystem, y fue importante este hecho, pues que una empresa de gran tamaño, tiene mayor recurso, y no todo el mundo se puede permitir el hardware que hace falta para probarlo en condiciones reales. Todo esto se fue consolidando para salir en la nueva versión Gnome 2, junto con la Guadec de Sevilla. Con esta nueva versión se garantizo la retrocompatibilidad de la API / ABI con la versiones anteriores de Gnome. Aladidos como VFS, para  acceso a carpetas virtuales, Gobject es un sistema de orientación de objetos. GDKPixBuf para la carga y manipulación de imágenes. Fueron incluyendo más aplicaciones en cada versión hasta que llegó Gnome 3.

Al principio querían hacer coincidir la salida de la versión 2.30 como la versión 3, por el juego de números al correr la coma, y quitar el 2, nos da la versión 3. Pero aún no estaba preparado, no querían que ocurriera lo mismo que pasó con el lanzamiento de KDE 4.
Realizaron grandes cambios visuales, ahora utiliza Clutter como toolkit gráfico, con el que se puede realizar efectos 3D. Esto puede que en ordenadores más antiguos sea un problema, pues necesita de una aceleradora gráfica, aunque los problemas provienen sobretodo en los drivers para Linux de las tarjetas gráficas, no están lo suficientemente optimizados para que funcione fluido. A pesar de Clutter que nos sirve para los efectos visuales, no quiere decir que se abandona GTK, aparece la versión 3, con el que se rompe con la retrocompatibilidad. No quiere decir que no funciones aplicaciones en GTK2 sino que no podrán ejecutar componentes de diferentes versiones simultáneamente. El sistema de temas pasa a ser programado bajo CSS, una gran ayuda y facilidad para muchos desarrolladores web, acostumbrados a usar este estándar.Y empiezan a aparece características multitouch, que por ahora no se usan pero da una visión sobre donde podrá implementarse Gnome 3, como por ejemplo tablets o smartphones.

GNOME IS PEOPLE!
Después de hablar de la historia, no quiero cerrar el post sin hablar de las personas responsables de este proyecto, de la comunidad de Gnome. La comunidad está dividida en equipos, de los cuales existen de  desarrollo, traductores, documentadores, accesibilidad o Marketing. También existe la brigada de bugs que coordinan el bugzilla ahorrando trabajo extra a los desarrolladores. Existe una web centralizada con los recursos de comunicación, pero también puedes comunicarte a través de listas de correo, canales de char IRC. También existe una lista de aplicaciones incluidas en el entorno.
Existe la meritocracia por lo que a pesar de que exista cierta facilidad para dar tu opinión en listas de correo y demás, tiene mayor valor alguien que esté dentro del proyecto, y que haya colaborado previamente. Esto puede causar la ira de muchos Trolls dispuestos a flamear hilos de conversación, por eso se ha creado un código de conducta para evitar discusiones innecesarias.
Cualquier persona puede llegar a ser un committer del repositorio, para que alguien obtenga este permiso tiene que realizar una petición de cuenta, que por regla general es impulsado por el maintainer del modulo. Una vez obtenidos los permisos de commit no quiere decir que puedes subir cualquier código, debe ser revisado.
El maintainer es el encargado de un módulo, escribe las release notes, revisa parches para aprobarlos o rechazarlos, siempre explicando porqué y animando a que siga colaborando guiando qué cosas no fueron las correctas. Al final no dejan de ser dictadores benevolentes, ya que sus cambios no es obligatoriamente revisado.


Si quieres apoyar al movimiento puedes encontrar mas información en Gnome Hispano. Toda esta información ha sido recopilada gracias a las clases de Carlos García Campos realizadas durante el Master de Software Libre 2010/2011. Podéis encontrar los videos en los siguientes enlaces:

Netiquetas

Cuando mantenemos un proyecto de Software Libre o nos queremos dirigir a una comunidad ya establecida, no debemos lanzarnos a escribir en sus listas de correo, foros o cualquier canal de  comunicación público, si no antes cuidar nuestro lenguaje, a quién nos dirigimos y si realmente nuestra consulta es necesaria. Cada caso tiene unas ciertas reglas que deberíamos preguntarnos antes de escribir y después de escribir.

Para dirigirse a en un BTS (Bug Tracking System), intentar describir como reproducir ese bug, leer las instrucciones del mismo BTS sobre como se debe reportar un error en este sistema, si tenemos diferentes errores abir diferentes hilos. No utilizar un BTS como un foro de discusión, y sobretodo, y quizás lo mas importante, buscar o tratar de encontrar si tu error no existía previamente.

El código fuente también debe cuidar el aspecto, hay que utilizar las estructuras comunes de guías de estilo para cada lenguaje. Cada persona tiene su forma de escribir su propio código, pero para que todo el mundo nos sea más fácil comunicarnos con nuestro propio código, debemos escribir siguiendo unos patrones de estilo. No se escribe igual un código en Java y otro en Python, debido a su sintáxis, su escritura también difieren.
Cuando hacemos commit en el repositorio oficial debemos cuidar que el mensaje sea lo suficiente claro y conciso, no debe ocupar mucho, para que al verlo se pueda identificar qué cambios se han realizado, sin tener que ir linea por linea comparando código.

Si dentro del proyecto, estamos en un nivel jerárquico que nos posiciona como committers, y todos los parches deben ser aprobados por nosotros, como un dictador benevolente, debemos cuidar la manera de dirigirnos ante la persona que nos envía un parche. No todo el mundo tiene el mismo nivel sobre el proyecto, si por alguna razón, su parche es rechazado, cuidaremos nuestro lenguaje, pues la persona al otro lado, puede sentirse muy ofendido, y existen casos en los que con mucha razón. Un clásico ejemplo es el de Linus Torvalds https://lists.linux-foundation.org/pipermail/desktop_architects/2005-December/001588.html pues no cuida sus formas.

Estas y muchas más reglas fueron descritas por primera vez en el RFC 1855 . Más adelante, este tipo de personas o actos fueron tomando nombres, creando una jerga hacker, en las que podemos encontrar palabras como:

Flame: Término para describir una discusión sin sentido dentro de un foro o lista de correo.
Troll: Persona que dedica esfuerzos a crear Flame.
Lamer: Persona que a pesar de no tener un alto conocimiento técnico, presumen de tenerlo para tratar de tener fama.

Forjas, ¿Dónde alojar tu proyecto de software?

Cuando empiezas con un proyecto de software, no pensamos donde vamos a almacenar ese código que vamos escribiendo. Pero cuando llega el momento en el que decides liberar todo ese trabajo con el que te has peleado, para poder ayudar a otras personas con tu esfuerzo, necesitas un lugar para que el gran público pueda verlo, descargarlo, modificarlo y ejecutarlo. Para eso nacieron las forjas.

A continuación detallo unas forjas de las que he tenido experiencia:

Uno de los grandes para empezar. Google cuenta con esta forja que permite subir proyectos. A pesar de tener mucha fama a nivel internacional, cuenta con una serie de limitaciones:

  • Sistema de control de versiones: Subversion o Mercurial. No es que me parezcan pocas pero creo que mucha gente hecha en falta Git.
  • Licencias permitidas:  Apache, Artistic, BSD, GPLv2, GPLv3, LGPL, MIT, MPL y EPL aunque puedes utilizar cualquiera que esté aprobada por la OSI. Creo que es suficiente, aunque no deja de ser una pequeña limitación.
  • El número de proyectos que puedes alojar por persona, es de 25.
  • Desde ciertos paises no puedes acceder a esta herramienta,  Cuba, Iran, Libia, Corea del Norte, Sudan y Siria. 
  • Google Code no es libre, por lo que no podremos montar nuestra propia forja al estilo Google.
Como ventaja, es la API que incluye, con la que podrás integrar fácilmente otros productos de Google como Analytics. Permite crear una Wiki por proyecto.


Uno de los repositorios con control de versiones Git más famosos. Al igual que la forja de Google, los proyectos que subamos, deben tener una licencia de Software Libre. Pero en este caso permite crear repositorios cerrados pagando una cuota. Se detacan su fácil y agradable interfaz para navegar por partes del código públicado. No es Software Libre, pero nos facilitan su propio repositorio con gran cantidad de  software liberado de sus recursos, como la creación de wikis, la API o la forma de colorear la sintaxis de código.


Forja de ámbito nacional, la conocí gracias al contacto con Cenatic, donde mantengo alojado mi proyecto visor ODF para Android. La mantienen varias entidades como Telefónica, GSyC/LibreSoft,  Universidad Rey Juan Carlos (URJC), Universidad Politécnica de Madrid (UPM), Cenatic entre otros, y forman parte del centro de competencia Qualipso. Quizás no cuente con el estilo visual que competidores de la talla de Google, pero es un buen punto de partida para dar a conocer un proyecto dentro del ámbito nacional.

Por supuesto, existe una gran cantidad de forjas que no he mencionado, y de las que existe una buena tabla comparativa en Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities