Funcții ale platformei web de crowdfunding cu prioritizare deschisă

În ultima mea postare, am descris câteva caracteristici CSS interesante - dintre care unele sunt disponibile doar într-un singur browser. Majoritatea dezvoltatorilor web au o caracteristică pe care și-ar dori să fie disponibilă mai pe scară largă sau care să fie disponibilă deloc. Încurajez dezvoltatorii să folosească, să vorbească despre și să ridice erori de implementare cu browsere pentru a încerca să implementeze funcțiile, totuși, ce se întâmplă dacă ar exista o modalitate mai directă de a face acest lucru? Ce se întâmplă dacă dezvoltatorii web s-ar putea reuni și s-ar putea finanța dezvoltarea acestor funcții?

Acesta este modelul pe care compania de consultanță open-source Igalia îl lansează cu experimentul Open Prioritization. Ideea de bază este un model de crowdfunding pentru caracteristicile platformei web. Dacă vrem să implementăm o funcție, putem pune o sumă mică de bani pentru a ajuta la finanțarea acelei lucrări. Dacă obiectivul este atins, caracteristica poate fi implementată. Acest articol se bazează pe un interviu cu Brian Kardell, Developer Advocate la Igalia.

Ce este prioritizarea deschisă?

Ideea prioritizării deschise este că comunitatea poate alege și ajuta la finanțarea dezvoltării caracteristicilor. Igalia a selectat o listă de caracteristici țintă, toate implementate sau implementate în prezent în cel puțin un motor. Prin urmare, finanțarea unei funcții o va ajuta să devină disponibilă între browsere și mai ușor de utilizat pentru noi, ca dezvoltatori. Lista inițială este:

• Culori CSS lab( ) în Firefox
• :focus-visible în WebKit/Safari
• HTML inert în WebKit/Safari
• Argumentele din lista selectorului pentru :not( ) în Chrome
• Suport CSS Containment în WebKit/Safari
• Suport CSS d (cale SVG) în Firefox

Site-ul web oferă mai multe explicații pentru fiecare caracteristică și toate detaliile despre modul în care va funcționa finanțarea. Igalia lucrează cu Open Collective pentru a gestiona angajamentele.

Cine sunt Igalia?

Poate că nu ați auzit niciodată de Igalia, dar veți fi beneficiat de munca lor. Igalia lucrează pe motoarele de browser și are cunoștințe de specialitate despre toate motoarele. Ei au avut al doilea cel mai mare număr de comitări către sursa Chrome și WebKit în 2019. Dacă îți place CSS Grid Layout, atunci trebuie să-i mulțumești Igaliei pentru implementarea în Chrome și WebKit. Lucrarea de adăugare a funcției la acele browsere a fost făcută de o echipă de la Igalia, mai degrabă decât de ingineri care lucrează intern la compania de browser.

Acesta este ceea ce face această idee atât de convingătoare. Nu este vorba de a strânge niște bani și apoi de a încerca să convingi pe cineva să facă treaba. Igalia are un palmares în a face treaba. Dezvoltatorii trebuie să fie plătiți, așa că prin crowdsourcing banii putem alege despre ce se lucrează în continuare. De asemenea, Igalia are deja relațiile cu motoarele pentru a face ca orice caracteristică sugerată să fie un succes.

Vor accepta browserele aceste funcții dacă le finanțăm?

Faptul că Igalia are deja relații în cadrul echipelor de motoare de browser și a discutat deja despre caracteristicile selectate cu acestea înseamnă că, dacă va fi finanțat, ar trebui să vedem funcțiile în browsere. Și, există deja precedente pentru caracteristicile majore finanțate de terți și dezvoltate de Igalia. Implementarea Grid Layout în Chrome și WebKit a fost finanțată de Bloomberg Tech. Au fost frustrați de lipsa implementării Grid Layout și Bloomberg Tech a fost cea care a oferit banii pentru dezvoltarea acestei funcții de-a lungul mai multor ani.

Chrome și WebKit au fost bucuroși să accepte implementarea; nu a existat nicio controversă cu privire la adăugarea caracteristicii. Mai degrabă, a fost o chestiune de prioritizare. Browserele aveau alte lucrări care au fost considerate o prioritate mai mare și, prin urmare, angajamentul financiar și timpul de dezvoltare au fost direcționate în altă parte. Caracteristicile care au fost selectate pentru această încercare inițială de crowdfunding nu sunt, de asemenea, controversate în ceea ce privește implementarea lor. Dacă lucrarea poate fi făcută, este posibil ca motoarele să o accepte. Interoperabilitatea - lucrurile care funcționează în același mod în toate browserele - este ceva la care le pasă tuturor furnizorilor de browsere. Nu există niciun beneficiu ca un motor să rămână în urmă. În esență, ajungem să ocolim procesul intern de prioritizare pentru funcție.

De ce browserele nu fac doar aceste lucruri?

L-am întrebat pe Brian de ce companiile de browser nu finanțează singure aceste lucruri. A explicat,

„Oamenii s-ar putea gândi, de exemplu, „Apple are toți banii din lume”, dar acest lucru ignoră realitățile complexe. Afacerea Apple nu este browserul lor web. De fapt, browserul web în sine nu este un efort de a face bani pentru nimeni. Browserele și standardele sunt voluntare, sunt un bun comun. Din punct de vedere al costurilor, totuși, browserele sunt considerabile. Sunt mult mai complexe decât ne dăm seama cei mai mulți dintre noi. Doar 3 organizații de astăzi au investit mulți ani și milioane de dolari anual de care este nevoie pentru a evolua și a menține un proiect de motor de randare. Oricare dintre ei face deja o investiție masivă și de neegalat în comun.”

Brian a continuat subliniind investiția considerabilă a Firefox în Servo și Google în LayoutNG, proiecte care vor îmbunătăți experiența browserului și, de asemenea, vor face posibilă implementarea de noi funcții ale platformei. Există multe pe care orice browser le -ar putea implementa în motorul său, dar modul în care aceste funcții sunt prioritizate intern poate să nu fie întotdeauna adaptat nevoilor noastre ca dezvoltatori.

Mi-a trecut prin minte că, prin finanțarea implementării browserului, facem același lucru pe care îl facem pentru alte produse pe care le folosim. Mulți dintre noi vor fi dezvoltat un plugin pentru o funcție necesară într-un CMS sau au plătit o terță parte pentru a o furniza. Dezvoltatorii CMS își petrec timpul lucrând la produsul de bază, asigurându-se că este robust, sigur și actualizat. Fără produsul de bază, adăugarea de pluginuri ar fi imposibilă. Cu toate acestea, terții pot contribui cu părți la platforma respectivă și, într-un sens, asta este ceea ce putem face prin prioritizarea deschisă. Arătați că o funcție este suficient de utilă pentru a ne angaja niște bani pentru a trece peste linie.

Cum se potrivește acest lucru cu proiecte precum web pe care le dorim?

SmashingConf a susținut proiectul Web We Want, în care dezvoltatorii au prezentat idei de platforme web pentru a fi discutate și votate pe scenă la conferințe. Am fost implicat în câteva dintre aceste evenimente în calitate de gazdă și în panel. M-am întrebat cum se potrivește prioritizarea deschisă cu aceste eforturi existente. Brian a explicat că acestea sunt lucruri destul de diferite spunând:

„... dacă m-ai întreba ce mi-ar putea face casa mai bună, aș putea numi un milion de lucruri. Unele dintre acestea nu sunt nici pe departe practice, ar fi doar foarte îngrijite. Dar dacă ai spune să faci o listă de lucruri pe care le poți face cu un buget pentru cât costă fiecare - lista mea va fi mult mai practică și legată de realitățile despre care știu că există.

La sfârșitul lunii, dacă spui „există lista ta și aici sunt 100 USD, ce vei face cu ea?” aceasta este o întrebare foarte directă care mă ajută să realizez ceva practic. Poate voi picta. Poate voi cumpăra niște iluminare nouă. Sau poate o voi economisi câteva luni pentru ceva mai costisitor.”

Proiectul Web We Want pune o întrebare deschisă, întreabă ce vrem de la platformă. Multe dintre dorințe nu sunt lucruri care există deja ca specificație. A începe efectiv să implementezi oricare dintre aceste lucruri ar însemna să începi chiar de la început, cu o idee care trebuie luată chiar din etapa de specificare. Sunt puține certitudini și ar fi foarte greu să le pui preț.

Caracteristicile selectate pentru acest prim experiment deschis de prioritizare sunt în mod deliberat limitate în domeniul de aplicare. Au deja implementare; au o specificație, iar Igalia a vorbit deja cu întreținerii browserului pentru a verifica dacă funcțiile sunt gata de funcționare, dar nu figurează în prioritățile imediate.

Sprijinirea acestui proiect înseamnă sprijinirea unei părți concrete de dezvoltare, care se poate întâmpla într-un interval de timp rezonabil de scurt. Postarea unei idei pe Web We Want, scrierea unei idei pe blogul dvs. sau adăugarea unei probleme care descrie o caracteristică complet nouă în repo-ul CSSWG GitHub poate aduce o idee nouă în discuție. Cu toate acestea, aceste idei pot avea o cale lungă și lent pentru a deveni realitate. Și, având în vedere natura discuțiilor despre standarde, probabil că nu se va întâmpla exact așa cum v-ați imaginat. Este valoros să propunem aceste lucruri, dar foarte greu de estimat timpul și costurile pentru o implementare finală.

Aceeași problemă este valabilă și pentru caracteristica mult dorită a interogărilor containerului, Igalia a mers atât de departe încât a menționat interogările containerului în Întrebări frecvente. Interogările de containere sunt ceva pe care mulți oameni implicați în procesul standardelor și furnizorii de browsere îl analizează, cu toate acestea, acele discuții sunt într-un stadiu incipient. Nu este ceva pe care ar fi posibil să se pună o valoare monetară în acest moment.

A se implica!

Există mai multe informații pe site-ul de Prioritizare deschisă, împreună cu o Întrebări frecvente detaliate care răspund la alte întrebări pe care le-ați putea avea. Sunt încântat de acest lucru, deoarece sunt întotdeauna dornic să ajut să găsesc modalități prin care designerii și dezvoltatorii să se implice în platforma web. Este platforma noastră. Putem aștepta ca vânzătorii de browsere să le permită folosirea lucrurilor sau putem contribui în mod activ prin idei, rapoarte de erori și cu Prioritizare deschisă un pic de numerar, pentru a ajuta la îmbunătățirea situației.