OSGi no está listo para ser usado por la mayoría de los desarrolladores-Adrian Colyer, CTO de SpringSource

Esa es la afirmación que hace Adrian Colyer, el CTO (el chief technology officer, es decir, el principal cargo por la rama tecnológica de la empresa) de SpringSource. Ayer nos enterábamos de que SpringSource había decidido mover dmServer, un servidor de aplicaciones que no sólo está basado en OSGI (al igual que, por ejemplo, Glassfish o Eclipse) sino que pretende ir más allá y permitir que los desarrolladores que creen las aplicaciones para dicho servidor de aplicaciones usen OSGi en ellas.

Adrian Colyer en una extensa entrada en su blog explica el porqué de este movimiento. Según él, después de que la empresa haya invertido dos años en el producto y a pesar de todos los esfuerzos que han realizado el resultado final es algo que todavía resulta demasiado tedioso y complicado para los desarrolladores "comunes". En general, al menos desde su punto de vista, emplear OSGi en aplicaciones empresariales no compensa por lo complicado y tedioso que es, desventajas que acaban sobrepasando las ventajas que proporciona esta tecnología.

Según él, es necesario seguir realizando trabajo sobre OSGi para conseguir que deje de ser sólo una excelente tecnología para construir infraestructura y herramientas y pase a ser también una tecnología que puedan emplear los desarrolladores de las aplicaciones empresariales. Por ello, han decidido donar dos años de trabajo de la empresa a Eclipse, para que bajo esta fundación (la principal fundación que apoya y trata de fomentar OSGi) se continúe avanzando en esa dirección. A partir de ahora dm-server se convertirá en el proyecto Virgo.

Os dejo aquí un párrafo de Colyer que resume bastante bien su posición:

"There is a great deal of interest and innovation around enterprise OSGi and the dm Server.  This interest is strongest amongst early adopters, and projects with requirements that match closely the dynamically modular nature of the OSGi Service Platform. For a mainstream development team though, who just want to build an enterprise application as quickly as possible, and with as little hassle as possible, the costs currently associated with adopting enterprise OSGi can outweigh the short-term benefits. This situation needs to be addressed before enterprise OSGi can become the de-facto approach for mainstream enterprise application development.  Please note that I’m talking about enterprise application development here; if you’re writing infrastructure software [...] then OSGi is already the de-facto approach, and fully supported by the dm Server and the associated dm kernel sub-project."

Las cursivas son del autor original. Hasta un buen punto, esto ha sido un jarro de agua fría para OSGi, y el movimiento podría interpretarse como una deshaciéndose de un producto al cual no le ven futuro comercial.

¿Cuántos por aquí tenéis experiencia con OSGi? ¿Que opinais de este movimiento?