domingo, febrero 10, 2008
My Stats On WCG
He puesto un widget con las estadísticas que genera mi Sempron 2200 en World Community Grid. Son modestas, pero es lo mínimo con lo que se puede colaborar en una buena causa, que para el que no sepa lo que es.. aqui:
jueves, febrero 07, 2008
El valor del OpenSource. Pero ahora hablando en Euros
Mirad por donde, voy a continuar con la conversación de lo que tiene el OpenSource y de lo que vale.
He encontrado la lista de las adquisiciones más sonadas y costosas del mundo del OS. Es la siguiente:
Ayer mismo discutía si el modelo OS no es una manera de crear dinero "gratis", montando una empresa con el único fin de ser comprada, y nutriéndose de contribuciones de una comunidad anónima. Algo así como pasa con casi todas las web 2.0.
Quizás si, y se den casos como este que comento, pero yo creo que lo que no tiene valor no se compra ni se vende, directamente no despierta el interés de nadie. Al menos, en la lista anterior no hay ninguna empresa que no se lo haya currado, mucho y durante mucho tiempo.
Solo el tiempo, y el mercado lo dirán, yo sigo contento con el modelo OpenSouce + soporte :)
He encontrado la lista de las adquisiciones más sonadas y costosas del mundo del OS. Es la siguiente:
- Sun buys MySQL, $1 billion, 2008
Sun now has their hands on the world’s most widely used open source database. - Red Hat buys Cygnus Solutions, $675 million, 1999
Red Hat started the open source acquisition race early when they bought Cygnus Solutions, providers of open source software support. - Citrix buys XenSource, $500 million, 2007
Considering how hot virtualization is right now, we can see why Citrix bought XenSource, the company behind the Xen virtualization software. - Yahoo buys Zimbra, $350 million, 2007
Yahoo already have their own email services, and with Zimbra they got an integrated email, messaging and collaboration software. - Red Hat buys JBoss, $350 million, 2006
Red Hat strengthened their SOA offerings by buying the JBoss Java application server. - Novell buys SUSE, $210 million, 2003
Novell got their own Linux distribution by buying SUSE. - Nokia buys Trolltech, $153 million, 2008
Trolltech is the company behind the Qt GUI framework which is used by the popular Linux desktop environment KDE.
Ayer mismo discutía si el modelo OS no es una manera de crear dinero "gratis", montando una empresa con el único fin de ser comprada, y nutriéndose de contribuciones de una comunidad anónima. Algo así como pasa con casi todas las web 2.0.
Quizás si, y se den casos como este que comento, pero yo creo que lo que no tiene valor no se compra ni se vende, directamente no despierta el interés de nadie. Al menos, en la lista anterior no hay ninguna empresa que no se lo haya currado, mucho y durante mucho tiempo.
Solo el tiempo, y el mercado lo dirán, yo sigo contento con el modelo OpenSouce + soporte :)
miércoles, febrero 06, 2008
Buceando en JBoss
Tras una intersante conversación con un ex-piratoso, me ha dado por bucear dento de JBoss (Redhat), de lo que ofrece tanto por su rama comercial como por la comunitaria.
He descubierto dos proyectos que me han llamado mucho la atención, la verdad. Uno porque puede casar muy bien con alguno de mis objetivos en Piratosa para este año (aún por desvelar) y otro porque me ha parecido un proyecto muy interesante.
El primero se llama Kosmos, y se trata de un conjunto de Portlets que sirven para monitorizar ciertas aplicaciones. Como un monitor para gestores de la configuración. Soporta: subversion, jira, sourceforge y cruisecontrol. Entiendo que no todo el mundo dispone de un proyecto en SourceForge, pero el de subversion y cruisecontrol pueden servir en más de un proyecto.
El otro proyecto interesante se llama mobicents (1) y (2). Este proyecto es un servidor orientado a eventos, de tal manera que sobre él se pueden implementar servicios de mensajería instantanea (XMPP-Jabber-Googletalk), VoIP, y prácticamente todo lo que queramos sobre multimedia-IP.
Ahora mismo no tenemos que cubrir ningún proyecto de estas características, pero nunca se sabe por donde va a salir el tema. Además, que se trata de un proyecto bonito, que quizás encaje con alguna barrabasada de proyecto-I+D+i...
He descubierto dos proyectos que me han llamado mucho la atención, la verdad. Uno porque puede casar muy bien con alguno de mis objetivos en Piratosa para este año (aún por desvelar) y otro porque me ha parecido un proyecto muy interesante.
El primero se llama Kosmos, y se trata de un conjunto de Portlets que sirven para monitorizar ciertas aplicaciones. Como un monitor para gestores de la configuración. Soporta: subversion, jira, sourceforge y cruisecontrol. Entiendo que no todo el mundo dispone de un proyecto en SourceForge, pero el de subversion y cruisecontrol pueden servir en más de un proyecto.
El otro proyecto interesante se llama mobicents (1) y (2). Este proyecto es un servidor orientado a eventos, de tal manera que sobre él se pueden implementar servicios de mensajería instantanea (XMPP-Jabber-Googletalk), VoIP, y prácticamente todo lo que queramos sobre multimedia-IP.
Ahora mismo no tenemos que cubrir ningún proyecto de estas características, pero nunca se sabe por donde va a salir el tema. Además, que se trata de un proyecto bonito, que quizás encaje con alguna barrabasada de proyecto-I+D+i...
lunes, febrero 04, 2008
Fábricas de software, creatividad y sueldo
Me he encontrado con un artículo publicado en Cinco Días, en el que se pretende fomentar el outsorcing europeo a empresas españolas. Lo mejor de todo es el motivo: somos baratos.
La que se ha liado con el tema en barrapunto es buena, y con razón. Pero la conversación ha ido por otros derroteros:
Se habla de las condiciones de trabajo, que si las 10h al día, que si los 16mil al año, que si las factorías son cárnicas... y todo lo que muchos ya nos sabemos casi de memoria. ¿Y es verdad? Pues por desgracia sí. Y no creo que exista ningún informático que no haya hecho horas o sepa de cerca por donde van los tiros.
Además de las discusiones, las repercusiones ya se ven: cada vez hay menos informáticos en las aulas. Sin embargo yo no creo que sea una mala noticia. Me explico.
Tal vez yo esté traumatizado (empiezo a pensar que si) por mi época universitaria, pero he de decir que aquello estaba plagado de oportunistas. Por aquellas lo de "haz infomática que tiene mucho trabajo y cobran una pasta" sonaba. Claro, estábamos por los dosmil. Tanto es así, que gente de mi bachillerato, de los que iban para educación, o biología, aparecieron en mi clase de la universidad el primer día sin haber encendido un ordenador.
El resultado es que esa gente ha acabado la carrera, y ahora trabajará... donde sea, pero sin tener ni puta idea - que eso nos pasa a todos al empezar-, pero con una diferencia: sin la más mínima curiosidad. Con ese panorama, trabajando en algo que no les gusta, viendo que cobran 16mil, y que trabajan sus 10horitas... echarán pestes de aquello y estarán quemados. Lógico. El desengaño del oportunista. Pero se lo merecen.
Lo "bueno" que tiene el nuevo panorama es que ahora ya no pasará eso. Con las aulas vacías no habrá "oportunistas", sino gente a la que le verdad le interesa o le gusta la informática. Saldrán generaciones de gente que, además de correrse sus buenas juergas en la universdad, habrán aprendido aquello que les gusta y querrán seguir aprendiendo en su vida laboral.
Quizás con la aún mayor escasez de informáticos útiles, y quien sabe, puede que hasta un poco más de reputación profesional (algo más allá del friki). El informático de profesión tome cierta relevancia social y profesional, y acabemos siendo valorados social y económicamente.
Cada vez tengo más claro que la informática no es cosa ni de técnicos ni de superiores (ni mucho menos los panolis de primera de los que ya hablé), sino de gente con curiosidad por este tema, con ganas de aprender cada día, de encontrarse retos cada día. Como dice Fowler esto no es construir un puente. Tampoco es cosa de frikis.
El informático, por definición, es un ser blandito (si estás cuadrado no vales, huesudo si vales) que le gusta reirse de cosas escritas en binario (hex tb vale) pero que además siente la inquietud de averiguar, investigar y probar en su casa cosas nuevas (apis, tecnologías, leer sobre metodologías, sistemas operativos, videojuegos) que despiertan su interés y le abren el espectro de visión para hacer su trabajo de manera creativa.
Y eso se merece un dineral al mes.
La que se ha liado con el tema en barrapunto es buena, y con razón. Pero la conversación ha ido por otros derroteros:
Se habla de las condiciones de trabajo, que si las 10h al día, que si los 16mil al año, que si las factorías son cárnicas... y todo lo que muchos ya nos sabemos casi de memoria. ¿Y es verdad? Pues por desgracia sí. Y no creo que exista ningún informático que no haya hecho horas o sepa de cerca por donde van los tiros.
Además de las discusiones, las repercusiones ya se ven: cada vez hay menos informáticos en las aulas. Sin embargo yo no creo que sea una mala noticia. Me explico.
Tal vez yo esté traumatizado (empiezo a pensar que si) por mi época universitaria, pero he de decir que aquello estaba plagado de oportunistas. Por aquellas lo de "haz infomática que tiene mucho trabajo y cobran una pasta" sonaba. Claro, estábamos por los dosmil. Tanto es así, que gente de mi bachillerato, de los que iban para educación, o biología, aparecieron en mi clase de la universidad el primer día sin haber encendido un ordenador.
El resultado es que esa gente ha acabado la carrera, y ahora trabajará... donde sea, pero sin tener ni puta idea - que eso nos pasa a todos al empezar-, pero con una diferencia: sin la más mínima curiosidad. Con ese panorama, trabajando en algo que no les gusta, viendo que cobran 16mil, y que trabajan sus 10horitas... echarán pestes de aquello y estarán quemados. Lógico. El desengaño del oportunista. Pero se lo merecen.
Lo "bueno" que tiene el nuevo panorama es que ahora ya no pasará eso. Con las aulas vacías no habrá "oportunistas", sino gente a la que le verdad le interesa o le gusta la informática. Saldrán generaciones de gente que, además de correrse sus buenas juergas en la universdad, habrán aprendido aquello que les gusta y querrán seguir aprendiendo en su vida laboral.
Quizás con la aún mayor escasez de informáticos útiles, y quien sabe, puede que hasta un poco más de reputación profesional (algo más allá del friki). El informático de profesión tome cierta relevancia social y profesional, y acabemos siendo valorados social y económicamente.
Cada vez tengo más claro que la informática no es cosa ni de técnicos ni de superiores (ni mucho menos los panolis de primera de los que ya hablé), sino de gente con curiosidad por este tema, con ganas de aprender cada día, de encontrarse retos cada día. Como dice Fowler esto no es construir un puente. Tampoco es cosa de frikis.
El informático, por definición, es un ser blandito (si estás cuadrado no vales, huesudo si vales) que le gusta reirse de cosas escritas en binario (hex tb vale) pero que además siente la inquietud de averiguar, investigar y probar en su casa cosas nuevas (apis, tecnologías, leer sobre metodologías, sistemas operativos, videojuegos) que despiertan su interés y le abren el espectro de visión para hacer su trabajo de manera creativa.
Y eso se merece un dineral al mes.
sábado, febrero 02, 2008
Empezando a pensar ágil
Hace ya un tiempo que me empieza a picar el gusanillo de lo ágil. Sé que no es el modelo que mejor casa en una factoría, pero dado que cada vez tenemos proyectos más llave en mano quizás sea algo que debamos abordar.
También ha ayudado a ello gente del equipo en el que trabajo, con experiencia en este tema. Ayer, sin ir más lejos, estuvimos manteniendo una conversación sobre XP, y ahora estaba leyendo sobre ello.
A continuación os pongo un fragmento de "La Nueva Metodología", en la que Martin Fowler (ahí es nada) presenta sus razones por las que pensar ágil:
- Adaptabilidad de los procesos.
- Métodos orientados a la gente y no a los procesos.
"Separación de Diseño y Construcción
La inspiración usual para las metodologías han sido disciplinas como las ingenierías civil o mecánica. Tales disciplinas enfatizan que hay que planear antes de construir. Los ingenieros trabajan sobre una serie de esquemas que indican precisamente qué hay que construir y como deben juntarse estas cosas. Muchas decisiones de diseño, como la manera de controlar la carga sobre un puente, se toman conforme los dibujos se producen. Los dibujos se entregan entonces a un grupo diferente, a menudo una compañía diferente, para ser construidos. Se supone que el proceso de la construcción seguirá los dibujos. En la práctica los constructores se encuentran con algunos problemas, pero éstos son normalmente poco importantes.
Como los dibujos especifican las piezas y cómo deben unirse, actúan como los fundamentos de un plan de construcción detallado. Dicho plan define las tareas que necesitan hacerse y las dependencias que existen entre estas tareas. Esto permite un plan de trabajo y un presupuesto de construcción razonablemente predecibles. También dice en detalle cómo deben hacer su trabajo las personas que participan en la construcción. Esto permite que la construcción requiera menos pericia intelectual, aunque se necesita a menudo mucha habilidad manual.
Así que lo que vemos aquí son dos actividades fundamentalmente diferentes. El diseño, qué es difícil de predecir y requiere personal caro y creativo, y la construcción que es más fácil de predecir. Una vez que tenemos el diseño, podemos planear la construcción. Una vez que tenemos el plan de construcción, podemos ocuparnos de la construcción de una manera más predecible. En ingeniería civil la construcción es mucho más costosa y tardada que el diseño y la planeación.
Así el acercamiento de muchas metodologías es: queremos un plan de trabajo predecible que pueda usar gente del más bajo nivel. Para hacerlo debemos separar el plan de la construcción. Por consiguiente necesitamos entender cómo hacer el diseño de software de modo que la construcción pueda ser sencilla una vez que el plan esté hecho.
¿Qué forma toma este plan? Para muchos, éste es el papel de notaciones de diseño como el UML. Si podemos hacer todas las decisiones significativas usando UML, podemos armar un plan de construcción y entonces podemos dar planes a los programadores como una actividad de construcción.
Pero aquí surgen preguntas cruciales. ¿Es posible armar un plan que sea capaz de convertir el código en una actividad de construcción predecible? Y en tal caso, ¿es la construcción suficientemente grande en costo y tiempo para hacer valer la pena este enfoque?
Todos esto trae a la mente más preguntas. La primera es la cuestión de cuán difícil es conseguir un diseño UML en un estado que pueda entregarse a los programadores. El problema con un diseño tipo UML es que puede parecer muy bueno en el papel, pero resultar seriamente fallido a la hora de la programación. Los modelos que los ingenieros civiles usan está basado en muchos años de práctica guardados en códigos ingenieriles. Además los problemas importantes, como el modo en que juegan las fuerzas, son dóciles al análisis matemático. La única verificación que podemos hacer con los diagramas UML es la revisión cuidadosa. Mientras esto es útil trae errores al diseño que sólo se descubren durante la codificación y pruebas. Incluso los diseñadores experimentados, como me considero a mí mismo, nos sorprendemos a menudo cuando convertimos dichos diseños en software.
Otro problema es el costo comparativo. Cuando se construye un puente, el costo del esfuerzo en el plan es aproximadamente un 10% del total, siendo el resto la construcción. En software la cantidad de tiempo gastada codificando es mucho, mucho menor. McConnell sugiere que para un proyecto grande, sólo 15% del proyecto son código y pruebas unitarias, una inversión casi perfecta de las proporciones de la construcción del puente. Aun cuando se consideren las pruebas parte de la construcción, el plan es todavía 50% del total. Esto genera una pregunta importante sobre la naturaleza del diseño en software comparado con su papel en otras ramas de la ingeniería.
Esta clase de preguntas llevaron a Jack Reeves a sugerir que de hecho el código fuente es un documento de diseño y que la fase de construcción está en realidad en la compilación y el ligado. De hecho cualquier cosa que pueda tratar como construcción puede y debe automatizarse.
Estas ideas llevan a algunas conclusiones importantes:
En software la construcción es tan barata que es casi gratis.
En software todo el esfuerzo está en el diseño, de modo que requiere de personas creativas y talentosas.
Los procesos creativos no se planean fácilmente, de modo que la previsibilidad bien puede ser una meta imposible.
Debemos ser muy cautos al usar la metáfora de la ingeniería tradicional para construir software. Es un tipo diferente de actividad y por ende requiere un proceso diferente."
Tras leer el texto completo la única conclusión que saco es que XP es una buena metodología, y tiene mucha mucha razón, pero se han de conjugar una cierta serie de circunstancias para que sea beneficiosa con respecto a la adaptación de RUP que tradicionalmente seguimos en mi empresa.
Ahora mismo (acabo de leer el artículo) tengo unas cuantas por las que no pondría XP, entre las que enumeraría el análisis de riesgos, la gestión de plazos, la facturación y sobre todo la implicación del cliente, pero seguiré analizando y espero, dentro de poco, tener alguna conclusión menos inmediata, y sobre todo, más fundamentada.
Por si acaso os pongo el enlace al artículo traducido.
La inspiración usual para las metodologías han sido disciplinas como las ingenierías civil o mecánica. Tales disciplinas enfatizan que hay que planear antes de construir. Los ingenieros trabajan sobre una serie de esquemas que indican precisamente qué hay que construir y como deben juntarse estas cosas. Muchas decisiones de diseño, como la manera de controlar la carga sobre un puente, se toman conforme los dibujos se producen. Los dibujos se entregan entonces a un grupo diferente, a menudo una compañía diferente, para ser construidos. Se supone que el proceso de la construcción seguirá los dibujos. En la práctica los constructores se encuentran con algunos problemas, pero éstos son normalmente poco importantes.
Como los dibujos especifican las piezas y cómo deben unirse, actúan como los fundamentos de un plan de construcción detallado. Dicho plan define las tareas que necesitan hacerse y las dependencias que existen entre estas tareas. Esto permite un plan de trabajo y un presupuesto de construcción razonablemente predecibles. También dice en detalle cómo deben hacer su trabajo las personas que participan en la construcción. Esto permite que la construcción requiera menos pericia intelectual, aunque se necesita a menudo mucha habilidad manual.
Así que lo que vemos aquí son dos actividades fundamentalmente diferentes. El diseño, qué es difícil de predecir y requiere personal caro y creativo, y la construcción que es más fácil de predecir. Una vez que tenemos el diseño, podemos planear la construcción. Una vez que tenemos el plan de construcción, podemos ocuparnos de la construcción de una manera más predecible. En ingeniería civil la construcción es mucho más costosa y tardada que el diseño y la planeación.
Así el acercamiento de muchas metodologías es: queremos un plan de trabajo predecible que pueda usar gente del más bajo nivel. Para hacerlo debemos separar el plan de la construcción. Por consiguiente necesitamos entender cómo hacer el diseño de software de modo que la construcción pueda ser sencilla una vez que el plan esté hecho.
¿Qué forma toma este plan? Para muchos, éste es el papel de notaciones de diseño como el UML. Si podemos hacer todas las decisiones significativas usando UML, podemos armar un plan de construcción y entonces podemos dar planes a los programadores como una actividad de construcción.
Pero aquí surgen preguntas cruciales. ¿Es posible armar un plan que sea capaz de convertir el código en una actividad de construcción predecible? Y en tal caso, ¿es la construcción suficientemente grande en costo y tiempo para hacer valer la pena este enfoque?
Todos esto trae a la mente más preguntas. La primera es la cuestión de cuán difícil es conseguir un diseño UML en un estado que pueda entregarse a los programadores. El problema con un diseño tipo UML es que puede parecer muy bueno en el papel, pero resultar seriamente fallido a la hora de la programación. Los modelos que los ingenieros civiles usan está basado en muchos años de práctica guardados en códigos ingenieriles. Además los problemas importantes, como el modo en que juegan las fuerzas, son dóciles al análisis matemático. La única verificación que podemos hacer con los diagramas UML es la revisión cuidadosa. Mientras esto es útil trae errores al diseño que sólo se descubren durante la codificación y pruebas. Incluso los diseñadores experimentados, como me considero a mí mismo, nos sorprendemos a menudo cuando convertimos dichos diseños en software.
Otro problema es el costo comparativo. Cuando se construye un puente, el costo del esfuerzo en el plan es aproximadamente un 10% del total, siendo el resto la construcción. En software la cantidad de tiempo gastada codificando es mucho, mucho menor. McConnell sugiere que para un proyecto grande, sólo 15% del proyecto son código y pruebas unitarias, una inversión casi perfecta de las proporciones de la construcción del puente. Aun cuando se consideren las pruebas parte de la construcción, el plan es todavía 50% del total. Esto genera una pregunta importante sobre la naturaleza del diseño en software comparado con su papel en otras ramas de la ingeniería.
Esta clase de preguntas llevaron a Jack Reeves a sugerir que de hecho el código fuente es un documento de diseño y que la fase de construcción está en realidad en la compilación y el ligado. De hecho cualquier cosa que pueda tratar como construcción puede y debe automatizarse.
Estas ideas llevan a algunas conclusiones importantes:
En software la construcción es tan barata que es casi gratis.
En software todo el esfuerzo está en el diseño, de modo que requiere de personas creativas y talentosas.
Los procesos creativos no se planean fácilmente, de modo que la previsibilidad bien puede ser una meta imposible.
Debemos ser muy cautos al usar la metáfora de la ingeniería tradicional para construir software. Es un tipo diferente de actividad y por ende requiere un proceso diferente."
Tras leer el texto completo la única conclusión que saco es que XP es una buena metodología, y tiene mucha mucha razón, pero se han de conjugar una cierta serie de circunstancias para que sea beneficiosa con respecto a la adaptación de RUP que tradicionalmente seguimos en mi empresa.
Ahora mismo (acabo de leer el artículo) tengo unas cuantas por las que no pondría XP, entre las que enumeraría el análisis de riesgos, la gestión de plazos, la facturación y sobre todo la implicación del cliente, pero seguiré analizando y espero, dentro de poco, tener alguna conclusión menos inmediata, y sobre todo, más fundamentada.
Por si acaso os pongo el enlace al artículo traducido.
viernes, febrero 01, 2008
jueves, enero 31, 2008
El pañuelo rojo
Y me pierde, si me ponen el pañuelo... embisto.
"El «Software Libre» es un asunto de libertad, no de precio. Para entender el concepto, debe pensarse en «libre» como en «libertad de expresión», no como en «cerveza gratis»."
La frase está extraida del proyecto GNU. En la definición de software libre.
Motivado por la entrada a un blog amigo, he de hacer una reflexión sobre el OpenSource y el modelo económico que unas veces está detrás, y otras no.
Salvando las distancias con todo lo que tenga que ver con los diferentes tipos de licencia (GPL, Apache, Eclipse, ...), y conjugándolo con la frase con la que abro la entrada, podemos decir que dos tipos de proyectos OpenSource: los que disponen el código fuente de maner a gratuita y los que no.
No hay que confundir además con el tamaño de los proyectos, porque ahí está además el Kernel de Linux y su indudable caracter gratuito (y libre). De hecho, la palabra "Open Source" es un término que se introdujo para que no se entrase en la confusión de lo que es gratis y de lo que no, ya que el término "free" en inglés también significa gratis. Para que veamos hasta donde llega la importancia de este asunto, a los puristas del GNU no les gusta el término Open Source, porque dicen haber perdido el concepto de libre, mucho más explícito que el de "abierto".
Pues bien, en aquella entrada, el autor denotaba un cierto desengaño con el modelo comercial que se "esconde" dentro del mundo Open Source. Como si hubiese una especie de escondrijo o estratagema comercial. Creo que el desengaño no tiene que ver con el propio modelo Open, sino con el confuso concepto de gratuito, y expongo el porqué:
El modelo del OpenSource nació de la manera más idealista posible, compartiendo código en universidades y creando proyectos en colaboración. Ofreciéndo sus fuentes, y además de manera gratuita.
Con el tiempo esos proyectos crecieron (ahí está Linux) y empezaron a crecer. Se empezaba a ver la oportunidad de negocio con productos competitivos comercialmente y se empezó a ofrecer el "coge gratis todo el código (o binarios+codigo) y úsalo, si quieres soporte de expertos lo pagas". Ese es el modelo quizás más extendido ahora mismo, pero últimamente el modo de ofrecer ese código (o binario+código) cambia un poco (SuSE, RedHat o el mencionado en aquel blog JBoss). Ahora se paga por descargar el paquete y también por soporte. Lo que no deja de ser perfectamente lícito, y además legal.
No hay que pensar en que el OS es algo de románticos, ni de idealistas, porque no siempre es así. Lo bueno que tiene el movimiento OS es que tiene, gracias al GNU, ASF, Eclipse, licencias que lo protegen y que garantizan que eso seguirá siendo así... siempre. Y además permite que mucha gente (en empresas) vivan de ello. ¡Que los programadores también comen!
Por lo tanto, una vez que un "usuario" haya dispuesto del código fuente puede hacer con él lo que le dé la real gana (y eso incluye redistribuirlo) incluso sin que nadie tenga que pagar por ello. Con el software libre se compran empresas, no el código :-)
Y como ejemplo... solo hay que pensar en Linux. ¿no?
"El «Software Libre» es un asunto de libertad, no de precio. Para entender el concepto, debe pensarse en «libre» como en «libertad de expresión», no como en «cerveza gratis»."
La frase está extraida del proyecto GNU. En la definición de software libre.
Motivado por la entrada a un blog amigo, he de hacer una reflexión sobre el OpenSource y el modelo económico que unas veces está detrás, y otras no.
Salvando las distancias con todo lo que tenga que ver con los diferentes tipos de licencia (GPL, Apache, Eclipse, ...), y conjugándolo con la frase con la que abro la entrada, podemos decir que dos tipos de proyectos OpenSource: los que disponen el código fuente de maner a gratuita y los que no.
No hay que confundir además con el tamaño de los proyectos, porque ahí está además el Kernel de Linux y su indudable caracter gratuito (y libre). De hecho, la palabra "Open Source" es un término que se introdujo para que no se entrase en la confusión de lo que es gratis y de lo que no, ya que el término "free" en inglés también significa gratis. Para que veamos hasta donde llega la importancia de este asunto, a los puristas del GNU no les gusta el término Open Source, porque dicen haber perdido el concepto de libre, mucho más explícito que el de "abierto".
Pues bien, en aquella entrada, el autor denotaba un cierto desengaño con el modelo comercial que se "esconde" dentro del mundo Open Source. Como si hubiese una especie de escondrijo o estratagema comercial. Creo que el desengaño no tiene que ver con el propio modelo Open, sino con el confuso concepto de gratuito, y expongo el porqué:
El modelo del OpenSource nació de la manera más idealista posible, compartiendo código en universidades y creando proyectos en colaboración. Ofreciéndo sus fuentes, y además de manera gratuita.
Con el tiempo esos proyectos crecieron (ahí está Linux) y empezaron a crecer. Se empezaba a ver la oportunidad de negocio con productos competitivos comercialmente y se empezó a ofrecer el "coge gratis todo el código (o binarios+codigo) y úsalo, si quieres soporte de expertos lo pagas". Ese es el modelo quizás más extendido ahora mismo, pero últimamente el modo de ofrecer ese código (o binario+código) cambia un poco (SuSE, RedHat o el mencionado en aquel blog JBoss). Ahora se paga por descargar el paquete y también por soporte. Lo que no deja de ser perfectamente lícito, y además legal.
No hay que pensar en que el OS es algo de románticos, ni de idealistas, porque no siempre es así. Lo bueno que tiene el movimiento OS es que tiene, gracias al GNU, ASF, Eclipse, licencias que lo protegen y que garantizan que eso seguirá siendo así... siempre. Y además permite que mucha gente (en empresas) vivan de ello. ¡Que los programadores también comen!
Por lo tanto, una vez que un "usuario" haya dispuesto del código fuente puede hacer con él lo que le dé la real gana (y eso incluye redistribuirlo) incluso sin que nadie tenga que pagar por ello. Con el software libre se compran empresas, no el código :-)
Y como ejemplo... solo hay que pensar en Linux. ¿no?
Otra con nombre de mujer
Cuando leía sobre la adquisición de MySQL por parte de Sun, ya tuve la oportunidad de sorprenderme acerca de que MySQL estaba desarrollando otro motor de almacenamiento para MySQL, con el fin, sobre todo, de sustituir a MyISAM.
Todavía recuerdo que, en mis inicios profesionales (allá por MySQL 3) se discutía en piratosa si MySQL era transaccional o no, o si soportaba integridad referencial. Pues resulta que tenía mucho que ver con esto. O mejor dicho con el tipo de tablas que eligieses. MyISAM es un motor de almacenamiento que permite la gestión de registros de una manera muy rápida, pero que tiene sus pegas, y es que es fácilmente corrompible. Por ello funciona "tan bien" en entornos PHP-Web, pero se nos viene abajo cuando el OpenCMS empieza a mover ficheros a las tablas de backup/histórico como un animal y alguien le da al botón de apagar en Acens... jeje.
También existe InnoDB, pero por lo visto Oracle ha comprado la empresa que desarrolló InnoDB y, supongo que entre el miedo y las continuas quejas de los usuarios de MyISAM, MySQL se lanzó al desarrollo de su propio motor (aunque los dos anteriores siguen distribuyendose normalmente y no creo que desaparezcan).
Pues bien, hace unos días nació María (otro nombre bonito). Que es el motor que estrena MySQL en sustitución de MyISAM. Podeis leer todo sobre ella en el blog de su creador, Michael Widenius. También podeis bajaros la distribución de aqui. Por supuesto en MySQL 6 vendrá de serie.
Creo que con este paso se demuestra que MySQL sigue teniendo independencia a pesar de la compra por parte de Sun, y que su linea innovadora y de mejora avanza firme y que no se han dedicado a dormirse en los laureles.
Bien por ellos.
Todavía recuerdo que, en mis inicios profesionales (allá por MySQL 3) se discutía en piratosa si MySQL era transaccional o no, o si soportaba integridad referencial. Pues resulta que tenía mucho que ver con esto. O mejor dicho con el tipo de tablas que eligieses. MyISAM es un motor de almacenamiento que permite la gestión de registros de una manera muy rápida, pero que tiene sus pegas, y es que es fácilmente corrompible. Por ello funciona "tan bien" en entornos PHP-Web, pero se nos viene abajo cuando el OpenCMS empieza a mover ficheros a las tablas de backup/histórico como un animal y alguien le da al botón de apagar en Acens... jeje.
También existe InnoDB, pero por lo visto Oracle ha comprado la empresa que desarrolló InnoDB y, supongo que entre el miedo y las continuas quejas de los usuarios de MyISAM, MySQL se lanzó al desarrollo de su propio motor (aunque los dos anteriores siguen distribuyendose normalmente y no creo que desaparezcan).
Pues bien, hace unos días nació María (otro nombre bonito). Que es el motor que estrena MySQL en sustitución de MyISAM. Podeis leer todo sobre ella en el blog de su creador, Michael Widenius. También podeis bajaros la distribución de aqui. Por supuesto en MySQL 6 vendrá de serie.
Creo que con este paso se demuestra que MySQL sigue teniendo independencia a pesar de la compra por parte de Sun, y que su linea innovadora y de mejora avanza firme y que no se han dedicado a dormirse en los laureles.
Bien por ellos.
lunes, enero 21, 2008
Y BEA... con Oracle
Se me rompe el corazón. Y aunque esta "Bea" no sea mi favorita ;) creo que no es una buena noticia.
La adquisición de BEA Systems es un golazo que si bien era anunciado y previsible, no me ha gustado leer, y menos ahora que encima -parece- íbamos a empezar a trabajar con sus productos de verdad.
¿El objetivo de Oracle? está claro: comprar mercado. Estoy de acuerdo en que existan empresas que nazcan para ser absorvidas en uno u otro momento por algún gigante, como las operadoras móviles en España, pero no creo que BEA fuese una de esas.
Con casi total probabilidad BEA dispone de la suite de middelware - SOA - más avanzada, le da sopas con honda a las de IBM, JBoss y, por supuesto, a la propia Oracle. BEA tien grandes clientes y una proyección de futuro apuesto a que envidiable.
¿Y ahora? Pues parece que seguirá siendo así. Según parece no será absorvida "tal cual" sino que las dos empresas, al menos de momento, seguirán paralelamente sus caminos pero no más allá de la cuenta bancaria, claro. Yo no lo creo posible, y empiezo a argumentar porqué.
Como leía en uno de los blog a los que ando sindicado, todo lo que toca Oracle se lo carga. Y además lo sabemos: hace no mucho bromeaba con compañeros acerca del CMS de Oracle, de Coherence, de peoplesoft y supongo que de cientos de productos o compañías que adquiere para comprar también mercado, pero que tras la compra se ven tapados por una niebla espesa, que hace que no se vuelva a saber de ellos. Triste.
Y es que, pese a seguir la misma estrategia, Oracle se lo monta peor que Microsoft. Biztalk o Navision eran algo desconocido para mi hasta que los compró Microsoft. Justo al revés que con Oracle.
BEA ahora lo tiene difícil. Integrarse dentro de una gran compañía como Oracle supondrá un parón en su hasta ahora constante innovación que probablemente le lastre tecnológicamente.
No cabe duda de que una compra es algo dificil de llevar. Supone un cambio de jefe, integrarse dentro de las directrices (también las tecnológicas) de alguien ajeno a ti, y, lo que es peor: asumir que eres la comprada, que tecnológicamente eres mejor que la compradora, pero que has de agachar las orejas. Duro. Muy duro.
Más allá de eso, creo que ahora será más encarnizada la lucha Open vs Propietario. No cabe duda que quedan dos frentes abiertos: Sun/Jboss (por lo open) contra BEA/Oracle (porque no enseñan ni la goma del tanga). El mercado ahora está de un solo lado, pero la tendencia hacia el OpenSource es cada vez mayor, y el parón tecnológico que asumo para BEA/Oracle podrá poner a la par a "luchadoras" como RedHat y a la propia Sun. Emocionante.
Yo cada vez lo tengo más claro, y apuesto por el OpenSource en mi trabajo. Ahora estamos con Glassfish y propusimos JBoss como alternativa libre y con soporte a un integrador. También IBM Community Server (Apache Geronimo). Y Tomcat ya no es de juguete.
En el mercado de los servidores de aplicaciones el OpenSource ya tiene mucho que decir, pero en lo que se refiere a productos va por detrás. Eso sí, cumpliendo expectativas.
Lástima para Oracle, lástima para BEA. Otra oportunidad para el OpenSource.
Y en el fondo... lo que me jode... es cambiar el $BEA_HOME por el $ORACLE_HOME. Jejejje.
La adquisición de BEA Systems es un golazo que si bien era anunciado y previsible, no me ha gustado leer, y menos ahora que encima -parece- íbamos a empezar a trabajar con sus productos de verdad.
¿El objetivo de Oracle? está claro: comprar mercado. Estoy de acuerdo en que existan empresas que nazcan para ser absorvidas en uno u otro momento por algún gigante, como las operadoras móviles en España, pero no creo que BEA fuese una de esas.
Con casi total probabilidad BEA dispone de la suite de middelware - SOA - más avanzada, le da sopas con honda a las de IBM, JBoss y, por supuesto, a la propia Oracle. BEA tien grandes clientes y una proyección de futuro apuesto a que envidiable.
¿Y ahora? Pues parece que seguirá siendo así. Según parece no será absorvida "tal cual" sino que las dos empresas, al menos de momento, seguirán paralelamente sus caminos pero no más allá de la cuenta bancaria, claro. Yo no lo creo posible, y empiezo a argumentar porqué.
Como leía en uno de los blog a los que ando sindicado, todo lo que toca Oracle se lo carga. Y además lo sabemos: hace no mucho bromeaba con compañeros acerca del CMS de Oracle, de Coherence, de peoplesoft y supongo que de cientos de productos o compañías que adquiere para comprar también mercado, pero que tras la compra se ven tapados por una niebla espesa, que hace que no se vuelva a saber de ellos. Triste.
Y es que, pese a seguir la misma estrategia, Oracle se lo monta peor que Microsoft. Biztalk o Navision eran algo desconocido para mi hasta que los compró Microsoft. Justo al revés que con Oracle.
BEA ahora lo tiene difícil. Integrarse dentro de una gran compañía como Oracle supondrá un parón en su hasta ahora constante innovación que probablemente le lastre tecnológicamente.
No cabe duda de que una compra es algo dificil de llevar. Supone un cambio de jefe, integrarse dentro de las directrices (también las tecnológicas) de alguien ajeno a ti, y, lo que es peor: asumir que eres la comprada, que tecnológicamente eres mejor que la compradora, pero que has de agachar las orejas. Duro. Muy duro.
Más allá de eso, creo que ahora será más encarnizada la lucha Open vs Propietario. No cabe duda que quedan dos frentes abiertos: Sun/Jboss (por lo open) contra BEA/Oracle (porque no enseñan ni la goma del tanga). El mercado ahora está de un solo lado, pero la tendencia hacia el OpenSource es cada vez mayor, y el parón tecnológico que asumo para BEA/Oracle podrá poner a la par a "luchadoras" como RedHat y a la propia Sun. Emocionante.
Yo cada vez lo tengo más claro, y apuesto por el OpenSource en mi trabajo. Ahora estamos con Glassfish y propusimos JBoss como alternativa libre y con soporte a un integrador. También IBM Community Server (Apache Geronimo). Y Tomcat ya no es de juguete.
En el mercado de los servidores de aplicaciones el OpenSource ya tiene mucho que decir, pero en lo que se refiere a productos va por detrás. Eso sí, cumpliendo expectativas.
Lástima para Oracle, lástima para BEA. Otra oportunidad para el OpenSource.
Y en el fondo... lo que me jode... es cambiar el $BEA_HOME por el $ORACLE_HOME. Jejejje.
domingo, enero 20, 2008
Sun Compra MySQL
Pretendo que mis dos siguientes post tengan que ver con las noticias de la semana. Oracle compra Bea y Sun MySQL.
Una estaba anunciada, la otra creo que a casi todos nos ha pillado por sorpresa. Como bien ha dicho antes ... las cosas cambiarán, ¿pero qué? ¿quizás podamos intuir algo? Yo voy a hacer mis reflexiones...
Está claro que los dos movimientos son estratégicos (estas cosas siempre lo son), pero aunque tienen factores comunes -desarrollo de productos (Sun y Bea) y bases de datos (Oracle y MySQL)- creo que el fondo es bien diferente.
Si os parece voy a dedicar el primero de mis post a la noticia de Sun, que a pesar de ser la menos sonada, creo que es la que más interés tiene.
Sun ha cerrado un acuerdo de compra de MySQL por mucha mucha pasta.
Gosling comenta en su blog esto:
"Similar cultures, goals and markets."
Veamos los objetivos, culturas y mercados de cada una, empezando por la adquirida:
MySQL nació como un proyecto OpenSource con pocos recursos que ha ido tomando fuerza en el mercado y se ha ido haciendo hueco en nuestros equipos y corazones. Además, a mi juicio, ha ido siguiendo una estrategia de crecimiento muy bien definida, tanto técnica (p.e hasta la v4 no había subselects) como comercial que han concluido creando su versión comercial (mysql.com) con la que se ofrece soporte y mantenimiento. Ahora mismo debe haber unos 15 billones de bases de datos MySQL.
MySQL en estos momentos es una compañía de servicios más dentro del negocio del OpenSource, como es JBoss, o Alkacon, Alfresco, Interface21 u otras muchas. ¿Objetivo alcanzado?
Sun, por su parte, y desde hace un tiempo sigue fiel a su estrategia de liberar productos OpenSource del que ya hablamos en este mismo blog, y desarrolla con cada vez más éxito sus productos como Solaris, SPARC, Project Glassfish, Netbeans. Todos sabemos que la joya de Sun es Java, y sus proyectos Open como los ya comentados Glassfish o NetBeans le quitan protagonismo en los foros de Internet a Apache o al propio Eclipse. ¿Objetivo alcanzado? En ello andan.
Según lo comentado, y más allá del OpenSource, parece que Sun y MySQL no tienen objetivos ni mercados similares, ¿porqué dijiste eso Gosling?
Quizás lo que se pretendía decir es que es un buen momento para escribir un futuro común. Y en la que aparentemente ganan las dos partes.
Sin duda MySQL es la estrella en proyectos pequeños, y sobre todo en LAMP. A mi juicio no cabe duda. Sun intentará formar una suite parecida a LAMP, basándose en JRuby o el propio Java distribuyendo algo así como SGMJ + Netbeans. Impronunciable xDDDD. Ahora que está tan de moda esto de los stacks estoy seguro de que dentro de nada veremos uno nuevo con estas características.
Sun gana enteros dentro de la venta de hardware. Es fácil pensar que ahora es capaz de distribuir sistemas más complejos y hacer competencia no a Oracle, que son palabras mayores, pero quizás sí a Microsoft SQL Server y a PostgreSQL. Pero según palabras de Jonathan Schwartz no pretenden olvidarse de ellas. Sun quiere llegar a ser el número uno en datacenters, y para eso no puede dejar de lado a ningún SGDB que se precie. Por ello seguirá dando soporte como hasta ahora a Postgre, y seguirá compartiendo clientes con Oracle con su binomio (Oracle-Solaris). En sus objetivos sigue estando dar soporte a DB2 y cada vez más cerca a SQLServer, gracias a los acuerdos que llevan firmando ya un buen tiempo con Microsoft e Intel. Es un zorro Schwartz, pero alguna vez le tocará bailar con la fea.
La gente de MySQL está muy contenta, y ve una vía para ejecutar sus planes de ampliación. Además se garantizan una transición poco traumática, son 400 empleados y probablemente el cambio no vaya mucho más allá que la integración de los sistemas corporativos y la migración de los datacenter y callcenters. No pinta mal.
Paradójicamente, quizás el único perjudicado sea el usuario mediano (las pymes), que tendrá que pagar el soporte a Sun Microsystems en lugar de a MySQL AB. Los precios de soporte de Sun son mucho más altos, lo que hace que deba elegir entre pagar el soporte a Sun o bien tirar por la rama sin soporte y buscarse las castañas él solito.
Veremos como evoluciona esto. Creo que se trata de una buena noticia para todos, aunque me cuesta trabajo creerlo. El valor de Sun ha subido tras la compra....
Una estaba anunciada, la otra creo que a casi todos nos ha pillado por sorpresa. Como bien ha dicho antes ... las cosas cambiarán, ¿pero qué? ¿quizás podamos intuir algo? Yo voy a hacer mis reflexiones...
Está claro que los dos movimientos son estratégicos (estas cosas siempre lo son), pero aunque tienen factores comunes -desarrollo de productos (Sun y Bea) y bases de datos (Oracle y MySQL)- creo que el fondo es bien diferente.
Si os parece voy a dedicar el primero de mis post a la noticia de Sun, que a pesar de ser la menos sonada, creo que es la que más interés tiene.
Sun ha cerrado un acuerdo de compra de MySQL por mucha mucha pasta.
Gosling comenta en su blog esto:
"Similar cultures, goals and markets."
Veamos los objetivos, culturas y mercados de cada una, empezando por la adquirida:
MySQL nació como un proyecto OpenSource con pocos recursos que ha ido tomando fuerza en el mercado y se ha ido haciendo hueco en nuestros equipos y corazones. Además, a mi juicio, ha ido siguiendo una estrategia de crecimiento muy bien definida, tanto técnica (p.e hasta la v4 no había subselects) como comercial que han concluido creando su versión comercial (mysql.com) con la que se ofrece soporte y mantenimiento. Ahora mismo debe haber unos 15 billones de bases de datos MySQL.
MySQL en estos momentos es una compañía de servicios más dentro del negocio del OpenSource, como es JBoss, o Alkacon, Alfresco, Interface21 u otras muchas. ¿Objetivo alcanzado?
Sun, por su parte, y desde hace un tiempo sigue fiel a su estrategia de liberar productos OpenSource del que ya hablamos en este mismo blog, y desarrolla con cada vez más éxito sus productos como Solaris, SPARC, Project Glassfish, Netbeans. Todos sabemos que la joya de Sun es Java, y sus proyectos Open como los ya comentados Glassfish o NetBeans le quitan protagonismo en los foros de Internet a Apache o al propio Eclipse. ¿Objetivo alcanzado? En ello andan.
Según lo comentado, y más allá del OpenSource, parece que Sun y MySQL no tienen objetivos ni mercados similares, ¿porqué dijiste eso Gosling?
Quizás lo que se pretendía decir es que es un buen momento para escribir un futuro común. Y en la que aparentemente ganan las dos partes.
Sin duda MySQL es la estrella en proyectos pequeños, y sobre todo en LAMP. A mi juicio no cabe duda. Sun intentará formar una suite parecida a LAMP, basándose en JRuby o el propio Java distribuyendo algo así como SGMJ + Netbeans. Impronunciable xDDDD. Ahora que está tan de moda esto de los stacks estoy seguro de que dentro de nada veremos uno nuevo con estas características.
Sun gana enteros dentro de la venta de hardware. Es fácil pensar que ahora es capaz de distribuir sistemas más complejos y hacer competencia no a Oracle, que son palabras mayores, pero quizás sí a Microsoft SQL Server y a PostgreSQL. Pero según palabras de Jonathan Schwartz no pretenden olvidarse de ellas. Sun quiere llegar a ser el número uno en datacenters, y para eso no puede dejar de lado a ningún SGDB que se precie. Por ello seguirá dando soporte como hasta ahora a Postgre, y seguirá compartiendo clientes con Oracle con su binomio (Oracle-Solaris). En sus objetivos sigue estando dar soporte a DB2 y cada vez más cerca a SQLServer, gracias a los acuerdos que llevan firmando ya un buen tiempo con Microsoft e Intel. Es un zorro Schwartz, pero alguna vez le tocará bailar con la fea.
La gente de MySQL está muy contenta, y ve una vía para ejecutar sus planes de ampliación. Además se garantizan una transición poco traumática, son 400 empleados y probablemente el cambio no vaya mucho más allá que la integración de los sistemas corporativos y la migración de los datacenter y callcenters. No pinta mal.
Paradójicamente, quizás el único perjudicado sea el usuario mediano (las pymes), que tendrá que pagar el soporte a Sun Microsystems en lugar de a MySQL AB. Los precios de soporte de Sun son mucho más altos, lo que hace que deba elegir entre pagar el soporte a Sun o bien tirar por la rama sin soporte y buscarse las castañas él solito.
Veremos como evoluciona esto. Creo que se trata de una buena noticia para todos, aunque me cuesta trabajo creerlo. El valor de Sun ha subido tras la compra....
Suscribirse a:
Entradas (Atom)
