InnerSource terimini anlamıyorsanız yalnız değilsiniz. Yazarın arkadaşları arasında yaptığı bir anket, profesyonel yazılım geliştiricileri ve ürün yöneticileri de dahil olmak üzere açık kaynak konusunda onlarca yıllık deneyime sahip kişilerin bile en iyi ihtimalle kaba bir fikre sahip olduğunu ortaya çıkardı.
Duyuru
Dr. Rüdiger Berlich, 1992'den beri Açık Kaynak ile çalışıyor ve MBA programında ilgili iş modelleri konusunu ele aldı. Şirketlere açık kaynak ve iç kaynak konularında, çevik uygulamalar ve değişim yönetimi konularında danışmanlık yapmaktadır.
Terim yirmi yıldan fazla bir süre önce icat edildi. Tim O'Reilly Aralık 2000'de OpenGL ile açık kaynak arasındaki ilişki hakkında şunları yazdı: “İşbirlikleri [CollabNet war eine von O’Reilly mitgegründete Firma] Misyon, bir bütün olarak yazılım endüstrisi için açık kaynak tarzı işbirliğine dayalı geliştirmeyi mümkün kılmaktır. Tipik olarak bu, büyük şirketlerin açık kaynağa geçişine yardımcı olmayı içerir. Ama aynı zamanda şirketlerle 'iç kaynak kullanımı' dediğimiz, yani açık kaynak teknolojilerini şirket içinde kullanmalarına destek olmak konusunda da çalıştık.” Farkındalık eksikliği, kavramın büyük şirketler arasında daha yaygın olmasıyla açıklanabilir. Şirketler ve özel yazılım geliştirme bir rol oynamaktadır.
InnerSource'un boşluksuz yazılması, konseptin görünürlük eksikliğini iyileştirme girişiminden kaynaklanmaktadır. Danese Cooper ve Klaas-Jan Stol'un “Adopting InnerSource” kitabında şöyle bir açıklama var: “Terimin bulunmasını kolaylaştırmak için (eğer 'iç kaynak' aramaya çalışırsanız, yalnızca yazılıma referans vermeden sonuçları bulacaksınız) , merkezi alanı kaldırdık ve CamelCase notasyonunu tanıttık.” Bugün bu artık bir sorun değil: Hem Google hem de ChatGPT “İç Kaynak” için de uygun yanıtlar sağlıyor.
Açık kaynak konseptlerinin şirkete aktarılması
InnerSource birçok şirketteki temel bir sorunu ele alıyor: bilgi ve kaynaklar parçalanmış durumda. Olgun organizasyon yapılarında ekipler genellikle ayrı ayrı çalışır, bu da işin tekrarına, bilgi silolarına ve kaynakların verimsiz kullanımına yol açar. Büyük şirketlerde, geliştirme ekiplerinin bir özelliği kendilerinin yazması, kodu yalnızca yarısına sığabilen diğer ekiplerden talep etmek yerine genellikle daha kolaydır. Bu, karmaşıklıkları arttıkça pekiştirilmesi giderek zorlaşan paralel dünyalar yaratır.
InnerSource felsefesi bir alternatif sunuyor: Eric Raymond'un 1997 tarihli “Katedral ve Çarşı” makalesinde anlattığı “Erken yayınlayın ve müşterilerinizi dinleyin” açık kaynak ilkesini uyguluyor. İşletmelere uygulandığında, kodun kullanılabilir hale getirilmesi ve oluşturulduğu anda şirket içinde tanıtılması anlamına gelir. Katkıda bulunanlar yalnızca kendi akran grubunuzdan gelmemeli, ideal olarak departman sınırlarının ötesinden de gelmeli, ancak kendi kuruluşunuzla sınırlı olmalıdır. Bu, yeni oluşturulan siloların sayısının zamanında sınırlandırılmasına yardımcı olur ve aynı zamanda daha büyük bir kararlılıkla halihazırda başlamış projelerde de kullanılabilir.
Bu iç topluluk oluşturma başarılı olursa, yalnızca silolanmış çözümlerden kaçınmakla kalmaz, aynı zamanda şirket aynı zamanda Eric Raymond tarafından formüle edilen ikinci bir ilkeden de yararlanır: “Yeterince göz önüne alındığında, tüm hatalar yüzeyseldir”, aynı zamanda Linus Yasası olarak da bilinir. Kalite artar ve aynı zamanda geliştirme, kullanıcıların gerçek ihtiyaçlarına dayanır, bu da verimliliğin daha da artmasına yol açar.
Mercedes-Benz AG FOSS Manifestosu aşağıdakiler de dahil olmak üzere çeşitli ilkeleri açıklamaktadır:
Merkezi bir iletişim noktası olarak InnerSource Commons
Açık kaynak öncüsü Danish Cooper, InnerSource hakkındaki bilgileri toplamak ve yaymak amacıyla 2015 yılında şirketler arası, iyi organize edilmiş InnerSource Commons girişimini başlattı. Girişim merkezi bir merkez sağlıyor, platform hakkında kapsamlı bilgiler yayınlıyor ve InnerSource Kalıplarını sunuyor. InnerSource topluluklarını daha da oluşturmak ve işletmek için teknik bilgi sağlarlar. Platformda ilgilenen taraflar aynı zamanda ücretsiz kitaplar, vaka çalışmaları ve açık kaynakla karşılaştırmalar da bulabilirler. Girişim aynı zamanda 20 – 21 Kasım 2024 tarihleri arasında çevrimiçi olarak düzenlenen en son InnerSource Zirvesi gibi etkinlikler de düzenlemektedir. YouTube üzerinden ücretsiz olarak erişilebilen konferans yayınları da iyi bir bilgi kaynağıdır.
Girişim tarafından yayınlanan 2024 InnerSource Durumu Raporu, InnerSource girişimlerinin mantığı ve uygulamasına ilişkin niceliksel bir genel bakış sunuyor.
Konuyu aktif olarak ele alan SAP yayınlarında da pek çok bilgi bulunabilir. GitHub'daki SAP proje portalı, bahsedilen Commons şablonlarından biri için şablon görevi gördü. SAP Bulut Yerel Geliştiricisi Benjamin Ihrig, Zirve 2024'teki “SAP's Repository Linter” konuşmasının özetinde işvereninin kararlılığını şu şekilde açıklıyor: “Yazılım geliştirme sürecimizin önemli bir parçası: işbirliğini, yeniliği ve kodun verimli yeniden kullanımını teşvik etmek “
Duyuru
Dr. Rüdiger Berlich, 1992'den beri Açık Kaynak ile çalışıyor ve MBA programında ilgili iş modelleri konusunu ele aldı. Şirketlere açık kaynak ve iç kaynak konularında, çevik uygulamalar ve değişim yönetimi konularında danışmanlık yapmaktadır.
Terim yirmi yıldan fazla bir süre önce icat edildi. Tim O'Reilly Aralık 2000'de OpenGL ile açık kaynak arasındaki ilişki hakkında şunları yazdı: “İşbirlikleri [CollabNet war eine von O’Reilly mitgegründete Firma] Misyon, bir bütün olarak yazılım endüstrisi için açık kaynak tarzı işbirliğine dayalı geliştirmeyi mümkün kılmaktır. Tipik olarak bu, büyük şirketlerin açık kaynağa geçişine yardımcı olmayı içerir. Ama aynı zamanda şirketlerle 'iç kaynak kullanımı' dediğimiz, yani açık kaynak teknolojilerini şirket içinde kullanmalarına destek olmak konusunda da çalıştık.” Farkındalık eksikliği, kavramın büyük şirketler arasında daha yaygın olmasıyla açıklanabilir. Şirketler ve özel yazılım geliştirme bir rol oynamaktadır.
InnerSource'un boşluksuz yazılması, konseptin görünürlük eksikliğini iyileştirme girişiminden kaynaklanmaktadır. Danese Cooper ve Klaas-Jan Stol'un “Adopting InnerSource” kitabında şöyle bir açıklama var: “Terimin bulunmasını kolaylaştırmak için (eğer 'iç kaynak' aramaya çalışırsanız, yalnızca yazılıma referans vermeden sonuçları bulacaksınız) , merkezi alanı kaldırdık ve CamelCase notasyonunu tanıttık.” Bugün bu artık bir sorun değil: Hem Google hem de ChatGPT “İç Kaynak” için de uygun yanıtlar sağlıyor.
Açık kaynak konseptlerinin şirkete aktarılması
InnerSource birçok şirketteki temel bir sorunu ele alıyor: bilgi ve kaynaklar parçalanmış durumda. Olgun organizasyon yapılarında ekipler genellikle ayrı ayrı çalışır, bu da işin tekrarına, bilgi silolarına ve kaynakların verimsiz kullanımına yol açar. Büyük şirketlerde, geliştirme ekiplerinin bir özelliği kendilerinin yazması, kodu yalnızca yarısına sığabilen diğer ekiplerden talep etmek yerine genellikle daha kolaydır. Bu, karmaşıklıkları arttıkça pekiştirilmesi giderek zorlaşan paralel dünyalar yaratır.
InnerSource felsefesi bir alternatif sunuyor: Eric Raymond'un 1997 tarihli “Katedral ve Çarşı” makalesinde anlattığı “Erken yayınlayın ve müşterilerinizi dinleyin” açık kaynak ilkesini uyguluyor. İşletmelere uygulandığında, kodun kullanılabilir hale getirilmesi ve oluşturulduğu anda şirket içinde tanıtılması anlamına gelir. Katkıda bulunanlar yalnızca kendi akran grubunuzdan gelmemeli, ideal olarak departman sınırlarının ötesinden de gelmeli, ancak kendi kuruluşunuzla sınırlı olmalıdır. Bu, yeni oluşturulan siloların sayısının zamanında sınırlandırılmasına yardımcı olur ve aynı zamanda daha büyük bir kararlılıkla halihazırda başlamış projelerde de kullanılabilir.
Bu iç topluluk oluşturma başarılı olursa, yalnızca silolanmış çözümlerden kaçınmakla kalmaz, aynı zamanda şirket aynı zamanda Eric Raymond tarafından formüle edilen ikinci bir ilkeden de yararlanır: “Yeterince göz önüne alındığında, tüm hatalar yüzeyseldir”, aynı zamanda Linus Yasası olarak da bilinir. Kalite artar ve aynı zamanda geliştirme, kullanıcıların gerçek ihtiyaçlarına dayanır, bu da verimliliğin daha da artmasına yol açar.
Mercedes-Benz AG FOSS Manifestosu aşağıdakiler de dahil olmak üzere çeşitli ilkeleri açıklamaktadır:
- Geliştiriciler, kodu kendileri geliştirmeden veya satın almadan önce öncelikle uygun açık kaynak veya dahili alternatifleri araştırmalıdır.
- Geliştiriciler InnerSource topluluğuna dahil olmalı ve projelere katkıda bulunmalıdır.
Merkezi bir iletişim noktası olarak InnerSource Commons
Açık kaynak öncüsü Danish Cooper, InnerSource hakkındaki bilgileri toplamak ve yaymak amacıyla 2015 yılında şirketler arası, iyi organize edilmiş InnerSource Commons girişimini başlattı. Girişim merkezi bir merkez sağlıyor, platform hakkında kapsamlı bilgiler yayınlıyor ve InnerSource Kalıplarını sunuyor. InnerSource topluluklarını daha da oluşturmak ve işletmek için teknik bilgi sağlarlar. Platformda ilgilenen taraflar aynı zamanda ücretsiz kitaplar, vaka çalışmaları ve açık kaynakla karşılaştırmalar da bulabilirler. Girişim aynı zamanda 20 – 21 Kasım 2024 tarihleri arasında çevrimiçi olarak düzenlenen en son InnerSource Zirvesi gibi etkinlikler de düzenlemektedir. YouTube üzerinden ücretsiz olarak erişilebilen konferans yayınları da iyi bir bilgi kaynağıdır.
Girişim tarafından yayınlanan 2024 InnerSource Durumu Raporu, InnerSource girişimlerinin mantığı ve uygulamasına ilişkin niceliksel bir genel bakış sunuyor.
Konuyu aktif olarak ele alan SAP yayınlarında da pek çok bilgi bulunabilir. GitHub'daki SAP proje portalı, bahsedilen Commons şablonlarından biri için şablon görevi gördü. SAP Bulut Yerel Geliştiricisi Benjamin Ihrig, Zirve 2024'teki “SAP's Repository Linter” konuşmasının özetinde işvereninin kararlılığını şu şekilde açıklıyor: “Yazılım geliştirme sürecimizin önemli bir parçası: işbirliğini, yeniliği ve kodun verimli yeniden kullanımını teşvik etmek “