InnerSource adalah Kebohongan - Tanggapan terhadap Kesalahpahaman Umum
Ketika Anda mencari “InnerSource” di YouTube, salah satu hasil pertama yang kemungkinan akan Anda temui adalah video yang mengklaim bahwa “InnerSource adalah kebohongan.”
(link: https://youtube.com/shorts/53jEP3mPP3E)
Sudut pandang ini mewakili jebakan tipikal yang banyak orang alami ketika mereka pertama kali belajar tentang InnerSource.
Saya ingin menggunakan video ini sebagai studi kasus untuk menjelaskan jenis kesimpulan menyesatkan yang dipromosikannya. Ini adalah kesalahan yang pernah saya buat di masa lalu juga, dan ini adalah jebakan yang mudah dijatuhkan oleh banyak orang yang belum mendalami bidang ini. Itulah mengapa saya ingin mengkaji ini dengan refleksi diri dan membantu orang lain menemukan jalan yang benar dengan mengurai jebakan-jebakan ini.
Kesalahpahaman Pertama: “Gunakan React Agar Orang Lain Bisa Berkontribusi” #
Mari saya uraikan argumen dalam kasus ini terlebih dahulu. Video tersebut menyarankan penggunaan React untuk aplikasi internal “Gunakan React karena orang lain bisa berkontribusi padanya.” Jenis penalaran seperti ini jarang terdengar dalam diskusi InnerSource yang sebenarnya.
should you use react HTMX or solid or something for your company’s internal application now a lot of people what you’re going to hear is use react so other people can contribute to this
Argumen ini dapat dibedah menjadi tiga masalah utama:
- Kesalahpahaman mendasar tentang apa sebenarnya InnerSource
- Memilih domain yang salah untuk penerapan InnerSource
- Mengacaukan perspektif individu versus tim
Apa Sebenarnya InnerSource #
InnerSource adalah tentang mempraktikkan prinsip-prinsip open source dalam sebuah perusahaan. Ini bukan hanya tentang “berkontribusi” atau “menerima kontribusi.”
Kebanyakan orang yang berinteraksi dengan open source hanyalah “pengguna.” Beberapa hanya konsumen, yang lain mengajukan laporan bug, dan hanya sebagian kecil yang benar-benar mengirimkan pull request. InnerSource menerapkan pembelajaran open source secara internal untuk menciptakan organisasi yang terbuka, dapat diakses secara luas, dengan pengambilan keputusan yang transparan, dan hubungan tim yang dibangun atas dasar kepercayaan melalui kepemilikan dan mentoring. Ini menciptakan budaya transparansi dan kolaborasi.
Inilah yang dimaksud dengan “mempraktikkan open source secara internal” - ini bukan hanya tentang “menerima pull request.” Pull request hanyalah satu hasil dari budaya ini, bukan tujuan utama.
Domain yang Kurang Optimal untuk Penerapan InnerSource #
Masalah kedua adalah bahwa argumen ini berkembang dalam domain di mana InnerSource dan open source menghadapi tantangan khusus.
Jika Anda ingin “menerima pull request” atau “memiliki banyak orang menggunakan kode Anda untuk meningkatkan kualitas,” itu mungkin dibatasi oleh sifat produk Anda. Jelas bahwa berbagi “komponen dengan dependensi tinggi” atau alat tingkat platform akan menciptakan lebih banyak nilai daripada aplikasi pengguna akhir. Meskipun tim yang selaras dengan alur (stream-aligned teams) tetap harus mengadopsi praktik open source ketika menguntungkan, dinamika kolaborasinya berbeda secara signifikan.
Dalam pengalaman saya bekerja dengan perusahaan enterprise, menggunakan InnerSource untuk inisiatif tingkat proyek di mana pengguna akhir adalah “non-insinyur” menghadirkan tantangan unik. Mengapa? Karena pada akhirnya, produk-produk ini perlu melayani kebutuhan “pengguna akhir” atau “pengguna bisnis” yang mungkin kekurangan keterampilan pengembangan dan saluran komunikasi langsung dengan tim pengembangan. Ini menciptakan persyaratan yang kompleks dan individual serta waktu tunggu komunikasi yang lebih lama.
Implementasi InnerSource cenderung bekerja relatif baik ketika diterapkan pada pustaka bersama, komponen platform, alat pengembangan, dan kode infrastruktur—area di mana “pengguna” utamanya adalah pengembang lain yang dapat berkontribusi secara bermakna dan mendapat manfaat dari praktik pengembangan kolaboratif.
Meskipun menerapkan praktik InnerSource pada aplikasi yang menghadap pengguna dapat membawa manfaat berharga seperti transparansi dan pelacakan masalah yang lebih baik (yang saja sudah membuatnya bermanfaat).
Perspektif Individu vs. Tim #
Masalah ketiga menyangkut apakah “Anda” merujuk pada individu atau tim.
Penting untuk dicatat bahwa InnerSource tidak harus tentang menunggu seseorang berkontribusi pada “proyek pribadi Anda” dalam sebuah perusahaan. Ketika InnerSource diterapkan, mungkin ada kasus di mana orang berkontribusi pada proyek yang dikembangkan selama waktu 20%, seperti perusahaan teknologi besar, tetapi itu tidak harus menjadi pendekatan utama.
InnerSource terutama diperkenalkan dan dipertahankan karena menghasilkan ROI melalui pengurangan biaya, menghindari penemuan kembali roda, menciptakan sinergi, jaminan kualitas, dan menghilangkan overhead komunikasi dari pengambilan keputusan hierarkis. Ini biasanya melibatkan pustaka internal bersama, komponen keunggulan kompetitif proprietary, atau hal-hal dengan dependensi tinggi yang khusus dalam enterprise. Dan “manfaat bisnis” ini biasanya mengalir kembali ke “operasi tim” dalam kebanyakan kasus. Pada akhirnya, ini semua tentang ROI untuk tim dan organisasi. Jika kita tidak memikirkan tim, seseorang akan menghentikan Anda berkontribusi pada proyek. Anda perlu membenarkan ROI Anda baik jangka pendek maupun jangka panjang.
Yang unik tentang InnerSource adalah bahwa ini pada dasarnya tentang kolaborasi tim-ke-tim. Di sinilah sebagian besar implementasi akhirnya berakhir. Ini tidak harus individu yang secara acak berkontribusi pada proyek pribadi yang nyaman. Ini biasanya diimplementasikan melalui hubungan tim host dan tim tamu, di mana tim tamu ikut serta dengan bagian yang dipertahankan oleh tim host. Sebagian besar enterprise memiliki karyawan dengan peran dan tanggung jawab yang terdefinisi, dan kolaborasi cenderung terjadi dalam struktur ini.
Oleh karena itu, InnerSource sangat efektif ketika hubungan antara tim platform dan tim yang selaras dengan alur (tim tamu dan tim host) terbentuk. Ko-kreasi aktif antara tim yang selaras dengan alur atau individu lebih tidak pasti untuk berhasil secara alami.
Mengkritik seluruh InnerSource berdasarkan skenario yang tidak mungkin berhasil tidak masuk akal secara logis.
Kesalahpahaman Kedua: “Itu Tidak Pernah Terjadi di Perusahaan Nyata” #
because we want people doing that the reality is that’s not what’s going to happen ever at any company ever inner source
Sebenarnya, ini sedang terjadi. Studi kasus membuktikannya. Titik.
Kesalahpahaman Ketiga: “99,69% Proyek InnerSource Akan Gagal” #
99.69% a lie you’re going to build the entire project by yourself when it goes down people are going to look to you
Ini mungkin benar tergantung pada bagaimana Anda mendefinisikan “InnerSource.” Seperti yang disebutkan sebelumnya, InnerSource bukan tentang “menerima kontribusi PR.”
Namun, ada tiga poin penting yang perlu dipertimbangkan:
- InnerSource terutama berlaku untuk komponen strategis - tidak diperlukan untuk semua komponen
- Manfaat meluas di luar kontribusi aktif
- Open source memiliki masalah “tingkat kegagalan” yang sama
InnerSource adalah Strategi Korporat #
Ketika orang berpikir tentang InnerSource, mereka terkadang membayangkan ide radikal seperti “berbagi semua kode dalam enterprise” atau “semua orang berkontribusi pada segalanya.” Mereka mungkin membayangkan ratusan repositori bersama dalam perusahaan dengan semua orang secara aktif bertukar kontribusi. Seperti open source menjadi strategi untuk perusahaan, InnerSource juga merupakan strategi korporat dengan prioritas. Perusahaan berbagi “apa yang layak dibagi” terlebih dahulu.
Oleh karena itu, jumlah sebenarnya dari basis kode di mana kode secara aktif mengalir antara tim dan kolaborasi lintas tim yang hidup terjadi relatif kecil. Ini mungkin memang persentase satu digit. Namun, bahkan tanpa kolaborasi lintas tim yang aktif, banyak proyek dapat memperoleh manfaat dari menjadi terbuka dan transparan. Dalam pengertian InnerSource ini, enterprise sering dapat berbagi nilai di banyak kasus lagi.
Meskipun InnerSource mencakup kontribusi individu, ini terutama difokuskan pada kolaborasi tim-ke-tim. Oleh karena itu, apa yang dibagikan melalui InnerSource cenderung relatif khusus dalam enterprise, atau item khusus tujuan seperti distribusi Linux yang di-fork untuk kebutuhan tertentu. Atau mungkin hanya budaya pengembangan seperti open source, seperti ketika GitHub berbagi kode Ruby on Rails di semua karyawan.
Ketika kita mengkondisikan diskusi persentase ini pada InnerSource yang secara aktif berkolaborasi dan dipertahankan sebagai persyaratan umum, persentasenya mungkin memang relatif rendah. Namun, kolaborasi kecil seperti pull request dokumentasi atau perubahan konfigurasi kecil (mengirim patch kecil) antara tim tamu dan tim platform/host terjadi relatif sering. Ketika Anda memasukkan mikro-kolaborasi ini dan manfaat transparansi yang mencegah upaya duplikat, angka-angka ini meningkat secara signifikan.
Open Source Memiliki “Masalah” yang Sama #
Di sisi lain, jika kita mendefinisikannya seperti itu, open source juga akan menjadi “kebohongan.” Karena “99,69% proyek open source akan gagal.” Sebagian besar kode yang dipublikasikan sebagai open source tidak menerima kontribusi. Tetapi tidak ada yang mengatakan “open source adalah kebohongan” karena itu. Orang mengejar open source karena ada manfaat di luar menerima kontribusi.
Sekali lagi, “dikontribusi” bukan satu-satunya nilai InnerSource. Dan hal yang sama berlaku untuk nilai open source juga
Manfaat Nyata Transparansi #
Menjaga kode internal terbuka daripada tersembunyi - di GitHub, arsitek atau insinyur solusi di tim pendapatan mungkin dapat memeriksa kode sumber untuk menemukan informasi yang relevan, berpotensi menemukan detail yang sangat dekat dengan permintaan pelanggan, memfasilitasi percakapan dukungan yang lebih lancar, dan mengekstrak informasi yang lebih akurat dari masalah. Saya tinggal di Tokyo, dan terkadang lebih cepat untuk hanya melihat kode Ruby untuk memeriksa implementasi, atau pergi ke masalah untuk memeriksa latar belakang perubahan, daripada menunggu tim produk berbasis SF bangun untuk menanyakan pertanyaan implementasi tentang perubahan dan latar belakangnya.
Menggunakan perintah git blame, Anda dapat mengidentifikasi pemangku kepentingan “nyata” dari kode dan mengajukan pertanyaan tentang latar belakang keputusan.
Tidak perlu dikatakan, hal yang sama berlaku untuk tim pengembangan lainnya. Memiliki informasi yang mudah tersedia tentang komponen yang mungkin menciptakan dependensi jelas mengurangi overhead komunikasi.
InnerSource adalah tentang mempraktikkan prinsip-prinsip open source secara internal. InnerSource bukan hanya tentang mengirim pull request bolak-balik - ini tentang memastikan transparansi dan memperoleh manfaat melalui kolaborasi gaya open source. Manfaat ini meluas jauh di luar beberapa persen repositori yang dipertahankan secara aktif ke manfaat implementasi budaya yang lebih luas.
Kesalahpahaman Keempat: “Anda Akan Dipanggil Kembali Ketika Anda Pergi” #
“when you leave the company they’re going to send you a message 6 months later asking you questions or seeing if you would like to contract with them to upgrade your application there is no such thing as innersourcing”
Sumber daya terkadang tidak dipertahankan, tetapi ini bukan kritik yang tepat terhadap InnerSource itu sendiri - ini kritik terhadap kegagalan mengimplementasikan InnerSource dengan benar. Ini bukan kritik terhadap InnerSource, tetapi kritik terhadap kurangnya budaya pemeliharaan di mana tidak ada yang memelihara kode. Ini hasil dari kegagalan mengimplementasikan InnerSource dengan benar atau tidak mempertimbangkannya sama sekali - hasil dari kurangnya kepemilikan.
Analogi DevOps #
Ini adalah kritik terhadap kegagalan melakukan InnerSource, bukan kritik terhadap InnerSource itu sendiri. Terkadang ini membingungkan logika. Untuk menempatkan ini dalam istilah DevOps: ini seperti mengatakan “perusahaan akhirnya mengadopsi siklus review yang lambat selama beberapa bulan atau audit, atau menambahkan proses untuk keputusan rilis, sehingga rilis menjadi triwulanan atau hanya dua kali setahun. Oleh karena itu DevOps, yang mengklaim memungkinkan rilis cepat, tidak baik.” Itu bukan karena metodologi DevOps buruk, tetapi hanya karena “ada kasus di mana DevOps tidak dapat diimplementasikan.”
Memecah proses bisnis sangat sulit, dan banyak perusahaan mengatakan DevOps tidak mungkin. Tetapi bahkan ketika orang berpikir itu tidak mungkin, ada pelopor yang berani yang bekerja keras untuk mengubah budaya dan mencapai DevOps. Hal yang sama dapat terjadi dengan InnerSource.
Kesalahpahaman Kelima: “Anda Harus Memiliki Segalanya 100%” #
you own it 100% (which implies: InnerSource where you don’t own 100% is impossible)
“InnerSource berarti meninggalkan kepemilikan kode” adalah salah. InnerSource sebenarnya membutuhkan tim untuk memiliki kode. Ini adalah kesalahan umum. Ini seperti orang yang ingin meninggalkan tanggung jawab pemeliharaan dan berkata “mari kita buat ini open source.” Itu tidak berhasil.
Kepemilikan Individu vs. Tim - Apakah InnerSource Kepemilikan Kode yang Kuat? #
Pertama, apakah “Anda” ini individu atau jamak? Meskipun individu mungkin terdaftar sebagai file CODEOWNERS dalam organisasi, tim pada akhirnya memegang tanggung jawab untuk kode. Secara kontekstual, kemungkinan berbicara tentang Strong Code Ownership. Tetapi ini tidak baik ketika mempertimbangkan pemeliharaan organisasi. Karena karyawan mungkin berhenti.
InnerSource bukan Strong Code Ownership. Minimal, beberapa orang perlu berbagi tanggung jawab. Meskipun demikian, saya mengakui bahwa Strong Code Ownership mungkin muncul dalam jangka pendek, dan pada tahap awal proyek, kemauan individu yang kuat mungkin secara alami mengarah pada pengaturan seperti itu, tetapi jika Anda ingin mencapai kesuksesan jangka panjang, perlu mendelegasikan otoritas sehingga organisasi dapat menangani pemeliharaan secara kolektif.
Jenis Kepemilikan Tim - Apakah InnerSource Kepemilikan Kode Kolektif? #
Jenis argumen ini mungkin terkadang merujuk pada Collective Ownership. Dalam hal ini, argumen tersebut juga tampaknya menyarankan bahwa InnerSource berarti kepemilikan kolektif, tetapi itu sebenarnya berbeda. InnerSource bukan Collective Code Ownership InnerSource melibatkan tim host yang pada akhirnya menangani pemeliharaan. InnerSource adalah Weak Code Ownership. Jadi meskipun tanggung jawab pemeliharaan 100% benar, mengatakan “Anda harus memiliki 100% dan InnerSource berbeda” benar-benar tidak logis. Ini sebenarnya adalah pendapat yang salah.
Seperti yang terkenal diargumentasikan Martin Fowler tentang kepemilikan kode, memiliki semua orang memiliki kode 100% (kepemilikan kolektif) terkadang menciptakan situasi di mana tidak ada yang bertanggung jawab. Itu sangat bermasalah - tanggung jawab menjadi tidak jelas dan proyek pada akhirnya gagal.
Model Weak Code Ownership #
Dalam Weak Code Ownership, maintainer ada, tim host memelihara proyek, dan bagian tertentu mungkin membawa committer/maintainer tepercaya dari tim lain. Seseorang mungkin berkontribusi, seseorang mungkin memelihara, tetapi tidak 100% oleh “Anda” atau “tim Anda” - mungkin sangat berbeda. Misalnya, 98% kode mungkin dimiliki oleh tim Anda, sementara 2% mungkin dimiliki oleh tim lain.
Dalam hal ini, ingat bahwa bahkan jika individu ditugaskan sebagai pemilik kode dalam organisasi, tim pada akhirnya memegang tanggung jawab untuk kode. Tim harus memilikinya, dan jangan lupakan poin penting ini.
Kesalahpahaman Keenam: “Seseorang Akan Menjatuhkan 7000 Baris pada Anda” #
Every now and then there will be a sufficiently motivated coworker who’s really great and do like a 7,000 line update no explanation but don’t ever fall into this idea that choosing anything for an internal app that you are going to be working on
Memiliki pull request 7000 baris tiba-tiba muncul itu sendiri adalah kegagalan untuk memperkenalkan budaya InnerSource - ini bukan sesuatu yang terjadi dengan melakukan InnerSource. Kasus ini mungkin khawatir bahwa memperkenalkan InnerSource membuat kolaborasi seperti itu terjadi, tetapi itu benar-benar salah.
Masalah Sebenarnya #
Argumen ini mewakili kegagalan mengimplementasikan budaya InnerSource dan praktik kolaboratif, bukan InnerSource itu sendiri. Implementasi 7000 baris adalah kasus yang sangat terbatas. Ini mewakili kegagalan budaya kolaborasi di mana 7000 baris diajukan sebagai pull request tiba-tiba tanpa pemberitahuan apa pun - organisasi harus memperbaiki masalah budaya fundamental ini, yang merupakan pra-InnerSource.
Jika Anda ingin mencegah ini, ada solusinya. Kembangkan budaya InnerSource dalam organisasi Anda:)
Realitas: Apa Sebenarnya InnerSource #
InnerSource adalah implementasi budaya - menggunakan praktik kolaborasi open source untuk menikmati berbagai manfaat yang diterima open source melalui kolaborasi. Tujuan utama InnerSource bukan hanya menerima kontribusi (pull request), tetapi termasuk permintaan fitur melalui masalah, koordinasi dukungan, dan berbagai manfaat lainnya, plus transparansi dalam pengambilan keputusan dan promosi budaya praktis.
Oleh karena itu, saya secara definitif menolak klaim bahwa “mengimplementasikan praktik terbaik InnerSource untuk mendapatkan pull request adalah kebohongan.”
Memahami Realitas Kontribusi #
“Nobody ever is going to contribute”
Dalam kolaborasi open source, kontributor memang merupakan fraksi kecil. Dari 1000 pengguna, mungkin sebagian besar hanya pengguna, 20 mungkin mengirimkan masalah atau permintaan fitur, 5 mungkin mengirim pull request, dan mungkin hanya satu yang menjadi maintainer.
Sekali lagi, praktik terbaik InnerSource tidak akan membuat semua 1000 orang berkontribusi. InnerSource membantu mendorong kolaborasi seperti itu, tetapi pada akhirnya bertujuan untuk memecah silo enterprise, meningkatkan kolaborasi yang terhambat oleh kendala organisasi tradisional, mengurangi waktu tunggu dari silo informasi, dan mengoptimalkan alokasi sumber daya organisasi menggunakan praktik open source.
Kesimpulan #
Meskipun argumen dalam kasus ini menyentuh beberapa tantangan nyata, mereka didasarkan pada kesalahpahaman umum yang banyak orang temui ketika pertama kali belajar tentang InnerSource. Ini adalah jebakan yang terkenal dalam komunitas, dan dapat dimengerti bagaimana seseorang mungkin mencapai kesimpulan ini tanpa eksplorasi yang lebih dalam tentang bidang ini.
Wawasan kunci adalah bahwa InnerSource bukan tentang memaksa praktik open source ke dalam kerangka yang kaku. Sebaliknya, ini tentang kembali ke pertanyaan fundamental: apa yang bisa kita pelajari dari open source? Dengan memeriksa open source melalui lensa yang lebih luas, kita dapat lebih baik mengadaptasi prinsip-prinsip ini secara internal.
Anda dapat bergabung dalam percakapan ini dan membawa perspektif segar. Apakah Anda ingin membangun diskusi ini, menjelajahi detail implementasi yang lebih spesifik, atau bahkan menantang argumen ini sepenuhnya - semua pendekatan diterima. Yang paling penting adalah mempertahankan perspektif luas tentang pembelajaran open source dan bagaimana mereka diterjemahkan ke konteks organisasi internal.
Untuk informasi komprehensif tentang InnerSource, saya merekomendasikan untuk memeriksa InnerSource Commons Foundation. Mereka menyambut sudut pandang yang beragam dan dialog berkelanjutan tentang bagaimana prinsip-prinsip open source dapat menciptakan nilai dalam organisasi.
