Terwijl de PostgreSQL-olifant doorgaat
zijn opmars naar weer een nieuwe release, heb ik nogal wat nagedacht
over de rol die gebruikers van software zouden moeten spelen zijn gebruikersinterface
ontwerp. Vandaag heb ik iets voorgesteld waardoor een databaseparameter
mensen zich vroeger zorgen moesten maken, en dat was helemaal niet duidelijk
hoe ze moesten worden ingesteld, en waarvan de waarde grotendeels automatisch wordt gemaakt. Dat is een mooie
ondubbelzinnige voorwaartse verandering; gebruikers waren geïrriteerd, goed standaardgedrag
vastgesteld, en dat standaardgedrag werd voorgesteld als een patch. Als het wordt toegepast, zou ik geschokt zijn als ik iemand zou vinden die dat een slechte
beslissing vindt.
Er is een soortgelijke discussie geweest over
hoe de gebruikersinterface rond databasecontrolepunten moet worden aangepast. Op dit moment wordt de snelheid waarmee gegevens door een controlepunt naar de schijf worden geschreven,
beïnvloed door drie waarden die de gebruiker kan specificeren. De interactie
tussen deze is goed genoeg gedocumenteerd, zij het op een manier die
de complexiteit weerspiegelt, en sommige gebruikers vinden het gedrag dat het geeft
goed presteert. Het is heel goed mogelijk dat om dingen
beter te maken voor de typische gebruiker, er in sommige gevallen een prestatie
regressie zal zijn ten opzichte van de huidige code. Het gebruik van een
andere implementatie die de effectieve schaal van de
parameters verandert, zal resulteren in subtiele veranderingen in de timing, en ze zullen niet
per definitie allemaal positief zijn. In deze situatie kunnen we als ontwikkelingsgemeenschap het beste
voldoende benchmarkgegevens verzamelen om
die oproep te doen. Het kan zijn dat het verbeteren van de worstcasescenario's
de zaken enigszins verslechtert ten opzichte van de eerdere implementatie. Als
het nettoresultaat gemakkelijker aan te passen blijkt te zijn – het vervangen van meerdere
gecompliceerde instellingen door één enkele, zoals ik suggereerde, zou hier de
juiste richting kunnen zijn, zou dat gemiddeld beter moeten zijn. Soms is het nodig om de oude aanpak los te laten om er een te krijgen die beter is.
Maar dit is hoeveel we ons zorgen maken
over het breken van gedrag waarop gebruikers vertrouwen. Er is veel aandacht voor
achterwaartse compatibiliteit en er worden alleen dingen toegevoegd op een manier die
de oude benadering in PostgreSQL-ontwikkeling niet weghaalt. Soms is er echter
geen keuze:je moet naar een nieuwe aanpak streven. In gevallen
waar zowel oud als nieuw gedrag volkomen legitiem is, is het ooit
het bereiken van zelfs een duidelijke meerderheidsopinie moeilijk. Dat is vaak het
geval bij het ontwerpen van gebruikersinterfaces. Hoewel je dat kunt benchmarken met de
juiste tools en professionals, wordt dit zelden gedaan in de
open-sourcegemeenschap. Het is moeilijk om een gemeenschapsconsensus te krijgen uit die mix
van zeer persoonlijke meningen.
Ik werd er weer aan herinnerd hoe ik als ontwikkelaar niet
om moet gaan met gebruikersfeedback door vandaag enkele updates te ontvangen
over een lang vervelende regressie in hoe gnome- terminal, mijn nominale
geprefereerde opdrachtregelterminal, verwerkt toetsenbordinvoer. Het probleem
kwam bijna precies twee jaar geleden voor het eerst in een bugrapport, op een
Ubuntu-tracker, om vervolgens te migreren naar de onderliggende
bron van de regressie:een opzettelijke wijziging door een van de GNOME
ontwikkelaars om gedrag te elimineren dat ze ongepast vonden. Er was een ticket geopend waarin om een oplossing werd gevraagd, maar het was nooit veel meer dan beledigend voor alle betrokkenen.
Ik ben zo actief geweest in de laatste
ticketgeschiedenis dat ik mijn argument hier niet hoef te herhalen.
In wezen was alles wat ik wilde een configuratieoptie met selectievakjes om
terugkeren naar het oude gedrag mogelijk te maken. Ik begon zelfs
om precies dat te doen, door in de code te graven om tijdelijke oplossingen voor te stellen,
alleen om te beseffen dat dit nooit zou worden samengevoegd. Mijn
suggesties waren erop gericht om een gemeenschappelijke basis te vinden die
iedereen tevreden zou stellen. Het is heel duidelijk dat de ontwikkelaars daar niets om geven
maar. Ze doen wat ze willen, en
de rest doet er niet toe. Dat mij werd verteld dat er "een paar honderd" klachten zouden duren voordat dit als belangrijk zou worden beschouwd
verbaast me, aangezien het gebruik van de bedieningssleutel in de terminal
niet bepaald het meest populaire is . Er waren tientallen rapporten,
elke ontvangen klacht werd verenigd in de geprefereerde
oplossing, en de enige persoon die het er niet mee eens was, was een van hun
ontwikkelaars.
We krijgen klachten van mensen dat
de PostgreSQL-community vol zit met ontwikkelaars die de voorkeur geven aan
technisch zuivere oplossingen in plaats van de gebruikers te geven wat ze willen.
Dat is tot op zekere hoogte waar, zoals de aanhoudende weerstand tegen
toevoegen van tabellen tonen als een alternatieve manier om de
database in uw database te vinden. Maar al die discussie ging over
onderwerpen waar de discussie zeer gemengde meningen geeft; veel mensen
hebben aan beide kanten een uitgesproken mening. Als elke gebruiker het eens is over een
ontwerp, wat het geval is met dit probleem met de gnome-terminal, is het afwijzen van
die meningen als nog steeds niet juist, het toppunt van ontwikkelaar
arrogantie.
Een van de interessantere voorbeelden van
dit soort dingen betreft de ontwikkelaars van de Pidgin IM-software
het wijzigen van de manier waarop de tekstgrootte van het chatvenster werkt in hun programma.
Gebruikers kwamen in opstand. Er is een goed voorbeeld van het oude en nieuwe gedrag met wat
analyse bij CodingHorror.
Iedereen werd getikt door de manier waarop de
ontwikkelaars hun feedback leken te negeren. Hun perceptie was
dat de feedback van de gemeenschap niet relevant was voor de ontwikkelaars, omdat
ze vonden dat hun ontwerp beter was dan het oude, ongeacht wat
de gebruikers dachten. Iemand heeft een plug-in geschreven om het oude
gedrag te herstellen. En toen was er een officiële splitsing. De missie
verklaring
van de resulterende vork, oorspronkelijk "Fun Pidgin" genoemd en nu
genaamd "Carrier Instant Messenger", is interessant om te lezen hoe
ze zich gebruikersgericht voelen ontwikkeling zou moeten werken.
Jeff Atwood's CodingHorror-discussie
hiervan suggereerde vier manieren waarop zo'n vork zou kunnen uitpakken. Hij liet
een heel belangrijke weg:de mogelijkheid dat door het
opsplitsen van de inspanningen van de gemeenschap, beide vorken zouden sterven, zonder dat geen van beide genoeg
middelen zou hebben om te concurreren met de alternatieven. Hoewel Pidgin nog niet
dood is - het is een eindje verwijderd van "rennen door het gordijn en voegde zich bij
het onzichtbare koor van bloeden", zijn ze minder belangrijk dan ze
vroeger waren, en dit hele debacle hielp hun zaak niet. Vanaf
Ubuntu 9.10 verving Canonical Pidgin als de primaire IM-client
verzending met die zeer populaire Linux-distributie. In plaats daarvan hebben ze
GNOME Empathy op zijn plaats gezet. Zou dat nog steeds zijn gebeurd als de
Pidgin-gemeenschap niet was gebroken en in verband werd gebracht met zulke slechte
PR? Mogelijk, maar dat hielp hun zaak zeker niet.
Dat dezelfde soort gebruikersonwetende
beslissingen worden genomen met betrekking tot een populair GNOME-project zoals
gnome-terminal is vermakelijk (ik lach nogal dan huilen) op weg naar
een vergelijkbare situatie. Twee maanden geleden werd aangekondigd dat Ubuntu in hun volgende release aanzienlijk afstapte van het gebruik van de volledige GNOME-softwarestack. Let goed op wat daar gebeurde.
Mark Shuttleworth zegt dat ze professionele UI-ontwerpers hebben ingehuurd,
ze aan het werk hebben gezet om erachter te komen dat dit beter zou werken voor de desktopgebruiker
ervaring, en vervolgens de resultaten aan de GNOME-gemeenschap.
In plaats van dit uiterst waardevolle werk te accepteren en Canonical te bedanken
voor het doen van dat onderzoek, verwierpen ze genoeg fundamentele ideeën dat
er geen middenweg mogelijk was. Ubuntu gaat nu op een grote
manier richting het Unity-project, als de enige overgebleven weg om "te doen wat onze
gebruikers willen". Op basis van mijn eigen interactie die ik heb gehad met de GNOME
-ontwikkelaars in de jaren sinds ik deze ergernis tegenkwam, verbaast de
reactie die Mark kreeg me geen moment.
We zijn nog steeds op het punt waar het
niet duidelijk is hoe deze Unity-splitsing zal uitpakken. Wat ik verwacht is
dat dit hele gebeuren ook zal leiden tot een soort dubbele mislukking
situatie. Er zal een heleboel dubbele ontwikkeling zijn die
op zichzelf in eerste instantie niets nuttigs oplevert. De eerste
releases zullen een vreselijke kwaliteitscontrole hebben - dit spul duurt
een eeuwigheid om goed te krijgen. En door de ontwikkelaarsbasis te splitsen, is het
heel goed mogelijk dat geen van beide groepen genoeg mensen over heeft om ooit te eindigen
goed werk te doen, waardoor we allemaal achterblijven met meerdere slechte Linux-desktop
opties (opnieuw) in plaats van één verenigde staat iedereen in de rij om
te verbeteren. Ik hoopte inmiddels dat de manier waarop Nokia is verbeterd
de licentie voor Qt eindelijk zou kunnen maken om te overwegen hoe te elimineren
het hebben van beide Qt+GNOME. Dat Linux in plaats daarvan een
ontwikkelingsproject bovenop de mix krijgt, en het Unity of all things noemen, is een
vreselijke grap.
Maar ik had het over databases... een
van de interessante dingen over PostgreSQL is hoeveel vorken het heeft
gegenereerd. De genereuze BSD-licentie had geleid tot meerdere
closed-source commerciële forks; Ik werkte bij een bedrijf dat er
een maakte. Netezza was de eerste die uiteindelijk uitgroeide tot een serieuze
commerciële productie. En de Greenplum Database is onlangs
gekocht door EMC, het is een zeer succesvol product. Wat niet
is gebeurd, is dat een van de open-source vorken een levensvatbare vervanging wordt
voor de hoofddistributie. Tenzij u over het soort grote
middelen beschikt die een groot bedrijf kan inzetten voor engineering, is het
gemakkelijker om de gemeenschap uw ideeën te laten accepteren dan om te proberen
en een onafhankelijke implementatie uit te voeren van hen. Rechte community
PostgreSQL blijft gewoon de juiste keuze.
De PostgreSQL-gemeenschap maakt veel ruzie,
en staat vijandig tegenover veel dingen waar mensen om vragen; we hebben zelfs een
lijst die we niet willen doen.
Dit zijn meestal dingen die gewoon technisch niet
haalbaar zijn om te bouwen zonder nadelen die niet altijd duidelijk zijn voor
degenen die erom vragen. Als een gebruiker beargumenteert waarom een wijziging
een betere gebruikersinterface zou opleveren voor iets in de database, en
er geen technische bezwaren zijn waarom dit een probleem zal veroorzaken,
>die verandering wordt overwogen. Wat ik nog nooit in de gemeenschap heb gezien, is
een van de ontwikkelaars die tegenover een unanieme, ondubbelzinnige gebruiker
voorkeur staan, waarbij die optie zonder
nadelen beschikbaar kan worden gesteld, simpelweg omdat ze hou er niet zo van. Als je een
ontwikkelaar bent van een open source-project dat afdwaalt naar waar overmoed
de nederigheid zo slecht heeft overtroffen, wees dan niet verbaasd als je gebruikers
woede genoeg zullen zijn om te forken. En een dezer dagen zul je misschien ontdekken dat
de forks of herimplementaties die wel aandacht besteden aan wat mensen
echt willen, je zullen verdringen.