Seiring PostgreSQL Elephant melanjutkan
perjalanannya menuju rilis lain, saya telah berpikir sedikit
tentang peran yang seharusnya dimiliki pengguna perangkat lunak antarmuka penggunanya
desain. Hari ini saya mengusulkan sesuatu yang membuat parameter basis data
dulu harus dikhawatirkan oleh orang-orang, dan itu sama sekali tidak jelas
cara menyetel, dan menjadikan nilainya sebagian besar otomatis. Itu cukup
perubahan ke depan yang jelas; pengguna terganggu, perilaku default yang baik
terbentuk, dan perilaku default tersebut disarankan sebagai tambalan. Jika diterapkan, saya akan terkejut menemukan orang yang menganggapnya sebagai
keputusan yang buruk.
Ada diskusi serupa tentang
cara mengerjakan ulang antarmuka pengguna di sekitar pos pemeriksaan basis data. Benar
sekarang, kecepatan penulisan data ke disk oleh pos pemeriksaan
dipengaruhi oleh tiga nilai yang dapat ditentukan pengguna. Interaksi
antara ini didokumentasikan dengan cukup baik, meskipun dengan cara yang
mencerminkan kerumitannya, dan beberapa pengguna menemukan perilaku yang diberikannya
berperforma baik. Sangat mungkin bahwa untuk membuat segalanya
lebih baik bagi pengguna biasa, akan ada kemunduran
kinerja dalam beberapa kasus relatif terhadap kode saat ini. Menggunakan
implementasi berbeda yang mengubah skala efektif
parameter akan menghasilkan perubahan pengaturan waktu yang halus, dan semuanya tidak
harus menjadi positif. Dalam situasi ini, yang terbaik yang dapat kita lakukan
sebagai komunitas pengembang adalah mengumpulkan data benchmark yang cukup untuk melakukan
panggilan tersebut. Mungkin meningkatkan skenario terburuk
sedikit mengurangi hal-hal yang terkait dengan implementasi sebelumnya. Jika
hasil bersihnya ternyata lebih mudah untuk disesuaikan–mengganti beberapa
pengaturan rumit dengan satu pengaturan, seperti yang saya sarankan mungkin
arah yang benar di sini–rata-rata itu akan lebih baik. Terkadang
terkadang kita perlu melepaskan pendekatan lama untuk mendapatkan
yang lebih baik.
Tapi ini adalah seberapa besar kekhawatiran kami
tentang melanggar perilaku yang diandalkan pengguna. Ada fokus besar pada
kompatibilitas mundur dan hanya menambahkan hal-hal dengan cara yang tidak
menghapus pendekatan lama dalam pengembangan PostgreSQL. Terkadang
tidak ada pilihan:Anda harus mendorong pendekatan baru. Dalam kasus
di mana perilaku lama dan baru sepenuhnya sah, sulit
mencapai pendapat mayoritas yang jelas sekalipun. Itu sering terjadi
dalam desain antarmuka pengguna. Meskipun Anda dapat membandingkannya dengan
alat dan profesional yang tepat, namun hal itu jarang dilakukan di
komunitas sumber terbuka. Sulit untuk mendapatkan konsensus komunitas dari campuran
opini yang sangat pribadi.
Saya diingatkan lagi tentang bagaimana tidak
menangani umpan balik pengguna sebagai pengembang dengan mendapatkan beberapa pembaruan hari ini
tentang regresi lama yang mengganggu dalam cara gnome- terminal, terminal baris perintah pilihan
nominal saya, menangani input keyboard. Masalahnya
pertama kali menjadi laporan bug hampir tepat dua tahun yang lalu, pada pelacak
Ubuntu, hanya untuk bermigrasi ke
sumber regresi yang mendasarinya:perubahan yang disengaja oleh salah satu GNOME
pengembang untuk menghilangkan perilaku yang mereka anggap tidak pantas. Ada tiket terbuka yang meminta perbaikan, tetapi tidak pernah lebih dari menghina semua yang terlibat.
Saya sudah cukup aktif dalam
sejarah tiket terakhir sehingga saya tidak perlu mengulangi argumen saya di sini.
Pada dasarnya, yang saya inginkan hanyalah opsi konfigurasi kotak centang untuk
memungkinkan kembali ke perilaku lama. Saya bahkan mulai bekerja
untuk melakukan hal itu, menggali kode untuk menyarankan solusi,
hanya untuk menyadari bahwa tidak mungkin ini bisa digabungkan. Saran
saya difokuskan untuk mencoba menemukan kesamaan yang
menyenangkan semua orang. Sangat jelas bahwa pengembang tidak peduli
tentang itu. Mereka melakukan hal yang mereka suka, dan
orang lain tidak peduli. Bahwa saya diberi tahu bahwa diperlukan “
beberapa ratus” keluhan sebelum hal ini dianggap penting
mengejutkan pikiran saya, mengingat bahwa penggunaan tombol kontrol di terminal
bukanlah hal yang paling populer . Ada puluhan laporan,
setiap keluhan yang diterima disatukan dalam
resolusi pilihan, dan satu-satunya orang yang tidak setuju adalah salah satu
pengembangnya.
Kami mendapatkan beberapa keluhan dari orang-orang bahwa
komunitas PostgreSQL dipenuhi dengan pengembang yang lebih memilih
solusi murni teknis daripada sekadar memberikan apa yang diinginkan pengguna.
Itu benar sampai batas tertentu, seperti penolakan yang berkelanjutan untuk
menambahkan tampilkan tabel sebagai cara alternatif untuk menemukan
database di database Anda. Tapi semua diskusi itu
topik di mana diskusi memberikan pendapat yang sangat beragam; banyak orang
memiliki pendapat yang kuat di kedua sisi. Jika setiap pengguna setuju tentang
desain, seperti halnya masalah terminal gnome ini, menolak
pendapat tersebut karena masih belum benar adalah puncak kesombongan
pengembang.
Salah satu contoh yang lebih menarik dari
hal semacam ini melibatkan pengembang perangkat lunak Pidgin IM
mengubah cara kerja ukuran teks jendela obrolan di program.
Pengguna memberontak. Ada contoh bagus dari perilaku lama dan baru dengan beberapa
analisis di CodingHorror.
Semua orang terkesima dengan cara
pengembang mengabaikan masukan mereka. Persepsi mereka adalah
bahwa umpan balik komunitas tidak relevan dengan pengembang, karena
mereka merasa desain mereka lebih baik daripada yang lama terlepas dari apa
pendapat pengguna. Seseorang menulis plugin untuk memulihkan
perilaku lama. Dan kemudian ada perpisahan resmi. Misi
pernyataan
dari fork yang dihasilkan, awalnya disebut "Fun Pidgin" dan sekarang
disebut "Carrier Instant Messenger", adalah bacaan yang menarik tentang bagaimana
mereka merasa berpusat pada pengguna pengembangan harus berhasil.
Diskusi CodingHorror Jeff Atwood
tentang ini menyarankan empat cara untuk menghasilkan garpu seperti itu. Dia meninggalkan
satu hal yang sangat penting:kemungkinan bahwa dengan memecah
upaya komunitas, kedua garpu akan mati, tanpa keduanya memiliki
sumber daya yang cukup untuk bersaing dengan alternatif lain. Sementara Pidgin belum
mati–itu agak jauh dari “lari ke bawah tirai dan bergabung
paduan suara berdarah yang tak terlihat”–mereka kurang penting dibandingkan
dulu, dan seluruh bencana ini tidak membantu tujuan mereka. Sejak
Ubuntu 9.10, Canonical menggantikan Pidgin sebagai klien IM utama
yang dikirimkan dengan distribusi Linux yang sangat populer itu. Sebaliknya mereka menempatkan
GNOME Empathy sebagai gantinya. Apakah hal itu masih akan terjadi seandainya komunitas
Pidgin tidak terpecah dan dikaitkan dengan
PR yang buruk seperti itu? Mungkin, tapi itu tidak membantu kasus mereka.
Bahwa jenis pengguna yang bodoh
keputusan yang sama sedang dibuat sehubungan dengan proyek GNOME populer seperti
gnome-terminal adalah hal yang lucu (saya agak tertawa daripada menangis) menuju
situasi yang serupa. Dua bulan lalu diumumkan bahwa Ubuntu
beralih secara signifikan dari penggunaan tumpukan perangkat lunak GNOME lengkap dalam rilis berikutnya. Perhatikan baik-baik apa yang terjadi di sana.
Mark Shuttleworth mengatakan bahwa mereka menyewa desainer UI profesional, menempatkan
mereka untuk bekerja mencari tahu akan bekerja lebih baik untuk
pengalaman pengguna desktop, lalu mempresentasikan hasilnya ke Komunitas GNOME.
Daripada menerima pekerjaan yang sangat berharga ini dan berterima kasih kepada Canonical
untuk melakukan penelitian itu, mereka menolak cukup banyak ide mendasar yang
tidak ada jalan tengah yang mungkin. Ubuntu sekarang bercabang dalam
besar menuju proyek Unity, sebagai satu-satunya jalan yang tersisa untuk "melakukan apa yang
diinginkan pengguna kami". Berdasarkan interaksi saya sendiri dengan para
pengembang GNOME selama bertahun-tahun sejak saya mengalami gangguan ini,
reaksi yang didapat Mark tidak mengejutkan saya sedikit pun.
Kami masih berada di titik di mana
jelas bagaimana akhirnya perpecahan Unity ini akan berakhir. Apa yang saya harapkan adalah
bahwa semua ini akan mengarah pada semacam situasi
kegagalan ganda juga. Akan ada banyak pengembangan duplikat yang
tidak dengan sendirinya menghasilkan sesuatu yang berguna pada awalnya. Rilis
awal akan memiliki kontrol kualitas yang buruk–hal ini membutuhkan
selamanya untuk menjadi benar. Dan dengan memisahkan basis pengembang, itu
sangat mungkin tidak ada grup yang akan memiliki cukup banyak orang yang tersisa untuk
melakukan pekerjaan dengan baik, meninggalkan kita semua dengan beberapa pilihan desktop Linux yang buruk
(lagi) alih-alih satu kesatuan, semua orang berbaris untuk
meningkatkan. Saya berharap sekarang bahwa cara Nokia telah meningkatkan
lisensi ke Qt akhirnya dapat membuat mempertimbangkan cara menghilangkan
memiliki keduanya Qt+GNOME. Alih-alih Linux mendapatkan proyek
pengembangan di atas campuran, dan menamakannya Unity of all things, adalah
lelucon yang mengerikan.
Tapi saya berbicara tentang database…salah satu
hal yang menarik tentang PostgreSQL adalah berapa banyak fork yang
dihasilkan. Lisensi BSD yang murah hati telah menghasilkan banyak
fork komersial sumber tertutup; Saya dulu bekerja di perusahaan yang membuat
satu. Netezza adalah yang pertama yang akhirnya menjadi produksi komersial
yang serius. Dan Database Greenplum baru-baru ini
dibeli oleh EMC, ini adalah produk yang sangat sukses. Apa yang belum
terjadi adalah garpu open-source mana pun yang menjadi pengganti yang layak
untuk distribusi utama. Kecuali jika Anda memiliki
sumber daya yang besar yang dapat digunakan oleh perusahaan besar dalam bidang rekayasa,
lebih mudah membuat komunitas menerima ide Anda daripada mencoba
dan melakukan implementasi independen dari mereka. Komunitas biasa
PostgreSQL terus menjadi pilihan yang tepat.
Komunitas PostgreSQL banyak berdebat,
dan menentang banyak hal yang diminta orang; kami bahkan memiliki
daftar yang Tidak Kami Inginkan.
Ini adalah sebagian besar hal yang secara teknis
layak untuk dibangun tanpa kerugian yang tidak selalu jelas bagi
mereka yang memintanya. Jika pengguna membuat alasan mengapa perubahan akan
membuat antarmuka pengguna yang lebih baik untuk sesuatu dalam database, dan
tidak ada keberatan teknis mengapa hal itu akan menyebabkan masalah,
perubahan itu dianggap. Apa yang belum pernah saya lihat di komunitas adalah
pengembang mana pun yang berhadapan dengan preferensi pengguna yang bulat dan tidak ambigu
di mana opsi itu dapat tersedia tanpa
kerugian—hanya karena mereka tidak suka seperti itu. Jika Anda adalah
pengembang proyek open source yang berkeliaran di mana keangkuhan telah
mengalahkan kerendahan hati, jangan heran jika pengguna Anda
cukup marah untuk membayar. Dan suatu hari nanti, Anda mungkin menemukan bahwa
garpu atau implementasi ulang yang memperhatikan apa yang benar-benar diinginkan orang
akan menggantikan Anda.
