InnerSource Bir Yalan - Yaygın Yanlış Anlamalara Bir Yanıt
YouTube’da “InnerSource” aradığınızda, karşılaşacağınız ilk sonuçlardan biri muhtemelen “InnerSource bir yalan” iddia eden bir video olacaktır.
(bağlantı: https://youtube.com/shorts/53jEP3mPP3E)
Bu bakış açısı, birçok insanın InnerSource hakkında ilk öğrendiklerinde düştükleri tipik bir tuzağı temsil ediyor.
Bu videoyu, ne tür yanıltıcı sonuçları teşvik ettiğini açıklamak için bir vaka çalışması olarak kullanmak istiyorum. Bu, geçmişte benim de yaptığım bir hata ve bu alanı derinlemesine keşfetmemiş birçok insanın kolayca düşebileceği bir tuzak. Bu yüzden bunu öz eleştiri ile incelemek ve bu tuzakları çözerek başkalarının doğru yolu bulmasına yardımcı olmak istiyorum.
Birinci Yanlış Anlama: “Başkaları Katkıda Bulunabilsin Diye React Kullan” #
Önce bu vakadaki argümanı açıklayayım. Video, dahili uygulamalar için React kullanmayı öneriyor “React kullan çünkü diğer insanlar ona katkıda bulunabilir.” Bu tür bir mantık yürütme, gerçek InnerSource tartışmalarında nadiren duyulur.
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
Bu argüman üç temel soruna ayrılabilir:
- InnerSource’un gerçekte ne anlama geldiğine dair temel yanlış anlama
- InnerSource uygulaması için yanlış alan seçimi
- Bireysel ve takım perspektiflerini karıştırma
InnerSource Gerçekte Ne Anlama Geliyor #
InnerSource, açık kaynak ilkelerini bir şirket içinde uygulamakla ilgilidir. Bu sadece “katkıda bulunma” veya “katkı alma” ile ilgili değildir.
Açık kaynak ile etkileşime giren çoğu insan sadece “kullanıcı"dır. Bazıları sadece tüketici, diğerleri hata raporları dosyalar ve sadece küçük bir kesim gerçekten pull request gönderir. InnerSource, açık kaynak öğrenimlerini dahili olarak uygulayarak açık, geniş çapta erişilebilir, şeffaf karar verme süreçli ve sahiplik ve mentorluk yoluyla güven üzerine kurulu takım ilişkilerine sahip organizasyonlar yaratır. Bu, şeffaflık ve işbirliği kültürü oluşturur.
“Açık kaynağı dahili olarak uygulamak” budur - bu sadece “pull request almak” ile ilgili değildir. Pull requestler bu kültürün sadece bir sonucudur, birincil hedef değil.
InnerSource Uygulaması İçin Daha Az Optimal Bir Alan #
İkinci sorun, bu argümanın InnerSource ve açık kaynağın özel zorluklarla karşılaştığı bir alanda gelişmesidir.
“Pull request almak” veya “birçok insanın kodunuzu kullanarak kaliteyi artırmasını” istiyorsanız, bu ürününüzün doğası tarafından sınırlanabilir. “Yüksek bağımlılık bileşenlerini” veya platform düzeyindeki araçları paylaşmanın, son kullanıcı uygulamalarından daha fazla değer yaratacağı açıktır. Akış odaklı takımlar faydalı olduğunda açık kaynak uygulamalarını benimserken, işbirliği dinamikleri önemli ölçüde farklıdır.
Kurumsal şirketlerle çalışma deneyimime göre, son kullanıcıların “mühendis olmayan” kişiler olduğu proje düzeyindeki girişimler için InnerSource kullanmak benzersiz zorluklar sunar. Neden? Çünkü nihayetinde, bu ürünlerin geliştirme becerileri ve geliştirme takımlarıyla doğrudan iletişim kanalları olmayabilecek “son kullanıcıların” veya “iş kullanıcılarının” ihtiyaçlarına hizmet etmesi gerekir. Bu, karmaşık, bireyselleştirilmiş gereksinimler ve daha uzun iletişim süresi yaratır.
InnerSource uygulamaları, paylaşılan kütüphaneler, platform bileşenleri, geliştirme araçları ve altyapı koduna uygulandığında nispeten iyi çalışma eğilimindedir - “kullanıcıların” öncelikle işbirlikçi geliştirme uygulamalarına anlamlı katkıda bulunabilecek ve bundan faydalanabilecek diğer geliştiriciler olduğu alanlarda.
InnerSource uygulamalarını kullanıcı odaklı uygulamalara uygulamak şeffaflık ve geliştirilmiş sorun takibi gibi değerli faydalar getirebilir (bu tek başına buna değer kılar).
Bireysel ve Takım Perspektifi #
Üçüncü sorun, “sen"in bir bireyi mi yoksa bir takımı mı ifade ettiğiyle ilgilidir.
InnerSource’un mutlaka bir şirket içinde “kişisel projenize” birinin katkıda bulunmasını beklemekle ilgili olmadığını belirtmek önemlidir. InnerSource uygulandığında, büyük teknoloji firmalarındaki %20 zaman gibi, insanların %20 zaman boyunca geliştirilen projelere katkıda bulunduğu durumlar olabilir, ancak bu mutlaka ana akım yaklaşım değildir.
InnerSource öncelikle maliyet azaltma, tekerleği yeniden icat etmekten kaçınma, sinerji yaratma, kalite güvencesi ve hiyerarşik karar vermeden kaynaklanan iletişim yükünü kaldırma yoluyla ROI ürettiği için tanıtılır ve sürdürülür. Bu tipik olarak paylaşılan dahili kütüphaneleri, tescilli rekabet avantajı bileşenlerini veya kurumsal içinde niş olan yüksek bağımlılıklı şeyleri içerir. Ve bu “iş faydaları” tipik olarak çoğu durumda “takım operasyonlarına” geri döner. Nihayetinde, takımlar ve organizasyonlar için ROI ile ilgilidir. Takımları düşünmezsek, birisi projelere katkıda bulunmanızı engelleyecektir. Kısa vadeli veya uzun vadeli olsun ROI’nizi haklı çıkarmanız gerekir.
InnerSource’un benzersiz yanı, temelde takımdan takıma işbirliği ile ilgili olmasıdır. Çoğu uygulama nihayetinde buraya varır. Bu mutlaka bireylerin rastgele uygun kişisel projelere katkıda bulunması değildir. Tipik olarak ev sahibi takım ve misafir takım ilişkileri aracılığıyla uygulanır, burada misafir takımlar ev sahibi takımlar tarafından sürdürülen parçalarla birlikte hareket eder. Çoğu kuruluşun tanımlanmış rol ve sorumluluklara sahip çalışanları vardır ve işbirliği bu yapılar içinde gerçekleşme eğilimindedir.
Bu nedenle, InnerSource özellikle platform takımları ve akış odaklı takımlar (misafir takımlar ve ev sahibi takımlar) arasında ilişkiler kurulduğunda etkilidir. Akış odaklı takımlar arasında veya bireyler arasında aktif ortak yaratım daha belirsizdir ve doğal olarak başarılı olma olasılığı daha düşüktür.
Çalışma olasılığı düşük senaryolara dayanarak tüm InnerSource’u eleştirmek mantıklı değildir.
İkinci Yanlış Anlama: “Bu Gerçek Şirketlerde Asla Olmaz” #
because we want people doing that the reality is that’s not what’s going to happen ever at any company ever inner source
Aslında, bu oluyor. Vaka çalışmaları bunu kanıtlıyor. Nokta.
Üçüncü Yanlış Anlama: “InnerSource Projelerinin %99.69’u Başarısız Olacak” #
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
Bu, “InnerSource"u nasıl tanımladığınıza bağlı olarak doğru olabilir. Daha önce belirtildiği gibi, InnerSource “PR katkıları almak” ile ilgili değildir.
Ancak, dikkate alınması gereken üç önemli nokta vardır:
- InnerSource özellikle stratejik bileşenler için geçerlidir - tüm bileşenler için gerekli değildir
- Faydalar aktif katkıların ötesine uzanır
- Açık kaynağın da aynı “başarısızlık oranı” sorunu vardır
InnerSource Bir Kurumsal Stratejidir #
İnsanlar InnerSource hakkında düşündüklerinde, bazen “kuruluş içindeki tüm kodu paylaşmak” veya “herkesin her şeye katkıda bulunması” gibi radikal fikirler hayal ederler. Bir şirket içinde yüzlerce paylaşılan depo ile herkesin aktif olarak katkı alışverişinde bulunduğunu hayal edebilirler. Açık kaynağın şirketler için bir strateji olması gibi, InnerSource da öncelikleri olan bir kurumsal stratejidir. Şirketler önce “paylaşmaya değer olanı” paylaşır.
Bu nedenle, takımlar arasında kodun aktif olarak aktığı ve canlı çapraz takım işbirliğinin gerçekleştiği kod tabanlarının gerçek sayısı nispeten azdır. Bu gerçekten tek haneli yüzdeler olabilir. Ancak, aktif çapraz takım işbirliği olmasa bile, birçok proje açık ve şeffaf olmaktan faydalanabilir. InnerSource’un bu anlamında, kuruluşlar genellikle çok daha fazla vakada değer paylaşabilir.
InnerSource bireysel katkıları içerse de, öncelikle takımdan takıma işbirliğine odaklanır. Bu nedenle, InnerSource aracılığıyla paylaşılan şeyler kuruluşlar içinde nispeten niş olma eğilimindedir, veya belirli ihtiyaçlar için çatallanmış Linux dağıtımları gibi amaca özel öğeler olabilir. Ya da GitHub’ın tüm çalışanlar arasında Ruby on Rails kodunu paylaştığı gibi, sadece açık kaynak benzeri geliştirme kültürü olabilir.
Bu yüzde tartışmasını aktif olarak işbirliği yapan ve ortak gereksinimler olarak sürdürülen InnerSource üzerinde koşullandırdığımızda, yüzde gerçekten nispeten düşük olabilir. Ancak, misafir takımlar ve platform/ev sahibi takımlar arasında dokümantasyon pull requestleri veya küçük konfigürasyon değişiklikleri (küçük yamalar gönderme) gibi küçük işbirlikleri nispeten sık gerçekleşir. Bu mikro işbirliklerini ve yinelenen çabaları önleyen şeffaflık faydalarını dahil ettiğinizde, bu sayılar önemli ölçüde artar.
Açık Kaynağın Aynı “Sorunu” Vardır #
Öte yandan, bu şekilde tanımlarsak, açık kaynak da bir “yalan” olurdu. Çünkü “açık kaynak projelerinin %99.69’u başarısız olacak.” Açık kaynak olarak yayınlanan kodların çoğu katkı almaz. Ancak kimse bundan dolayı “açık kaynak bir yalan” demez. İnsanlar açık kaynağı takip ederler çünkü katkı almanın ötesinde faydalar vardır.
Yine, “katkı alınması” InnerSource’un tek değeri değildir. Ve aynı şey açık kaynak değeri için de geçerlidir.
Şeffaflığın Gerçek Faydaları #
Dahili kodu gizli tutmak yerine açık tutmak - GitHub’da, gelir ekibindeki mimarlar veya çözüm mühendisleri ilgili bilgileri bulmak için kaynak kodunu inceleyebilir, potansiyel olarak müşteri isteklerine çok yakın ayrıntılar bulabilir, daha sorunsuz destek konuşmaları kolaylaştırabilir ve sorunlardan daha doğru bilgi çıkarabilir. Tokyo’da yaşıyorum ve bazen değişikliklerin uygulanmasını kontrol etmek için Ruby koduna bakmak veya değişikliklerin geçmişini kontrol etmek için sorunlara gitmek, değişiklikler ve geçmişleri hakkında uygulama sorularını sormak için SF merkezli ürün ekibinin uyanmasını beklemekten daha hızlıdır.
git blame komutunu kullanarak, kodun “gerçek” paydaşlarını belirleyebilir ve kararların geçmişi hakkında sorular sorabilirsiniz.
Tabii ki, aynı şey diğer geliştirme takımları için de geçerlidir. Bağımlılık yaratabilecek bileşenler hakkında hazır bilgiye sahip olmak açıkça iletişim yükünü azaltır.
InnerSource, açık kaynak ilkelerini dahili olarak uygulamakla ilgilidir. InnerSource sadece pull requestleri ileri geri göndermekle ilgili değildir - şeffaflığı sağlamak ve açık kaynak tarzı işbirliği yoluyla fayda sağlamakla ilgilidir. Bu faydalar, aktif olarak sürdürülen depoların birkaç yüzdesinin çok ötesine, daha geniş kültürel uygulama faydalarına uzanır.
Dördüncü Yanlış Anlama: “Ayrıldığınızda Geri Çağrılacaksınız” #
“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”
Kaynaklar bazen sürdürülmez, ancak bu InnerSource’un kendisine yönelik uygun bir eleştiri değildir - bu, InnerSource’u düzgün uygulayamamanın eleştirisidir. Bu InnerSource’un eleştirisi değil, kimsenin kodu sürdürmediği sürdürme kültürünün eksikliğinin eleştirisidir. Bu, InnerSource’u düzgün uygulayamamanın veya hiç düşünmemenin sonucudur - sahiplik eksikliğinin sonucu.
DevOps Benzetmesi #
Bu InnerSource yapmayı başaramamanın eleştirisidir, InnerSource’un kendisinin eleştirisi değil. Bazen bu mantığı karıştırır. Bunu DevOps terimleriyle ifade etmek gerekirse: “şirketler sonunda birkaç aylık yavaş inceleme döngüleri veya denetimler benimsiyor, veya sürüm kararları için süreçler ekliyor, bu yüzden sürümler üç aylık veya yılda sadece iki kez oluyor. Bu nedenle hızlı sürümler sağladığını iddia eden DevOps iyi değil” demek gibi. Bu DevOps metodolojisinin kötü olmasından değil, sadece “DevOps’un uygulanamadığı durumlar olmasından” kaynaklanır.
İş süreçlerini kırmak son derece zordur ve birçok şirket DevOps’un imkansız olduğunu söyledi. Ancak insanlar bunun imkansız olduğunu düşündüklerinde bile, kültürü değiştirmek için çok çalışan ve DevOps’u başaran cesur öncüler vardı. Aynı şey InnerSource ile de olabilir.
Beşinci Yanlış Anlama: “Her Şeyin %100’üne Sahip Olmalısınız” #
you own it 100% (ima ediyor ki: %100 sahip olmadığınız InnerSource imkansızdır)
“InnerSource kod sahipliğini terk etmek anlamına gelir” yanlıştır. InnerSource aslında takımların koda sahip olmasını gerektirir. Bu yaygın bir hatadır. Bu, bakım sorumluluğunu terk etmek isteyen ve “açık kaynak yapalım” diyen insanlar gibidir. Bu işe yaramaz.
Bireysel ve Takım Sahipliği - InnerSource Güçlü Kod Sahipliği midir? #
Öncelikle, bu “Sen” tekil mi çoğul mu? Organizasyonlarda bireyler CODEOWNERS dosyasında listelenebilse de, takımlar nihayetinde kod için sorumluluk taşır. Bağlamsal olarak, muhtemelen Güçlü Kod Sahipliği’nden bahsediyor. Ancak bu, organizasyonel bakım düşünüldüğünde iyi değildir. Çünkü çalışanlar işten ayrılabilir.
InnerSource Güçlü Kod Sahipliği değildir. En azından, birden fazla kişinin sorumluluğu paylaşması gerekir. Bununla birlikte, Güçlü Kod Sahipliği’nin kısa vadede ortaya çıkabileceğini ve bir projenin erken aşamalarında güçlü bireysel iradenin doğal olarak bu tür düzenlemelere yol açabileceğini kabul ediyorum, ancak uzun vadeli başarı elde etmek istiyorsanız, organizasyonun bakımı toplu olarak ele alabilmesi için yetkiyi devretmek gereklidir.
Takım Sahipliği Türleri - InnerSource Kolektif Kod Sahipliği midir? #
Bu tür argümanlar bazen Kolektif Sahiplik’e atıfta bulunabilir. Bu durumda, argüman ayrıca InnerSource’un kolektif sahiplik anlamına geldiğini öne sürüyor gibi görünüyor, ancak bu aslında farklı. InnerSource Kolektif Kod Sahipliği değildir InnerSource ev sahibi takımların nihayetinde bakımı ele almasını içerir. InnerSource Zayıf Kod Sahipliği’dir. Yani bakım sorumluluğu %100 doğru olsa da, “%100 sahip olmalısınız ve InnerSource farklıdır” demek tamamen mantıksızdır. Bu aslında yanlış bir görüştür.
Martin Fowler’ın kod sahipliği hakkında ünlü argümanında belirttiği gibi, herkesin koda %100 sahip olması (kolektif sahiplik) bazen kimsenin sorumluluk almadığı durumlar yaratır. Bu çok sorunludur - sorumluluk belirsiz hale gelir ve projeler nihayetinde başarısız olur.
Zayıf Kod Sahipliği Modeli #
Zayıf Kod Sahipliği’nde, bakımcılar mevcuttur, ev sahibi takımlar projeleri sürdürür ve belirli kısımlar diğer takımlardan güvenilir committer/bakımcılar getirebilir. Birisi katkıda bulunabilir, birisi bakım yapabilir, ancak “sen” veya “takımın” tarafından %100 değil - oldukça farklı olabilir. Örneğin, kodun %98’i takımınıza ait olabilirken, %2’si diğer takımlara ait olabilir.
Bu durumda, organizasyonlarda bireyler kod sahipleri olarak atanmış olsa bile, takımların nihayetinde kod için sorumluluk taşıdığını unutmayın. Takımlar sahip olmalı ve bu önemli noktayı unutmayın.
Altıncı Yanlış Anlama: “Birisi Size 7000 Satır Bırakacak” #
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
7000 satırlık pull requestlerin aniden ortaya çıkması, InnerSource kültürünü tanıtmayı başaramamanın kendisidir - bu InnerSource yaparak olan bir şey değildir. Bu vaka, InnerSource’u tanıtmanın bu tür işbirliğinin gerçekleşmesini sağladığından endişe edebilir, ancak bu tamamen yanlıştır.
Gerçek Sorun #
Bu argüman InnerSource kültürünü ve işbirlikçi uygulamaları uygulayamamayı temsil eder, InnerSource’un kendisini değil. 7000 satırlık uygulamalar çok sınırlı durumlardır. Bu, 7000 satırın herhangi bir bildirim olmadan aniden pull request olarak gönderildiği işbirliği kültürünün başarısızlığını temsil eder - organizasyon bu temel kültür sorununu düzeltmeli, bu InnerSource öncesi bir sorundur.
Bunu önlemek istiyorsanız, bir çözüm var. Organizasyonunuzda InnerSource kültürünü geliştirin :)
Gerçek: InnerSource Gerçekte Nedir #
InnerSource kültürel uygulamadır - işbirliği yoluyla açık kaynağın aldığı çeşitli faydalardan yararlanmak için açık kaynak işbirliği uygulamalarını kullanmak. InnerSource’un nihai amacı sadece katkı almak (pull requestler) değil, aynı zamanda sorunlar aracılığıyla özellik istekleri, destek koordinasyonu ve çeşitli diğer faydalar, artı karar vermede şeffaflık ve pratik kültürel teşviki içerir.
Bu nedenle, “pull request almak için InnerSource en iyi uygulamalarını uygulamanın bir yalan olduğu” iddiasını kesinlikle reddediyorum.
Katkı Gerçekliğini Anlama #
“Kimse asla katkıda bulunmayacak”
Açık kaynak işbirliğinde, katkıda bulunanlar gerçekten küçük bir kesimdir. 1000 kullanıcıdan, belki büyük çoğunluğu sadece kullanıcıdır, 20’si sorun veya özellik istekleri gönderebilir, 5’i pull request gönderebilir ve belki sadece biri bakımcı olur.
Yine, InnerSource en iyi uygulamaları tüm 1000 kişinin katkıda bulunmasını sağlamayacaktır. InnerSource bu tür işbirliğini teşvik etmeye yardımcı olur, ancak nihayetde kurumsal siloları kırmayı, geleneksel organizasyonel kısıtlamalar tarafından engellenen işbirliğini geliştirmeyi, bilgi silolarından kaynaklanan teslim sürelerini azaltmayı ve açık kaynak uygulamalarını kullanarak organizasyonel kaynak tahsisini optimize etmeyi amaçlar.
Sonuç #
Bu vakadaki argümanlar bazı gerçek zorluklara değinse de, birçok insanın InnerSource hakkında ilk öğrendiklerinde karşılaştıkları yaygın yanlış anlamalara dayanıyor. Bunlar toplulukta iyi bilinen tuzaklardır ve birinin bu alanı daha derinlemesine keşfetmeden bu sonuçlara nasıl varabileceğini anlamak mümkündür.
Temel anlayış, InnerSource’un açık kaynak uygulamalarını katı bir çerçeveye zorlamakla ilgili olmadığıdır. Bunun yerine, temel soruya dönmekle ilgilidir: açık kaynaktan ne öğrenebiliriz? Açık kaynağı daha geniş bir lens aracılığıyla inceleyerek, bu ilkeleri dahili olarak daha iyi adapte edebiliriz.
Bu konuşmaya katılabilir ve yeni bakış açıları getirebilirsiniz. Bu tartışmayı geliştirmek, daha spesifik uygulama ayrıntılarını keşfetmek, hatta bu argümanları tamamen sorgulamak istiyorsanız - tüm yaklaşımlar hoş karşılanır. En önemli olan, açık kaynak öğrenimleri ve bunların dahili organizasyonel bağlamlara nasıl çevrildiği konusunda geniş perspektifi korumaktır.
InnerSource hakkında kapsamlı bilgi için, InnerSource Commons Foundation’ı kontrol etmenizi öneririm. Çeşitli bakış açılarını ve açık kaynak ilkelerinin organizasyonlar içinde nasıl değer yaratabileceği konusundaki devam eden diyalogu memnuniyetle karşılıyorlar.
