Toby el creador de Flarum nos explica su enfoque y el futuro de Flarum

Toby el creador de Flarum nos explica su enfoque y el futuro de Flarum

Voy a comenzar con un poco de un de historia, para explicar cómo llegamos a donde estamos ahora.
Historia

En 2015, como resultado de una campaña fallida de Kickstarter, me tomé un año de mi curso uni para dedicarme exclusivamente a la construcción de Flarum. Más que nada, fue una gran experiencia de aprendizaje. Franz (que estaba trabajando en FluxBB 2.0 en ese momento) se unió a mí hace unos meses. Ya había comenzado a crear la aplicación en Ember.js, y decidimos reescribir con Mithril.js por motivos de rendimiento.

Nos llevó unos pocos meses, pero finalmente completamos todas las funcionalidades básicas que esperaría de un foro: categorías, búsqueda, presupuestos, me gusta, buena UX móvil, suscripción a temas, y lanzamos la primera versión beta en agosto. Se lanzaron más características y lanzamos beta 2 el próximo mes.

Aunque Flarum se veía bien por fuera, no estábamos contentos con la forma en que el código estaba estructurado por dentro, y era importante hacerlo bien para que las extensiones tuvieran la potencia que necesitaban, y para que eventualmente nos comprometiéramos a mantenimiento de API y versiones semánticas. Así que pasamos los siguientes meses trabajando en un gran refactor de código base para intentar solucionarlo.

Las cosas se ralentizaron en 2016, ya que no había establecido un plan para mantener un ritmo de desarrollo razonable antes de volver a la universidad. La documentación aún era escasa, no habíamos perseguido a ningún desarrollador principal nuevo y, en términos generales, las cosas se estancaron un poco. Beta 5 salió en marzo, un total de cuatro meses después de la beta 3/4.

Si bien el software era bastante útil en esta etapa, todavía no estábamos listos para "estabilizarnos" porque queríamos construir más extensiones para desarrollar aún más la API de extensión. Y a medida que avanzaba el año, creo que tuvimos un poco de catch-22. Para mejorar la API de extensión, necesitábamos construir más extensiones. Pero estábamos recelosos de crear más extensiones porque estábamos planeando algunos cambios grandes y mal definidos en la API de extensión. Nos quedamos atrapados en una rutina con la falta de dirección, la falta de un plan y la consiguiente falta de motivación. Pasó otro medio año antes de lanzar la versión beta 6, que en su mayoría contenía pequeñas contribuciones de la comunidad.

A fines de 2016, me senté y comencé a redactar correctamente una lista de acciones específicas que debíamos tomar para estabilizar la API. Fue largo, y los cambios fueron vastos. Entre ellos se encontraba una gran reestructuración del espacio de nombres (que finalmente está a punto de fusionarse). La escala de algunos de estos cambios fue desalentadora, y el bloque motivacional sobre el desarrollo se mantuvo. A comienzos de 2017, seguía habiendo más planificación en el fondo, pero el progreso tangible en materia de desarrollo era muy deficiente.

Había pasado casi un año desde el último lanzamiento cuando salió la beta 7, y no fue un lanzamiento particularmente emocionante. Todavía no habíamos avanzado en ninguna de las refactorizaciones que habíamos planeado. Claramente, la escala de lo que estábamos tratando de lograr era demasiado grande, y no íbamos a llegar a ningún lado si continuamos a lo largo de esa hoja de ruta.

Así que en septiembre se nos ocurrió una nueva, dividiendo los cambios en trozos más pequeños y manejables. Nuestro personal se reunió y habló sobre cómo podemos acelerar las cosas y revitalizar el proyecto. Desde entonces, las cosas se han visto un poco más positivas:

@luceos se ha incorporado como desarrollador principal.
@Franz y @luceos han estado trabajando duro en el refactor de espacio de nombres grande y actualizando a Laravel 5.5, que se fusionará muy pronto.
Terminé mis exámenes y he estado trabajando en diversas mejoras y características para un cliente.
Lanzamos un Patreon para cubrir los costos de nuestro servidor (que anteriormente estaban fuera de su bolsillo) y disminuimos la necesidad de que hagamos trabajo con el cliente.

Avanzando

Supongo que una forma de ver todo esto es que "las cosas buenas toman tiempo". El plan que tenemos para Flarum es realmente emocionante, y es posible que gran parte no se haya producido sin una lluvia de ideas sobre el "tiempo de inactividad" durante finales de 2016/17. Estamos realmente agradecidos por la paciencia de todos durante este tiempo.

Pero estaría bromeando si dijera que esta es una forma aceptable de dirigir un proyecto de código abierto. No lo es, y siento haber decepcionado a todos. Quiero que Flarum sea un proyecto comunitario respetado y bien gestionado, y en este momento su reputación se ha visto empañada por el hecho de que todavía está en "beta" después de casi tres años. Estoy trabajando seriamente en tratar de ser un mejor líder, y estoy extremadamente agradecido por el increíble equipo que me rodea tratando de hacerme responsable.

Esto es lo que debe buscar en los próximos meses:

  • Queremos ser más transparentes con lo que estamos trabajando, por lo que haremos un esfuerzo para mantener actualizados los hitos de la versión. Específicamente, necesito extraer toda la información de planificación que tenemos actualmente en un documento interno sobre los problemas de GitHub.
  • Franz está trabajando en una nueva abstracción para la API de extensión que facilitará la escritura de extensiones 10 veces.
  • Trabajaré en mejorar el rendimiento de las bases de datos y las búsquedas en las próximas semanas.
  • Lanzaremos la versión beta 8 en algún momento después de que se haga lo anterior

Una vez terminada la beta 8 y teniendo ya la documentación escrita. Empezaremos a preparar una versión de Flarum que sea candidata para la versión 0.1.

Contribuciones

Creo que las contribuciones fueron desafortunadamente atrapadas en el catch-22 que mencioné antes: antes de alentar demasiado las contribuciones, queríamos que nuestro gran refactor de código base fuera hecho. Pero para hacer que el refactor de la base de código se haga más rápido, tal vez necesitábamos más colaboradores. Ahora que el refactor está prácticamente allí, las cosas deberían ser mucho más fáciles, tanto en términos de contribuciones para los contribuyentes como en términos de participación de los usuarios . ¡Estamos más que felices de entrenar a las personas en conjunto con nuestro trabajo de desarrollo! La historia de la contribución también mejorará mucho una vez que centremos nuestra atención hacia los documentos. Mientras tanto, si tiene los conocimientos técnicos, definitivamente apreciaríamos cualquier contribución a los documentos para que sea muy fácil para las personas comenzar. CONTRIBUTING.md podría hacer mucho con una actualización. Visión Mi visión personal para Flarum siempre ha sido solo hacer un asombroso software de foro de código abierto. Hermoso, simple, rápido, extensible. No estoy preocupado en este momento por cuántas personas lo están usando, porque todavía está en versión beta. Casi todo nuestro crecimiento hasta la fecha ha sido orgánico. Tampoco estoy demasiado preocupado por obtener ganancias. Sería bueno poder recibir donaciones suficientes a través del Patreon para no tener que preocuparse por hacer trabajo con los clientes. Y sería bueno establecer un SaaS oficial algún día, una vez que el software esté estable. Pero por ahora, considero que es una distracción de mi visión principal: crear un excelente software de foro. Espero que responda algunas de sus preguntas. Estoy más que feliz de escuchar sugerencias y críticas sobre cómo podemos manejar mejor esta nave :)

Flarum: Link
Original Post: Link