Cinco soluciones basadas en Lucene para Real Time Search

Hace unos días trascendió que Twitter había terminado su proyecto de migración para su backend de búsqueda en tiempo real (search.twitter.com). El proyecto había comenzado en la primavera del 2010 y terminó en Abril del 2011 así que tenemos, tal y como señala Javier Murillo en su análisis, un año para un proyecto desarrollado por un equipo de quince ingenieros.

Twitter tenía dos problemas para querer cambiar la arquitectura de su sistema de búsqueda y que hasta el momento estaba basado en el modelo clásico de base de datos relacional. Uno era el que describen en el post de este mes, y es la escalabilidad. Con Rails estaban atados a un thread por búsqueda y eso hacía que desperdicien CPU y recursos mientras se está realizando la búsqueda. Algo realmente importante cuando tienes 12.000 búsquedas por segundo y mil millones de búsquedas diarias. Para eso decidieron migrar a una arquitectura asíncrona basada en Netty tal y como explica el artículo.

Retrospectiva sobre Hadoop y el Open Source

Eric Baldeschwieler, VP Hadoop Development en Yahoo, analiza en el blog de desarrolladores de Yahoo como ha sido la evolución de Hadoop durante sus cuatro años de vida y como ha influido la decisión de haberlo hecho Open Source en lugar de mantenerlo como un proyecto privado. ¿Fue una buena decisión?

La verdad es que atendiendo a sus comentarios parece que fue la mejor decisión que pudieron haber tomado. Yahoo nace en el 2006 y en su momento pensaron que no podía ser un producto de demasiado interés para sus competidores así que decidieron hacerlo Open Source simplemente para que se crease una comunidad de usuarios con itnereses relacionados. Con el tiempo todas sus expectativas se han disparado:

Software Libre distinto de Software sin Compromiso

¿Quién no conoce a estas alturas la frase "Software Libre distinto de Software Gratis"? No creo que sea necesario explicarla. Pero a cuento de un hilo en una lista de un proyecto Open Source (que tampoco quiero mencionar, porque no importa demasiado y porque es algo que se ve en muchas partes), pues llevo varios días pensando en lo frecuente que es el ver como en las comunidades de Software Libre se utiliza el hecho de tratarse de software abierto para excusar otros problemas.

Es especialmente frecuente el ver aparecer este tipo de excusa cuando las críticas arrencian, cuando los usuarios reclaman funcionalidades que sería difícil implementar, cuando carecemos de los recursos necesarios para hacer dichas funcionalidades, o cuando simplemente no nos apetece gastar nuestro tiempo en eso. ¿Por qué afirmo esto? Pues porque lo he visto en infinidad de ocasiones, y voy más allá, porque tengo que confesar que he utilizado dichas excusas en muchas ocasiones.

Cuando estaba en pleno desarrollo de jLibrary, era común el que llegase gente pidiendo cosas que podrían hacerse. Y la verdad es que siendo un equipo pequeño, no te queda más remedio que filtrar. A veces te llegaban sugerencias fenomenales, pero es que no te quedaba más remedio que cerrar la conversación con un "es un proyecto de Software Libre, puedes contribuir". Que conste que más de una vez funcionó, pero la mayor parte de las veces, la petición queda ahí, en una simple petición, y nunca recibías ningún parche.

Y no creáis que no me daba rabia el tener que sacar la excusilla de marras. Al contrario, me daba muchísima. Cuantas veces tengo pensado, ojalá tuviese aquí diez commiters totalmente motivados o un buen presupuesto para implementaros todo lo que pedís. Pero por desgracia, ni los tenía, ni parece que tuve la capacidad de convicción para atraerlos. Pero entonces, ¿por qué esa rabia? Pues porque para mi el Software Libre, por mucho que tengas esa excusa tan a mano y tan socorrida, no está exento de responsabilidad.

Cuando creas un proyecto abierto en Internet, eso tiene una responsabilidad enorme. O quizás soy yo que simplemente me lo tomo muy a pecho. Pero para mi, al abrir un proyecto le estás pidiendo a la gente que lo pruebe. Estás creando una comunidad. Una comunidad de personas que ponen su confianza en ti y en tu producto, aunque sea sólo para invertir treinta minutos en descargárselo, instalarlo, y probarlo. Si pasan de esa fase, incluso puede que lo comiencen a usar, y esos minutos pasan a ser horas, días, semanas, meses o años de confianza en tu software.

Y tú, como creador del software, necesitas de esa comunidad y su confianza. Porque al final lo que quieres es que tu producto lo usen más y más personas. Y después, con suerte, te harás famoso, podrás vivir de ello o vendrán y te comprarán por varios millones de euros, como ya ha pasado con muchas empresas. Pero sin confianza ni compromiso, nada de nada.

Pero hay gente que piensa que como es Software Libre, pues ya está, lo usas si quieres y punto, y si quieres mejorarlo pues no te quejes tanto y ponte a ayudar. Este argumento, tiene alguna base cuando utilizas un proyecto que lo mantienen cuatro gatos, sin ningún tipo de apoyo, pues como era el nuestro, y que a fin de cuentas es gente dedicando su tiempo libre a hacer algo que a otros les reporta un beneficio económico. Y digo alguna base, porque a fin de cuentas el creador siempre tiene sus motivos para crear el software e iniciar ese compromiso con sus usuarios.

Pero sin embargo, ¿qué argumentos se puede tener cuando tienes capital de sobra?, ¿o cuando te han comprado?, ¿o cuando eres una gran compañía? Por ejemplo, digamos que te compra una compañía que acaba de recibir varios millones de euros en inversión, tus usuarios te piden que redirijas un poco el proyecto para solucionar determinados problemas, y ¿tu respuesta es pedirle a los usuarios que en vez de protestar ayuden? Mal vamos. Más bien habría que pedirle a quien te ha comprado que ponga recursos para que el proyecto salga para adelante.

Os soy franco, para mi el argumento de "es software libre, puedes ayudar" no es válido cuando el proyecto pasa una determinada raya, la raya de la inversión, la raya del mega-éxito, o cuando simplemente están sustentados por compañías enormes. Proyectos como Alfresco, Spring, JBoss, Glassfish, MySQL, ... Señores, en muchas de estas compañías, ni te aceptarán los parches en caso de que los tengas, pues porque quizás no tengan tiempo, o porque sean parches que hagan conflicto con otros clientes, etc. (en una empresa en la que trabajé nos pasó algo de esto con Hibernate). Ellos han elegido el camino del Software Libre, y el Software Libre, ni es gratis, ni está exento de la responsabilidad hacia sus usuarios.

Un porcentaje de estos usuarios, seguramente alto, serán gorrones que no aportan nada, ni hacen contratos de mantenimiento, ni van a cursos oficiales, ni tienen sus certificaciones, pero.... son tus usuarios. Tú has escogido el modelo de negocio. Para bien o para mal. Y si los usuarios protestan normalmente es que el río agua lleva.

Perdón por el rant, pero es que el topicazo de "es libre, menos protestar y más ayuda" lo llevo fatal. Hasta cuando soy yo el que lo tiene que decir.

Imagen via schoschie@flickr

Knight News Challenge: 5 millones de dólares para proyectos sociales Open Source

Estamos en época de crisis. La bolsa se hunde y los bancos apenas disponen de liquidez. Aún así, todo el mundo comenta que emprender en Europa es muy complicado, y los emprendedores sufren para encontrar capital de riesgo. Con este panorama iniciativas como el Knights News Challenge toman mucho atractivo.

Se trata de un concurso en el que se reparten 5 millones de dólares en premios para proyectos y aplicaciones basadas en Software Libre y centradas en el desarrollo comunitario. Redes sociales, blogs sobre temas que afecten a la sociedad, herramientas para acercar las tecnologías a comunidades de ciudadanos, etc. Cualquier proyecto es válido con tal que cumpla los siguientes tres requisitos:

1. Ha de liberarse como software libre.


2. Ha de servir al interés público.


3. Ha de beneficiar a una o más comunidades geográficas.

Y para probar que la gente gana, se puede echar un vistazo a los ganadores del 2008 y 2007, que como veréis son proyectos normales y corrientes.

¿Alguien se anima? Se me ocurre que los chicos de Linking Paths podrían tener mucho que decir con su flamante Tog.

Spring cambia el modelo de mantenimiento, ¿y qué?

Desde luego, mira que egoistas somos. Tenemos un proyecto que probablemente hoy por hoy el 90% de los desarrolladores Java se está aprovechando de él, directa o indirectamente, y justo cuando el proyecto anuncia una nueva forma de ganar dinero nos lanzamos a criticarlo ferozmente por vendidos.

Claro, al fin de cuentas uno se acostumbra a tener unos cuantos esclavos de primera clase haciendo el trabajo que a nosotros nos llevaría años y sin cobrar ni un céntimo; y ojo con retrasarse en las releases que a nosotros nos gusta estar a la última; y apurando con esa actualización de la versión 1.1.0.2 de hace dos años que tengo un cliente un poco pesadito y necesito que me arregléis un bug que tenéis pendiente. Así que venga, que tenéis capital de riesgo y hay que ganarse el pan.

Estos dos párrafos derrochando ironia vienen a cuento de las reacciones en ese nido de trolls en el que se ha convertido lo que en su día fue una gran comunidad como TheServerSide y en el que no han tardado en despellejar a Spring por el anuncio de su nueva política de mantenimiento. Claro que tampoco es de extrañar ya que el portal ya se dedica sólo a noticias de lanzamientos de productos y rumores.

En InfoQ hacen un resumen mucho más pausado y tranquilo de el nuevo modelo de mantenimiento que básicamente viene a ser:

• Los usuarios normales (que no pagan) de Spring tendrán acceso a todas las builds de versiones mayores del producto.


• Los usuarios normales (que no pagan) tendrán acceso a las actualizaciones (bug fixes) de estas versiones durante los tres meses desde su lanzamiento.


• Los usuarios "enterprise" (de pago) tendrán acceso a todas las builds de todas las versiones incluso tras tres meses después de su lanzamiento.


• Todo sigue accesible en el repositorio de fuentes del proyecto, así que cualquier usuario puede descargarse un proyecto con los últimos parches y construirlo el mismo.

Teniendo en cuenta el último punto, en mi opinión no hay ninguna razón para protestar. A mi me parece una muy buena idea para monetizar el proyecto y estoy seguro de que muchos clientes decidirán subscribirse al mantenimiento para evitar el engorro de tener que descargarse los fuentes de una determinada versión y poder descargarse directamente una versión que puedan desplegar directamente.

Por lo demás, se supone que esto podría perjudicar a algún proyecto Open Source que necesita indirectamente los últimos parches, pero bueno realmente no creo que a los administradores de proyectos Open Sources les moleste demasiado descargarse Spring para tener los últimos parches; lo último es aplicable a cualquier persona que le guste estar a la última en cuestión de este framework.

Eso sí, ojo porque los chicos de SpringSource ya nos han sorprendido con un servidor de aplicaciones y con un nuevo modelo de mantenimiento más comercial. ¿Qué será lo siguiente?

jLibrary 1.2 ve por fin la luz: Historia de una release.

Ayer, hemos lanzado por fin la versión 1.2 de jLibrary. El trabajo en jLibrary 1.2 empezó hace más o menos un año cuando Dani buscaba algo que hacer y nos pusimos a trabajar en crear una aplicación web. La aplicación web fue tomando forma poco a poco. Y lo que empezó como un simple frontend para mostrar los documentos que estaban almacenados en un repositorio de jLibrary, pues como suele pasar se le van añadiendo más y más y más cosas y terminó en toda una aplicación web para visualizar y editar documentos, su contenido, sus relaciones, y personalizable mediante templates. En fin, lo que se puede ver desde hace tiempo en la página de la demo.

La web poco a poco fue recibiendo carga y eso permitió sacar a relucir unos cuantros problemas en la gestión de sesiones y de memoria. Venga. Seamos transparentes. La web no duraba más de un par de días funcionando! Aunque lo cierto es que estabamos hablando de utilizarla con 128Mb de RAM, que hoy por hoy no es nada para un servidor. Pero no es escusa. Una vez solucionados esos problemillas, hubo que dedicarse a mejorar el sistema de seguridad. Lo bueno de crear una aplicación web de este estilo sobre una aplicación de escritorio es que saca a relucir casos de uso no existentes hasta el momento, como podía ser el disponer de una área pública para la publicación de documentos en la demo al tiempo que la sección de docuemntación de la demo seguía siendo privada e intocable. Como anécdota puedo contar que algún malvado consiguió evitar los chequeos de seguridad y borrar la documentación. Que mejor estímulo para arreglar algunos bugs!!

Después de todos los arreglos, la web ya funcionaba mucho mejor. Al principio como no estaba seguro después de los problemas de memoria, le llegué a dedicar 384Mb. A medida que fue madurando y madurando lo bajé a 256, 128 y 64Mb. Estuvo funcionando durante algún tiempo con 64Mb, pero al ampliar la memoria de mi servidor a 1Gb decidí darle 128Mb constantes para olvidarme un poco del tema. Y lo cierto es que parece que las optimizaciones funcionaron, porque normalmente nunca tengo que rearrancar el servidor de jLibrary salvo cuando mi proveedor tiene que reiniciar el servidor físico. Ahora mismo lleva casi un mes funcionando y ha servido unos 7000 documentos, 12000 downloads de ficheros y 20000 visualizaciones de directorios entre otros. Eso sí, la carga es super-modesta, y siempre está sobre las 10/20 sesiones concurrentes. No es demasiado, pero bueno, tampoco está mal para 128Mb.

Durante el camino se unieron al proyecto un par de desarrolladores polacos, Ryszard y Renata Perkovski, que por curiosamente se vienen a trabajar a Dublin, y que se dedicaron en pleno al interfaz de usuario. Añadieron mejoras en la usabilidad, integraron el editor XML de WTP, adaptaron y mejoraron la build de Maven para trabajar que fuera más sencilla (jLibrary creo que es uno de los pocos casos en los que se ha sido capaz de integrar Eclipse RCP con Maven) y lo más importante es que actualizaron todo a Eclipse 3.4. Ayer lo estuve probando, y la verdad es que el rendimiento y aspecto de la aplicación ha mejorado un montón con esta nueva versión de Eclipse. Usar Eclipse RCP tiene sus desventajas, pero también tiene muchas ventajas, siendo una de ellas que cada vez que hay versión nueva de Eclipse, es como si hubiese una versión nueva de tu aplicación :)

Aún así, allá por Marzo, empezé un nuevo proyecto totalmente diferente, que me ha tenido ocupado durante todos estos meses, por lo que jLibrary quedó un poco (bastante) de lado. Y era una pena porque esta nueva versión estaba listísima, sólo hacía falta ese empujoncito de un par de semanas para que viese la luz. Al final, allá por Mayo llegó una empresa rusa, Blandware que se interesó en el proyecto y empezó a aportar parches importantes, tanto en el servidor como en el cliente. Sin duda lo más importante que han aportado ha sido el migrar el soporte que ya existía de propiedades personalizadas en los documentos al UI, es decir que ya se pueden añadir propiedades personalizadas desde el propio interfaz de usuario. Como esta gente no paraba de mandarme parches, lo que es muy bueno, al final he decidido cederles el mando de jLibrary, y han sido ellos los que se han encargado de preparar y lanzar la release, así que justo es el reconocerles el mérito.

En fin, está es más o menos la historia de jLibrary 1.2. Mucho más detallada de lo que aparece en las release notes. El proyecto por lo que a mi respecta es ahora mismo muy maduro, y aunque por ahora no continuaré desarrollándolo, espero que Blandware tire del carro. Es muy posible de todos modos que en unos meses lo recupere, ya que tengo pendiente la tarea de probar a añadir Amazon S3 como sistema de almacenamiento y aprovechar eso para desarrollar una idea que tengo en mente y que sería muy interesante para alguna startup chula. ¿Alguien interesado y con tiempo libre por ahí? Porque quizás podríamos hablarlo :)

Por cierto, que el que quiera descargarse jLibrary, pues ya sabe: jLibrary.org.

Dos productos Open Source interesantes saliendo de una tienda de viajes online

Leyendo InfoQ he visto que Orbitz, una compañía de venta de viajes online, curiosamente ha lanzado dos frameworks como Open Source.

Uno es ERMA del que a pesar de la presentación en la JavaOne, que aunque yo no sería partidario de implementar este tipo de frameworks en una empresa teniendo cosas Hyperic, Wily o insideApps que pueden cubrir muchas de las necesidades, siempre está interesante alternativas para el procesado de eventos. En InfoQ hablan también de Esper que parece realmente interesante.

El otro es Graphite, que personalmente lo encuentro más interesante porque, su motor, whisper, supone una alternativa a RRDTool (n su página tienen una discusión sobre las diferencias entre ambos motores), y siempre está bien disponer de alternativas, especialmente Open Source. En InfoQ comentan que lo utilizan para manejar información agregada de 70000 métricas lo cual no está del todo mal, aunque tampoco especifican cuanta memoria o hardware se necesita para ello. En el wiki quizás haya más información.

Por cierto, he visto que uno de sus autores, Ray Krueger, es también el creador de un plugin para integrar memcached como caché de segundo nivel en Hibernate. Ni idea de como funcionará, pero si alguien se anima a probarlo, me encantaría oir sobre los resultados.

Una de las divisiones de Open Source más importantes en el mundo del middleware podría desaparecer

Hace un par de meses IONA, la compañía de software más importante de la historia de Irlanda, y una de las compañías más importantes en el desarrollo de middleware hace diez años, confirmó que había recibido una oferta de adquisición que a tenor de los rumores que circulan por Dublin parece claro que están dispuestos a aceptar.

Anteayer publicaban en TheServerSide el rumor de que la compañía compradora podría ser Software AG. Pero lo realmente importante, y en mi opinión preocupante de la noticia, es que parece ser que la compañía compradora (no tiene por que ser la que nombran) ha estado intentando vender la división de Open Source de IONA a través del inversor que se está encargando de la operación. Parece ser que confirman que al menos dos compañías han recibido ofertas de este inversor para la venta de esta división.

Como bien mencionan en uno de los comentarios del rumor, y aunque sea una pena, el mundo del Open Source no está fuera del bien y del mal, y no escapa de los intereses de las grandes compañías en hacer dinero. Y en este caso, consideran que la división de IONA que ha trabajado en torno al Open Source durante casi dos décadas no puede dar dinero dentro del mundo de SOA. No deja de ser un poco triste que una de esas pocas compañías centradas en el desarrollo de Open Source y que dedica parte de su plantilla a contribuir código a la fundación Apache vaya a desaparecer de esta manera.

Hace unos meses hablaba sobre lo que me había impresionado
Apache Camel y James Strachan en sus presentaciones de la IJTC. Poco después se inició un proyecto en mi pasada compañía que utilizaba Apache Camel y la verdad que es un producto muy elegante. Supongo que una vez que se confirme este tipo de noticias el futuro de este tipo de proyectos estará un poco en el aire, aunque con un poco de suerte igual es una buena justificación para una start-up en torno a estos productos.

Por cierto que desde un mes antes al anuncio de que la compañía podría ser vendida, las acciones han subido hasta casi el doble...

Las 7 adquisiciones más grandes en el mundo del Open Source

Muy interesante entrada en Pingdom (parece que estos chicos no dejan de sacar entradas interesantes) que analiza las siete compras más caras del mundo del Open Source (sin contar algunas de las que no se tienen números).

Sun compara MySQL por 1000 millones de dólares,2008.

RedHat compra Cygnus Solutions, una empresa de soporte para productos Open Source por 675 millones de euros, 1999.

Citrix compra XenSource por 500 millones de dólares, 2007

Yahoo compra Zimbra por 250 millones de dólares, 2007

Red Hat compra JBoss por 350 millones de dólares (barato creo), 2006

Novell compra SUSE por 210 millones de dólares, 2003

Nokia compra Trolltech por 153 millones de dólares, 2008

Exceptuando dos, todas las compras se han producido en los dos últimos años, lo que indica claramente que el valor del Open Source ha crecido enormemente. Esto que comento se viene a reflejar en un estudio del grupo 451 donde se ve que el número de compras ha pasado de 6 en el 2003 a 30 en el 2007.

Por último se preguntan, ¿quién será el siguiente? Esta pregunta es difícil porque cada vez quedan menos. Tenemos a Postgresql en las bases de datos, Spring en cuanto a desarrollo, G2One (groovy/grails) podría tener potencial de compra aunque por ahora poca cosa, Terracotta sería apetecible. Pero quizás si tuviese que apostar probablemente lo haría por producto más tipo Alfresco o Pentaho, o quizás a algo más bloggeril como Wordpress.

¿Vuestras apuestas?

por cierto, si alguien quiere pujar por jLibrary ya sabe ;)

jLibrary web disponible

Daniel Latorre ha sido tan amable de anunciar oficialmente (en castellano) en su blog el lanzamiento de la nueva web de jLibrary y su demo online. Durante los últimos meses Daniel y yo mismo hemos estado trabajando en llevar a jLibrary a la web, y creo que el objetivo se ha cumplido y que el resultado es bastante satisfactorio.

Desde que comencé el proyecto allá a finales del 2003, desde siempre la principal "feature" que había faltado era la posibilidad de navegar tus respositorios de documentos via web. La aplicación de escritorio es fenomenal, y siempre recibo mensajes o leo mensajes en el foro del proyecto hablando maravillas de la misma. Pero lo cierto es que una de las cosas de las que me arrepiento en este proyecto es el de no haber lanzado la web con mucha más antelación. Pero bueno, el proyecto siempre ha sido un playground en si mismo, y creo que tanto Daniel como yo mismo lo hemos aprovechado para aprender nuevas tecnologías estos últimos meses.

La demo está disponible en http://demo.jlibrary.org. Daniel explica en esta entrada como utilizarla. Ambas páginas, la demo y jLibrary, comparten el mismo servidor pero son distintos repositorios de documentos. La única diferencia es que la demo te permite subir documentos y jugar un poco con ellos. Se puede acceder a ambos repositorios usando el cliente de escritorio, aunque eso ya está explicado en la documentación.

Por aportar algo más deciros que el desplegar esta web online nos ha ayudado ha encontrar algunos leaks en el sistema que estaban ahí, ocultillos. Hemos desplegado un sistema de monitorización que nos ha sido bastante útil para ello, así que ahora estamos bastante contentos con el resultado. El servidor es bastante modesto y está ejecutándose sobre un VPS con 384Mb de RAM, aunque realmente no utiliza mucho. La verdad es que no tengo números muy exactos porque siempre reinicio el servidor para meter algún parchecillo, pero la última vez que miré llevaba una semana de ejecución y no había hecho ni una sola "major garbage collection", lo que está muy bien :)

Claro que una segunda lectura es que la actividad no es demasiada, jejeje. Solemos tener entre 5-10 sesiones abiertas, se suelen crear cada dia unos 3 o cuatro documentos, actualizarse lo mismo y la gente va creando también unos cuantos comentarios. El repositorio anda por los 100Mb, 200Mb de tamaño y normalmente la gente visitará unas 1000 o 2000 páginas por día, más o menos.

Update: Desde que lo han anunciado en javaHispano ahora ya sabemos que soporta bien las 60-70 sesiones concurrentes :-)

Como veis, números muy modestos, pero estamos bastante contentos con el resultado. Por cierto, muchas gracias Dani por echarme una mano con esto, ya que si no estuvieras tú por ahí, no creo que el proyecto hubiese visto la luz.

Los sin sentidos de VMWare respecto al Open Source

O quizás debiera haber titulado este post "Los sin sentidos de Diane Greene...". Dian Greene es la CEO de VMWare y que durante estos dos últimos días ha recibido feroces críticas de The Register a raiz de una entrevista que mantuvieron con ella recientemente.

En la entrevista la dejan fina. Pero, en una entrada de hoy mismo, tampoco se quedan cortos. VMWare es ya la quinta empresa de software más valiosa del mundo, (se excluye IBM y Google) al menos siguiendo las valoraciones de la bolsa de Nueva York, y tras dos meses en la bolsa ha roto toda las expectativas y su capitalización en mercado ya es de 38 mil millones de dólares.

Pero parece ser que el éxito lleva a la extravagancia (tener una cascada en la sala de reuniones parece suficientemente extravagante) y que los medios dudan de la capacidad de Diane para dirigir la compañía por su falta de diplomacia y de saber estar ante los medios.

Y es que la CEO de VMWare no se corta a la hora de atacar a sus competidores y en especial de despreciar al Open Source con sus últimas declaraciones:

"What we want to do is fund ourselves to be able to build new stuff. If you're purely open source, there is no way you can do new stuff."

Parece que a pesar de ser la niña bonita de Wall Street, VMWare tiene miedo de Xen, compañía que arrasa en el mundo de los servidores virtuales y que poco a poco, y sin hacer tanto ruido se está haciendo con parte del mercado. Como resaltan en la columna de opinión que destacaba anteriormente, lo cierto es que VMWare está actualmente en una posición en la que no tiene que hacerle guiños a nadie, pero ¿es realmente necesario embarcarse en este tipo de luchas?

Linux en Wall Street

Menuda racha llevo. Vamos, que parece que desde hace un par de semanas no hay manera de mantener una regularidad en los posts. Nada más aterrizar de las vacaciones un virus me ha pillado por banda y me ha dejado literalmente KO durante dos días.

En fin, que por escribir algo se me ha ocurrido comentar algo que me dejé en mi último post sobre Wall Street. Ya os habréis dado cuenta por las transparencias del evento High Performance on Wall Street que Linux tiene realmente importancia ahí, especialmente para sistemas de computación en tiempo real.

Resulta que las mismas personas que organizan ese evento organizan también el Linux on Wall Street, donde obviamente Linux es el gran protagonista. Creo que no es un evento muy conocido en la blogosfera hispana ya que apenas me han salido resultados cuando he buscado gente que ya hubiese hablado de él. El caso es que las presentaciones parecen realmente interesantes y las podéis descargar desde este enlace.

Lotus Symphony, Eclipse RCP y Open Source

Como quizás ya conoceréis porque se ha anunciado en todas partes, esta semana IBM ha lanzado Lotus Symphony una suite ofimática destinada a competir con Microsoft Office y que por ahora se basa en Open Office 1.x pero que pronto lo hará en 2.x.



Ya adentrándose un poco más en la parte técnica del producto, lo que muchos no saben es que está basado en Eclipse RCP y por lo tanto se beneficia de muchas de las características que vienen ya con Eclipse como el soporte de OSGi, su update manager, su sistema de ayuda y sobre todo el poder integrar y aprovechar toda la plataforma en la que han trabajado durante años. No deja de ser interesante como se pueden sacar productos como una suite ofimática a partir de algo que inicialmente sólo era un entorno de desarrollo.



Ahora bien, realmente lo de que pueda competir con Microsoft Office, o google docs, ya es un poco más utópico, al menos por ahora. El anuncio del producto es bastante confuso y aunque en algunos sitios comentan que la suite es Open Source, a mi me da más bien la impresión de que simplemente han querido decir que se basa en Open Source (OpenOffice), ya que no he podido acceder al código fuente o encontrar nada relacionado con el desarrollo.

En caso de que fuese realmente Open Source, entonces sí que puede que la suite tuviese algo que decir, ya que al estar basado en Eclipse RCP sería realmente sencillo el crear aplicaciones que incrustasen esta suite, o aplicaciones que aprovechasen todos los componentes gráficos que incluye.



Una de las preguntas más típicas que me llegaban cuando estaba haciendo el cliente de jLibrary, y que todavía me llega de vez en cuando, era si se podía integrar OpenOffice en Eclipse RCP, y como hacerlo. Básicamente las opciones no eran demasiado agradables:

1. Usar las librerías Java de OpenOffice.


2. Integrar directamente el componente ActiveX (windows) y olvidarse de todo.

Sin embargo, si esta suite ofimática fuese realmente Open Source entonces ya se podría simplemente añadir los plug-ins necesarios y ya tendríamos OpenOffice listo para utilizar e integrar en nuestras aplicaciones corporativas. Y es que creo que eso de "¿puedo integrar Microsoft Office?" o "tenemos que crear un editor que sea igual que Office" es algo que más de uno estará acostumbrado a escuchar.



En fin, os dejo aquí unos cuantos enlaces en los que hablan de Symphony y su relación con Eclipse. Será interesante seguir como evoluciona el proyecto y ver si realmente tiene algún éxito.

Chris Aniszczyk sobre Lotus Symphony.
Lotus Symphony: First Impression.
Escape Velocity: Lotus Symphony.
My firsts impressions of Lotus Symphony.

Tus vecinos, los del Open Source

No es novedad, porque es algo que ya pusieron hace mucho pero quizás alguno no conozca todavía que ohloh la web social de proyectos Open Source se integra con Google Maps, así que puedes averiguar si tus vecinos participan o no en esto del Open Source.



Por lo de pronto la imagen de Irlanda es algo decepcionante, aunque está claro que mucha gente o no se ha dado de alta o no ha actualizdo su perfil con su geo-localización.

He añadido a mi ya de por sí sobrecargada columna derecha mi calificación, que aunque no es de las más altas (1000 y pico) estoy muy orgulloso de mi ocho -evitar los chistes :-)

¿Vale la pena buscar colaboradores en sf.net?

Ahí queda esta pregunta abierta. Y es que tengo que reconcer que el servicio de recruitment de SourceForge.net me frustra. En fin, aunque hay que reconocer que SourceForge no tiene ninguna culpa; bastante hacen ofreciéndome ese servicio gratuito.

El caso es que lo que os voy a contar ya no es la primera, ni la segunda vez que me pasa. Pero iluso de mi, la semana pasada volví a picar, y se me ocurrió publicar un trabajo buscando gente interesada en hacer algo con jLibrary. La idea era (y es) probar jLibrary, crear alguna aplicación interesante sobre la web (incluso tipo scribd, que la gente la pueda usar para probar frameworks web; en fin que es un campo de pruebas interesante, y se me ocurrió publicar un anuncio para ver si había alguien interesado en el Open Source y sus oportunidades.

Durante las tres semanas que ha estado el anuncio abierto me han llegado mensajes de trece personas interesadas, cosa que me parece que está bastante bien, y se asimila a lo que ya he tenido en las otras ocasiones que he publicado un trabajo. Lo que me frustra es que la mayoría de las personas que se ponen en contacto conmigo:

1. No tienen ni idea de que va el proyecto o,


2. tienen idea pero ni siquiera se lo han descargado y/o probado o,


3. no tienen los conocimientos suficientes de Java para bajarse Maven y construir el proyecto o,


4. tienen los conocimientos pero en cuanto ven que les pides un poco de esfuerzo para al menos construir el proyecto, ejecutar los unit tests, etc., se les baja el subidón inicial y prefieren buscar otra cosa más sencilla o,


5. (y esta es la buena) asumen que es un trabajo remunerado. Lo siento, pero en esta ocasión va a ser que no.

Uno de los últimos me mató cuando me pedía que le enviase la documentación de sus tareas y diagramas de diseño que especificasen lo que tenía que hacer. No sé si lo hizo a propósito pero vaya bajón de moral.

En fin que tras mis experiencias buscando gente en sf.net me queda claro que los canales tradicionales: amigos, usuarios de tu aplicación, empresas interesadas, son mucho más productivos.

Presentaciones de las OSCON 2007

Pues nada, notita rápida. Ya se pueden descargar algunas de las presentaciones que se pudieron ver esta semana en la OSCON 2007.

Desde aquí.

Tienen buena pinta.

El stack Open Source y Java de Joost

Joost es una aplicación que está llamada al éxito. Viene avalada por los fundadores de Skype y Kazaa y básicamente se dedica a distribuir contenidos de televisión a través de una red P2P

En la ficha de Techcrunch podéis ver más detalle sobre la compañía, que como se aprecia ya ha recibido 45 millones de dólares en capital de riesgo. El caso es que un amigo me comentaba que su stack está completamente basado en Open Source y Java.

Investigando un poco se puede llegar a su página sobre Open Source donde describen todos los productos que utilizan tanto en cliente como en servidor. No los voy a listar porque ya lo podéis leer vosotros mismos. Destaca que utilizan PostgreSQL, Jetty, el hosting está en Ubuntu, el framework web es Apache Wicket, para clientes pesados utilizan Eclipse RCP, y por supuesto Spring.

Bueno, la verdad es que después utilizan un montón de cosas más e incluso lenguajes como perl, python, ruby, pero más que nada para interoperar. Su base se ve que sigue siendo Java. Sólo hay que echarle un vistazo a la lista de frameworks Java Open Source que utilizan:

abdera.client, abdera.core, abdera.extensions, abdera.parser, abdera.protocol, abdera.security, abdera.server, acegi-security, acegi-security-cas, acegi-security-catalina, acegi-security-jboss, acegi-security-jetty, acegi-security-resin, acegi-security-tiger, activation, ant, antlr, antlr3, aopalliance, arq, asm, aspectjlib, aspectjrt, aspectjtools, aspectjweaver, avalon-framework, axiom-api, axiom-impl, axis, axis-ant, batik, bcmail-jdk14, bcprov-jdk14, burlap, cas-server, cas-server-generic, cas-server-jdbc, cas-server-ldap, cas-server-trusted, cas-server-x509, cglib-nodep, colt, commons-attributes-api, commons-attributes-compiler, commons-beanutils, commons-beanutils-core, commons-cli, commons-codec, commons-collections, commons-configuration, commons-dbcp, commons-digester, commons-discovery, commons-el, commons-fileupload, commons-httpclient, commons-httpclient-contrib, commons-io, commons-jci-core, commons-jci-eclipse, commons-jci-janino, commons-jexl, commons-jxpath, commons-lang, commons-logging, commons-logging-adapters, commons-logging-api, commons-pool, comp4swt, concurrent, dom4j, ehcache, ehcache-remote-debugger, fop, geoip, geronimo-spec-jta, hadoop, hadoop-test, hessian, hsqldb, hsqldb-release, htmlunit, ibatis, ibatis-common, ibatis-dao, ibatis-sqlmap, icu4j, iri, itext, jakarta-slide-webdavlib, janino, jardiff, jasper-compiler, jasper-runtime, jasperreports, jaxen, jaxme-api, jaxrpc, jbarcodebean, jcalendar, jcommon, jdbm, jdom, jdtcore, jena, jetty, jetty-plus, jetty-util, jfreechart, jgroups-all, jmdns, jmxremote, jmxremote_optional, jnlp, jnlp-servlet, joda-time, joesnmp, joseki, json, jsp-api, jsr173, jsr173-ri, jsr94, jss-asn1, jstl, jta, jung, junit, ldapbp, log4j, lucene, lucene-similarity, lucene-snowball, mail, mina-core, mina-filter-codec-asn1, mina-integration-spring, mockrunner, nekohtml, ognl, opencsv, oro, oscache, oscore, osworkflow, poi, postgresql, propertyset, pull-parser, quartz, rmissl, rome, rome-fetcher, rome-itunes-rss-ext, rome-media-rss-ext, saaj, sandler, serializer, servlet-api, shared-asn1, slf4j-simple, spread, spring, spring-aspects, spring-beans, spring-binding, spring-core, spring-ldap, spring-mock, spring-webflow, standard, stax-api, stax-utils-snapshot, stringtemplate, swtplus, velocity, velocity-dep, velocity-tools, wicket, wicket-auth-roles, wicket-contrib-dojo, wicket-contrib-velocity, wicket-extensions, wicket-spring, wsdl4j, wstx-asl, xalan, xbean, xbean_xpath, xercesImpl, xml-apis, xmlpublic, xmlunit, xpp3, xstream, yale-cas-client

Guau!

Sourceforge revoluciona el mundo del Open Source (otra vez)

Hace casi 8 años (aquí un enlace a una presentación sobre su historia) Sourceforge.net revolucionó el mundo del Open Source al ofrecer a todo el mundo un repositorio público para alojar proyectos de manera gratuita. Durante todos estos años, Sourceforge.net se ha convertido en un punto de referencia para el mundo del Open Source y un lugar donde se alojan e incuban desde proyectos recien creados hasta otros mucho más maduros y mundialmente conocidos.

Es de sobra conocido, que durante todos estos años Sourceforge ha tenido muchos problemas, pero siempre los han ido resolviendo con bastante profesionalidad. Ahora, tras todo este tiempo, parece que están decididos a darle un nuevo empujón al mundo del software libre gracias al SourceForge MarketPlace.

Ayer me llegó un correo avisándome de que el SourceForge MarketPlace entraba en fase de beta y que se podía probar ya públicamente. Todavía no me he apuntado pero si vais a la web veréis que ya hay algo más de 60 proyectos que ofrecen servicios (cuando miréis habrá más seguramente). Pinchando en cada proyecto se puede ver los diferentes servicios que dicho proyecto ofrece, la duración del servicio y el precio del mismo.



Por lo que he visto navegando por el servicio los proyectos pueden vender servicios utilizando tarjeta de crédito, paypal o mediante un acuerdo para pagar con dinero en efectivo. Si no me equivoco se trata de una beta en la que le van ofreciendo gradualmente acceso a los proyectos, ya que a mi me ha llegado hoy la invitación pero ya había otros proyectos inscritos de unos cuantos días antes.

En mi opinión se trata de un gran empujón al Open Source. El concepto de donaciones introducido hace años ya estuvo muy bien, pero sin lugar a dudas esto va mucho más allá y rompe definitivamente el mito de "el Open Source es gratis y vive de donaciones".

Es más, seguro que mucha gente confusa con el concepto de OSS mostrará más interés al ver que hay soporte comercial detrás, y por parte de los desarrolladores originales. Por otra parte, ofrecer soporte comercial siempre te requiere un pequeño esfuerzo que SourceForge.net hace ahora por nosotros, lo que supone una gran ayuda para el proyecto pequeño que está empezando.

Un diez de nuevo para SourceForge.

jLibrary 1.1 disponible

Pues nada, me toca anunciar esta actualización de mi proyecto jLibrary que la mayoría ya conocéis. No me voy a parar mucho en las novedades porque, tampoco son muchas y las podéis encontrar en la web.

Lo más notable es la migración del cliente a Eclipse 3.2, la sustitución del protocolo de servicios web por algo más ligero basado en tunnelling HTTP, la posibilidad de añadir propiedades personalizadas a los documentos, y finalmente que ahora hay una nueva versión para Mac OS X. Además las versiones de Linux son mucho más estables ahora, y el proceso de construcción está basdo en Maven 2 y ahora es mucho más sencillo, lo que debería hacer más fácil que alguien interesado en el proyecto sea capaz de ponerse a trabajar con el en minutos.

Dejando a parte las novedades, para mi esta ha sido más que nada una versión de compromiso. Ha sido una actualización moral. Con jLibrary 1.0 había una serie de cosas que no me gustaban nada, especialmente que no pudieras subir documentos grandes (+10Mb) sin incrementar el tamaño del heap de las máquinas virtuales del cliente y servidor, todo ello debido al consumo y a la forma en que Axis transmite los contenidos. Otro compromiso fue las continuas peticiones por parte de usuarios de poder crear propiedades personalizadas, aunque esto último también tiene que ver con la orientación que le quiero dar ahora al proyecto. Y por último estaba la necesidad moral de cambiar el método de construcción; sustituir todos los hacks de Ant por algo mucho más decente y sencillo basado en Maven.

Todos estos cambios han llevado mucho más tiempo del que me temía. Mi cambio de residencia y de forma de vida ha reducido drásticamente el tiempo que le he podido dedicar al proyecto; y si antes podía dedicarle dos horitas extras al día, pues ahora se han convertido en dos horitas extras a la semana. Todo ello me ha hecho replantearme el futuro de jLibrary.

Y es que para mi ahora mismo jLibrary ha llegado a lo que debe ser un punto de inflexión. Muy probablemente esta sea la última versión del cliente basado en Eclipse RCP, que yo haga. En su momento estaba interesado en la tecnología, pero creo que ya la he aprendido más que de sobra :-) Así que es algo que no me motiva demasiado ya.

Lo que sí que me interesa mucho más ahora es trabajar en la parte servidor de jLibrary. En mi opinión el proyecto puede ser un banco de pruebas muy bueno para muchas tecnologías. Es un servidor estable, que ofrece una abstracción documental sobre una tecnología estándar (JSR-170) y que se me antoja como un banco de pruebas muy interesante. La idea es que para mi es más fácil ahora utilizar jLibrary para probar un determinado framework que crear desde cero todo un modelo de datos, relaciones, persistencia, configuración, etc.

Es decir, que si quiero probar Wicket, Seam y similares, pues puedo utilizar jLibrary para ello; que si quiero jugar con Grails, pues más de lo mismo; qué si lo que quiero es crear una web de reviews, un sistema de blogs, un youtube de documentos, o una alternativa a diggs meneames y similares, pues ahí está un framework que me ofrece ya las abstracciones para documentos, directorios, recursos, categorías, tags, relaciones, bookmarks, que además soporta propiedades personalizadas, y que tiene una aplicación de escritorio para administrar todos los datos.

Si alguien está interesado en esta idea, tiene algo en mente, quiere probarlo, etc., pues sólo tiene que mandarme un correo (mpermar en gmail). Las posibilidades están ahí, y a ver si sale algo de todo esto. Quizás no salga nada, pero mientras se pueda juguetear y aprender, pues ya habrá beneficio.

Sobre Software Libre y las nuevas formas de encontrar trabajo (y IV) (Hacerse mercenario)

Como muchos sabéis, hace unos meses escribí una serie de artículos en los que trataba de resumir muchas de las formas con las que hoy en día se puede encontrar trabajo gracias al Open Source, algo que hace unos años era impensable:
Sobre Software Libre y las nuevas formas de encontrar trabajo (I)
Sobre Software Libre y las nuevas formas de encontrar trabajo (II)
Sobre Software Libre y las nuevas formas de encontrar trabajo (y III)

Hacerse mercenario del Software Libre

En esa lista olvidé añadir una posibilidad con la que me encontré hace un par de semanas y que tanto InfoQ, como Rod Johnson en su blog, como OpenLogic han sacado a la palestra estos días.

Esta posibilidad es, como comenta el título del blog, vender tu alma al diablo. Hacerte mercenario del Open Source. O hablando más claro, que te subcontraten para dar soporte a proyectos de Software Libre. ¿Cómo es esto? Bueno, la verdad es que esta opinión tan dura que tengo viene a raiz de un email que me llegó hace tres semanas del CEO de OpenLogic y que directamente fue a parar a la basura, pero que he recuperado ya que la blogsfera ha sacado el tema a relucir. A continuación podéis ver algunos fragmentos (es bastante largo, al que le interese todo se lo puedo proporcionar, pero vamos que es lo mismo que podéis leer en su web):

I am contacting you because I’m looking for help supporting Apache Jackrabbit; we have customers who use Jackrabbit and look to us for support. We also have an offer going on right now – we are giving iPods to the next 25 people to join once they resolve their first issue.

We are inviting committers from leading open source projects to join the OpenLogic Expert Community. OpenLogic offers enterprises 24x7, one source of support for over 160 open source projects. We provide a first line of support – taking the calls from our enterprise customers and answering basic questions. For more complex issues (and after we’ve screened out the “read the manual” type questions), we turn to the OpenLogic Expert Community.

If you join the OpenLogic Expert Community, you will:

• get paid for each issue you resolve for your project. You can choose which issues you want to work on and you can choose to take that payment in cash or merchandise. You can even decide to direct your payment to your favorite open source organization.
• receive a $25 gift certificate to Amazon or Starbucks just for signing up. In order to become a member, you’ll need to sign our OpenLogic Expert Community agreement so that we can share confidential customer data with you. We understand reading legal agreements is not fun, so we’ve tired to keep it short and sweet -- and we’ll give you a gift certificate for your trouble.
• have the opportunity to hear first hand the challenges real users encounter when using your software.

Expuestos los hechos, no puedo más que comentar que realmente la estrategia de esta empresa me parece de lo más barriobajera. Por diferentes razones, incluso a las que Rod Johnson expone probablemente por no lanzarse al patio de lo políticamente incorrecto.

Primero, esta empresa contacta a cualquiera, estrategia que me parece bastante poco profesional, sucia, y también mezquina cuando la contrapones con sus argumentos a favor de su modelo de negocio. Y es que yo, en Jackrabbit soy un cualquiera, por mucho que tenga un proyecto basado en Jackrabbit, por mucho que mi nombre aparezca en la lista de contruibuidores, y por mucho que esporádicamente comente cosas en los foros.

Simplemente van a saco e intentan captar incautos que quieran hacer de soporte técnico para ellos, aunque ni siquieran sean muy activos, simplemente analizan la información del proyecto y proceden al envío de emails captación masivos.

Segundo, y como consecuencia del primer punto, esta empresa le hace un flaco favor al Software Libre. Obviamente (o al menos si tienen sentido común), esta gente no apunta a los top committers de los proyectos ya que la mayor parte de ellos ya tienen trabajos en empresas que los esponsorizan o que son propietarias del proyecto en cuestión. Así que su objetivo es la comunidad.

Por ejemplo, en el muy supuesto caso, de que para un proyecto cualquiera en concreto, un 50% entrase en el juego que plantean (esperemos que no), tendríamos que esas personas probablemente dejarían de participar en los foros porque tendrían su tiempo ocupado en resolver incidencias para otros. En este caso, dicho proyecto habría perdido el 50% de su comunidad lo que claramente tendría una influcencia negativa en su salud.

Muchos proyectos se basan en la comunidad. La comunidad y la colaboración son lo que realmente mueven a un proyecto de software libre. Un proyecto sano, es un proyecto con una comunidad sana. Cuanta más gente participa en los foros más dudas se resuelven, más confianza tienen los nuevos participantes, o más se animan las personas a participar en el proyecto y aportar sus parches. Esta empresa, OpenLogic, con su forma de actuar ataca a la linea de flotación de las comunidades.

Es esa actitud, la de asaltar directamente a los desarrolladores más modestos de los proyectos Open Source la que realmente me parece despreciable en su modelo; la de querer minar comunidades saludables convirtiéndolas en comunidades de mercenarios a sueldo que se peleen por resolver las incidencias con las compensaciones más suculentas.

Tercero, el modelo que plantean no es tan bonito. Ahí coincido bastante con Rod Johnson. Realmente plantean un modelo donde pagan a apagafuegos para que les saquen las castañas del fuego cuando en su equipo son incapaces de solucionar sus propios problemas. El contribuidor Open Source pasa a ser el último en la cadena, el que recibe todos los marrones.

Intentan vender unos sueldos magnificos de 100 dólares a la hora cuando probablemente sean 100 dólares a la semana por resolver un marronazo. Claro, por algo ellos no te recomiendan dejar tu trabajo diario para unirte a su programa.

Cuarto, en el caso de que un desarrollador fuese realmente bueno, no necesitaría realmente acudir a este tipo de empresas, sino que podría convertirse en un consultor autónomo y ofrecer sus servicios con su cuenta. Todos sabemos (especialmente en España) lo que significa estar subcontratado. Y en este caso encima estas subcontratado específicamente como la última opción, el come-marrones de turno para el proyecto Open Source en cuestión.

Pues bien, en caso de tener que ser un come marrones, pues casi mejor serlo por tu cuenta, sin tener que darle el 500% del beneficio a una empresa que no va a hacer nada más que rellenar el parte de la incidencia.

Fin de la crítica. Voy a parar aquí aunque realmente esto daría para rato. Ahora me voy a cambiar el traje y me convierto en abogado del diablo. Sea como sea la oferta que plantean es una opción para encontrar trabajo con el Open Source (de hecho, es que es un trabajo). Realmente puede ser una opción cuando no tienes otra fuente de ingresos, no planeas montarte un negocio con tu cuenta, y lo único que quieres es ganar un dinerillo durante unas semanas, meses, o lo que sea. En este caso, pues probar es una opción, pero yo intentaría tener siempre claro el donde te vas a meter, y el tipo de trabajo que vas a hacer. Pero vamos, que si lo que haces normalmente es estar en casa aburrido contestando dudas de Spring, y no te quieres meter en lios, pues puede ser una forma de ganar dinero, aunque la actitud de la emrpesa sea más o menos ética, pero una forma de ganar dinero a fin de cuentas.

El otro punto en el que puedo hacer de abogado del diablo es criticando la actitud de Rod Johnson. Porque, siendo sinceros, ¿qué va a decir? Interface21 es una empresa que vive directamente de dar soporte y consultoría, nada más. Y, la realidad es que aunque han hecho una gran labor y han contratado a muchos de los colaboradores, lo cierto es que muchas de las personas que participan en sus foros y resuelven problemas y dudas lo hacen por puro placer y en su tiempo libre.

Claro, estas personas, son un beneficio enorme para Interface21 ya que ellos pueden mantener a sus mejores desarrolladores ocupados en mejorar el producto (algo a fin de cuentas bueno para todos), mientras otras personas de su empresa y muchos voluntarios, que no veran un duro, hacen las labores de soporte técnico.

Desde el punto de vista de Interface21, OpenLogic es un peligro importante ya que les ataca en dos puntos críticos para ellos: Uno, les roban contratos de soporte ya que pueden acercarse a los clientes vendiéndoles la moto de que disponen de un equipo de soporte con muchos contribuidores del proyecto; y dos, ocupan el tiempo de la gente que participa en sus foros con incidencias de sus empresas cliente lo que potencialmente disminuye la participanción en sus foros y en general debilita la comunidad.

Vamos que, haciendo de abogado del diable, la respuesta de Rod Johnson tampoco es tanto mirando a la comunidad en general, sino que es también en cierto punto una respuesta interesada, mirando a su modelo de negocio y mirando a proteger a su propia comunidad.

Bueno, esto es todo. La verdad es que el post me ha quedado un poco ladrillo, pero bueno, el verme un poco involucrado por ser uno de los que ha recibido la oferta me ha hecho rajar un poco de más. Lo dicho, la opción de ganar dinero y encontrar un trabajo está ahí, pero yo tendría claro que es simplemetne convertirse en mercenario. Que puede que no esté mal para ganarse unos euros durante un tiempo, pero que yo no tomaría como la carrera a seguir dentro del Open Source.