Características de la plataforma web de crowdfunding con priorización abierta

En mi última publicación, describí algunas funciones CSS interesantes, algunas de las cuales solo están disponibles en un navegador. La mayoría de los desarrolladores web tienen alguna característica que desearían que estuviera más ampliamente disponible, o que estuviera disponible. Animo a los desarrolladores a usar, hablar y plantear errores de implementación con los navegadores para intentar implementar funciones; sin embargo, ¿qué pasaría si hubiera una forma más directa de hacerlo? ¿Qué pasaría si los desarrolladores web pudieran unirse y financiar el desarrollo de estas funciones?

Este es el modelo que la consultora de código abierto Igalia está lanzando con su experimento Open Prioritization. La idea básica es un modelo de financiación colectiva para las características de la plataforma web. Si queremos que se implemente una función, podemos aportar una pequeña cantidad de dinero para ayudar a financiar ese trabajo. Si se alcanza el objetivo, se puede implementar la característica. Este artículo se basa en una entrevista con Brian Kardell, Developer Advocate en Igalia.

¿Qué es la priorización abierta?

La idea de la priorización abierta es que la comunidad pueda elegir y ayudar a financiar el desarrollo de funciones. Igalia ha seleccionado una lista de funciones de destino, todas las cuales están implementadas o se están implementando actualmente en al menos un motor. Por lo tanto, financiar una función ayudará a que esté disponible en todos los navegadores y sea más útil para nosotros como desarrolladores. La lista inicial es:

• Colores CSS lab( ) en Firefox
• :focus-visible en WebKit/Safari
• HTML inert en WebKit/Safari
• Argumentos de la lista de selectores para :not( ) en Chrome
• Soporte de contención CSS en WebKit/Safari
• Compatibilidad con CSS d (ruta SVG) en Firefox

El sitio web brinda más explicaciones de cada característica y todos los detalles de cómo funcionará la financiación. Igalia está trabajando con Open Collective para gestionar las aportaciones.

¿Quiénes son Igalia?

Puede que nunca hayas oído hablar de Igalia, pero te habrás beneficiado de su trabajo. Igalia trabaja en motores de navegador y tiene un conocimiento especializado de todos los motores. Tuvieron el segundo mayor número de compromisos con la fuente de Chrome y WebKit en 2019. Si te encanta el diseño de cuadrícula CSS, entonces tienes que agradecer a Igalia por la implementación en Chrome y WebKit. El trabajo para agregar la función a esos navegadores lo realizó un equipo de Igalia, en lugar de los ingenieros que trabajan internamente en la empresa del navegador.

Esto es lo que hace que esta idea sea tan convincente. No se trata de recaudar algo de dinero y luego tratar de persuadir a alguien para que haga el trabajo. Igalia tiene un historial de hacer el trabajo. A los desarrolladores se les debe pagar, por lo que mediante el crowdsourcing del dinero podemos elegir en qué se trabaja a continuación. Igalia también tiene las relaciones con los motores para hacer que cualquier característica sugerida sea un éxito.

¿Los navegadores aceptarán estas funciones si las financiamos?

El hecho de que Igalia ya tenga relaciones dentro de los equipos de motores de navegador y que ya haya discutido las características seleccionadas con ellos significa que, si se financia, deberíamos ver las características en los navegadores. Y ya hay precedentes de funciones importantes financiadas por terceros y desarrolladas por Igalia. La implementación de Grid Layout en Chrome y WebKit fue financiada por Bloomberg Tech. Estaban frustrados por la falta de implementación de Grid Layout, y fue Bloomberg Tech quien proporcionó el dinero para desarrollar esa función durante varios años.

Chrome y WebKit aceptaron con gusto la implementación; no hubo controversia sobre la adición de la función. Más bien, era una cuestión de priorización. Los navegadores tenían otro trabajo que se consideró de mayor prioridad y, por lo tanto, el compromiso financiero y el tiempo del desarrollador se dirigieron a otra parte. Las características que se han seleccionado para este intento inicial de financiación colectiva tampoco son controvertidas en términos de su implementación. Si se puede hacer el trabajo, es probable que los motores lo acepten. La interoperabilidad (las cosas que funcionan de la misma manera en todos los navegadores) es algo que preocupa a todos los proveedores de navegadores. No hay ningún beneficio para que un motor se quede atrás. Esencialmente, solo podemos omitir el proceso interno de priorización de la función.

¿Por qué los navegadores simplemente no hacen esto?

Le pregunté a Brian por qué las compañías de navegadores no financian estas cosas por sí mismas. Él explicó,

“La gente podría pensar, por ejemplo, 'Apple tiene todo el dinero del mundo', pero esto ignora realidades complejas. El negocio de Apple no es su navegador web. De hecho, el navegador web en sí mismo no es un esfuerzo para hacer dinero para nadie. Los navegadores y los estándares son voluntarios, son comunes. Sin embargo, en cuanto al costo, los navegadores son considerables. Son enormemente más complejos de lo que la mayoría de nosotros nos damos cuenta. Actualmente, solo 3 organizaciones han invertido los muchos años y millones de dólares anuales que se necesitan para evolucionar y mantener un proyecto de motor de renderizado. Cualquiera de ellos ya está haciendo una inversión masiva e incomparable en los bienes comunes”.

Brian continuó señalando la considerable inversión de Firefox en Servo y Google en LayoutNG, proyectos que mejorarán la experiencia del navegador y también permitirán implementar nuevas funciones de la plataforma. Hay muchas cosas que cualquier navegador podría implementar en su motor, pero la forma en que esas funciones se priorizan internamente puede no siempre corresponder a nuestras necesidades como desarrolladores.

Se me ocurrió que al financiar la implementación del navegador, estamos haciendo lo mismo que hacemos con otros productos que usamos. Muchos de nosotros habremos desarrollado un complemento para una característica necesaria en un CMS o pagado a un tercero para que lo proporcione. Los desarrolladores de CMS dedican su tiempo a trabajar en el producto central, asegurándose de que sea sólido, seguro y actualizado. Sin el producto principal, sería imposible agregar complementos. Sin embargo, los terceros pueden contribuir con partes a esa plataforma y, en cierto sentido, eso es lo que podemos hacer a través de la priorización abierta. Muestre que una función vale lo suficiente como para que podamos prometer algo de dinero para superarla.

¿Cómo encaja esto con proyectos como Web We Want?

SmashingConf ha apoyado el proyecto Web We Want, donde los desarrolladores presentaron ideas de plataformas web para ser discutidas y votadas en el escenario de las conferencias. Participé en varios de estos eventos como anfitrión y en el panel. Me preguntaba cómo encaja la priorización abierta con estos esfuerzos existentes. Brian explicó que estas son cosas muy diferentes diciendo:

“... si me preguntaran qué podría mejorar mi casa, podría nombrar un millón de cosas. Algunos de esos no son ni remotamente prácticos, simplemente serían geniales. Pero si dijiste que hicieras una lista de las cosas que podrías hacer con un presupuesto de lo que cuesta cada una, mi lista será considerablemente más práctica y estará limitada por las realidades que sé que existen.

Si al final del mes dices "ahí está tu lista, y aquí tienes $100, ¿qué harás con ella?" esa es una pregunta muy directa que me ayuda a lograr algo práctico. Tal vez pintaré. Tal vez compre alguna iluminación nueva. O tal vez lo guarde durante algunos meses para algo más costoso”.

El proyecto Web We Want hace una pregunta abierta, pregunta qué queremos de la plataforma. Muchos de los deseos no son cosas que ya existen como especificación. Comenzar realmente a implementar cualquiera de estas cosas significaría comenzar desde el principio, con una idea que debe tomarse desde la etapa de especificación. Hay pocas certezas, y sería muy difícil ponerles un precio.

Las características seleccionadas para este primer experimento de priorización abierta tienen un alcance deliberadamente limitado. Ya tienen alguna implementación; tienen una especificación, e Igalia ya ha hablado con los encargados del mantenimiento del navegador para verificar que las características estén listas para funcionar, pero que no estén incluidas en las prioridades inmediatas.

Apoyar este proyecto significa apoyar una parte concreta del desarrollo, que puede ocurrir en un período de tiempo razonablemente corto. Publicar una idea en Web We Want, escribir una idea en su blog o agregar un problema que describa una característica totalmente nueva en el repositorio CSSWG GitHub potencialmente genera una nueva idea en la discusión. Sin embargo, esas ideas pueden tener un camino largo y lento para convertirse en realidad. Y, dada la naturaleza de las discusiones sobre estándares, probablemente no suceda exactamente de la manera que imaginaste. Es valioso proponer estas cosas, pero es muy difícil estimar el tiempo y los costos para una implementación final.

El mismo problema es cierto para la característica tan buscada de las consultas de contenedores, Igalia ha ido tan lejos como para mencionar las consultas de contenedores en sus preguntas frecuentes. Las consultas de contenedores son algo que muchas personas involucradas en el proceso de estándares y en los proveedores de navegadores están investigando; sin embargo, esas discusiones se encuentran en una etapa temprana. No es algo a lo que sería posible ponerle un valor monetario en este punto.

¡Involucrarse!

Hay más información en el sitio de Open Prioritization, junto con preguntas frecuentes detalladas que responden a otras preguntas que pueda tener. Estoy entusiasmado con esto porque siempre estoy dispuesto a ayudar a encontrar formas para que los diseñadores y desarrolladores se involucren en la plataforma web. Es nuestra plataforma. Podemos esperar a que los proveedores de navegadores otorguen el uso de las cosas, o podemos contribuir activamente a través de ideas, informes de errores y con Open Prioritization un poco de efectivo, para ayudar a mejorarlo.