W miarę jak Słoń PostgreSQL kontynuuje
swój marsz w kierunku kolejnego wydania, sporo się zastanawiałem
o roli, jaką powinni odgrywać użytkownicy oprogramowania jego interfejs użytkownika
projekt. Dzisiaj zaproponowałem coś, co sprawia, że parametr bazy danych,
kiedyś ludzie musieli się martwić, a to wcale nie było oczywiste,
jak go ustawić, i sprawia, że jego wartość jest w dużej mierze automatyczna. To całkiem
jednoznaczna zmiana naprzód; użytkownicy byli zirytowani, ustanowiono dobre domyślne zachowanie
i to domyślne zachowanie sugerowano jako poprawkę. Gdyby to było zastosowane, byłbym zszokowany, gdybym znalazł każdego, kto uzna to za złą
decyzję.
Podobna dyskusja,
jak przerobić interfejs użytkownika wokół punktów kontrolnych bazy danych. Teraz
na szybkość, z jaką dane są zapisywane na dysku przez punkt kontrolny,
wpływają trzy wartości, które użytkownik może określić. Interakcja
między nimi jest wystarczająco dobrze udokumentowana, aczkolwiek w sposób
odzwierciedlający złożoność, a niektórzy użytkownicy uważają, że zachowanie, które zapewnia,
działa dobrze. Jest całkiem możliwe, że w celu poprawy
dla typowego użytkownika, w niektórych przypadkach nastąpi regresja wydajności
w stosunku do obecnego kodu. Użycie
innej implementacji, która zmienia efektywną skalę
parametrów, spowoduje subtelne zmiany w czasie i niekoniecznie wszystkie będą pozytywne. W tej sytuacji najlepsze,
co możemy zrobić jako społeczność programistów, to zebrać wystarczającą ilość danych porównawczych, aby
nawiązać to połączenie. Może się zdarzyć, że poprawienie najgorszych scenariuszy
nieznacznie rozstraja sytuację w stosunku do wcześniejszej implementacji. Jeśli
wynik netto okaże się łatwiejszy do dostosowania – zastąpienie wielu
skomplikowanych ustawień jednym, jak sugerowałem, może być
właściwym kierunkiem – średnio powinno być lepiej. Czasami
konieczne jest porzucenie starego podejścia, aby uzyskać
takie, które jest lepsze.
Ale tak bardzo martwimy się
o łamaniem zachowań, na których polegają użytkownicy. Duży nacisk kładzie się na
kompatybilność wsteczną i dodawanie rzeczy tylko w sposób,
nie usuwający starego podejścia w rozwoju PostgreSQL. Czasami jednak
nie ma wyboru:musisz dążyć do nowego podejścia. W przypadkach,
gdzie zarówno stare, jak i nowe zachowanie są całkowicie uzasadnione,
dotarcie nawet do wyraźnej opinii większości jest trudne. Często tak jest
przy projektowaniu interfejsu użytkownika. Chociaż możesz to porównać za pomocą
właściwych narzędzi i profesjonalistów, ale rzadko jest to wykonywane w społeczności
open-source. Uzyskanie konsensusu społeczności z tej mieszanki
bardzo osobistych opinii jest trudne.
Ponownie przypomniano mi, jak nie
rozpatrywać opinii użytkowników jako programista, otrzymując dzisiaj kilka aktualizacji
o długiej irytującej regresji w tym, jak gnome- terminal, mój nominalny
preferowany terminal wiersza poleceń, obsługuje wprowadzanie z klawiatury. Problem
po raz pierwszy pojawił się w zgłoszeniu błędu prawie dokładnie dwa lata temu, na
ubuntu trackerze, tylko po to, aby przejść do podstawowego
źródła regresji:celowa zmiana dokonana przez jednego z GNOME
programistów, aby wyeliminować zachowania, które uznali za niewłaściwe. Otwarto zgłoszenie z prośbą o naprawę, ale nigdy nie było to obraźliwe dla wszystkich zaangażowanych.
Byłem na tyle aktywny w historii tych ostatnich
, że nie muszę tutaj powtarzać mojej argumentacji.
W zasadzie wszystko, czego chciałem, to opcja konfiguracji pola wyboru, aby
umożliwić powrót do starego zachowania. Zacząłem nawet
nad tym pracować, zagłębiając się w kod, by zasugerować obejścia,
tylko po to, by zdać sobie sprawę, że nie ma możliwości, aby to się kiedykolwiek scaliło. Moje
sugestie koncentrowały się na znalezieniu wspólnego języka, który
zadowoliłby wszystkich. Jasne jest jednak, że programiści po prostu nie przejmują się tym
. Robią to tak, jak lubią, a
wszyscy inni nie mają znaczenia. To, że powiedziano mi, że zajmie „kilkaset” skarg, zanim zostanie to uznane za ważne,
przeraża mnie, biorąc pod uwagę, że użycie klawisza kontrolnego w terminalu
nie jest najpopularniejszą rzeczą . Było dziesiątki zgłoszeń,
każda otrzymana skarga była ujednolicona w preferowanej
rozwiązaniu, a jedyną osobą, która się nie zgodziła, był jeden z ich
programistów.
Otrzymujemy pewne skargi od ludzi, że
społeczność PostgreSQL jest wypełniona programistami,
którzy wolą
technicznie czyste rozwiązania nad dawaniem użytkownikom tego, czego chcą.
Do pewnego stopnia to prawda, na przykład ciągły opór przed
dodawaniem tabeli pokazowych jako alternatywny sposób znajdowania
bazy danych w Twojej bazie danych. Ale cała ta dyskusja dotyczyła
tematów, w których dyskusja daje bardzo mieszane opinie; wiele osób
ma zdecydowane opinie po obu stronach. Jeśli każdy użytkownik zgadza się z
projektem, tak jak w przypadku tego problemu z terminalem gnomów, odrzucenie
takich opinii jako wciąż niesłusznych jest szczytem arogancji programistów.
Jeden z ciekawszych przykładów
tego rodzaju rzeczy polega na tym, że twórcy oprogramowania Pidgin IM
zmieniają sposób działania rozmiaru tekstu w oknie czatu w ich program.
Użytkownicy zbuntowali się. Jest dobry przykład starego i nowego zachowania z pewną
analizą w CodingHorror.
Wszystkich interesowało sposób, w jaki
programiści ignorowali ich opinie. W ich odczuciu
odzew społeczności był nieistotny dla deweloperów,
ponieważ czuli, że ich projekt jest lepszy niż stary, niezależnie od tego, co pomyśleli
użytkownicy. Ktoś napisał wtyczkę, aby przywrócić stare
zachowanie. A potem nastąpił oficjalny rozłam. Misja
oświadczenie
powstałego widelca, pierwotnie zwanego „Fun Pidgin”, a teraz
nazwanego „Carrier Instant Messenger”, jest ciekawą lekturą, w jaki sposób
czują się skoncentrowani na użytkowniku rozwój powinien działać.
Dyskusja Jeffa Atwooda CodingHorror
na ten temat zasugerowała cztery sposoby, w jakie taki widelec może się zmienić. Pominął
bardzo ważną kwestię:możliwość, że dzieląc wysiłki
społeczeństwa, oba widelce umrą, a żaden z nich nie będzie miał wystarczających
zasobów, by konkurować z alternatywami. Chociaż Pidgin nie
jeszcze nie umarł – jest w pewnej odległości od „opuszczenia kurtyny i dołączenia
do krwawiącego chóru niewidzialnego” – są mniej ważni niż kiedyś, i ta cała klęska nie pomogła ich sprawie. Począwszy od
Ubuntu 9.10, Canonical zastąpił Pidgin jako głównego klienta IM
dostarczanego z tą bardzo popularną dystrybucją Linuksa. Zamiast tego zamiast tego umieścili
GNOME Empathy. Czy tak by się nadal działo, gdyby
społeczność Pidgin nie uległa podziałowi i nie stała się kojarzona z tak złym
PR? Możliwe, ale to z pewnością nie pomogło ich sprawie.
Ten sam rodzaj ignorujących użytkowników
decyzje są podejmowane w odniesieniu do popularnego projektu GNOME, takiego jak
gnome-terminal, jest zabawne (raczej się śmieję niż płakać) zmierzam do
podobnej sytuacji. Dwa miesiące temu ogłoszono, że Ubuntu
odchodzi znacznie od używania pełnego stosu oprogramowania GNOME w następnym wydaniu. Zwróć uwagę na to, co się tam wydarzyło.
Mark Shuttleworth mówi, że zatrudnili profesjonalnych projektantów interfejsu użytkownika,
ich do pracy, aby dowiedzieć się, co będzie lepiej działać dla użytkowników komputerów stacjonarnych
doświadczenie, a następnie przedstawili wyniki Społeczność GNOME.
Zamiast zaakceptować tę niezwykle cenną pracę i podziękować firmie Canonical
za przeprowadzenie tych badań, odrzucili wystarczająco dużo fundamentalnych idei,
które nie były możliwe. Ubuntu rozwidla się teraz w dużym
do projektu Unity, jako jedyna ścieżka, która pozostała do „robienia tego, czego chcą
nasi użytkownicy”. Biorąc pod uwagę moją własną interakcję, jaką miałem z programistami GNOME
w ciągu lat, odkąd wpadłem na tę jedną irytację,
reakcja, którą Mark nie zaskoczyła mnie ani trochę.
Wciąż jesteśmy w punkcie, w którym nie jest
jasne, jak zakończy się ten podział Unity. Spodziewam się
że cała ta sprawa również doprowadzi do podwójnej
sytuacji. Będzie wiele zduplikowanych programów, które
samodzielnie nie dają niczego użytecznego na początku. Początkowe
wydania będą podlegały strasznej kontroli jakości – to wszystko zajmie
wieczność. A dzieląc bazę programistów, jest
całkiem możliwe, że żadna z grup nie będzie miała wystarczająco dużo ludzi, by kiedykolwiek skończyć,
wykonać dobrą robotę, pozostawiając nas wszystkich z wieloma słabymi opcjami pulpitu Linuxa (ponownie) zamiast jednego zunifikowanego,
wszyscy są gotowi do poprawy. Miałem nadzieję, że sposób, w jaki Nokia ulepszyła
licencję na Qt, może w końcu zastanowić się, jak wyeliminować
posiadanie zarówno Qt, jak i GNOME. To, że zamiast tego Linux wciąż rozwija się
projekt na szczycie miksu i nazywanie go Jednością wszystkich rzeczy, jest
okropnym żartem.
Ale mówiłem o bazach danych... Jedną
ciekawą rzeczą dotyczącą PostgreSQL jest liczba wygenerowanych forków. Hojna licencja BSD doprowadziła do powstania wielu
komercyjnych forków o zamkniętym kodzie źródłowym; Kiedyś pracowałem w firmie, która zrobiła
jeden. Netezza była pierwszą z nich, która ostatecznie wkroczyła w poważną
produkcję komercyjną. A baza danych Greenplum została niedawno
kupiona przez firmę EMC i jest to bardzo udany produkt. To, co się
nie wydarzyło, to fakt, że którykolwiek z forków open-source stał się opłacalnym zamiennikiem
dla głównej dystrybucji. O ile nie masz tak dużych
zasobów, jakie duża firma może wnieść do inżynierii,
łatwiej jest sprawić, by społeczność zaakceptowała Twoje pomysły, niż spróbować
samego wdrożenia z nich. Prosta społeczność
PostgreSQL wciąż jest właściwym wyborem.
Społeczność PostgreSQL często się kłóci
i jest wrogo nastawiona do wielu rzeczy, o które proszą ludzie; mamy nawet
listę, której nie chcemy robić.
Są to w większości rzeczy, których po prostu nie da się
zbudować bez wad, które nie zawsze są oczywiste dla
osób, które o nie proszą. Jeśli użytkownik uzasadni, dlaczego zmiana
powodowałaby lepszy interfejs użytkownika do czegoś w bazie danych i
nie ma żadnych technicznych zastrzeżeń co do tego, dlaczego spowoduje to problem,
ta zmiana jest brana pod uwagę. To, czego nigdy nie widziałem w społeczności, to
żadnego z programistów sprzeciwiających się jednomyślnej, jednoznacznej preferencji
użytkownika – tam, gdzie ta opcja może być dostępna bez
wad – po prostu dlatego, że nie lubię tego w ten sposób. Jeśli jesteś
twórcą projektu open source wędrującego do miejsca, w którym pycha
tak bardzo przebiła pokorę, nie zdziw się, jeśli Twoi użytkownicy będą
na tyle zdenerwowani, by się rozwidlić. A pewnego dnia możesz odkryć, że
widły lub ponowne implementacje, które zwracają uwagę na to, czego naprawdę chcą ludzie
, wyprą Cię.
