Open Source: Bukan Itu Menakutkan!

Berikut ini telah diposting sebelum peluncuran Beasiswa Toptal untuk Pengembang Wanita.

Sebagai pengembang, sangat menyenangkan dan menantang untuk mengikuti perkembangan tren terbaru dalam teknologi. Setiap hari, bahasa, kerangka kerja, dan perangkat baru menarik perhatian kami dan mendorong percakapan dalam pertemuan, forum, dan obrolan. Namun, komunitas pengembang kami terdiri dari orang-orang, bukan alat, dan sangat menarik untuk mengeksplorasi aspek sosial politiknya (karena tidak ada kata yang lebih baik; "sosial" cenderung dikaitkan dengan jejaring sosial, akhir-akhir ini).

Di Toptal, kami baru-baru ini memiliki beberapa percakapan menarik tentang seberapa banyak wanita berkontribusi pada open source dan apa yang mungkin mencegah mereka berkontribusi lebih banyak, jadi kami telah menyelidiki masalah tersebut. Setelah menjadi bagian dari percakapan itu dengan Breanden Beneschott dan Bozhidar Batsov, saya bertanya-tanya: Bozhidar adalah salah satu kontributor open source teratas di GitHub. dimana saya? Jika Anda memeriksa akun GitHub publik saya pada hari ini, ini terutama proyek uji kecil yang saya gunakan di kelas untuk siswa saya. Mereka setengah matang, dan jelas tidak mewakili keterampilan atau keahlian saya. (Anda harus menerima kata-kata saya tentang ini.) Jika seseorang mempertimbangkan untuk mempekerjakan saya berdasarkan apa yang dapat mereka temukan di akun itu, saya kira saya akan kesulitan mencari nafkah. Namun, saya telah menjadi pengembang profesional selama lebih dari 20 tahun, dan dalam pekerjaan sehari-hari saya, saya telah menggunakan lebih banyak perangkat lunak sumber terbuka daripada yang ingin saya ingat. Seiring waktu, saya telah meretas kernel Linux untuk membengkokkannya ke beberapa kebutuhan khusus, mengubah setiap router dan NAS yang saya beli, dengan sabar menunggu selama berbulan-bulan di daftar tunggu Raspberry Pi untuk mendapatkannya dan mendapatkan domotics buatan saya sebagai Saya suka itu. Namun, tidak satu pun dari tweak dan pengujian ini yang berhasil membuat GitHub saya menjadi open source. Selain itu, selain memperbaiki bug di salah satu versi pertama Tomcat, saya tidak pernah berkontribusi pada proyek sumber terbuka. Penasaran, bukan?

Anda mungkin berpikir itu hanya kurangnya waktu atau minat, tetapi saya tahu itu tidak benar. Adapun proyek pribadi saya, saya mungkin berpikir tidak ada yang benar-benar tertarik dengan apa yang telah saya lakukan, tetapi kebanyakan hanya gagasan untuk menerbitkan karya saya di sana, untuk dilihat semua orang dan untuk anak cucu, sangat menakutkan saya. Dan meskipun Anda selalu dapat meruntuhkan proyek pribadi dari GitHub, pada hari Anda mencoba dan berkontribusi pada proyek sumber terbuka yang tersedia secara luas, tidak ada kata mundur. Bagaimana jika kode saya tidak cukup baik? Bagaimana jika saya tidak memahami masalahnya dengan benar? Bagaimana jika permintaan tarik saya ditolak? Bagaimana jika orang mempermainkan saya?

Sebuah putaran panggilan cepat dengan sesama pengembang teman, kebanyakan perempuan, segera meyakinkan saya bahwa saya bukan satu-satunya dengan masalah ini, tetapi untuk seorang insinyur tidak ada masalah, hanya solusi, bukan?

Ini adalah masalah penting untuk dipecahkan, karena berkontribusi pada proyek open source dapat membuat perbedaan dramatis:

• Selama karir Anda : Banyak klien akan melihat segala hal sosial Anda sebelum memutuskan untuk mempekerjakan Anda; akun GitHub dan resume LinkedIn Anda berada di urutan teratas, bersama dengan profil Facebook dan Twitter Anda. Anda harus menggunakannya dengan bijak.
• Untuk keterampilan teknis Anda : Memeriksa basis kode yang ditulis oleh pengembang lain, dan seringkali yang sangat bagus, mengajarkan Anda banyak hal. Kemampuan untuk mengeluarkan makna dari basis kode yang ditulis dengan buruk akan menantang dan mengajari Anda sama banyak.
• Untuk soft skill Anda : Perangkat lunak open source adalah proses kolaboratif, dan hampir semua proyek menarik di luar sana dibangun oleh tim. Belajar bekerja dengan pengembang lain melalui alat yang digunakan semua orang, untuk berbaur dengan tim, berkomunikasi secara efisien, itulah yang akan membuat Anda menjadi pengembang yang hebat, bukan hanya yang terampil.
• Untuk komunitas : Setiap bit yang Anda sumbangkan ke proyek sumber terbuka penting. Semakin banyak Anda berkontribusi semakin baik, tetapi bahkan memperbaiki satu kesalahan ketik kecil dalam terjemahan akan membuat produk akhir menjadi lebih baik.
• Untuk jaringan Anda : Anda dapat mengirim ratusan resume ke perusahaan, tetapi tidak ada yang berhasil seperti memiliki rekan kerja dengan koneksi pribadi. Terlibat secara aktif dalam proyek open source akan memastikan Anda bertemu orang dan mendapatkan rasa hormat mereka, dan reputasi Anda akan tumbuh, yang sangat berharga bagi profesional mana pun.

Ini adalah perjalanan pribadi kecil saya dalam melawan ketakutan ini. Menerbitkan artikel ini adalah bagian dari perjalanan itu sendiri. Saya menulisnya dengan harapan bahwa siapa pun yang diblokir dalam menulis posting blog, atau takut membuat kontribusi kecil, akan melihat bahwa pada akhirnya, itu tidak terlalu menakutkan. Juga, ini dimaksudkan untuk membantu siapa saja yang ingin berkontribusi pada open source, tetapi tidak tahu harus mulai dari mana, jadi saya akan mulai dengan dasar-dasarnya.

Apa itu Perangkat Lunak Sumber Terbuka dan di mana saya menemukannya?

Perangkat lunak sumber terbuka, atau disingkat OSS, adalah perangkat lunak apa pun yang dirilis dengan kode sumbernya, dan menyertakan lisensi yang memungkinkan Anda untuk memodifikasi dan mendistribusikannya kembali. Itu dapat dikirim ke mana saja: di situs web, melalui milis atau dengan burung hantu. Skenario yang paling umum, dan salah satu yang kami minati, adalah ketika basis kode dipertahankan pada repositori kolaboratif. Di sini, kami berfokus pada GitHub, tetapi ada opsi lain, seperti SourceForge dan Bitbucket. GitHub sangat ramah, memiliki basis pengguna yang besar, dapat digunakan untuk semua jenis kode, dan dengan lingkungan pengembangan apa pun yang Anda gunakan. Yang penting, ini juga banyak digunakan untuk proyek non open source. Kemungkinan proyek klien Anda berikutnya akan di-host di sana, jadi mengetahui cara bekerja dengannya adalah keterampilan yang berguna.

Bagaimana jika saya tidak tahu cara membuat kode?

Jika Anda membaca ini, kemungkinan Anda ingin belajar cara membuat kode. Anda dapat menemukan kursus luar biasa di beberapa situs web gratis dan berbayar. Anda harus memilih satu bahasa untuk dipelajari; jika Anda tidak memiliki preferensi, gunakan JavaScript. Anda sudah memiliki semua yang Anda butuhkan untuk memulai di browser web Anda dan ini adalah salah satu keterampilan yang paling banyak digunakan, dan dapat dipasarkan. Favorit pribadi saya adalah Python, yang digunakan baik dalam pengembangan web maupun dalam aplikasi ilmiah. Saya, juga, memiliki kursus pemula favorit pribadi, "Pengantar ilmu komputer" di Udacity. Saya menyukainya karena ini adalah kursus langsung, di mana Anda mengerjakan proyek sambil belajar. Anda juga dapat menemukan beberapa kursus lain di Coursera, Khan Academy, dan PluralSight.

Bagaimana jika saya tidak tahu Git?

Seperti yang disebutkan sebelumnya, mengetahui Git itu penting, jadi, ikuti kelas Git. Lakukan bahkan jika Anda telah bekerja dengan Git untuk sementara waktu; Anda tidak tahu seberapa banyak Anda tidak tahu tentang Git sampai Anda benar-benar mempelajarinya. Lakukan jika Anda tidak dapat dengan yakin menjelaskan apa yang dilakukan perintah rebase . Lakukan bahkan jika rebase yang salah tidak membuat Anda takut. Saya mengambil jalur Git lengkap di Code School, tetapi sekali lagi, Anda dapat menjelajahi situs lain untuk opsi lebih lanjut.

Bagaimana cara memilih proyek di GitHub?

Kemungkinan Anda menggunakan beberapa OSS dalam pengembangan sehari-hari Anda. Memilih kerangka kerja yang sudah dikenal adalah titik awal yang baik; Anda sudah familiar dengan fitur dan cara kerja framework. Saat Anda menyelami kode sumber, Anda akan belajar lebih banyak, dan Anda akan memahami logikanya dengan lebih jelas. Jika ada teknologi atau alat yang sangat Anda sukai, cari proyek yang menyebutkannya, atau proyek alat itu sendiri. Sebagai upaya terakhir, Anda dapat memeriksa proyek di GitHub Showcases dan mulai dengan memilih kategori yang Anda minati.

Misalnya, pencarian cepat untuk "Raspberry" di pencarian GitHub menunjukkan lebih dari 17 ribu repositori. Sangat mudah tersesat, jadi carilah proyek dengan komunitas yang baik dan pelacakan masalah yang baik. Saat memilih proyek, periksa jumlah:

• Kontributor : Targetkan apa pun di atas sepuluh kontributor. Ini harus memastikan bahwa proyek memiliki minat yang cukup dan bukan hanya upaya tim kecil. Jika Anda baru mengenal OSS, atau tidak terlalu ahli, batasi pencarian Anda pada proyek dengan paling banyak lima puluh kontributor; komunitas yang lebih besar menyiratkan basis kode yang lebih besar dan proyek yang lebih rumit.
• Komit : Pilih proyek yang memiliki setidaknya seribu komitmen, dan aktivitas terbarunya tidak lebih dari seminggu. Sebuah proyek yang telah tidak aktif selama satu bulan atau lebih sudah tua dan basi dalam istilah OSS, dan Anda mungkin tidak akan mendapatkan tanggapan dengan cepat. Aktivitas sehari-hari adalah tanda proyek yang sehat.
• Masalah : Masalah adalah masalah terbuka, bug yang telah dilaporkan atau fitur yang diminta untuk diimplementasikan. Mereka akan memberi Anda titik awal dan merupakan metrik yang baik dari minat dalam proyek.

Juga, cari tahu apa bahasa utama proyek itu; Anda dapat melihat statistik bahasa di bilah atas halaman proyek utama. Luangkan waktu untuk membaca nada diskusi, lihat seberapa ramah dan mendidik komentarnya. Beberapa proyek terkenal karena komunitasnya yang agresif, sehingga mungkin bukan titik awal yang tepat.

Saya memilih ScyllaDB, sebuah proyek penyimpanan data berbentuk kolom, karena saya memiliki ketertarikan pada data-apa pun yang berhubungan dengan kinerja. Saya belum pernah bekerja dengannya, tetapi saya berharap dapat menyelami basis kodenya. Mungkin lebih mudah untuk bekerja dengan alat yang saya tahu, tetapi saya menganggap ini sebagai tantangan dan kesempatan untuk mempelajari sesuatu yang baru. Selebihnya, itu sesuai dengan tagihan; ia memiliki 18 kontributor, 6,5 ribu komit (yang terbaru adalah 23 jam yang lalu pada saat penulisan), 178 masalah terbuka dan tampak aktif.

Apa yang saya lakukan sekarang?

Pertama, kloning repositori dan instal perangkat lunak pada mesin Anda untuk mendapatkan gambaran tentang bagian-bagiannya yang bergerak. Kemudian, mulailah membaca masalah. Setelah Anda merasa siap, lihat apakah Anda dapat mereproduksi masalah pada mesin Anda dan kemudian mulai menganalisis apa yang membuat perangkat lunak berperilaku tidak semestinya.

Pendekatan lain adalah menemukan sesuatu yang dapat Anda tingkatkan, atau modifikasi, sendiri. Mungkin Anda melihat salah ketik, atau font yang tidak selaras, misalnya. Saya memilih untuk memperbaiki bug kecil, khususnya nama variabel yang salah yang digunakan dalam dokumentasi skrip.

Tampaknya kecil, tetapi dokumentasi yang salah jauh lebih buruk daripada tidak ada dokumentasi. Pengguna akan menginstal ScyllaDB dan mengikuti langkah-langkah instalasi, mereka akan bergantung secara membabi buta pada apa yang tertulis dalam skrip itu, dan akan berakhir dengan frustrasi. Ini sempurna untuk kemampuan saya, dan memperbaikinya akan mengharuskan saya untuk mengikuti seluruh proses, dan menjadi sedikit akrab dengan basis kode. Perbaikan bug itu membosankan, tetapi ini adalah awal yang baik untuk menemukan jalan Anda ke dalam sebuah proyek.

Membuat garpu

Ini mungkin sepele, tetapi saat ini, untuk proyek ScyllaDB, saya adalah Ms. Nobody; akan berisiko untuk mengizinkan saya membuat perubahan pada kode mereka tanpa pengawasan. Yang perlu saya lakukan adalah membuat "garpu" di akun GitHub saya sendiri. Ini garpu ScyllaDB saya. Ini adalah taman bermain saya sendiri di mana saya memiliki akses ke semua kode, dan saya dapat memodifikasi file sesuai keinginan. Jika saya ingin membuat ScyllaDB versi saya sendiri dan mengubahnya untuk melakukan sesuatu yang sama sekali berbeda dari tujuan aslinya, saya dapat melakukannya di sini. Membuat garpu itu sederhana; pergi ke halaman utama proyek dan klik tombol "garpu". Tidak menakutkan sama sekali.

Saatnya memperbaiki bug

Sekarang, saatnya untuk menguji kode di komputer Anda dan membuat modifikasi yang diperlukan. Pertama-tama, pastikan Anda telah menginstal klien Git di mesin Anda. Kemudian, tambahkan kunci publik SSH Anda ke GitHub, dan pastikan itu dimuat oleh ssh-agent Anda. Mendapatkan kode secara lokal itu sederhana; cukup gunakan perintah git clone yang menunjuk ke garpu Anda, alih-alih cabang utama:

 git clone [email protected]:acbellini/scylla.git

Sekarang, Anda seharusnya sudah menguji proyek di cabang utama, jadi Anda akan membangun kode Anda secara lokal dan mengujinya dengan cara yang sama. Ingatlah bahwa Anda harus melakukan fork pada proyek GitHub lain yang menjadi sandaran proyek Anda, karena referensi bersifat relatif. Dalam kasus saya, saya harus melakukan fork seastar, scylla-ami dan scylla-swagger-ui.

Bug yang perlu saya perbaiki relatif sederhana; dokumentasi di conf/scylla.yaml menyebutkan tiga direktori yang dapat dikonfigurasi: Satu untuk file data, satu untuk log komit dan satu, tampaknya tidak digunakan, untuk cache, semuanya default ke beberapa subdirektori $CASSANDRA_HOME :

Menyelam ke dalam kode, itu menunjukkan bahwa defaultnya berbeda dan, seperti yang disebutkan dalam masalah #372 yang saya mulai, $CASSANDRA_HOME tidak boleh digunakan. Saya memvalidasi hipotesis saya dengan menguji kode dengan beberapa pengaturan berbeda, dengan menghapus pengaturan dari file konfigurasi dan memeriksa direktori mana yang digunakan. Setelah cukup yakin bahwa semuanya benar, saya dapat menambahkan, mengkomit, dan mendorong file yang dimodifikasi:

 git add conf/scylla.yaml git commit -m 'Correct default directories values in conf/scylla.yaml #372' git push

Perhatikan bahwa saya memperkenalkan nomor masalah yang didahului oleh hash dalam pesan komit. Ini akan memberi tahu GitHub untuk secara otomatis menautkan kode saya ke masalah itu sendiri.

Hal penting lainnya yang perlu diperhatikan adalah, ketika saya mengamati kodenya, saya menyadari bahwa direktori ketiga, direktori untuk cache, sebenarnya tidak digunakan. Sangat menggoda untuk melangkah terlalu jauh dan menghapus pengaturan ini sendiri, atau menambahkan komentar yang tidak digunakan, tetapi itu akan berada di luar cakupan masalah #372, dan akan salah untuk melakukan apa pun yang tidak sepenuhnya terkait dengan ini isu. Anda harus menjaga agar perubahan tetap fokus dan terbatas pada tugas yang ada.

Pada titik ini kode sudah diperbaiki dan ada di GitHub, di garpu pribadi saya. Di sinilah bagian yang menakutkan masuk: Meminta orang-orang ScyllaDB untuk menerima kode saya. Ini disebut permintaan tarik.

Langkah terakhir: permintaan tarik

Saya suka membuat permintaan tarik langsung dari antarmuka web di GitHub. Saya merasa lebih intuitif dan tahan kesalahan daripada mencoba melakukannya dari baris perintah. Yang harus saya lakukan untuk membuat permintaan tarik adalah mengklik tombol hijau kecil di sebelah nama cabang saya:

Perhatikan bahwa komentar secara otomatis dihitung oleh GitHub. Cabang saya sekarang memiliki satu komit baru, tetapi sejak membuat garpu saya, ada 14 komit lagi di repositori utama, jadi saya akan mengklik ikon hijau di sebelah kiri.

Untungnya, komit tunggal saya tidak bertentangan dengan 14 komit lainnya, jadi GitHub memberi tahu saya bahwa saya siap melakukannya. Saya tidak perlu menambahkan komentar atau pesan lain. Pesan komit, meskipun sangat singkat, mengatakan semuanya: Apa yang dilakukan perubahan kode saya dan apa yang terkait dengannya. Saat saya mengklik tombol terakhir untuk mengkonfirmasi permintaan saya, saya bertanya-tanya apa yang saya temukan begitu menakutkan beberapa hari yang lalu. Tidak ada monster yang mengaum padaku saat ini, dan api neraka sepertinya tidak menyala. Sejujurnya, itu tidak menakutkan sama sekali. Dalam kasus yang tidak mungkin saya salah, perbaikan saya tidak akan diterima dan hanya itu.

Jika sekarang Anda memeriksa detail masalah, Anda dapat melihat bahwa GitHub secara otomatis menambahkan catatan bahwa ada permintaan tarik yang merujuk pada masalah ini. Ini adalah keajaiban #372 dalam pesan komit. Ini akan membantu menghindari orang lain membuang waktu untuk memperbaiki sesuatu yang telah diperbaiki.

Catatan akhir

Sekarang saya sedang menunggu pull request saya diterima, saya akan menerima notifikasi ketika itu terjadi. Ingatlah bahwa ini bisa memakan waktu beberapa hari, bahkan berminggu-minggu; seseorang harus meninjau kode saya, mengujinya agar berfungsi seperti yang dijelaskan, memperbaiki masalah, dan, pada akhirnya, memastikan itu tidak mempengaruhi fungsionalitas kode lainnya (baca: membuat bug baru). Semua ini membutuhkan waktu seseorang, jadi bersabarlah. Pada akhirnya, ketika pull request saya diterima, ScyllaDB akan memiliki satu kontributor lagi, satu edisi lebih sedikit dan saya akan mendapatkan kontribusi OSS pertama saya. Sekarang, saatnya Anda mencobanya juga. Lagipula, itu tidak menakutkan sama sekali.