Funzionalità della piattaforma Web di crowdfunding con priorità aperta

Nel mio ultimo post, ho descritto alcune interessanti funzionalità CSS, alcune delle quali sono disponibili solo in un browser. La maggior parte degli sviluppatori web ha alcune funzionalità che vorrebbe fosse più ampiamente disponibile o che fosse disponibile del tutto. Incoraggio gli sviluppatori a utilizzare, parlare e sollevare bug di implementazione con i browser per cercare di implementare le funzionalità, tuttavia, cosa accadrebbe se ci fosse un modo più diretto per farlo? E se gli sviluppatori web potessero riunirsi e finanziare lo sviluppo di queste funzionalità?

Questo è il modello che la società di consulenza open source Igalia sta lanciando con il suo esperimento di Open Prioritization. L'idea di base è un modello di crowdfunding per le funzionalità della piattaforma web. Se vogliamo che una funzionalità venga implementata, possiamo investire una piccola somma di denaro per aiutare a finanziare quel lavoro. Se l'obiettivo viene raggiunto, la funzione può essere implementata. Questo articolo è basato su un'intervista con Brian Kardell, Developer Advocate di Igalia.

Che cos'è la priorità aperta?

L'idea della definizione delle priorità aperte è che la comunità può scegliere e aiutare a finanziare lo sviluppo delle funzionalità. Igalia ha selezionato un elenco di funzionalità di destinazione, tutte implementate o attualmente in fase di implementazione in almeno un motore. Pertanto, il finanziamento di una funzionalità lo aiuterà a diventare disponibile su più browser e più utilizzabile per noi come sviluppatori. L'elenco iniziale è:

• Colori CSS lab( ) in Firefox
• :focus-visible in WebKit/Safari
• HTML inert in WebKit/Safari
• Argomenti dell'elenco del selettore per :not( ) in Chrome
• Supporto per il contenimento CSS in WebKit/Safari
• Supporto CSS d (percorso SVG) in Firefox

Il sito Web fornisce maggiori spiegazioni su ciascuna caratteristica e tutti i dettagli su come funzionerà il finanziamento. Igalia sta lavorando con Open Collective per gestire gli impegni.

Chi sono Igalia?

Potresti non aver mai sentito parlare di Igalia, ma avrai beneficiato del loro lavoro. Igalia funziona sui motori dei browser e ha una conoscenza specialistica di tutti i motori. Nel 2019 hanno avuto il secondo numero più alto di commit per Chrome e WebKit. Se ami CSS Grid Layout, allora devi ringraziare Igalia per l'implementazione in Chrome e WebKit. Il lavoro per aggiungere la funzionalità a quei browser è stato svolto da un team di Igalia, piuttosto che da ingegneri che lavoravano internamente presso la società di browser.

Questo è ciò che rende questa idea così avvincente. Non si tratta di raccogliere dei soldi e poi cercare di convincere qualcuno a fare il lavoro. Igalia ha una lunga esperienza nel fare il lavoro. Gli sviluppatori devono essere pagati, quindi tramite il crowdsourcing dei soldi siamo in grado di scegliere su cosa lavorare dopo. Igalia ha anche già le relazioni con i motori per rendere probabile che qualsiasi funzionalità suggerita abbia successo.

I browser accetteranno queste funzionalità se le finanziamo?

Il fatto che Igalia abbia già relazioni all'interno dei team di motori di browser e abbia già discusso con loro le funzionalità selezionate significa che, se finanziato, dovremmo vedere le funzionalità nei browser. E ci sono già precedenti per funzionalità importanti finanziate da terze parti e sviluppate da Igalia. L'implementazione di Grid Layout in Chrome e WebKit è stata finanziata da Bloomberg Tech. Erano frustrati dalla mancanza di implementazione di Grid Layout ed è stata Bloomberg Tech a fornire i soldi per sviluppare quella funzionalità per diversi anni.

Chrome e WebKit sono stati felici di accettare l'implementazione; non ci sono state controversie sull'aggiunta della funzione. Piuttosto, era una questione di priorità. I browser avevano altro lavoro che era considerato una priorità più alta e l'impegno finanziario e il tempo degli sviluppatori erano quindi diretti altrove. Anche le caratteristiche che sono state selezionate per questo tentativo iniziale di crowdfunding non sono controverse in termini di implementazione. Se il lavoro può essere fatto, è probabile che i motori lo accettino. L'interoperabilità - le cose che funzionano allo stesso modo tra i browser - è qualcosa che interessa a tutti i fornitori di browser. Non c'è alcun vantaggio per un motore in ritardo. In sostanza, riusciamo semplicemente a bypassare il processo interno di definizione delle priorità per la funzione.

Perché i browser non fanno solo queste cose?

Ho chiesto a Brian perché le società di browser non finanziano queste cose da sole. Lui ha spiegato,

“La gente potrebbe pensare, ad esempio, 'Apple ha tutti i soldi del mondo', ma questo ignora realtà complesse. L'attività di Apple non è il loro browser Web. In effetti, il browser Web stesso non è uno sforzo per fare soldi per nessuno. I browser e gli standard sono volontari, sono beni comuni. Dal punto di vista dei costi, tuttavia, i browser sono considerevoli. Sono enormemente più complessi di quanto la maggior parte di noi creda. Solo 3 organizzazioni oggi hanno investito i molti anni e milioni di dollari all'anno necessari per evolvere e mantenere un progetto di motore di rendering. Ognuno di loro sta già facendo un investimento massiccio e senza precedenti nei beni comuni".

Brian ha poi sottolineato il notevole investimento di Firefox in Servo e di Google in LayoutNG, progetti che miglioreranno l'esperienza del browser e consentiranno anche di implementare nuove funzionalità della piattaforma. C'è molto che qualsiasi browser potrebbe implementare nel proprio motore, ma il modo in cui queste funzionalità hanno la priorità interna potrebbe non corrispondere sempre alle nostre esigenze di sviluppatori.

Mi è venuto in mente che, finanziando l'implementazione del browser, stiamo facendo la stessa cosa che facciamo per gli altri prodotti che utilizziamo. Molti di noi avranno sviluppato un plug-in per una funzionalità necessaria in un CMS o pagato una terza parte per fornirlo. Gli sviluppatori CMS trascorrono il loro tempo lavorando sul prodotto principale, assicurandosi che sia robusto, sicuro e aggiornato. Senza il prodotto principale, l'aggiunta di plug-in sarebbe impossibile. Terze parti, tuttavia, possono contribuire con parti a quella piattaforma e, in un certo senso, questo è ciò che possiamo fare tramite la definizione delle priorità aperte. Dimostra che una funzione è abbastanza utile da permetterci di impegnare un po' di denaro per superarla.

Come si adatta a progetti come il Web che vogliamo?

SmashingConf ha supportato il progetto Web We Want, in cui gli sviluppatori hanno presentato idee per piattaforme web da discutere e votare sul palco durante le conferenze. Sono stato coinvolto in molti di questi eventi come presentatore e nel panel. Mi chiedevo come la definizione delle priorità aperte si adattasse a questi sforzi esistenti. Brian ha spiegato che queste sono cose abbastanza diverse dicendo,

“... se mi chiedessi cosa potrebbe rendere migliore la mia casa potrei nominare un milione di cose. Alcuni di questi non sono nemmeno lontanamente pratici, sarebbero semplicemente davvero belli. Ma se dicessi di fare un elenco di cose che potresti fare con un budget per quello che ognuno costa, il mio elenco sarà considerevolmente più pratico e vincolato da realtà che so esistere.

Alla fine del mese se dici "c'è la tua lista, e qui ci sono $ 100, cosa ne farai?" questa è una domanda molto diretta che mi aiuta a realizzare qualcosa di pratico. Forse dipingerò. Forse comprerò delle nuove luci. O forse lo risparmierò per alcuni mesi per qualcosa di più costoso.

Il progetto Web We Want pone una domanda aperta, chiede cosa vogliamo dalla piattaforma. Molti dei desideri non sono cose che già esistono come specifica. Iniziare effettivamente a implementare una di queste cose significherebbe iniziare proprio dall'inizio, con un'idea che deve essere presa fin dalla fase di specifica. Ci sono poche certezze, e sarebbe molto difficile dargli un prezzo.

Le funzionalità selezionate per questo primo esperimento di definizione delle priorità aperte hanno una portata deliberatamente limitata. Hanno già qualche implementazione; hanno una specifica e Igalia ha già parlato con i manutentori del browser per verificare che le funzionalità siano pronte per funzionare ma non siano presenti nelle priorità immediate.

Sostenere questo progetto significa sostenere un pezzo concreto di sviluppo, che può avvenire in un lasso di tempo ragionevolmente breve. Pubblicare un'idea su Web We Want, scrivere un'idea sul tuo blog o aggiungere un problema che descrive una funzionalità completamente nuova nel repository GitHub CSSWG porta potenzialmente una nuova idea nella discussione. Tuttavia, quelle idee potrebbero avere un lungo percorso lento per diventare realtà. E, data la natura delle discussioni sugli standard, probabilmente non accadrà esattamente nel modo che avevi immaginato. È prezioso proporre queste cose, ma è molto difficile stimare tempi e costi per un'implementazione finale.

Lo stesso problema vale per la tanto ricercata funzionalità delle query sui container, Igalia è arrivata al punto di menzionare le query sui container nelle loro FAQ. Le query sui container sono qualcosa che molte persone coinvolte nel processo degli standard e presso i fornitori di browser stanno esaminando, tuttavia, tali discussioni sono in una fase iniziale. Non è qualcosa su cui sarebbe possibile attribuire un valore monetario a questo punto.

Mettersi in gioco!

Sono disponibili ulteriori informazioni sul sito Open Prioritization, insieme a una FAQ dettagliata che risponde ad altre domande che potresti avere. Sono entusiasta di questo perché sono sempre desideroso di aiutare a trovare modi per consentire a designer e sviluppatori di essere coinvolti nella piattaforma web. È la nostra piattaforma. Possiamo aspettare che le cose vengano concesse per l'uso dai fornitori di browser, oppure possiamo contribuire attivamente tramite idee, segnalazioni di bug e con Open Prioritization un po' di denaro, per contribuire a migliorarlo.