Bricks responde al caso Advanced Themer: avisará antes cuando se acerque al terreno de un plugin
Hace unos días os contaba que Advanced Themer había decidido dejar de añadir nuevas funcionalidades.
Bricks ha respondido. Y más que la respuesta al conflicto, me interesa lo que cambia a partir de ahora.
Primero, Thomas y Maxime Beguin han hablado directamente.
Por lo que cuenta Thomas, había puntos en los que veían la situación de forma distinta y la conversación sirvió para aclararlos.
Dice que no hay malas intenciones entre ellos, reconoce lo que Advanced Themer ha aportado al ecosistema y asegura que seguirán hablando sobre cómo hacer que Bricks y Advanced Themer puedan convivir mejor para sus usuarios.
Pero para mí, lo interesante viene después.
Bricks reconoce que está comunicando demasiado tarde lo que está construyendo.
Tienen un roadmap público, pero Thomas admite que no siempre refleja todo lo que está desarrollando el equipo.
Y eso es especialmente importante para quienes crean herramientas alrededor de Bricks.
Porque si descubres una nueva funcionalidad cuando prácticamente está terminada, puede que lleves meses desarrollando exactamente lo mismo.
El compromiso ahora es mantener mejor actualizado el roadmap y comunicar antes hacia dónde va Bricks.
Y aquí aparece el verdadero problema de construir sobre un ecosistema.
Muchas de las funcionalidades que Bricks desarrolla salen de las peticiones de los usuarios: la tabla de ideas, los votos, el foro, soporte y las conversaciones con la comunidad.
Pero esa información también es pública.
Así que un desarrollador puede detectar una necesidad, crear un plugin para resolverla y encontrarse tiempo después con que Bricks ha llegado a la misma conclusión y quiere incorporarla al core.
De hecho, esa capacidad de los desarrolladores para moverse más rápido es precisamente una de las razones por las que existe un ecosistema tan grande alrededor de Bricks.
Lo que Bricks no va a prometer es que una funcionalidad cubierta por un plugin nunca llegue al core.
Y creo que esta parte es importante.
Mejorar Bricks significa que algunas cosas que hoy necesitan un plugin probablemente acabarán formando parte del propio builder.
Lo que sí se comprometen a hacer es avisar antes.
Y cuando exista un solapamiento importante con un producto asentado, contactar con su desarrollador y estudiar si tiene sentido colaborar.
Sin prometer de antemano cómo será esa colaboración, porque cada caso será diferente.
Mi lectura es que Bricks no está eliminando el riesgo. Está intentando hacerlo más previsible.
Si desarrollas un producto sobre Bricks, sigue existiendo la posibilidad de que mañana el core haga parte de lo que hace tu plugin.
La diferencia es tener tiempo para verlo venir y reaccionar.
Y para nosotros, como usuarios, también hay una lección interesante.
La tabla de ideas de Bricks no sirve únicamente para votar lo que quieres que desarrollen. También te da pistas sobre hacia dónde puede evolucionar tu stack.
Si una de las razones principales por las que pagas un plugin aparece allí y empieza a acumular interés, merece la pena prestarle atención.
No significa que Bricks vaya a implementarla mañana.
Pero sí que esa necesidad está encima de la mesa.
Y esto vuelve a una idea de la que hablamos bastante en Flowtitude:
intenta que tu metodología dependa menos de una herramienta concreta que tu implementación.
Los plugins cambiarán.
Bricks cambiará.
Algunas funcionalidades desaparecerán, otras pasarán al core y aparecerán herramientas mejores.
Lo importante es que tu forma de trabajar pueda sobrevivir a esos cambios.
Thomas también ha dicho que tratará el caso de Novamira por separado porque considera que la situación es diferente. Cuando publique esa respuesta, la comentamos también por aquí.
Y ahora tengo curiosidad:
¿Hay alguna función de un plugin que utilicéis habitualmente que ya hayáis visto aparecer en la tabla de ideas de Bricks?
