Jak PostgreSQL Elephant pokračuje
ve svém pochodu k dalšímu vydání, docela jsem přemýšlel
o tom, jakou roli by měli mít uživatelé softwaru jeho uživatelské rozhraní
design. Dnes jsem navrhl něco, s čím se
lidé museli starat o parametr databáze, a nebylo vůbec zřejmé, jak jej nastavit, a jeho hodnota je do značné míry automatická. To je docela
jednoznačná změna vpřed; uživatelé byli naštvaní, bylo nastaveno dobré výchozí chování
a toto výchozí chování bylo navrženo jako oprava. Pokud to bude uplatněno, byl bych šokován, kdybych našel někoho, kdo to považuje za špatné
rozhodnutí.
Podobná diskuse byla o
jak přepracovat uživatelské rozhraní kolem kontrolních bodů databáze. Právě
teď je rychlost zápisu dat na disk kontrolním bodem
ovlivňována třemi hodnotami, které může uživatel zadat. Interakce
mezi nimi je dostatečně dobře zdokumentována, i když způsobem, který
odráží složitost, a někteří uživatelé považují chování, které poskytuje,
dobře. Je docela možné, že aby se věci
vylepšily pro typického uživatele, dojde v některých případech k regresi výkonu
vzhledem k aktuálnímu kódu. Použití
jiné implementace, která mění efektivní měřítko
parametrů, povede k jemným změnám načasování, které
nemusí být nutně všechny pozitivní. V této situaci to nejlepší, co můžeme
jako vývojářská komunita udělat, je shromáždit dostatek referenčních dat k provedení
to výzvy. Je možné, že vylepšení nejhorších scénářů
nepatrně rozladí věci ve srovnání s dřívější implementací. Pokud se ukáže
čistý výsledek jako snazší na úpravu – nahrazení více
složitých nastavení jediným, jak jsem navrhl, může být zde
správný směr – v průměru by to mělo být lepší. Někdy
je nutné opustit starý přístup, abychom získali
ten, který je lepší.
Velice nás však znepokojuje
narušení chování, na které uživatelé spoléhají. Velký důraz je kladen na
zpětnou kompatibilitu a pouze přidávání věcí způsobem, který
neodstraňuje starý přístup ve vývoji PostgreSQL. Někdy však
není na výběr:musíte tlačit na nový přístup. V případech
kde je staré i nové chování zcela legitimní, je někdy
dospět i k jasnému většinovému názoru těžké. To je často
případ v návrhu uživatelského rozhraní. I když to můžete porovnávat s
správnými nástroji a profesionály, v
komunitě open source se to dělá jen zřídka. Získat konsensus komunity z této směsi
velmi osobních názorů je obtížné.
Znovu mi bylo připomenuto, jak
jako vývojář neřešit zpětnou vazbu od uživatelů, když jsem dnes dostal několik aktualizací
o dlouhé otravné regresi v tom, jak gnome- terminál, můj nominální
preferovaný terminál příkazového řádku, zpracovává vstup z klávesnice. Problém
poprvé se objevil v hlášení o chybě téměř přesně před dvěma lety na
Ubuntu trackeru, jen aby migroval na základní
zdroj regrese:záměrná změna jednoho z GNOME
vývojáři eliminovali chování, které považovali za nevhodné. Byl otevřen lístek s žádostí o opravu, ale nikdy to nebylo nad rámec urážky pro všechny zúčastněné.
V historii poslední
vstupenky jsem byl natolik aktivní, že zde nemusím svůj argument opakovat.
V podstatě jsem chtěl jen možnost konfigurace zaškrtávacího políčka, která
umožní návrat ke starému chování. Dokonce jsem na tom začal pracovat
, kopal jsem se do kódu, abych navrhoval řešení,
jen abych si uvědomil, že neexistuje způsob, jak by se to mohlo někdy sloučit. Mé
návrhy se soustředily na snahu najít společnou řeč, která by
potěšila všechny. Je velmi jasné, že to vývojářům nezajímá
to. Dělají věci tak, jak se jim líbí, a
na všech ostatních nezáleží. To, že mi bylo řečeno, že to bude trvat „
několik stovek“ stížností, než to bude považováno za důležité
mám hlavu, když uvážím, že použití ovládacího klíče v terminálu
není zrovna nejoblíbenější . Byly to desítky hlášení,
každá jednotlivá obdržená stížnost byla sjednocena v preferovaném
rozlišení a jediný, kdo nesouhlasil, byl jeden z jejich
vývojářů.
Dostáváme několik stížností od lidí, že
komunita PostgreSQL je plná vývojářů, kteří dávají přednost
technicky čistým řešením před tím, než dávají uživatelům to, co chtějí.
To je do určité míry pravda, jako je pokračující odpor k
přidávání zobrazení tabulek jako alternativní způsob nalezení
databáze ve vaší databázi. Ale celá tato diskuse se týkala
témat, kde diskuse poskytuje velmi smíšené názory; mnoho lidí
má silné názory na obě strany. Pokud každý uživatel souhlasí s
designem, což je případ tohoto problému s gnome-terminálem, odmítání
těchto názorů jako stále nesprávných je vrcholem vývojářské
arogance.
Jedním ze zajímavějších příkladů
tohoto druhu věcí jsou vývojáři softwaru Pidgin IM
změnu toho, jak funguje velikost textu okna chatu ve svém program.
Uživatelé se vzbouřili. Dobrým příkladem starého a nového chování je určitá
analýza v CodingHorror.
Všichni byli překvapeni tím, jak se zdálo,
vývojáři ignorovali jejich zpětnou vazbu. Domnívali se,
že zpětná vazba komunity je pro vývojáře irelevantní, protože
se domnívali, že jejich design je lepší než ten starý, bez ohledu na to, co si
uživatelé mysleli. Někdo napsal zásuvný modul, který obnoví staré
chování. A pak došlo k oficiálnímu rozkolu. Poslání
výsledného forku, původně nazvaného „Fun Pidgin“ a nyní
nazývaného „Carrier Instant Messenger“, je zajímavé čtení v tom, jak se
cítí být zaměřeni na uživatele vývoj by měl fungovat.
Diskuse o CodingHorror Jeffa Atwooda
navrhla čtyři způsoby, jak by takový fork mohl dopadnout. Vynechal
velmi důležitou věc:možnost, že rozdělením
komunitního úsilí zemřou oba forky, aniž by ani jeden neměl dostatek
zdrojů, aby mohl konkurovat alternativám. I když Pidgin ještě není
mrtvý – je to kousek od toho, aby „seběhl závěs a přidal se
neviditelný krvácející sbor“ – jsou méně důležité, než
byly, a celý tento debakl nepomohl jejich věci. Od
Ubuntu 9.10 nahradil Canonical Pidgin jako primárního IM klienta
dodávaného s touto velmi populární distribucí Linuxu. Místo toho na její místo umístili
GNOME Empathy. Stalo by se to stále, kdyby se
komunita Pidginů nerozbila a nebyla spojována s tak špatným
PR? Možná, ale to jejich případu rozhodně nepomohlo.
To, že se stejný druh uživatelsky ignorantských
rozhodnutí činí v souvislosti s populárním projektem GNOME, jako je
gnome-terminal, je zábavné (spíš se směji než plakat) mířící k
podobné situaci. Před dvěma měsíci bylo oznámeno, že se Ubuntu
výrazně vzdaluje používání plného balíku softwaru GNOME ve svém příštím vydání. Všimněte si velmi pečlivě, co se tam stalo.
Mark Shuttleworth říká, že najali profesionální návrháře uživatelského rozhraní, dali
jemu práci zjistit, zda bude pro uživatele stolních počítačů fungovat lépe
, a poté výsledky představil Komunita GNOME.
Namísto toho, aby přijali tuto mimořádně hodnotnou práci a poděkovali společnosti Canonical
za provedení tohoto výzkumu, odmítli dost zásadních myšlenek,
které neexistovaly žádné střední cesty. Ubuntu se nyní ve velkém
rozvíjí směrem k projektu Unity, který je jedinou cestou, jak „dělat to, co naši
uživatelé chtějí“. Na základě mé vlastní interakce, kterou jsem měl s
vývojáři GNOME během let, kdy jsem se setkal s touto jedinou nepříjemností, mě
reakce, kterou Mark zaznamenal, ani trochu nepřekvapuje.
Stále jsme v bodě, kdy není
jasné, jak toto rozdělení Unity nakonec dopadne. Očekávám,
že celá tato věc povede také k jakémusi dvojitému selhání
. Vznikne spousta duplicitního vývoje,
který sám o sobě zpočátku nevytváří nic užitečného. Počáteční
vydání bude mít příšernou kontrolu kvality – to trvá
věčnost, než se to spraví. A rozdělením vývojářské základny je
dost možné, že ani jedné skupině nezbude dostatek lidí, kteří by kdy mohli skončit
odvádět dobrou práci, takže nám všem zůstane několik špatných linuxových desktopů
(opět) spíše než jeden sjednocený je každý připraven
zlepšit. Doufal jsem, že způsob, jakým Nokia vylepšuje
licence na Qt, by mohl konečně uvažovat o tom, jak odstranit
existenci Qt+GNOME. To, že Linux místo toho dostává ještě vývoj
projekt na vrcholu mixu a pojmenovává ho Jednota všech věcí, je
příšerný vtip.
Ale mluvil jsem o databázích...jedna
ze zajímavých věcí na PostgreSQL je to, kolik forků
vygeneroval. Velkorysá licence BSD vedla k mnoha
uzavřeným komerčním forkům; Kdysi jsem pracoval ve společnosti, která vyrobila
jeden. Netezza byla první z nich, která nakonec vytvořila seriózní
komerční produkci. A databáze Greenplum byla nedávno
koupena společností EMC, je to velmi úspěšný produkt. Co se
nestalo, je, že kterýkoli z open-source forků se stal životaschopnou náhradou
hlavní distribuce. Pokud nemáte takové velké
zdroje, jaké může velká společnost přinést do inženýrství, je
snazší přimět komunitu, aby přijala vaše nápady, než se snažit
a provést nezávislou implementaci z nich. Přímá komunita
PostgreSQL je stále tou správnou volbou.
Komunita PostgreSQL se hodně dohaduje
a je nepřátelská vůči spoustě věcí, které lidé požadují; dokonce máme
seznam, který nechceme dělat.
Toto jsou z velké části věci, které prostě není technicky
možné postavit bez nevýhod, které nejsou vždy zřejmé
těm, kteří je požadují. Pokud uživatel zdůvodní, proč by změna
pomohla k lepšímu uživatelskému rozhraní něčeho v databázi, a
neexistují žádné technické námitky proti tomu, proč by to způsobilo problém,
tato změna je zvažována. To, co jsem v komunitě nikdy neviděl, je
jakýkoli z vývojářů, který se postavil proti jednomyslným, jednoznačným uživatelským
preferencím – kde by tato možnost mohla být zpřístupněna bez
nevýhod – jednoduše proto, že takhle se mi to nelíbí. Pokud jste
vývojář projektu s otevřeným zdrojovým kódem, který putuje tam, kde arogance
tak těžce překonala pokoru, nedivte se, že se vaši uživatelé
rozhněvají natolik, že by se rozloučili. A jednoho z těchto dnů možná zjistíte, že
forky nebo reimplementace, které věnují pozornost tomu, co lidé
skutečně chtějí, vás vytěsní.