Publicar un plugin

Los dos paquetes

Y una consecuencia práctica: la publicación de las dos debería ser un solo paso automatizado, no dos manuales — porque dos pasos manuales acaban desincronizándose.

Lo mínimo antes de publicar

Y una que no está en la lista y merece pensarse: cómo se reportan los fallos y qué esperas responder. Un plugin sin canal claro recibe informes por vías raras y sin la información necesaria.

Lo que se adquiere

Y es la parte que merece leerse antes de publicar:

• Gente que construye sobre tu código y que sufre tus cambios. Romper compatibilidad les cuesta trabajo a ellos.
• Informes de fallo en plataformas que quizá no puedes reproducir. Nivel 67.5.
• Peticiones de funciones que quizá no quieres.
• Y la expectativa de que sigas ahí. Un plugin abandonado deja atascada a la gente que lo adoptó.

Nada de eso obliga a nada —publicar algo con una licencia permisiva no crea una obligación legal— y sí crea una expectativa. Y hay una forma honesta de gestionarla: decir desde el principio qué mantenimiento esperas dar.

Decidir si publicar

Y una recomendación honesta:

• Publica si resuelve un hueco general y estás dispuesto a mantenerlo un tiempo. Nivel 68.3.
• Publica marcándolo como experimental si no estás seguro. Es mejor que no publicar y mejor que prometer estabilidad.
• Y no publiques si es específico de tu aplicación, si no puedes probarlo en las plataformas que dice soportar, o si sabes que no vas a poder atenderlo.

Un plugin abandonado con permisos mal diseñados hace más daño que uno que nunca existió, porque la gente lo adopta y hereda sus problemas.