Tu plugin funciona desde hace años. Venderlo es otra cosa

Casi todas las academias con algo de recorrido tienen uno. Un plugin que alguien se hizo un día porque Moodle no hacía exactamente aquello, que lleva años funcionando y que en la oficina se da por hecho como se da por hecho la impresora.

Y en algún momento aparece la idea: esto lo vendemos.

Este artículo va de lo que hay entre esas dos cosas: qué instala hoy todo el mundo, en qué está escrito Moodle de verdad, qué permite la licencia, qué es lo complejo —que no es lo que parece—, cuándo no queda otra que desarrollar a medida y dónde entra la IA sin exagerar lo que hace. Con lo que Moodle publica en su documentación y lo que hemos aprendido haciéndolo con los nuestros.

Qué plugins instala todo el mundo

Antes de plantearte vender el tuyo, conviene saber qué hay. El catálogo oficial tiene 1.654 plugins y permite ordenarlos por instalaciones, que es un dato más honesto que las descargas: cuenta sitios donde el plugin está puesto ahora mismo, no cuántas veces se bajó un ZIP.

Estos son los más instalados, con las versiones de Moodle que soportan. Consultado el 11 de septiembre de 2026.

Míralos otra vez y fíjate en qué no hay.

Certificados, un tema, contenido interactivo, asistencia, formatos de curso, progreso, encuestas, informes, gamificación, una prueba de correo, videoconferencia e inicio de sesión único. Todos resuelven una carencia genérica del núcleo, la misma en un instituto de Lugo y en una universidad de Australia.

No hay ni uno que sepa cómo matriculas tú, ni que hable con tu programa de facturación, ni que entienda cómo están montados tus temarios. Eso no existe en el catálogo porque no puede existir: es distinto en cada centro.

Ahí está la respuesta a por qué a veces hay que desarrollar a medida.

Por qué a veces no queda otra que hacerlo a medida

Nuestra recomendación por defecto es no desarrollar. Un plugin del catálogo con veinte mil instalaciones lo mantiene gente que no eres tú, lo han probado veinte mil sitios y te sale gratis. Cualquier desarrollo propio empieza perdiendo esa partida.

Las razones honestas para hacerlo son pocas y se reconocen bien:

Porque lo tuyo no es genérico. Matricular en el curso correcto según lo que alguien acaba de comprar, con tus reglas de acceso y tus plazos, no lo puede resolver un plugin que no conoce tu tienda.

Porque hay que unir dos sistemas que no se conocen. Tu Moodle y tu CRM, tu facturación, tu pasarela. El catálogo tiene integraciones con los productos grandes; con el tuyo, no.

Porque lo que haces no es lo que Moodle espera. Preparar una oposición no es dar un curso: hay penalización por fallo, supuestos, simulacros cronometrados, repaso de lo fallado. El cuestionario del núcleo está pensado para evaluar, no para entrenar.

Porque es el trabajo repetido de una persona, todos los meses. Si alguien dedica seis horas al mes a cruzar pedidos con matrículas, eso son setenta y dos horas al año. Ese número sí justifica un desarrollo, y se puede calcular antes de empezar.

Porque el del catálogo hace el 80 % y el 20 % que falta es el que importa. Ese es el caso más común y el más engañoso, porque parece pequeño.

Y una razón que no vale, aunque es la que más se oye: que el plugin que hay no os gusta cómo se ve. Eso es un tema, no un desarrollo.

En qué está escrito Moodle

Moodle es PHP, y no de cualquier manera: la versión 5.2, publicada el 20 de abril de 2026, exige PHP 8.3.0 como mínimo y admite 8.4, siempre de 64 bits. Pide la extensión sodium y max_input_vars en 5.000 o más.

Debajo, una base de datos de las que soporta, con mínimos que suben en cada versión: PostgreSQL 16, MySQL 8.4, MariaDB 10.11, Aurora MySQL 8.0 o SQL Server 2019. Oracle ya no está soportado.

Pero decir «Moodle es PHP» se queda corto, porque un plugin toca cinco capas y cada una tiene sus reglas:

• PHP para la lógica, con las clases dentro de classes/ y espacios de nombres obligatorios en todo lo nuevo.
• XMLDB para el esquema de base de datos, que no se escribe a mano en SQL: se declara, y Moodle genera la migración para cada motor soportado.
• Mustache para las plantillas, no HTML metido dentro del PHP.
• JavaScript en módulos AMD, compilados, no un <script> suelto.
• SCSS si tocas el aspecto.

Y por encima de todo eso, las API del núcleo: capacidades, eventos, tareas programadas, ficheros, caché, formularios, servicios web y la Privacy API. La mayor parte del trabajo real de un plugin es usar esas API bien, no escribir PHP.

Por eso «sé PHP» no equivale a «puedo hacer un plugin de Moodle». La sintaxis se aprende en una semana; las convenciones, en unos cuantos plugins.

Qué es lo complejo, y no es lo que parece

Escribir la función que hace lo que quieres suele ser lo rápido. Lo que se lleva el tiempo es todo lo que la rodea:

Los permisos. Moodle no tiene «administrador y alumno»: tiene capacidades, contextos y roles que heredan. Cada acción del plugin tiene que comprobar la capacidad correcta en el contexto correcto, y ahí se equivoca mucha gente con consecuencias reales, del tipo un profesor viendo notas de otro curso.

Las actualizaciones. Un plugin con base de datos propia necesita su upgrade.php, que lleva a una instalación de hace tres versiones hasta la actual sin perder datos. Ese código se escribe una vez y se ejecuta en el peor momento posible: durante una actualización, en producción, con gente esperando.

El rendimiento con datos de verdad. Una consulta que va fina con doscientos alumnos puede tumbar el servidor con veinte mil. En Moodle es fácil escribir sin darse cuenta una consulta por cada fila de un bucle.

Las versiones. Cada versión de Moodle cambia API y deprecia otras. Si dices que soportas de la 4.5 a la 5.2, tu código tiene que funcionar en todas, y eso son pruebas, no confianza.

La concurrencia. Cien alumnos entregando a la vez a las 23:58 no es lo mismo que uno probando. Bloqueos, tareas programadas que se solapan, envíos duplicados.

Ninguna de esas cinco cosas aparece cuando un plugin lo usa sólo tu centro. Todas aparecen cuando lo usan veinte.

Cómo usamos la IA para desarrollar plugins

Una plantilla de pasta de soldar deja puestos en una sola pasada cientos de puntos exactos que a mano llevarían horas. Y no decide ni uno: el diseño estaba hecho antes de que la plantilla bajara.

Así es como la usamos, y conviene decirlo sin entusiasmo comercial.

Donde rinde. La estructura de un plugin es repetitiva y está documentada al detalle: el version.php, la declaración XMLDB, el esqueleto de la Privacy API, las cadenas de idioma, los formularios, los ficheros con su cabecera GPL y sus bloques de documentación. Todo eso tiene una forma canónica, y generarlo bien y de una vez ahorra un día por plugin.

Donde también rinde, y menos se espera. Revisar. Pasarle a un modelo un plugin interno con la lista de comprobación oficial delante encuentra en minutos lo que una lectura humana tarda una tarde en ver: el required_param() que falta, la consulta concatenada, la comprobación de capacidad que se hace después de mostrar el dato en lugar de antes.

Donde no rinde, y es la parte importante. Un modelo no sabe cómo está montado tu Moodle. No sabe que ese campo de perfil se llama así por una decisión de 2021, ni que hay tres sedes con configuraciones distintas, ni qué pasa si el cron se retrasa quince minutos un día de examen. Las decisiones de arquitectura, el modelo de permisos y todo lo que dependa de tu instalación siguen siendo humanas, y son justamente las que cuestan dinero cuando se equivocan.

Lo que cambia de verdad no es la velocidad de escribir: es que se puede permitir tirar código. Cuando montar un prototipo cuesta una tarde en vez de una semana, se prueban tres enfoques y se elige el bueno, en vez de defender el primero porque ya está pagado.

La licencia, que casi nadie se lee

Aquí se tuerce la mitad de las conversaciones, porque circulan dos creencias opuestas y las dos son falsas: que Moodle es libre y por tanto no puedes cobrar, y que tu plugin es tuyo y por tanto puedes hacer lo que quieras.

Lo que Moodle publica en su documentación de licencia es más preciso:

La licencia GPL se aplica a la plataforma Moodle y a su código base. No se extiende automáticamente a los plugins, temas u otros complementos desarrollados para usarse con Moodle.

Y sobre cobrar, la GPL no deja lugar a dudas:

Puedes cobrar cualquier precio o ninguno por cada copia que distribuyas, y puedes ofrecer soporte o garantía por una tarifa.

Es decir: vender está permitido. Lo que la GPL exige, cuando el programa es GPL, es que quien recibe una copia reciba también las mismas libertades, y eso incluye el acceso al código fuente.

Las dos rutas, que no son la misma

La diferencia práctica está en por dónde lo distribuyas.

Si quieres entrar en el catálogo oficial —que desde hace poco es el Moodle Marketplace, y que ha sustituido al antiguo Plugins Directory: la vieja URL redirige— la lista de comprobación de Moodle es explícita: los ficheros que implementan la interfaz del núcleo tienen que ser GPL v3 o posterior. Las librerías de terceros pueden llevar otra licencia compatible con la GPL siempre que se declaren en thirdpartylibs.xml, y lo binario tiene que traer su fuente o poder conseguirla.

Si lo distribuyes por tu cuenta, Moodle sostiene que la licencia la elige quien desarrolla, y que los plugins de su Marketplace están licenciados individualmente por sus autores.

Lo que no puedes hacer es mezclar las dos: publicar como GPL y después impedir que quien la recibió la comparta.

Esto no es asesoramiento legal y no lo pretende. Son las condiciones que Moodle publica. Si de ese modelo va a depender la facturación de tu centro, esa conversación la tienes con un abogado, no con un artículo.

El listón del catálogo, que sí se puede comprobar

Un utillaje de puntas de prueba no opina sobre si tu diseño es bueno: baja, toca todos los contactos a la vez y devuelve pasa o no pasa. La lista de comprobación de Moodle funciona igual, y tiene la virtud de que puedes contrastarla tú mismo antes de mandar nada.

Nombres. El repositorio se llama moodle-{tipo}_{nombre}. Tablas, ajustes, funciones, clases y constantes llevan prefijo frankenstyle, del tipo block_tunombre_loquesea, para que no choquen con nada.

Ficheros que tienen que estar. Un README que documente dependencias y pasos posteriores a la instalación, un version.php con las dependencias declaradas explícitamente, un settings.php si hay ajustes configurables, el directorio lang/en/ y un styles.css si usas estilos.

Seguridad. Es donde más plugins internos suspenden, porque en casa nunca hizo falta:

• Entrada saneada con required_param() y su tipo declarado.
• Consultas con marcadores, ? o :nombre, nunca concatenando.
• sesskey validada antes de procesar nada enviado.
• require_login() donde toca.
• Capacidades comprobadas antes de mostrar y antes de ejecutar.
• Nada de eval(), unserialize() ni call_user_func().

Privacidad. Si tu plugin se integra con un sistema externo, la implementación de la Privacy API es requisito previo a la aprobación. En un plugin interno que manda datos a tu CRM o a tu pasarela, esto casi nunca está hecho.

Idioma. Todo con get_string(), sin texto escrito a mano en el código, y el plugin viaja sólo con las cadenas en inglés; las traducciones van después por lang.moodle.org.

Pruebas. Con la depuración de desarrollador al máximo, y funcionando en MySQL y en PostgreSQL. Instalación limpia subiendo el ZIP, sin avisos ni advertencias de PHP.

Estilo. Es más rígido de lo que la gente espera: cuatro espacios de sangría, etiquetas PHP largas y sin cerrar el fichero, salto de línea Unix, sin espacios al final de línea, sin líneas en blanco al final del fichero, nombres de clase y de función en minúsculas separadas por guion bajo, constantes en mayúsculas con el prefijo del plugin, y cada fichero abriendo con el aviso de copyright GPL seguido de un bloque con @package, @copyright y @license.

Ninguna de esas reglas es difícil. Lo que sorprende es cuántas incumple a la vez un plugin que lleva cinco años funcionando perfectamente.

Lo que cuesta de verdad, y no está en ninguna lista

Todo lo anterior se puede leer, comprobar y tachar. Lo que sigue no, y es donde se va el tiempo.

Tu plugin da por supuesta tu instalación. El nombre de un campo de perfil que creasteis vosotros. Una categoría que existe porque la creó alguien en 2021. Un rol con un identificador concreto. Un formato de fecha. Ninguna de esas cosas existe en el Moodle de otro, y cada una es una suposición escrita en el código que hay que encontrar y sustituir por un ajuste.

Los textos están en tu idioma y dentro del código. Sacarlos a cadenas traducibles es mecánico, pero hay que pasar por todos.

Las versiones de Moodle que digas que soportas, las soportas. En version.php declaras un mínimo, y a partir de ahí cada versión nueva de Moodle es una prueba que alguien tiene que pasar. Eso ya no es desarrollo, es mantenimiento, y no termina nunca.

El soporte empieza el día que cobras. Un plugin interno que falla lo arregla quien lo escribió cuando puede. Un plugin vendido que falla lo arregla alguien hoy, porque hay un cliente parado. Ese cambio es el más caro de todos y no se ve venir.

¿Merece la pena?

Con honestidad, y aunque nosotros vendamos los nuestros: depende de qué resuelve.

Si tu plugin resuelve un problema que tienen igual muchos centros —matricular automáticamente al cobrar, ordenar un banco de preguntas que se ha ido de las manos, avisar a quien lleva tres semanas sin entrar— tiene sentido como producto. Ese problema no es tuyo, es del sector.

Si resuelve tu problema de una forma muy particular, encajado en cómo trabajas tú, casi seguro que no. Sacarlo te costará más de lo que ingreses, y el soporte no se acaba. Vale más como demostración de lo que sabes hacer que como catálogo.

Y una cuenta rápida que conviene hacerse antes de empezar: a una licencia anual de doscientos euros, ¿cuántas ventas hacen falta para pagar las horas de sacarlo, y cuántas para pagar además el soporte de los próximos tres años? Si el número te parece alto, la respuesta es que no.

Cómo lo hemos hecho nosotros

Todo lo de arriba lo hemos pasado con los plugins que usamos en nuestra propia academia, Esfera Oposiciones: el banco de preguntas, el motor de exámenes, las comunicaciones, la videoteca, el copiado entre cursos y las clases en directo. Algunos están hoy en el catálogo; otros no, porque al mirarlos de cerca resolvían un problema demasiado nuestro.

Esa es la parte que no sale en los tutoriales: decidir cuáles no.

Si tienes un plugin interno y quieres saber en cuál de los dos grupos cae, eso se ve leyendo el código, no hablando del código. Nuestra bolsa de horas sirve exactamente para eso: se compran horas, se gastan en mirarlo, y sales con una respuesta y una lista de lo que faltaría. Sin proyecto cerrado ni presupuesto de tres meses.

Y si lo que quieres es que lo hagamos nosotros, el desarrollo de plugins a medida es lo que hacemos todos los días. La primera consulta es gratuita.

Cuándo caduca esto

Los requisitos del directorio y las políticas de estilo se revisan con cada versión mayor de Moodle, así que este artículo toca repasarlo antes del 11 de marzo de 2027, y siempre contra la documentación oficial enlazada abajo. Lo que no va a cambiar en ese plazo es la parte de la licencia ni, sobre todo, la de decidir qué merece salir.