¿Programar tu propio CMS?

Ventajas e inconvenientes de emprender un desarrollo propio cuando existen alternativas de buena calidad en el mercado o soluciones open source.

Ventajas e inconvenientes de emprender un desarrollo propio cuando existen alternativas de buena calidad en el mercado o soluciones open source.

En otras ocasiones hemos hablado aquí sobre esa tendencia nuestra de re-inventar la rueda, ya sea programando nuestro propio CMS a partir de Blogger (haya por junio de 2005)… o en otras muchas otras cosas. 

Dare Obasanjo hace no mucho resumía en este párrafo:

I’m often surprised by how common it is for developers to prefer reinventing the wheel to using off-the-shelf libraries when solving problems tasks. This practice isn’t limited to newbies who don’t know any better but also to experienced developers who should. Experienced developers often make excuses about not wanting to take unnecessary dependencies or not trusting the code of others when justifying reinventing the wheel.


Si me permitieran volver a empezar, no sé… tal vez hubiera sido más interesante haber montado todo sobre Wordpress o MovableType y construir todas nuestras funcionalidades extras como
plugins: algo que sin duda hubiera sido una pesadilla en el momento de las actualizaciones, si  bien se podría haber visto compensado por la enorme cantidad de enlaces que uno puede recibir compartiendo con la comunidad algunas de esas funcionalidades (caso: LaMateporunYogur y sus dos WP Themes) y a su vez beneficiarte de las brillantes aportaciones de otros programadores.

Un post en febrero de Carlos Blanco ”Cada CTO que tengo hace un CMS nuevo“ estaba relacionado de pasada con este vicio… y el hilo de comentarios no dejo pasar la oportunidad de tratar el tema. En él Ferrán comentaba: 

Los informáticos tienen el síndrome de NIH (no invented here) con frecuencia, si no lo han hecho ellos, no les gusta. (…) Coger e instalar un WordPress son 5 minutos, adaptarlo, quizá una semana. Desarrollar tu propio CMS… no tiene precio. Pero en tiempo (oportunidad) y coste… no hay comparación.

Una vez hecho este ejercicio de auto-flagelación voy a mirar también los aspectos positivos de lo que han sido estos años en los que hemos ido montando y mejorando nuestro CMS:

  • Aprendimos – Y no es tan sencillo aprender porque el día a día te aboca a repetir una y otra vez tareas que ya dominas… y no es tan frecuente enfrentarte a nuevos retos que te obligan a estudiar en profundidad un tema.
  • Tranquilidad – Si surge un problema lo podemos resolver, puede que nos tengamos que quedar un par de noches sin dormir… pero al final lo resolveremos: I Know because I wrote it.
  • No todo lo hicimos nosotros – Lo único que hemos programado es el core del CMS y si bien es la segunda aplicación más grande que hemos programado… el hecho es que lo más dificil lo realizan componentes como Aspjpeg, FCKeditor, CKFinder
  • Seguridad – Los problemas de seguridad de WordPress son bien conocidos, no quiero decir que nuestro CMS sea un bunker: es probable que tenga más de una vulnerabilidad y alguna que otra grave: pero que alguien dedique su precioso tiempo en buscarlas es como entrar en La Casa Blanca para robarle la hucha-cerdito a la hija del presidente.
  • Adaptación - Integración de los post con nuestra guía, la pasarela con 11870, el mashup de APIs, las thumbs a medida, las capturas de webs para obtener logotipos

En definitiva, la lección del Gafapasta que hemos aprendido es que como en todo siempre hay un lado positivo…  ahora debemos centrarnos en él y aprovecharlo como una ventaja competitiva (entre otras razones porque no hay marcha atrás). 

No obstante estos posts los escribo para no perder el norte y para recordarme a mi mismo que “usar librerías no es de débiles“ y que por ejemplo ahora que estamos buscando la mejor manera de incorporar galerías de imágenes a nuestros posts haremos bien si utilizamos jQuery como librería AJAX y MultiPowUpload o algo parecido para poder subir múltiples ficheros al servidor.