No estoy muy seguro de dónde proviene esta cifra del 1%, pero con 14 millones de usuarios, todavía serían 14.000 usuarios a los que se les prohibiría el acceso a Discourse. ¿Solo para agregar algunos CSS y ajustes de rendimiento?
En cuanto a “¿Qué número de usuarios debería poder impedir que el porcentaje restante se beneficie de su software actualizado?”… ¿por qué ese número no puede ser mucho, mucho menor que el 1%, mucho más cercano al 0% que al 1%? Argumentaría que Discourse debería adoptar el enfoque opuesto, no hacer cambios innecesarios que rompan la compatibilidad hacia atrás a menos que haya una corrección crítica o una característica importante que lo requiera absolutamente, Y que haya una demanda generalizada de los usuarios.
La inversa de esa pregunta es “¿A cuántos usuarios estamos dispuestos a excluir para perseguir algunas comodidades menores con un impacto bajo o nulo en el usuario?” ¿Vale la pena una pequeña mejora de rendimiento que apenas se notará en nada más que en puntos de referencia cuidadosos, excluir a 14.000 personas de sus comunidades?
¿Qué tipo de “software actualizado” anhelan los usuarios del foro…? Es un foro. La gente lee texto y responde a publicaciones de texto. Es aterrador que los desarrolladores sigan diciendo “tenemos que seguir avanzando” mientras que sus clientes reales dicen, espera, ¿por qué, ninguna de estas características significa nada y estás excluyendo a personas reales?
Siento que este es exactamente el enfoque opuesto que esperarías que tomara un software de foro estable y antiguo como Discourse. Si quieres experimentar con nuevas funciones, eso debería suceder en una rama “canary” inestable a la que las personas deban optar explícitamente, y la rama principal debería ser LTS por defecto. No solo no estás ofreciendo mejoras progresivas, sino que tampoco estás ofreciendo degradaciones elegantes. Esa es una elección, no una parte inherente del desarrollo de software. Estás eligiendo avanzar más rápido de lo que tus usuarios pueden seguir.
Y sus comunidades alojadas no tienen elección alguna. Los que les pagan por su comunidad, no para que sea una demo tecnológica y un patio de recreo de JS.
ESTO es por lo que es un problema cultural y no técnico. Gracias por al menos estar dispuesto a decirlo en voz alta. Han sopesado los costos de esto en horas de desarrollo frente a los impactos estimados en el usuario, y en sus cálculos, los usuarios valen menos que el costo que tomaría crear una versión básica de publicación. No hay otra manera de decirlo: no valoran a sus usuarios y comunidades reales tanto como los atajos de desarrollador 
Perdón por sacar esta cita un poco de contexto, pero… si dejaran de pensar en términos de porcentajes y pensaran en los impactos en personas reales en sus comunidades, ¿quizás los cálculos serían diferentes?
Todo esto es un poco estalinista, diciéndole a la gente que son básicamente una estadística desechable porque son demasiado pobres para actualizar hardware o que es su culpa por no estar dispuestos y ser capaces de hacer malabares para instalar otro sistema operativo o capa de compatibilidad o bifurcación del navegador… ¿solo para que puedan seguir publicando mensajes de texto en un foro del que han sido parte durante muchos años?
Este es el tipo de análisis costo-beneficio que esperaría ver de una nueva versión importante, como una reescritura completa, no de algunas características menores, invisibles y orientadas al desarrollador que podrían tener algunos pequeños beneficios de rendimiento =/ Es realmente desafortunado que su empresa esté adoptando esta postura, en mi humilde opinión, pero aún así… realmente aprecio la transparencia.
OK. De todos modos, ya he lloriqueado bastante. Tengo una pregunta potencialmente/esperanzadoramente más constructiva…
Si asumimos que un modo HTML básico sería útil para un pequeño número de usuarios, pero no es algo en lo que Discourse quiera gastar recursos para construirlo… ¿es esto algo factible para que la comunidad de código abierto lo asuma? Parece demasiado grande para ser algo como un plugin, pero aún demasiado pequeño para un proyecto completamente separado (como Discorkie).
¿Sería concebible intentar definir esto como un frontend abierto alternativo que funcione con las API actuales y, si es así, habría alguna posibilidad de que tal cosa (si alguna vez se construye y prueba) sea “oficialmente” aceptada/integrada en el software principal tal que también pueda ser utilizada en instancias alojadas de Discourse (que es donde se encuentra una de mis comunidades afectadas)?
En ese sentido, ¿tienen algún tipo de sistema de versionado/estabilidad de API que un frontend alternativo pueda seguir?
Tal vez la respuesta siga siendo una variedad de “no” por diversas razones, y si es así, está bien, pero si es factible… ¿podría ser interesante pensarlo? No pido un estudio de viabilidad a gran escala, tal vez solo algunas impresiones generales.
No estoy seguro de si algo así podría tener éxito o mantenerse. No a muchos desarrolladores les gusta trabajar en software antiguo que utiliza HTML y JS mínimo (pero todavía hay algunos, como la gente de HTMX). Solo una idea.