Fork: Langkah Awal Sederhana untuk Mulai Kontribusi di Komunitas Open Source
Sebagai developer, keseharian kita tidak bisa lepas dari komunitas open source. Sehari-hari kita banyak memakai library tak berbayar yang dibuat atau dimaintain oleh komunitas open source. Jika kita menemukan error pada suatu library yang kita pakai, pastinya kita merasa kecewa karena timeline kerja kita jadi terganggu, dan kita melaporkan hal tersebut sebagai Issue di library tersebut.
Terkadang, issue yang kita buat tidak cepat ditanggapi oleh para maintainer library tersebut. Sehingga timeline pekerjaan kita menjadi benar-benar terganggu dan kita mulai mencari alternatif library lain. Padahal dipikir-pikir, para maintainer-maintainer itu tidak dibayar untuk me-maintain library tersebut.
Sambil menunggu issue kita ditanggapi, sebenarnya kita bisa melakukan Fork library tersebut, dan mencoba memperbaiki library tersebut khusus untuk kasus pekerjaan kita. Daripada menunggu orang lain yang belum tentu bisa me-reproduce issue-nya, lebih baik kita yang sudah dapat me-reproduce issue-nya mencoba memperbaikinya sendiri kan?
Banyak keuntungan dengan menekan tombol Fork ini:
- Kita bisa memperbaiki sendiri dan tidak perlu menunggu orang lain memperbaiki
- Library yang sudah di-fork menjadi terserah kita, jika kita tidak bisa memperbaiki, mungkin kita bisa membuat sebuah workaround fix atau hacky fix di library tersebut.
Seringkali saat melakukan fork, saya lebih fokus dalam membuat workaround fix sehingga pekerjaan saya bisa segera selesai. Nah, saat lagi santai di luar jam kerja, kita bisa membuka kembali kode kita dan mencari cara untuk membuat fix yang lebih global, yang bisa dipakai oleh semua orang bukan hanya untuk kita.
Jika kita berhasil membuat fix yang bisa dipakai oleh semua orang, kita bisa membuat Merge Request / Pull Request balik ke repository library utamanya. Dengan begitu kita sudah berkontribusi di dunia open source. Perbaikan kita bisa menyelamatkan waktu orang-orang lain yang berpotensi memiliki masalah yang sama dengan kita di kemudian hari.
Owner library mungkin tidak langsung merespon Pull Request kita. Ingat, masing-masing punya kesibukan. Saat owner mereview Pull Request kita dan ada yang perlu kita perbaiki lagi pun, kita tidak diharuskan untuk langsung mengerjakan hasil reviewnya. Malah terkadang nanti ada orang lain yang ikut me-review dan memberi solusi.
Santai saja, toh untuk pekerjaan kita, kita sudah punya workaround fix nya di library hasil fork kita. Namun alangkah lebih baik jika kita segera menyelesaikan Pull Request kita supaya dapat segera di-merge.
Saat owner sudah puas dengan fix yang kita buat, Pull Request kita akan segera di-merge. Walau begitu, owner library mungkin tidak akan langsung membuat rilis baru yang berisi fix kita. Tak perlu resah menunggu rilis baru, kan kita bisa pakai library hasil fork kita. 🙂
Sampai akhirnya beberapa hari kemudian kita diberitahu bahwa fix kita sudah dimasukkan ke rilis terbaru dan kita bisa menggunakan library tersebut dari repository utamanya lagi. 🕺
Yaay! Kita sudah berkontribusi di komunitas open source!
My extra thoughts
Artikel di atas sepertinya mudah namun tentunya berdampak pada timeline pekerjaan. Menurut saya, seharusnya timeline pekerjaan tidak dibuat mepet hanya karena sudah banyak library yang tersedia. Banyak hal yang bisa terjadi karena memakai library open source. Ingat, library-library itu dibuat oleh orang yang meluangkan waktu kerjanya demi berbagi dengan orang lain. Kita sebagai pemakai pun harusnya siap meluangkan waktu kerja juga jika terjadi masalah dengan library tersebut.
Dalam pekerjaan lebih baik spare waktu lebih. Terkadang kita dikejar-kejar stakeholder karena janji kita sendiri yang terlalu over confidence. Sehingga stakeholder terlanjur bilang ke stakeholder lainnya berdasarkan janji yang kita buat sendiri. Saat kita terlambat, stakeholder tersebut cerewet menagih-nagih karena dia juga ditagih-tagih oleh stakeholder lainnya. Awal masalahnya? Karena janji kita sendiri.
Dari seorang rekan yang saya kagumi, saya mendapat sebuah konsep perbedaan antara junior dan senior dalam menaksir waktu.
Kita ambil contoh dalam sebuah pekerjaan yang bisa selesai 5 hari:
- Junior: Over confidence. Berpikir jangka pendek. Berani berkata 3 hari selesai. Kenyataan selesai 7 hari. Terlambat dari deadline.
- Medior: Making problem more complex. Terlalu berpikir jangka panjang. Berani berkata 7 hari selesai. Kenyataan 7 hari selesai. Sesuai deadline.
- Senior: Bisa menyeimbangkan antara berpikir pendek dan berpikir panjang. Berani berkata 7 hari selesai. Kenyataan 5 hari selesai. Lebih cepat dari deadline.
Semoga artikel ini bermanfaat. Ingat, pakai library open source bukan untuk serba instant, tapi supaya tidak perlu reinvent the wheel. Jika ada yang ingin didiskusikan, silakan. 🙂
