El plugin gratuito hace el 80 %
Y el 20 % que falta es el que te importa. Acabas encadenando tres plugins que se pisan entre sí y ninguno mantenido, hasta que una actualización de Moodle rompe la cadena entera.
Plugins Moodle a medida
Un plugin es código que se ejecuta dentro de tu plataforma y sobrevive a sus actualizaciones. Escribirlo es la parte corta; lo que decide si fue buena idea es quién lo mantiene los tres años siguientes.
Hemos escrito y mantenido quince desarrollos propios para nuestra propia academia. Esta página cuenta lo que aprendimos auditándolos uno a uno, incluida la parte incómoda.
Dónde suele atascarse
Se toca el núcleo «sólo esta vez»
Funciona, y la siguiente actualización se lo lleva por delante. A partir de ahí ya no se puede actualizar sin rehacer el parche, y la plataforma se queda congelada en una versión sin soporte.
Lo hizo alguien que ya no está
Sin documentación, sin pruebas y sin nadie que entienda por qué está escrito así. Cada cambio es arqueología, y nadie se atreve a tocarlo.
Funciona aquí y sólo aquí
Identificadores de curso escritos a fuego, categorías propias, rutas de la casa. En cuanto se instala en otra plataforma, no arranca — y eso no se ve hasta que se intenta.
Declara cosas que no hace
El plugin dice soportar seguimiento de finalización o trabajo por grupos, aparecen los ajustes en el formulario, y detrás no hay nada. Nadie se entera hasta que alguien confía en esa casilla.
No pasa una auditoría de privacidad
Guarda datos de usuario sin declarar la clase de privacidad que exige Moodle. No exporta ni borra lo de una persona cuando lo pide, y eso bloquea publicarlo y es un agujero de RGPD, no un detalle de acabado.
Lo que separa «funciona en mi plataforma» de «se puede instalar en la tuya»
En septiembre de 2026 auditamos nuestros quince desarrollos internos uno a uno, contrastando cada funcionalidad afirmada contra el código. La conclusión más útil no fue cuáles servían, sino cuánto trabajo separa un plugin que funciona de un plugin que se puede entregar.
Lo que hay que resolver, en orden de lo que más bloquea:
- La clase de privacidad. Si el plugin guarda cualquier dato de usuario, Moodle exige declararlo y poder exportarlo y borrarlo. Sin eso no se publica en el directorio oficial y no se sostiene una auditoría de RGPD.
- El desacoplamiento. Identificadores escritos a fuego, nombres de curso fijos, dominios propios. Se busca con herramientas, no de memoria.
- Los textos fuera de los ficheros de idioma. Es lo que hace que un comprador de fuera vea media interfaz en español aunque el plugin diga estar traducido.
- Las funciones declaradas y no implementadas. Un plugin que anuncia soportar algo y no lo hace se descubre el día que alguien confía en ello.
- Cabeceras de copyright, licencia, historial de actualización y pruebas. Lo aburrido, y lo que decide si el plugin sobrevive a la siguiente versión de Moodle.
El dato que más nos sorprendió: nuestro plugin más sencillo —diez ficheros, poco más de mil líneas— necesitaba entre ocho y doce días de trabajo para poder entregarse, no los dos o tres de pulido que habíamos estimado. Y el trabajo escondido no estaba en las funciones, sino en una pantalla que cargaba todos los cursos del sitio en memoria: irrelevante en una academia, insostenible en una universidad.
Ése es el margen que conviene tener en cuenta antes de encargar un desarrollo: lo que cuesta que funcione y lo que cuesta que aguante no son la misma cifra.
La GPL, y qué significa de verdad cuando pagas un desarrollo
Todo plugin de Moodle es GPLv3 o posterior. No es una elección del autor: usa las bibliotecas del núcleo y hereda su licencia. Conviene entender qué implica antes de firmar nada.
Se puede cobrar por un plugin GPL. Es legal y es lo que hacen todos los vendedores comerciales del ecosistema. Lo que no se puede es impedir que quien lo compra lo redistribuya.
De ahí sale una consecuencia práctica que casi nunca se explica: lo que compras no es el derecho a usar el código, sino las actualizaciones y el soporte. Es también la razón de que las licencias anuales del sector dejen el plugin funcionando al vencer, y sólo corten actualizaciones y soporte.
Y una consecuencia para ti como cliente: si te desarrollamos algo a medida, el código es tuyo y te lo llevas. No hay forma de atarte a nosotros por la vía de la licencia, sólo por la de hacerlo bien.
Cuándo NO compensa desarrollar
Decirlo va contra nuestro interés inmediato, pero ahorra dinero a los dos:
- Cuando ya existe y es gratis. Nuestro propio plugin de copia entre cursos compite con uno comunitario consolidado que no cuesta nada. Si te cubre, úsalo.
- Cuando es un problema de configuración. Muchas peticiones que llegan como «necesitamos un plugin» se resuelven con roles, restricciones de acceso o un informe bien configurado.
- Cuando el proceso es el problema. Automatizar un procedimiento roto sólo hace que se rompa más deprisa.
- Cuando lo usará una persona una vez al mes. El coste de mantener el código durante tres años supera al del trabajo manual que evita.
Cómo lo resolvemos
Desarrollo a medida por horas
Se estima el trabajo, se hace por tramos y se factura por minutos reales. El código es tuyo, con su documentación y su clase de privacidad.
O uno de los nuestros, ya hecho
Los desarrollos que llevan años en producción en nuestra academia, con licencia anual o vitalicia. Salen conforme terminamos de sanearlos.
Revisión de lo que ya tienes
Auditoría de tus plugins actuales: qué hacen de verdad, qué declaran y no hacen, qué te ata a una versión y qué se rompe en la siguiente actualización.
Preguntas frecuentes
¿El código es mío?
Sí. Un plugin de Moodle es GPLv3 por obligación, así que te lo llevas con derecho a modificarlo y redistribuirlo, y con sus fuentes. No hay forma de atarte por la licencia.
¿Cuánto cuesta un plugin?
Depende del alcance, y la única respuesta honesta antes de mirarlo es un rango muy ancho. Lo que sí podemos decir por experiencia propia: el trabajo de dejarlo entregable suele ser mayor que el de hacerlo funcionar. Nuestro desarrollo más sencillo necesitó entre ocho y doce días sólo para eso. En la consulta gratuita se acota.
¿Sobrevive a las actualizaciones de Moodle?
Si está bien escrito, sí: se apoya en las interfaces públicas del núcleo y no lo modifica. Lo que no sobrevive es un parche sobre el núcleo, y por eso no los hacemos. Aun así, cada versión mayor exige revisión, y eso se planifica.
¿Podéis retomar un plugin que hizo otro?
Sí, y es habitual. Lo primero es una revisión: qué hace realmente, qué declara y no cumple, qué lo ata a tu instalación y qué se romperá en la siguiente versión. De ahí sale si compensa arreglarlo o rehacerlo, y a veces la respuesta es rehacerlo.
¿Publicáis los plugins en el directorio oficial de Moodle?
Sólo si tiene sentido para ti. Publicarlo exige requisitos concretos —privacidad, traducción, pruebas— que encarecen el desarrollo, y a cambio da difusión y revisión externa. Es una decisión tuya y se decide antes de empezar, no al final.
Relacionado
Cuéntanos qué necesitas que haga
A veces la respuesta es un plugin y a veces es configuración. En la consulta gratuita te decimos cuál de las dos, aunque sea la que no nos conviene.
Reservar la consulta gratuita