Ĉi tiu artikolo estas traduko de la artikolo «It is important for free software to use free software infrastructure» publikigita de Drew Devault sub la CC BY-SA 2.0-permesilo.

Averto: mi fondis projekton kaj firmaon centritan sur libera infrastrukturo. Mi elektas ne nomi ilin en ĉi tiu afiŝo kaj mi nur rekomendos solvojn, pri kiuj mi ne havas personan intereson.

La projektoj de liberaj programoj bezonas infrastrukturon: lokon por gastigi la kodon, por faciligi aferojn kiel la kontroladon de kodo, subtenon al la fina uzanto, sekvadon de cimoj, merkatiko, ktp. Kutima ekzemplo de ĉi tio estas la «forĝeja» platformo: infrastrukturo, kiu anoncas sin kiel universalan vendejon por multaj el la necesoj de liberaj projektoj en unu loko, kiel la koda gastigado kaj kontrolado, cimsekvado, diskutoj kaj tiel plu. Multaj projektoj ankaŭ uzos kromajn platformojn por provizi aliajn specojn de infrastrukturo: babilejoj, diskutejoj, sociaj retejoj, ktp.

Multaj el ĉi tiuj bezonoj havas neliberajn solvojn disponeblajn. GitHub estas populara proprieta kodejo, kaj GitLab, la plej granda konkuranto de GitHub, estas parte nelibera. Kelkaj projektoj uzas Discord-on aŭ Slack-on por babilejoj, Reddit-on kiel diskutejon aŭ Twitter-on kaj Facebook-on por merkatikado, atingo kaj subteno; ĉiu ĉi tiuj estas neliberaj. Laŭ mia opinio, dependi de ĉi tiuj platformoj por provizi infrastrukturon al via libera projekto estas eraro.

Kiam via libera projekto elektas uzi neliberan platformon, vi donas al ĝi oficialan konfidan voĉdonon nome de via projekto. Per aliaj vortoj, vi pruntas iom de la kredindeco kaj legitimeco de via projekto al la platformoj, kiujn vi elektas. Ĉi tiuj platformoj estas difinitaj per retefikoj, kaj via elekto estas investo en tiu reto. Mi dubus pri ĉi tiu investo mem kaj pri la saĝeco oferi al ĉi tiu platformoj vian konfidon kaj legitimecon, sed ekzistas ankaŭ pli maltrankviliga sekvo de ĉi tiu elekto: investo en nelibera platformo estas ankaŭ manko de investo en liberaj alternativoj.

Denove, la retefikoj estas la ĉefa kialo de la sukceso de ĉi tiuj platformoj. Grandaj komercaj platformoj havas multajn avantaĝojn tiurilate: grandajn merkatikajn buĝetojn, multe da kapitalo de investistoj kaj la avantaĝon de la posedo. Ju pli granda estu la posedanta platformo, des pli malfacila iĝas la tasko konkuri kun ĝi. Komparu ĉi tion kun liberaj platformoj, kiuj kutime ne havas la helpon de grandaj kvantoj da investoj aŭ grandajn merkatikajn buĝetojn. Krome, estas pli verŝajne, ke firmaoj fie agu por sekurigi sian pozicion ol projektoj de liberaj programoj. Se viaj propraj liberaj projektoj konkuras kun proprietaj komercaj opcioj, vi devas tre bone koni ĉi tiujn defiojn.

La liberaj platformoj havas esencan malavantaĝon, kaj via fido, aŭ manko de fido, en ili estas tre grava. GitHub ne maltrankviliĝos, se via projekto elektas gastigi sian kodon aliloke, sed elekti Codeberg-on, ekzemple, signifas multe por ili. Fakte via elekto malproporcie gravas al la liberaj platformoj: elekti GitHub-on doloras Codeberg-on multe pli ol elekti Codeberg-on doloras GitHub-on. Kaj kial devus projekto elekti uzi vian oferon antaŭ la proprietaj alternativoj, se vi ne donis al ili la saman ĝentilaĵon? Solidareco inter liberaj projektoj gravas por altigi la ekosistemon kiel tuton.

La lingvo HTML konformas kun la WHATWG-normo. Ĉar ĝi estas markolingvo, eraro en HTML ne kaŭzas, ke la paĝaro ceŝu funkcii, sed la retumilo ĝin montras kiel eble plej bone.

Havi erarojn en HTML estas problema, ĉar ĝi povas aperigi neatenditajn kaj malfacile reprodukteblajn erarojn, ĉefe kiam ili nur aperas en konkreta retumilo. Do estas necesega skribi validan HTML-n.

Tamen estas facile fari erarojn kaj ĝin pretervidi. Sekve oni rekomendas validigi la HTML-kodon, tio estas, trovi la erarojn kaj korekti ilin. Por tio ekzistas validiloj, kiuj generale simple montras erarojn. La plej ĝisdatigita kaj rekomendinda estas The Nu Html Checker. La W3C subtenas nodon de ĉi tiu validilo, kiu permesas al ni validigi HTML-dokumentojn en la retumilo, enigante URL-n, alŝutante dosieron kaj skribante la kodon en formularo. Ĉar ĉi tiu validilo estas libera programaro, vi povas instali ĝin facile en via komputilo.

La reta validilo bone funkcias, se vi nur devas validigi kelkajn retejojn okaze, sed ĝi ne utilas por validigi tutan retejon. Por tio mi rekomendas uzi la version de The Nu Html Checker, kiun oni plenumas en terminalo. Ĝi troviĝas en la dosiero vnu.jar (Java estas bezona).

Mi persone uzas la html5validator-pakon, ĉar mi laboras kun Python kaj ĝi ne signifas kroma dependaĵo. Por instali ĉi tiun pakon en GNU/Linukso-distribuo bazita sur Debiano oni nur devas plenumi...

sudo apt install default-jre
sudo pip3 install html5validator

Post la instalo havas ni programon kun la nomo html5validator, kiun ni povas plenumi en la terminalo:

html5validator index.html

Utilega argumento estas --root, kiu permesas validigi ĉiujn dosierojn en dosierujo, kaj en la dosierujo ene de la dosierujo..., tiel ĝis ĉiun ĝi validigis. Mi uzas ĝin donante la kernan dosierujon de mia retejo, validante tiel la tutan retejon en kelkaj sekundoj.

html5validator --root retejo/

Estas inde uzi ian kontinuan integriĝon por eviti plenumi mane la antaŭan komandon ĉiam, kiam vi ŝanĝas ion en la retejo. Por tio mi uzas GitLab CI. Tiel mi prizorgas ĉi tiun retejon kaj multajn aliajn sen HTML-eraroj kaj kiam mi rompas ion, mi rimarkas baldaŭ.

GitLab enhavas proprietan programon el Guglo, kaj ne ŝaijnas, ke ili formovos ĝin. Konkrete ĝi uzas la programon reCAPTCHA de Guglo, dokumentanta eĉ ĝian konfiguron.

Ĉi tio estas problema ne nur pro la temo de la programa libero, sed ankaŭ pro aliaj postefikoj de reCAPTCHA (kiel la labora ekspluatado kaj la vizaĝorekono por armeaj celoj).

La kodo ŝargas sin el la serviloj de Guglo, do ĝi povus bari la apertigon de novaj problemoj kaj la registron de novaj kontoj, kiam la Gugla servilo estu nealirebla.

Jam ekzistas malnove kelkaj problemoj malfermaj en la problemo-administrilo de GitLab.