OpenCms: difama y vencerás

Últimamente vengo observando en diversos grupos de opinión de nuestro entorno una creciente animadversión hacia OpenCms como plataforma de gestión de contenidos, indiferentemente de la versión de la que hablemos (la versión 7 ya lleva bastante tiempo estabilizada). Puedo entender cierto picorcillo contra una serie de experiencias de hace ya varios años, basadas en implantaciones de un pseudo-OpenCms 5 que tenía por delante un fuerte desarrollo frontend para dotarle de funcionalidades de las que no disponía esa versión. El problema (y la ventaja) del software libre es que tienes ahí el código fuente, listo para adaptarlo a tus necesidades. Pero claro, si lo “adaptas demasiado”, te separas de la línea principal de desarrollo y te quedas anclado en la versión antigua. Sin embargo, de eso no tiene la culpa el software (en este caso, OpenCms), sino el equipo que forman los contratados para hacer algo, y los que contratan eso.

La mayoría de organizaciones que buscan un CMS requieren una serie de características muy difíciles de conjugar:

  • Que sea software libre, y además gratuito.
  • Que los usuarios puedan ser dueños y señores de su web, pudiendo introducir contenidos con editores WYSIWYG, imágenes (y que se auto-redimensionen), contenidos estructurados (noticias, eventos, ficheros, etc.), con herramientas sencillas y usables…
  • Que a pesar de todo ello, se mantenga la accesibilidad de la página (algo complicado, porque los editores visuales no pueden generar HTML semánticamente correcto). ¿Quién le impide a un usuario poner un título con una etiqueta que no sea una <h1>, <h2>, …<hN>?
  • Circuitos y flujos de aprobación de los contenidos.
  • Gestión de permisos de edición y publicación sobre diferentes áreas funcionales, recursos, etc. Por ejemplo, “el grupo de prensa puede crear noticias”, etc.
  • Velocidad, estabilidad y alta disponibilidad: cacheo, posibilidad de balanceo de carga, clusterización…
  • Posibilidad de definir nuevos contenidos de la forma más sencilla posible, y la máxima flexibilidad para plasmar estos contenidos en la zona web (por ejemplo, un evento, que se pueda desplegar como un calendario).
  • Facilidad de mantenimiento (tanto a nivel Sistemas como Desarrollo), de forma que la evolución del portal sea lo menos costosa posible.
  • Publicación/despublicación diferida (programada para una fecha concreta).
  • En muchos casos, soporte multi-idioma.
  • Soporte de plantillas y temas.
  • Posibilidad de introducir zonas privadas con autenticación de usuarios (con funciones de registro, recordatorio de contraseñas, roles y visibilidad, etc.).
  • Funcionalidades más o menos avanzadas: indexación de contenidos (web, ficheros, etc.) y búsqueda, autogeneración del mapa de la web, autogeneración de migas (breadcrumbs) de navegación, autogeneración de menús, etc etc etc.

A lo largo de mi vida profesional he probado innumerables plataformas CMS. En Carrefour España fui el Jefe de Proyecto responsable de la creación de la intranet corporativa de la empresa, basada en el entonces novedosísimo PhpNuke versión 6 🙂 desarrollada por los nunca suficientemente valorados Simplelogica. He sido siempre un gran defensor de PHP como plataforma de desarrollo rápido, con plataformas bastante interesantes (Joomla, Drupal…) y veo con interés las apariciones de otras alternativas como Plone (Python), frameworks de desarrollos como Ruby On Rails, etc. Sin embargo, en este mercado suelen confundirse mucho los productos de portal, como era ese PhpNuke, mal llamados CMSs, con los productos de gestión de contenidos, como son OpenCms, Vignette, etc. De hecho, en tecnologías Java hablamos de dos especificaciones distintas: la JSR-170 para la persistencia de contenidos y la JSR-168 más orientada a portales, y en concreto a la estandarización de los componentes portlets.

En el caso de la Junta de Andalucía, que me pilla bastante cerca, no puedo entender cómo se puede poner en duda la utilización de OpenCms (al menos su última versión 7). Cumple a rajatabla todos los requisitos que se suelen solicitar, como los que he enumerado anteriormente, pero además tiene una serie de ventajas de gran importancia:

  • Tiene excelentes características de rendimiento (cacheo avanzado, posibilidad de clusterizar y balanceo de carga…).
  • Es coherente con la apuesta tecnológica (JAVA). Y eso es MUY importante para una organización que haya hecho una apuesta por una tecnología. Cuando ya dispones de programadores formados, de personal de Sistemas (muchos de ellos funcionarios de la propia Junta) que sabe gestionar servidores de aplicaciones y motores de servlets como JBoss, Oracle iAS, Tomcat, o SGBDR como Oracle 9i ó 10g, ¿de verdad es buena idea comenzar a desarrollar con plataformas como Python o PHP? No quiero decir que estas plataformas sean mejores o peores (como siempre, dime para qué), pero en una gran organización la estandarización es realmente importante.
  • A pesar de ser Open Source, tienen una empresa detrás (en este caso, Alcakon) que asegura la estabilidad, e incluso, por qué no decirlo, la posibilidad de acceder a servicios de soporte y mejoras de pago. Nunca olvidemos que la estrategia comercial del Software Libre se basa en los servicios. Ocurre igual con otros productos Open Source de moda como Alfresco, Open Office, algunas distribuciones de Linux, Tomcat, Hibernate, JBoss y tantos otros…

No sé si estaré influenciado por el excelente nivel de mis compis en OpenCms. No sólo se han ido encargando de realizar las traducciones al castellano, sino que la verdad es que han desarrollado portales estupendos, permitiendo a usuarios de dudoso nivel técnico (pedían que se les enseñase a copiar y pegar, verídico) meter, por ejemplo, complejos mapas de Google con zonas sensibles que desplegaban vídeos Youtube y galerías de imágenes Lightbox. Sacar a la luz portales en una semana. Y experiencias super-interesantes técnicamente, como crear una infraestructura OpenCms 6 clonable, de forma que se puedan crear múltiples portales (en este caso, para Ayuntamientos de la provincia de Sevilla) en apenas un par de horas de desarrollo, y cambiado el estilo inyectando CSS (al estilo del proyecto CSS Zen Garden de Dave Shea). Dos ejemplos interesantes son la web del Ayuntamiento de Paradas y la del Ayuntamiento de Gelves. Cualquier curioso podrá observar que tienen el mismo HTML. Las últimas noticias que tenía es que más de 50 Ayuntamientos de la provincia están usando, o van a usar, esta tecnología que montamos para la Diputación de Sevilla.

Plataformas como OpenCms, Plone o el excelente Joomla (o Drupal, quizás ya muy desplazado por éste último) son buenas en sí mismas, pero los que las hacen buenas o malas en la realidad son los desarrolladores. Al igual que ocurre con un proyecto JSF, Struts2 o RubyOnRails, el conocimiento es el que marca la diferencia. El problema es que de vez en cuando, se encargan estudios y comparativas a personas que no han estudiado y comparado todas las plataformas, y que tienen claro el resultado objetivo antes de empezar. Para hacer una comparativa seria, debería fijarse un objetivo, y realizar un pequeño piloto con cada alternativa. Analizar diferentes parámetros: facilidad de desarrollo, flexibilidad, ajuste a las necesidades de los usuarios, estabilidad (pruebas de estrés, etc.). Así se puede escribir con propiedad y convencimiento que X es mejor que Y y peor que Z para esta necesidad y este caso concreto.

Siempre será más fácil destruir que construir. Decir “X es una mierda” cala mucho más que un discurso técnico que suele aburrir a todo interlocutor que no se interese tanto por la tecnología como el entusiasta friki que habla de las excelencias de un software complejo. En este caso, creo que OpenCms está sufriendo este tipo de campaña de desprestigio, cuando, como cualquier otra plataforma, los que las harán buenas o malas serán los desarrolladores.

Comentarios

  1. No se si es el lugar adecuado pero ahi tiro la piedra.
    Me han pedido que implemente un CMS sobre Oracle, soy programador PHP desde la version 2.0
    No me asusta ni XOOPS,JOOMLA ,DRUPAL , mooble, mysource matrix o OPENCMS el tema es que funcione sobre Oracle, buscando llegue a tu pagina. He leido bastante pero aun no me he definido por ninguno.
    Quisiera escuchar tus cometnarios sobre los precedentes si has tenido buenas malas, etc.
    Muchas Gracias y espero no molestar!!

  2. Hombre, yo entiendo que los conocimientos del programador son importantes. Esa es una de las razones por las que no entiendo que en el entorno de la Junta de Andalucía, donde se ha optado por estandarizar sobre Java, se piense en Drupal.
    Te diría que no es tan importante la tecnología; si eres desarrollador PHP, yo optaría por Drupal, por qué no, o tal vez Mambo, que tiene tan buenas o mejores críticas.
    En Oracle funcionará; PHP embebe un controlador PHP de forma nativo, y prácticamente el 100% de los CMS PHP abstraen la lógica de persistencia mediante una capa específica para ello. Por eso, no tendrás mayores problemas con la persistencia sobre Oracle. Otra cosa es que bajo mi punto de vista no será tan óptima la forma de atacar a Oracle desde PHP como desde un servidor de aplicaciones Java con un pool de conexiones, pero sin duda tu cliente no lo notará 😉
    Suerte!!

  3. Hola Javier, estoy haciendo ua comparativa entre gestores de contenidos, y a la hora de valorar OpenCms, encuentro que su mayor problema es la falta de soporte para portlets, no siquiera siguen la norma JSR170 en la recién estrenada 7.0. ¿Hasta qué punto consideras importarnte este hecho? ¿Crees que el estándar JSR-168 va a ser usado de forma generalizada en un futuro inmediato? Lógicamente hablo dentro del mundo java.
    Gracias y saludos.

  4. Uff, esto daría para un post entero, me has dado una idea 😀
    Te diría que realmente hay dos familias de productos en este mundo Java… una familia tiene su principal enfoque en la solución de persistencia de los contenidos introducidos, las gestiones de usuarios/permisos/roles/workflows… y suelen implementar JSR-170 (no lo hace OpenCms). Ejemplos de este tipo de productos, además de OpenCms: Infoglue, Lenya, Magnolia, etc. Estas aplicaciones digamos que tienen su fuerte en la gestión de contenidos (editores visuales, flujos de aprobación, persistencia de los contenidos en binarios de forma transparente, etc.), pero además suelen permitir inyectar lógica en los portales web desarrollados con ellas. Por ejemplo, en el caso de OpenCms permite la inyección de JSPs, librerías de clases, etc. Incluso se puede inyectar frameworks como Struts o implementaciones de JSF.

    La otra familia son los motores de portales, que implementan (o podrían) JSR-168, el API de portlets. Ejemplos: eXo, Liferay, Oracle Portal, etc. Aunque pueden tener portlets dedicados a gestión de contenidos, no es su verdadero enfoque. Digamos que se centran más en ser plataformas de microaplicaciones, por ejemplo, iGoogle.

    En general, veo más lógico usar una de estas aplicaciones “motores de portlets” para desarrollos de intranet, etc., y utilizar soluciones de gestión de contenidos para webs de publicación, webs corporativas, etc. Pero sobre gustos, colores…

    Por lo que a tu respuesta, realmente no creo que sea una gran debilidad de OpenCms porque no es su enfoque principal, aunque sí parece que en un futuro a medio/corto las futuras versiones de OpenCms sí permitirán la inyección de portlets.

    Espero haberte ayudado, no dudes en contactarme si tienes más dudas.

  5. Gracias por tu rápida respuesta, Javier.
    Otro de los puntos débiles de OpenCms para ser adoptado por instituciones públicas de cierta envergadura, como las consejerías, es la dificultad para hacerlo escalable. Según he entendido, tampoco la verión 7 ha avanzado en este sentido, y un simple balenceo de carga requiere desarrollo a medida. ¿Has tenido oportunidad de enfrentarte a este problema?

  6. Hola Jorge! Pues ese es otro “bulo” famosillo sobre OpenCms. OpenCms, como cualquier aplicación Java EE, desplegable sobre Tomcat, se puede poner en balanceo de carga en según qué tipo de disposiciones básicas. En este caso no es mérito de OpenCms, sino de Java EE. En nuestro caso hemos probado a realizar balanceos software desde Apache y 2 nodos Tomcat independientes, y eso sí, una única base de datos (en este caso era Oracle), con un comportamiento bastante típico:

    -Un usuario entra, y el balanceador Apache redirige la petición hacia un servidor A (o B, el que le toque). A partir de ahí, TODA su sesión se mantiene en ese mismo servidor.
    -El balanceador se va encargando de mantener una carga similar en cada servidor.
    -Si un servidor se cae, el balanceador redirige el 100% al que se mantiene estable.

    Como te comento, este escenario ultratípico (manteniendo una base de datos, no dos) se puede conseguir con toda aplicación Java EE… otra cosa sería si quieres que una misma sesión vaya viajando aleatoriamente entre los servidores, con lo que ya hay requisitos mayores (objetos serializables, ficheros sincronizados, etc.).

    Eso sí, al balancear aplicaciones web puede haber un problema, y es el tema de los ficheros. Los 2 servidores deberían tener los mismos ficheros (imágenes, ficheros descargables, etc.) para usarlos en web. Evidentemente, en un gestor de contenidos como OpenCms se suben ficheros (los administradores cuelgan imágenes, ficheros pdf, html, etc. etc.), y requieres que en ambos nodos esté visibles a la vez. Si subes el fichero en el nodo A, ¿cómo garantizas que los usuarios redirigidos al B no tengan un 404?

    Hay varias opciones, y ojo, esto es un problema en casi cualquier aplicación web (no en OpenCms por lo que explico luego). Puede haber procesos de sincronización, NFS, etc. OpenCms no tiene este problema porque virtualiza el sistema de ficheros, serializándolo sobre la base de datos, gracias al VFS (Virtual File System).

    Todos los nodos OpenCms pueden ver los ficheros en paralelo, ya que éstos residen serializados sobre base de datos, y todos los nodos atacan a la base de datos. Ahí sí se da una posible contingencia, y es el tema de la utilización de Flex Cache, es decir, un cacheo de ficheros, generándolos físicamente mediante una consulta de base de datos, para evitar tanta carga de consulta. Sin cacheo, cada vez que un usuario quiere ver una imagen subida por un administrador, OpenCms realiza una consulta. Esto sorprendentemente no va mal, pero siempre es más óptimo cachear. Obviamente, los procesos de cacheo (generación de ficheros desde base de datos) de Flex Cache deben realizarse a ser posible simultáneamente en todos los nodos. Pero esto es perfectamente posible en OpenCms, puedes programar los lanzamientos de los servicios de cacheo. Alcakon vende un plugin comercial para facilitar esta gestión en una única utilidad, pero no es necesaria. El caso es que a partir de este hecho, se ha corrido la voz de que para balancear OpenCms hay que desarrollar o pagar, y tampoco es así 😀

    Por el tema de tener una única base de datos tampoco hay que preocuparse, porque se puede disponer de un cluster tranquilamente siendo una base de datos para OpenCms de forma transparente. De hecho es lo más común en la Junta de Andalucía, las aplicaciones Java EE persisten sus datos en una base de datos e internamente se replican.

    Espero haberte ayudado. Un saludo!

  7. Tu explicación detallada me ha sido de gran ayuda, aunque hay una parte muy relacionada con esto a la que no le hemos atacado: staging. Si necesito tres entornos (típicamente desarrollo, pruebas y producción), se requieren tres instalaciones distintas de OpenCms, con las consecuente pérdida de escalablidad y clusterización. Si a esto se le añade la necesidad de alta disponibilidad, algo muy usual en portales institucionales, el escenario puede ser bastante complejo. ¿Estoy en lo cierto?

  8. Hombre, te diría que en eso no observo ninguna diferencia con ningún otro CMS u entorno de aplicación web… es decir, salvo que no te haya entendido bien, siempre será lo “ideal” disponer de 3 entornos, y a ser posible que estos sean independientes. Por otro lado sí te comento de pasada que en la máquina de cada desarrollador sí que suele haber un primer entorno de desarrollo.

    Podrías utilizar un único entorno físico para obtener tres entornos software perfectamente, incluso en el mismo servidor de aplicaciones (instalando 3 OpenCms), aunque no creo que fuese recomendable. Incluso en el mismo OpenCms podrías tener 3 portales para los 3 entornos, aunque tampoco sinceramente me gusta… Pero nadie te impide tener 2 ó 3 servidores de aplicaciones en una misma máquina, y obviamente realizar los ajustes de memoria, etc. para darle prioridad a Producción, y así se evita parte de esa complejidad. Pero me parece que este problema del que hablas es universal a toda aplicación web, no sólo a OpenCms.

    De hecho, tal vez OpenCms te diera menos problemas gracias a que te evitas la sincronización de ficheros debido a la ventaja de la existencia del VFS…

    No se me ocurre una forma de evitar este mismo problema con otro CMS como Magnolia, un motor de portlets Java EE como eXo o Liferay, o motores de portales de otras arquitecturas como Mambo o Drupal…

    Saludos!

  9. Buenas, nosotros hemos desplegado entornos OpenCMS (almenos 4 que yo sepa) sobre Oracle sin problema alguno. Excepto en el caso de una versión concreta de OpenCMS (la 6.2.2 creo) en la que era necesario aplicar un pequeño parche (está documentado en el bugzilla)no hemos tenido nunca ningún problema 🙂

    Joomla! siempre lo hemos instalado en MySQL…

    Saludos

  10. Hola,
    nosotros estamos empezando a desarrollar con openCMS y viendo las amplias posibilidades que tiene. Dado que no tenemos mucha experiencia vamos investigando poco a poco. Una de las cosas que nos gustaría mejorar son las galerías imágenes. De momento utilizamos PhotoAlbum, pero visualmente deja mucho que desear. He visto que comentas que vosotros conseguisteis que los usuarios metan galerías tipo LightBox. Me puedes orientar sobre este tema? Gracias

    1. Hola Ana, para integrar cualquier js (lightbox, etc) lo que hay que hacer es una plantilla de tu módulo que haya llamadas al js, y esa plantilla asignarla a un contenido estructurado, listado, página, etc.

      El caso más simple sería añadirla a una página html, con un poco de detalle:

      Crea una carpeta en /system/modules/tumodulo/resources/ que se llame lightbox y sube los scripts, imágenes que usa lightbox y asociados. Edita el .js para que encuentre las imágenes de next, etc. en esta ruta.
      Crea una plantilla en /system/modules/tumodulo/templates/ que tenga los imports a los js
      Bajo /sites/defaul/ crea una página html, asignale la plantilla e incluye una imagen con la eitqueta re=”lightbox”

      Eso es todo.

      Un caso más complejo:

      Idem en la parte del módulo.
      En la parte de /sites/ default/ crea una galería de imágenes, y carga todas las que quieras.
      En la parte de /sites/default/ crea una jsp que haga un lista de las imágenes con rel=”ligthbox[grupo]”

      Más o menos es eso. Por cierto que no recuerdo si es rel=”lightbox” u otra cosa, confirmalo con la documentación del lightbox.

      Saludos.

Comments are closed.