Recursos da plataforma web de crowdfunding com priorização aberta

No meu último post, descrevi alguns recursos CSS interessantes – alguns dos quais estão disponíveis apenas em um navegador. A maioria dos desenvolvedores da web tem algum recurso que eles gostariam que estivesse mais amplamente disponível, ou que estivesse disponível. Eu encorajo os desenvolvedores a usar, falar e levantar bugs de implementação com navegadores para tentar implementar recursos, no entanto, e se houvesse uma maneira mais direta de fazer isso? E se os desenvolvedores da web pudessem se reunir e financiar o desenvolvimento desses recursos?

Este é o modelo que a consultoria de código aberto Igalia está lançando com seu experimento de Priorização Aberta. A ideia básica é um modelo de crowdfunding para recursos da plataforma web. Se quisermos que um recurso seja implementado, podemos colocar uma pequena quantia de dinheiro para ajudar a financiar esse trabalho. Se o objetivo for alcançado, o recurso pode ser implementado. Este artigo é baseado em uma entrevista com Brian Kardell, Developer Advocate da Igalia.

O que é priorização aberta?

A ideia de priorização aberta é que a comunidade possa escolher e ajudar a financiar o desenvolvimento de recursos. A Igalia selecionou uma lista de recursos de destino, todos implementados ou atualmente sendo implementados em pelo menos um mecanismo. Portanto, financiar um recurso ajudará a torná-lo disponível em vários navegadores e mais utilizável para nós como desenvolvedores. A lista inicial é:

• Cores CSS lab( ) no Firefox
• :focus-visible no WebKit/Safari
• HTML inert no WebKit/Safari
• Argumentos da lista de seletores para :not( ) no Chrome
• Suporte de contenção CSS no WebKit/Safari
• Suporte a CSS d (caminho SVG) no Firefox

O site fornece mais explicações sobre cada recurso e todos os detalhes de como o financiamento funcionará. A Igalia está trabalhando com o Open Collective para gerenciar as promessas.

Quem são Igalia?

Você pode nunca ter ouvido falar de Igalia, mas terá se beneficiado do trabalho deles. Igalia trabalha em motores de navegador e tem conhecimento especializado de todos os motores. Eles tiveram o segundo maior número de commits para a fonte Chrome e WebKit em 2019. Se você gosta do CSS Grid Layout, deve agradecer a Igalia pela implementação no Chrome e no WebKit. O trabalho para adicionar o recurso a esses navegadores foi feito por uma equipe da Igalia, em vez de engenheiros trabalhando internamente na empresa de navegadores.

É isso que torna essa ideia tão atraente. Não se trata de levantar algum dinheiro e depois tentar persuadir alguém a fazer o trabalho. Igalia tem um histórico de fazer o trabalho. Os desenvolvedores precisam ser pagos, então, ao fazer crowdsourcing do dinheiro, podemos escolher o que será trabalhado em seguida. A Igalia também já tem os relacionamentos com os motores para fazer com que qualquer recurso sugerido seja um sucesso.

Os navegadores aceitarão esses recursos se os financiarmos?

O fato de Igalia já ter relacionamentos dentro das equipes de mecanismos de navegadores e já ter discutido os recursos selecionados com eles significa que, se financiado, devemos ver os recursos nos navegadores. E já existem precedentes de grandes recursos sendo financiados por terceiros e desenvolvidos pela Igalia. A implementação do Grid Layout no Chrome e WebKit foi financiada pela Bloomberg Tech. Eles ficaram frustrados com a falta de implementação do Grid Layout, e foi a Bloomberg Tech que forneceu o dinheiro para desenvolver esse recurso ao longo de vários anos.

O Chrome e o WebKit ficaram felizes em aceitar a implementação; não houve controvérsia sobre a adição do recurso. Pelo contrário, era uma questão de priorização. Os navegadores tinham outro trabalho que era considerado de maior prioridade e, portanto, o compromisso financeiro e o tempo do desenvolvedor foram direcionados para outro lugar. Os recursos que foram selecionados para esta tentativa inicial de financiamento coletivo também não são controversos em termos de implementação. Se o trabalho puder ser feito, os motores provavelmente o aceitarão. A interoperabilidade — as coisas funcionam da mesma maneira nos navegadores — é algo com o qual todos os fornecedores de navegadores se preocupam. Não há nenhum benefício para um motor ficar para trás. Basicamente, apenas conseguimos contornar o processo de priorização interna do recurso.

Por que os navegadores não fazem isso?

Perguntei a Brian por que as empresas de navegadores não financiam essas coisas. Ele explicou,

“As pessoas podem pensar, por exemplo, 'A Apple tem todo o dinheiro do mundo', mas isso ignora realidades complexas. O negócio da Apple não é seu navegador da Web. Na verdade, o navegador da web em si não é um empreendimento lucrativo para ninguém. Navegadores e padrões são voluntários, são comuns. Em termos de custo, no entanto, os navegadores são consideráveis. Eles são muito mais complexos do que a maioria de nós imagina. Apenas 3 organizações hoje investiram os muitos anos e milhões de dólares anualmente necessários para desenvolver e manter um projeto de mecanismo de renderização. Qualquer um deles já está fazendo um investimento maciço e sem paralelo nos bens comuns.”

Brian destacou ainda o investimento considerável do Firefox no Servo e do Google no LayoutNG, projetos que vão melhorar a experiência do navegador e também possibilitar a implementação de novos recursos da plataforma. Há muita coisa que qualquer navegador pode implementar em seu mecanismo, mas a maneira como esses recursos são priorizados internamente nem sempre pode corresponder às nossas necessidades como desenvolvedores.

Ocorreu-me que, ao financiar a implementação do navegador, estamos fazendo a mesma coisa que fazemos para outros produtos que usamos. Muitos de nós desenvolvemos um plugin para um recurso necessário em um CMS ou pagamos a terceiros para fornecê-lo. Os desenvolvedores de CMS gastam seu tempo trabalhando no produto principal, garantindo que ele seja robusto, seguro e atualizado. Sem o produto principal, adicionar plugins seria impossível. Terceiros, no entanto, podem contribuir com partes para essa plataforma e, de certa forma, é isso que podemos fazer por meio da priorização aberta. Mostre que um recurso vale a pena o suficiente para que possamos prometer algum dinheiro para obtê-lo além da linha.

Como isso se encaixa com projetos como a Web que queremos?

A SmashingConf apoiou o projeto Web We Want, onde os desenvolvedores apresentaram ideias de plataformas web para serem discutidas e votadas no palco em conferências. Estive envolvido em vários desses eventos como apresentador e no painel. Eu me perguntei como a priorização aberta se encaixa com esses esforços existentes. Brian explicou que são coisas bem diferentes dizendo:

“... se você me perguntasse o que poderia melhorar minha casa, eu poderia citar um milhão de coisas. Alguns deles não são nem remotamente práticos, eles seriam muito legais. Mas se você disser faça uma lista de coisas que você poderia fazer com um orçamento de quanto custa cada uma – minha lista será consideravelmente mais prática e vinculada a realidades que eu sei que existem.

No final do mês, se você disser "aqui está sua lista e aqui estão $ 100, o que você fará com ela?" essa é uma pergunta muito direta que me ajuda a realizar algo prático. Talvez eu pinte. Talvez eu compre uma nova iluminação. Ou talvez eu guarde por alguns meses para algo mais caro.”

O projeto Web We Want faz uma pergunta aberta, pergunta o que queremos da plataforma. Muitos dos desejos não são coisas que já existem como uma especificação. Para realmente começar a implementar qualquer uma dessas coisas significaria começar logo no início, com uma ideia que precisa ser tirada desde o estágio de especificação. Há poucas certezas, e seria muito difícil colocar um preço.

Os recursos selecionados para este primeiro experimento de priorização aberta são deliberadamente limitados em escopo. Eles já têm alguma implementação; eles têm uma especificação, e a Igalia já conversou com os mantenedores do navegador para verificar se os recursos estão prontos para funcionar, mas não aparecem em prioridades imediatas.

Apoiar este projeto significa apoiar uma parte concreta do desenvolvimento, que pode acontecer dentro de um prazo razoavelmente curto. Postar uma ideia no Web We Want, escrever uma ideia em seu blog ou adicionar um problema descrevendo um recurso totalmente novo no repositório CSSWG GitHub potencialmente traz uma nova ideia para a discussão. No entanto, essas ideias podem ter um caminho longo e lento para se tornarem realidade. E, dada a natureza das discussões sobre padrões, provavelmente não acontecerá exatamente da maneira que você imaginou. É valioso propor essas coisas, mas muito difícil estimar tempo e custos para uma implementação final.

O mesmo problema é verdadeiro para o recurso muito desejado de consultas de contêiner, Igalia chegou ao ponto de mencionar consultas de contêiner em suas perguntas frequentes. As consultas de contêiner são algo que muitas pessoas envolvidas no processo de padrões e fornecedores de navegadores estão analisando, no entanto, essas discussões estão em um estágio inicial. Não é algo que seria possível colocar um valor monetário neste momento.

Se envolver!

Há mais informações no site Open Prioritization, juntamente com um FAQ detalhado respondendo a outras perguntas que você possa ter. Estou animado com isso porque estou sempre disposto a ajudar a encontrar maneiras para designers e desenvolvedores se envolverem na plataforma web. É a nossa plataforma. Podemos esperar que as coisas sejam concedidas para uso pelos fornecedores de navegadores, ou podemos contribuir ativamente por meio de ideias, relatórios de bugs e com a Priorização Aberta um pouco de dinheiro, para ajudar a torná-lo melhor.