Yazılımın “kullanılabilir kaynak” olması, “açık kaynak” olmaması sizin için önemli mi?

Muhtemelen OSI tarafından resmi olarak onaylanan açık kaynak lisanslarının listesini biliyorsunuzdur. En önemlisi, GPL, MIT, [en sevdiğiniz lisansı buraya ekleyin].

Son zamanlarda açık kaynak olmasına rağmen (içerik oluşturucu tüm kaynak kodunu kullanılabilir hale getirdi), bu resmi lisanslardan biri altında resmi olarak açık kaynak olmayan bir projeyle karşılaştım.

• Kaynağı serbest bıraktı, ancak gelecekte kaynağı serbest bırakmaya söz vermedi.

• Değişiklik önerilerine izin verdi, ancak harici yamalı sürümlerin yamaları ve harici dağıtımına izin verilmesini kabul etme sözü vermedi.

• Yazılımın ticari veya ücretli projelerde kullanılmasına izin verdi, ancak yazılımın satışına izin verilmedi.

Düşünmek istediğimiz gibi "açık kaynak" olarak adlandırılabilir diye düşünüyorum.

Bir şirketin yönetim ekibinin neden bu yazılımla iş yapmak istemediğini görebiliyorum. Çatamazlar, satamazlar, yazılımın kendi versiyonlarını oluşturamazlar, dağıtamazlar ya da satamazlar.

Ama bu yazılımı sadece kullanan bir yazılım mühendisliği ekibinin parçası olarak sizin için önemli mi? Çalışmamı hala bununla halledebilirim, ödeme yaptığım bir projede kullanabilirim (ancak yine de yapma işinde olmadığım yazılımı kendisi satamıyorum) ve yapabilirim kodlarımı ihtiyaçlarım için farklı davranması için kodda değişiklikler yapıyorum (ancak bu değişiklikleri herkese açık hale getiremiyorum) ve bu değişikliklerin resmi olarak başkalarına sunulmasını istiyorsanız, onay projenin kendisine bağlıdır ve resmi bir sürüme dahil edip etmemek.

İşini bu "mevcut kaynak" yazılıma dayandırmak isteyen bir şirketin bunu yapamayacağını biliyoruz, ancak yazılım mühendisliği ekibinden biri olarak bu farklılıklar sizin için önemli mi yoksa daha az alakalı görünüyor mu?

Başkalarının bunun hakkında ne düşündüğünü merak ediyorum.

Bu yazılım tarafından sağlanan işlevselliği sıfırdan geliştirmek zorunda kalacak projeler için, bunu yapmamak kesinlikle kolaylıktır.

Ancak karşılaştırılabilir bir açık kaynak paketinin daha iyi olup olmayacağı diğer faktörlere bağlıdır:

• bir hizmet sunmak veya başka bir ürünün parçası olarak paketlemek için kullanılacak mı?
• ürünü bağımsız olarak geliştirmek ve bakımını yapmak için kaynakları var mı?
• Bu yazılımı açık kaynaklı sürümde (kodda veya proje yönetiminde) kullanmanın rekabet avantajı var mı?

Bu faktörlerden herhangi birine hayır cevabını vermek OSS'nin daha iyi bir seçim olduğunu gösterir.

Çoğu zaman, kodun kendisi belirleyici faktör değildir. Büyük resmi incelemek gerekiyor.

SIDEBAR OSS projeleri yasal olarak gelecekteki sürümleri açık tutacağına ya da gelecekteki sürümler olacağına söz veremez . Açık lisansa sahip olmanın bu kadar avantajlı olmasının bir nedeni de budur. Ayrıca, OSS projelerinin katkıda bulunanların yamalarını kabul etmesi gerekmez (özellikle mülkiyet veya hak transferi olmadan).

Bu ve diğer herhangi bir harici kütüphane için soru bakımdır .

Başvurunuzun ömrü nedir ve bu kütüphanenin görünen ömrü nedir? Seninki umarım en kısa olmalı.

Bu kütüphane için kim hata düzeltmeleri yapacak? Buradan göründüğü gibi, sizin için başka herhangi bir düzeltme hatasına güvenemeyeceğiniz için şirketiniz gelecekte bu yazılımı korumak için açıkça kaynak tahsis etmelidir. Kaynağı yükleyemediğiniz için bakım yükünü başkasıyla paylaşamazsınız. Bilmediğiniz kodda zor bir yarış koşulu hatasını avlamak ister misiniz?

Bu düşünce tek başına kütüphaneyi kullanmak için çok pahalı olabilir.

Kütüphane çok sağlam ve sağlam ve kaynak düzeyinde çalışması kolaysa bu ilgisiz olabilir, ancak benim deneyimim, gerçek açık kaynak projelerinin akran baskısının kodu daha iyi hale getirmesidir, çünkü o zaman en iyisini yapma eğilimindesiniz.

Şahsen ben bu ya da başka bir dış kodu kabul edip edemeyeceğim konusunda çok dikkatli düşünürdüm, çünkü diğer insanların kodunu kullanmanın tüm nedeni kendinizle uğraşmak zorunda kalmamanızdır . Ayrıca gelecekteki bakıcıları da düşünün - kütüphanede kod değiştirerek yangın matkapları yapmalısınız. Burada ÇOK kötü sürprizler olabilir.

Söz konusu kütüphaneyi tartışma özgürlüğünüz var mı?

Dürüst olmak gerekirse, bir şirketin yönetim ekibinin böyle bir "mevcut kaynak" kütüphanesini kullanmada neden sorun yaşayacağını anlamıyorum. Kendi ürünlerine entegrasyon söz konusu olduğunda, bunu sadece kapalı kaynaklı bir kütüphane olarak görebilirler.

Benim için, bir programcı olarak, bir kütüphanenin "açık kaynak" veya "kullanılabilir kaynak" olması önemli değildir. Harici bir kütüphanede yerel değişiklikler yapmamayı tercih ediyorum, çünkü bu ek bakım yükü anlamına geliyor. Yalnızca yerel değişikliklerimde hatalar bulunduğunda değil, aynı zamanda kütüphanenin yeni bir sürümü çıktığında değişiklikleri tekrar tekrar entegre etmede.

IMHO, "açık kaynak" ın soruda özetlenen "kullanılabilir kaynak" lisansını geçtiği tek durum,

• ürünümüzün lisansı, içerilen kütüphanelerin kaynaklarının açıklanmasını da gerektirir
• kütüphanenin gelişmiş / genişletilmiş bir versiyonunu üretme işindeyiz

Özgür Yazılım Vakfı'nın yazılımı tanımlamak için 'ücretsiz' veya 'özgür olmayan' terimlerini kullanmasının nedeni budur . Fiyattan değil, yazılımın kullanımına veya dağıtımına getirilen kısıtlamalardan bahsetmektedirler.

Görünüşe göre, bir şeyin kaynak koduna tam erişime sahip olduğunuz nadir köşe durumlarından birini vurdunuz, ancak yazılım OSI tanımı ile "Açık Kaynak" değil .

Her iki terimin de yanlış isim verme kapasitesi vardır. İlk emac kopyam için (QIC kaset üzerinde) 50 dolar ödedim, ancak emacs ücretsiz bir yazılımdır . Şirketimin dahili olarak kullandığı bazı özel uygulamaların kaynak koduna sahibim, ancak bunlar açık kaynak değil.

En büyük kırmızı bayrağı (en azından bana) yükselten şey, gelecekteki sürümlerin kaynak koduna erişimin garantisi değildir. Bu aracı büyük ölçüde değiştirebilmenize bağlıysanız, dikkatli olurum. Satıcı ile sözlü bir anlaşmanız olsa bile, sözleşme formunda olmadığı sürece her zaman kodunuz olacaktır .. bu anlaşma asla gerçekleşmedi.

CTO olarak, özgür olmayan yazılıma bağlı olmadığımızdan emin olmak için elimden geleni yapıyorum . Ben geçmişte birkaç kez satıcı kilidi kötü ucunda oldum, kaçınmak gibi bir hata. Bazı tescilli şeyler kullansak da, birdenbire artık kullanamazsak işimiz gereksiz zorluklara maruz kalmazdı.

Bana bu yazılım ve kod erişim etrafında şeyler inşa gibi geliyor, bu yüzden her zaman erişim olacak diyor yazılı bir şey almak tavsiye ederim . Tedarikçi satın alınırsa ne olur?

Bu biraz önemli. Açıkladığınız "mevcut kaynak" yaklaşımıyla ilgili temel sorunlar:

• Kaynağı değiştirme özgürlüğünüz yoksa teknolojik kaderinizin kontrolü sizde değildir. Genellikle kaynağı doğrudan kesmek dağınık bir geçici çözüm için tercih edilebilir.
• Yazılımın korunmaya devam edeceğine dair bir garantiniz yok ve gerçek açık kaynakla elde ettiğiniz kendiniz yapma seçeneğine sahip değilsiniz.
• Özel bir lisans gibi göründüğünden, GPL veya BSD lisansları gibi iyi bilinen ve kanıtlanmış bir şeyi kullanmaya kıyasla muhtemelen daha büyük yasal riskiniz vardır.
• Gerçek bir açık kaynak değilse, etrafında aynı düzeyde yararlı topluluk elde edemezsiniz, bu da birçok açık kaynak projesi için büyük bir avantajdır.

Benim önerim: yaratıcıyı yazılımı açık kaynak lisansı altında yayınlamaya ikna etmeye çalışın. Bu herkes için bir kazan / kazan olmalı - çünkü açık kaynaklı lisanslama altında istediğiniz yazılımı elde edersiniz, yaratıcısı, çünkü projeyi açık kaynak yapmak uzun vadede yazılımı çok daha başarılı hale getirecektir.