Penulis dan pengelola beberapa proyek sumber terbuka , Andrew Gallant sedang mencoba untuk meredakan ketegangan yang baru-baru ini terakumulasi dalam komunitas sumber terbuka. Teriakan jiwa “Bagaimana rasanya menjadi pengelola perangkat lunak gratis” , “opensource tidak berterima kasih” dan keluhan lain dari pengelola memunculkan diskusi tentang agresivitas, kekasaran, tidak tahu berterima kasih, kelelahan emosional, dan kerasnya dukungan tanpa pamrih untuk proyek. Posting ini diterbitkan pada 19 Januari 2020, - kira-kira. trans.

Saya ingin beralih dari tradisi berbicara hampir secara ketat pada topik teknis - dan saya akan membagikan beberapa hubungan pribadi saya dengan perangkat lunak bebas dan sumber terbuka (FOSS). Meskipun semua orang berbeda, saya berharap bahwa pertukaran pandangan akan membantu membangun saling pengertian, empati dan kepercayaan pada komunitas kita.

Harap jangan menganggap posting ini sebagai reaksi langsung terhadap tindakan pengelola lainnya. Ini bukan resep untuk perilaku ideal, tetapi refleksi pribadi dengan harapan bahwa mereka akan menjadi kesempatan bagi orang lain untuk merefleksikan hubungan mereka sendiri dengan open source. Tidak ada satu cara yang tepat untuk menjadi pemelihara yang baik. Masing-masing memiliki cara sendiri untuk menangani hal ini.

Ini sama sekali bukan panggilan untuk bantuan. Ini tentang pengertian. Saya tidak menyerukan perubahan dalam ekonomi FOSS atau mendiskusikan kesehatan mental saya. Saya tidak berbicara tentang menarik pengelola tambahan. Saya hanya ingin membagikan cerita saya dan mencoba meningkatkan empati di komunitas FOSS.

Target pengguna : semua orang yang terlibat dalam sumber terbuka.

Isi

• Ceritanya
  
• Emosi terkutuk
  
• Negatif Purulent
  
• Bekerja melalui kekuatan
  
• Kekasaran
  
• Otoritas
  
• Lebih lanjut tentang kompetensi
  
• Kepercayaan
  
• Lebih baik dari yang terlihat
  
• Kesimpulan

Ceritanya

Proyek open source pertama saya muncul hampir 16 tahun yang lalu - papan buletin dalam PHP. Pada saat itu, hampir semua orang menciptakan hal-hal seperti itu, dan itulah bagaimana saya belajar memprogram. Proyek awalnya dimulai sebagai sistem sekolah untuk diskusi (pada waktu itu, sekolah tidak bekerja sama sekali dengan Internet, kecuali untuk hosting situs jelek). Kemudian saya pertama kali menemui kesulitan estimasi. Proyek berjalan selama lebih dari satu semester, dan secara bertahap pindah ke hobi yang melampaui ruang lingkup proyek sekolah.

Secara pribadi, saya selalu suka memprogram hanya untuk bersenang-senang. Saya suka semua tahap: pertama menyelidiki topik, menentukan kelayakan, mengembangkan rencana awal, coding terobsesi dan bahkan memikirkannya, saya suka setiap menit dari semuanya.

Untuk menikmati pemrograman, saya tidak harus membagikan hasil pekerjaan saya. Namun, open source dengan cepat menjadi bagian alami dari proses pengembangan saya, yang bertahan dalam satu atau lain bentuk selama 16 tahun. Sebenarnya, yang paling saya sukai adalah jika kode tersebut memungkinkan seseorang untuk memecahkan masalah mereka dengan lebih efisien. Semakin bagus kode saya, semakin menyenangkan. Sebagai aturan, saya tidak peduli siapa di sisi lain hanyalah seorang hacker yang memuaskan rasa ingin tahunya, atau perusahaan raksasa melakukan sesuatu yang menarik pada skala luar biasa.

Kisah FOSS saya berlanjut dengan beberapa rilis papan buletin saya dan wtcSQLite , klon sederhana dari phpMyAdmin , tetapi untuk SQLite.

Ketika saya beralih dari Windows ke Linux sekitar tahun 2009, saya meluncurkan lebih banyak lagi proyek, tetapi dengan Python dan X11. Diantaranya adalah PyTyle untuk memperbaiki frame di multi-window manager dan openbox-multihead , implementasi saya dari dukungan multi-monitor di Openbox . Proyek-proyek ini, bersama dengan beberapa penelitian oleh Go, menuntun saya untuk membuat window manager on Go yang masih saya gunakan.

Seiring berjalannya waktu, dan sekitar enam tahun yang lalu, saya mulai menulis di Rust. Quickcheck menjadi perpustakaan pertama, tetapi sejumlah besar lainnya mengikuti: regex , docopt.rs , rust-csv , fst , termcolor , walkdir dan banyak lainnya selama enam tahun ke depan.

Meskipun sebagian besar proyek Rust saya adalah perpustakaan, ada alat baris perintah seperti xsv dan ripgrep .

Banyak proyek lama saya sekarang benar-benar mati atau didukung oleh yang lain, tetapi saya terus mendukung sebagian besar proyek Rust. Atau mereka digantikan oleh rak berkualitas lebih baik dari orang lain (misalnya, bagaimana saluran balok silang menggantikan chan ).

Hari ini, saya masih suka banyak program, tapi saya juga menghabiskan banyak waktu untuk review kode, debugging masalah dengan pengguna akhir, menjawab permintaan fitur, dan hal-hal semacam itu. Ini selalu berarti interaksi, pekerjaan dan komunikasi dengan orang lain.

Emosi terkutuk

Di masa muda saya, saya bangga dengan "logika" dan "pengambilan keputusan yang adil". Seperti dalam setiap penipuan diri yang baik, ada sebutir kebenaran di sini. Tetapi pada dasarnya, saya pribadi adalah makhluk yang sangat emosional.

Emosi mengalir dalam dan dapat menjadi sumber yang sangat berguna untuk motivasi internal. Misalnya, untuk beberapa waktu setelah rilis ripgrep, saya benar-benar benci menyentuh kode yang bertanggung jawab untuk menampilkan hasil pencarian . Dia bingung, buggy dan sulit berubah. Untuk sepenuhnya menulis ulang kode adalah keputusan yang sepenuhnya logis yang dapat dibuat atas dasar teknis murni, tetapi saya termotivasi untuk melakukan ini karena rasa jijik. Saya hanya tidak menyukai perasaan saya . Emosi membantu saya memperbaiki situasi, membantu diri saya sendiri. Sebagai contoh, sekarang hasilnya terisolasi di perpustakaan terpisah dengan tes menyeluruh, dan saya merasa jauh lebih baik setiap kali saya perlu masuk ke kode ini dan melakukan sesuatu. Ini masih bukan karya terbaik saya, tetapi sudah merupakan perbaikan besar - setidaknya dari sudut pandang emosional - dibandingkan dengan keadaan sebelumnya.

Emosi adalah hal yang menyenangkan karena dapat membawa Anda ke kondisi yang benar-benar menakjubkan. Katakanlah, dalam contoh sebelumnya, apakah beberapa alasan teknis cukup untuk menulis ulang kode keluaran? Di sini Anda perlu membuat keputusan. Tetapi jika tidak ada motivasi, mungkin saya tidak akan pernah berani untuk menolak. Dan tanpa refactoring, kemungkinan besar basis kode akan mandek, dan program akan mulai gagal, atau kombinasi keduanya. Jika emosi memberi motivasi, maka refactoring akan membuka masa depan yang jauh lebih baik, di mana Anda dapat mengimplementasikan lebih banyak fungsi dalam perangkat lunak tanpa mengurangi keandalan.

Emosi memiliki kelemahan. Siapa pun yang merilis dan mendukung beberapa perangkat lunak yang cukup populer pasti akan menghubungi orang lain. Ternyata orang lain dapat memiliki efek yang menakjubkan pada keadaan emosional Anda. Gerakan atau komentar positif dapat mencerahkan hari Anda. Perasaan yang sama: ya, mengunggah kode saya sangat penting sehingga membantu orang ini . Tetapi, seperti yang dipastikan oleh pengelola mana pun, komentar positif hampir selalu dibayangi oleh komentar negatif.

Komentar negatif tidak terlalu buruk. Ini adalah konsekuensi alami dari pembagian kode ketika Anda mengundang pengguna lain untuk menggunakannya dan melaporkan masalah . Ketika pesan kesalahan muncul, Anda merasa bahwa Anda telah gagal pengguna ini. Ketika Anda menulis kode, Anda yakin telah mengujinya dengan cukup baik, tetapi itu masih salah . Apakah laporan bug tidak akan pernah berhenti? Berapa lama waktu yang dihabiskan pengguna ini karena bug? Berapa lama saya bisa memperbaiki semuanya? Bahkan tidak: berapa banyak waktu yang diperlukan untuk beralih ke mode di mana setidaknya ada harapan untuk memperbaikinya?

Pikiran-pikiran ini dapat menyebabkan emosi yang mulai menggerogoti Anda. Dan ini adalah skenario yang paling mungkin untuk komentar negatif.

Negatif Purulent

Saya segera belajar mengatasi emosi negatif dari laporan bug. Bahkan, pesan kesalahan yang mudah dibaca segera menjadi menyenangkan karena biasanya sangat jarang. Sebagian besar bug tidak direproduksi sama sekali, bahkan jika Anda menyediakan templat untuk masalah dengan permintaan eksplisit untuk semua parameter (templat masalah). Pengirim mungkin menginginkan yang terbaik, tetapi informasinya tidak cukup untuk mereproduksi kesalahan. Dan keributan mulai bolak-balik dalam upaya untuk mengisolasi bug.

Bagi saya pribadi, ini adalah area yang paling menyakitkan. Emosi di atas angin karena saya hanya dapat memikirkan satu hal: mengapa orang ini tidak meluangkan waktu untuk membaca dan mengisi templat untuk masalahnya ? Atau jika bug terjadi karena kesalahan pengguna yang belum membaca dokumentasi, saya hanya bisa berpikir: Saya meluangkan waktu untuk memberikan beberapa perangkat lunak kepada pengguna ini, dan dia bahkan tidak bisa membaca README sebelum mengirimkan laporan bug?

Ini gila. Tentu saja, emosi tidak selalu rasional. Dokumentasinya mungkin bisa lebih jelas. Atau pengguna mungkin tidak memperhatikan item ini. Mungkin dia tidak memiliki pengalaman dalam menjalankan proyek-proyek FOSS atau mengirimkan laporan bug dan, mungkin, dia tidak tahu bagaimana membantu dalam reproduksi bug yang sederhana. Semua ini adalah asumsi yang cukup masuk akal, dan itulah sebabnya saya melakukan yang terbaik agar emosi tidak menang. Meskipun empati dengan orang di ujung kabel juga penting.

Misalkan saya tidak mengatakan "Saya mengundang Anda untuk menggunakan kode saya" di mana saja, tetapi saya melakukan banyak hal hanya karena niat saya adalah agar orang lain menggunakan kode saya. Saya menulis dokumentasi yang lebih terperinci, contoh penggunaan. Saya menyiapkan pengujian integrasi berkelanjutan. Dibuat README untuk pemula. Tautan ke proyek ditunjukkan pada banyak halaman saya. Jika orang menerima undangan ini untuk menggunakan kode saya atau menganggap pelacak bug terbuka sebagai undangan untuk melaporkan kesalahan, maka saya tidak boleh menghukum mereka ketika mereka benar-benar mengirim pesan ini. Penulis laporan bug yang buruk mungkin berpikir bahwa ia melakukan segala yang mungkin. Dan sementara mereka bertindak karena perbuatan baik, saya benar-benar mencoba menjawab hal yang sama.

Ini menggarisbawahi asimetri antara pengguna dan pengelola. Penulis banyak laporan bug dapat bertukar satu atau dua pesan dengan saya. Bagi mereka, satu laporan bug yang ditulis dengan buruk tidak terlalu penting. Tetapi saya berada di sisi yang salah, karena adegan ini saya mainkan berulang kali di semua proyek saya. Sepanjang waktu. Hampir setiap hari. Mempertahankan empati dalam situasi seperti itu sangat sulit, terutama jika Anda mengalami hari yang buruk. Apa yang terkadang terjadi.

Terkadang ketidaksabaran saya dimanifestasikan dalam jawaban yang terlalu singkat. Saya mencoba yang terbaik untuk menjadi lebih baik dalam hal ini. Proses peningkatan diri belum selesai.

Bekerja melalui kekuatan

Jika Anda adalah pengelola proyek populer atau beberapa repositori reguler, Anda mendapatkan aliran hampir semua laporan bug dan permintaan kumpulan. Mereka datang setiap hari. Mengikuti dia hampir mustahil. Ukuran cache otak saya luar biasa kecil, jadi saya tidak pandai mengalihkan konteks antar proyek. Sebagai hasil dari fenomena ini, saya segera menyusun laporan bug dan mengumpulkan permintaan untuk proyek-proyek yang baru-baru ini saya kerjakan. Proyek-proyek ini mungkin lebih mudah diakses atau ditangani dengan lebih baik di halaman terakhir cache otak.

Namun dalam proyek lain, daftar masalah mulai menumpuk. Setiap hari Anda melihat masalah baru dan berkata pada diri sendiri: "Ya, saya benar-benar akan melihat ini segera setelah saya kembali dari pekerjaan." Tetapi sesuatu yang baru akan datang. Akibatnya, motivasi untuk beralih konteks muncul hanya ketika pengguna menelepon Anda setiap bulan selama empat bulan - mungkin permintaan kumpulannya sangat penting.

Maaf, ada sedikit sarkasme di kalimat terakhir, tetapi pada saat yang sama itu benar. Asimetri pengguna dan pengelola kembali beraksi, tetapi saya benar-benar berusaha membersihkan kumpulan antrian permintaan dan mengembangkan proyek. Saya ingin berkontribusi pengguna ini, tidak hanya untuk terus menggunakan kode saya, tetapi juga untuk membuatnya senang . Dalam banyak kasus, hanya satu jam sudah cukup untuk menyelesaikan permintaan kumpulan dan semua masalah yang memerlukan tindakan.

Tapi saya menghabiskan empat bulan hanya menonton dengan sedih bagaimana masalah mereda pada mereka yang masuk tanpa solusi.

Untuk fenomena ini, saya menerapkan metode yang saya gunakan dengan sangat efektif dalam kehidupan pribadi saya: untuk menetapkan batasan. Dengan sopan, tetapi dengan tegas menetapkan batas adalah salah satu hack kehidupan ajaib yang menghasilkan dividen segera setelah Anda mempelajarinya. Jika Anda tidak tahu bagaimana melakukan ini, maka saya hampir tidak bisa menjelaskan. Namun, menetapkan batas memungkinkan Anda untuk fokus pada apa yang penting bagi Anda , bukan orang lain .

Jelas, seseorang harus berjuang untuk keseimbangan. Pembentukan batas tidak berarti bahwa Anda hanya dapat fokus pada urusan Anda sendiri. Tetapi kemampuan untuk memasang tembok ini dan berkata: "Tidak, saya tidak melakukan X, tapi saya dengan senang hati akan melakukannya Y" - itu benar-benar bekerja keajaiban bagi saya. Rahasia saya adalah membuat argumen yang tidak bisa diperdebatkan orang lain berdasarkan pengalaman dan keinginan saya sendiri.

Apa hubungannya ini dengan open source? Bagi saya pribadi, kuncinya adalah menetapkan batas antara saya - dan semua masalah yatim ini dengan permintaan kumpulan. Anda perlu entah bagaimana mengesankan diri sendiri: “Saya secara sukarela menghabiskan waktu saya, dan itu normal bahwa saya tidak merespons tepat waktu. Saya yakin kebanyakan orang akan memahami ini dan masuk akal. "

Ini juga muncul ketika mendiskusikan permintaan untuk fitur baru. Terkadang permintaan tersebut masuk akal untuk proyek Anda, tetapi fungsi ini menyiratkan beban besar dukungan. Saya belajar menetapkan batasan: Anda bisa mengatakan "Tidak" pada fungsi hanya dengan alasan bahwa Anda tidak ingin menghabiskan waktu ekstra untuk mendukung. Seperti yang telah terjadi lebih dari sekali, maka Anda dapat berubah pikiran! Misalnya, jika kode telah ditingkatkan, menjadi lebih mudah diakses untuk pemeliharaan - Anda mungkin melihat dalam diri Anda lebih banyak keinginan untuk memperkenalkan fungsionalitas baru. Tetapi jika tidak, maka saya melakukan yang terbaik untuk meraba-raba batas-batas saya dan menolak untuk memuat diri saya dengan pekerjaan ekstra yang tidak memberikan kesenangan.

Saya ingin menulis petunjuk langkah-demi-langkah tentang cara menetapkan batasan yang tegas dan berhenti merasa buruk karena tumpukan masalah. Ini tidak sepenuhnya menghilangkan yang negatif, tetapi banyak membantu.

Kekasaran

Troll yang jelas biasanya mudah ditangani. Ini adalah sekelompok orang dengan niat jelas untuk membuat Anda marah. Troll biasanya tidak mengirim kode apa pun, sehingga komentar mereka tidak perlu diberi banyak perhatian. Paling tidak, itulah yang saya katakan pada diri saya dalam kerangka mekanisme pertahanan. Jika saya melihat troll, saya biasanya melaporkannya untuk mendukung GitHub dengan pemblokiran selanjutnya. Secara umum, saya sangat jarang bertemu dengan karakter seperti itu, jadi di sini saya tampaknya beruntung.

Tetapi kekasaran memiliki banyak bentuk. Emosionalitas saya menetapkan kerangka kesopanan yang agak ketat, sehingga Anda tidak dapat mempertimbangkan semua kekasaran ini. Tapi dari sudut pandang saya, ini paling tidak kasar.

• "Alatmu tidak berfungsi [untuk cerukku], jadi alat itu rusak."
  
• "Saya hanya akan campur tangan untuk mengatakan bahwa saya juga akan menyukai fitur ini" (Catatan. Tampaknya beberapa pembaca tidak tahan dengan apa yang saya sebut sebagai "kekasaran." Mungkin ini kata yang terlalu kuat, tetapi ketika dalam diskusi mereka mengakumulasikan fitur tersebut " "Add-ons", itu hanya menambahkan suara ke email dan dapat mengganggu. Sebaliknya, emotikon dipersilakan atau Anda dapat menambahkan beberapa detail ke kasus penggunaan spesifik Anda. Namun, itu terlihat sangat kecil dengan latar belakang, dan saya benar-benar melihat bahwa di sini astically masalah saya).
  
• Untuk menegaskan bahwa untuk mengimplementasikan fungsi Anda perlu " hanya membuat X".
  
• Agresi pasif ketika Anda menyampaikan permintaan fungsi.
  
• Cerewet tidak konstruktif tentang perangkat lunak di [masukkan di sini media sosial apa pun].
  
• Variasi pada tema "Mengapa Anda menciptakan kembali roda?" Atau "Mengapa tidak berkontribusi pada proyek yang sudah ada?"

Dalam banyak kasus, kekasaran adalah hasil dari kekecewaan yang tulus dari pihak pengguna. Berapa kali Anda bergumam ketika beberapa instrumen tidak berperilaku seperti yang Anda inginkan? Tidak masalah bahwa alat ini mungkin disajikan kepada Anda secara gratis. Anda hanya mencoba menyelesaikan masalah, dan alat ini menghalangi Anda. Saya sendiri pasti merasakannya. Menurut pendapat saya, perasaan manusia yang sepenuhnya normal.

Terkadang kekasaran berlaku, yang diekspresikan dalam berbagai cara yang tidak produktif. Saya tahu bahwa saya sendiri melakukan ini dan, tentu saja, juga terjadi di sisi lain. Ini sangat menjengkelkan bagi semua orang yang terlibat.

Dalam kasus lain, beberapa orang sendiri tidak memahami kekasaran mereka. Mungkin karena kendala bahasa, atau karena mereka tidak tahu bagaimana kata-kata mereka akan memengaruhi orang lain. Cukup polos, tetapi tidak mengubah perasaan saya.

Menghadapi kekasaran seperti ini bisa sangat sulit. Mungkin masalah ini tidak mengganggu siapa pun, tetapi saya bukan salah satu dari mereka. Saya bisa berpura - pura bahwa itu tidak mengganggu saya, tetapi saya yakin ini akan mengarah pada penghinaan terhadap open source dan bahkan lebih banyak kekecewaan.

Di sini lagi, menetapkan batas membantu saya. Jika kami membuang troll, maka sebagian besar snappers biasanya merespons dengan cukup baik, jika Anda dengan sopan mengatasinya. Saya sering melakukan ini di pelacak bug saya, dan ini umumnya memperbaiki situasi. Saya tidak merasa terhina karena saya melindungi diri saya sendiri, dan pada saat yang sama saya merasa lebih baik ketika orang lain meminta maaf, yang terjadi pada sebagian besar kasus.

Untuk melakukan ini, cukup dengan mengatakan: "Saya tidak suka dengan apa yang Anda katakan X. Saya pikir itu akan jauh lebih produktif jika kita menolak permohonan semacam itu di masa depan."

Tetapi dalam beberapa kasus, orang tidak merespons dengan baik kata-kata tersebut. Dalam pengalaman saya, mereka biasanya mengabaikannya. Jika mereka terus bersikap kasar, saya dapat mengulangi ini beberapa kali, karena beberapa perlu mendengar sesuatu lebih dari sekali untuk menjangkau mereka. Setidaknya saya tahu ini sendiri (banyak yang tidak disukai istri saya). Jika ini masih tidak berhasil, dan nada mereka masih mengganggu saya, maka saya berhenti berinteraksi. Cukup tutup atau blokir masalah atau permintaan kumpulan, atau melangkah lebih jauh hingga pengguna diblokir di [masukkan media sosial di sini].

Otoritas

Suatu hari, saya berbicara dengan beberapa teman dekat yang bepergian ke luar negeri. Baru saja kembali ke Amerika Serikat, mereka berbagi contoh kecil kejutan budaya. Hal utama?

Saya tidak pernah memikirkan betapa orang Amerika suka sekali memaksakan .

Apakah ini fitur semua budaya Amerika atau hanya lingkungan - kita tidak akan membahas. Intinya adalah bahwa beberapa orang suka berbicara tentang apa yang harus dilakukan orang lain. Saya tumbuh dengan umpan dari orang-orang dari tingkat hierarki kekuasaan yang paling berbeda - dan saya benar-benar merasa jijik sejak lahir untuk ini.

Saya sangat yakin bahwa kebanyakan orang bahkan tidak menyadari perilaku seperti itu. Beberapa tidak ingin masuk ke dalam hidup Anda, tetapi hanya mencoba memberikan nasihat. Setidaknya begitulah cara mereka merespons ketika saya menunjukkan kasus-kasus pemaksaan yang mengerikan.

Melangkah mundur sedikit, menggunakan kata "seharusnya" tidak dengan sendirinya buruk. Tapi yang benar-benar mengubah maknanya, menurut saya, adalah kehadiran undangan . Jika Anda meminta saran seseorang pada suatu topik, dan dia mengatakan sesuatu seperti "Ya, Anda harus membuat X", maka itu tidak terdengar terlalu buruk. , .

:

• .
  
• [ ].
  
• .
  
• [ ].
  
• .

, - . . , , - , . , - , - , .

, , . :

• , « ?», , . FAQ .
  
• . , - , .

, . , Rust, UNLICENSE . - «» , () , . . . - , .

, . - , . . , .

, . , , , - .

, - ( ), . . . -, . - , — , , — . , -: - , .

. . , , .

. open source. , , , .

FOSS — . , . FOSS , , . , .

, . - , , , .

. , . :

• , , ?
  
• ?
  
• ?
  
• ?

, . , . , . . — , . , , .

, JSON, , . , / . .

, , . . , . , , . , .

, , . , , FOSS.

,

. : « ?» , . . , , . , ( ) .

, :

• , . , . , : «, , . ».
  
• -, .
  
• -, , , . — , .
  
• changelog, , . , , .
  
• , , . , .
  
• . , , .
  
• . , , .

, — — . . , , , . .

Kesimpulan

FOSS, . , . , . , . , , . , . - , FOSS.

, , , , . , .

Dalam artikel itu, saya telah mencantumkan banyak jenis perilaku yang saya anggap negatif. Tidak semua orang akan menganggapnya sama negatifnya dengan saya. Ini normal dan diharapkan . Selain itu, saya sendiri melakukan beberapa hal negatif ini. Orang tidak sempurna, dan kita tidak pernah bisa sepenuhnya 100% responsif dari waktu. Ini adalah pertanyaan yang halus, dan saya berharap kita dapat memperbaiki situasi, setidaknya sedikit.