Bir Açık Kaynak projesinin bir üründe kullanılacak kadar olgun olup olmadığını nasıl anlarım?

İş yerinde bir ürüne dahil etmek istediğim bazı açık kaynaklı projeler var. Kendimiz için bant genişliğine veya konu uzmanlığına sahip değiliz. Bunları Google'da arayarak buldum. Projeleri kullanan herhangi bir "büyük oyuncunun" farkında değilim, ama gördüğüm şeyle oldukça cesaretlendirildim.

Şimdi, joe-blow'ın açık kaynaklı projesini kullanarak maruz kaldığım risk miktarından biraz endişeliyim. Beni yolun% 95'ine götürürse, belki de kalan% 5'in eklenmesi veya düzeltilmesi kolaydır. Belki de önemsiz değil.

İnsanlar bir açık kaynak projesinin bir üründe kullanmak için yeterince olgun olup olmadığını nasıl belirleyebilirler?

Bu bir hobi projesi değildir, bu nedenle istikrar, sürdürülebilirlik, vb.

Projenin gereksinimlerimi karşılaması koşuluyla, kullandığım kriterler:

1. İnsanların yardım sağlayabileceği aktif bir topluluk var mı?
2. Lisans gelişimime uygun mu?
3. Ürün hala aktif geliştirme aşamasında mı?
4. Yaygın olarak kullanılan bir çerçeve mi?
5. Ürün hakkında herhangi bir yorum / blog yayını / vb. Bulabilir miyim?

4 & 5, sizinki gibi görünen niş projeler için gerçekten yardımcı olmuyor.

Tek önemli şey ihtiyaçlarınızı karşılaması mı? Bunu yaptığını düşünüyorsanız, yapılacak bir sonraki şey, projeyi test etmek için bir koşum takımı yapmak ve yapmak istediğiniz şeyi yapıp yapamayacağınızı görmek. Bu, API'sı (bir kütüphane ise) ve nasıl çalıştığı hakkında bir fikir verecektir.

Günün sonunda, yaptıklarınızın% 90'ını yapan bir açık kaynak varsa, çatallayın, ekstra işlevselliği ekleyin ve topluluğa geri gönderin. Bunu daha önce ticari projelerde yaptım.

1. Çerçeve için, genellikle sadece önceden yazılmış modüllerin ve büyük topluluğun bulunduğu büyük ve olgun bir çerçeveyle giderim. Genel olarak, bir çerçeveyi diğeri üzerinden seçmek, kendi kodunuzda harcamanız gereken iş miktarını çok fazla azaltmaz, bazı çerçeve daha güzel bir kodu teşvik edebilir, diğerleri belirli işlemleri kolaylaştırabilir, ancak genellikle çok toplam geliştirme çabası arasında çok az fark vardır. Bununla birlikte, popüler çerçevelerde kaldırabileceğiniz daha önceden yazılmış modüller bulunur ve bu şekilde genellikle daha fazla zaman ve çabadan tasarruf edebilirsiniz.
2. Küçük çerçevesiz kütüphane için, gerekirse çok fazla sorun yaşamadan kendiniz değişiklik yapabilirsiniz, bu yüzden genellikle topluluğa ek bir bonus olarak sahip olmayı düşünürüm. Çoğu küçük kütüphane yalnızca tek bir kişi tarafından yönetilir, ancak yine de kendinizi inşa etmekten daha iyidir. Ancak büyük kütüphaneler için olgun, aktif bir topluluğa ve belgelere sahip olmak çok önemlidir, çünkü kendinizi kolayca değiştirebilmeniz mümkün değildir.
3. Lisans şarttır. Tek kişilik kütüphaneler için, kütüphanede değişiklikler yapmanız gerekecektir, bu nedenle lisanslarının kabul ettiğiniz şartlar altında bunu yapmanıza izin vermesi önemlidir.

Küçük kütüphaneler için, her zaman çatallanmanız gerektiğini ve projenin zaten terk edildiğini varsaymalısınız. Bu, özellikle proje Github veya BitBucket'te barındırılıyorsa, genellikle bir sorun değildir, çünkü diğer insanların projelerini aptalca kolaylaştırırlar. Küçük kütüphaneler için, orijinal bakıcı gitmişse veya proje yönünü gitmek istemediğiniz yerlere götürmeyi planlıyorsa, projenin bakımını her zaman kendiniz üstlenebilirsiniz.

Proje faaliyeti ile daha az ilgileniyorum, "mükemmeliyet" duygusunu elde eden olgun kütüphane genellikle hata düzeltmeleri yapmak zorundaydı, bu yüzden aktiviteleri yavaşladı. Proje etkinliği, yalnızca kütüphane aktif olarak gelişen bir hedef içeriyorsa önemlidir, örneğin, harici hizmet geliştikçe harici hizmet için bir paketin sürekli olarak güncellenmesi gerekir, bu nedenle aktif geliştirme gereklidir, ancak bir matematik kütüphanesi çok fazla ihtiyaç duymaz ihtiyaç duyduğu tüm özelliklere sahip olduğunda yeni gelişme.

Daha büyük kütüphaneler için işler daha da zorlaşır. Devralma çok daha karmaşıktır, neyse ki daha büyük kütüphaneler genellikle daha olgun oldukları için hızlı hareket etmezler.

@Sam'ın cevabında söylediği gibi, açık kaynak kütüphanesini değerlendirmedeki en önemli şeyin gereksiniminize ne kadar uyduğunu kabul ediyorum. Herhangi bir lisans sorunu çözüldükten sonra, bir açık kaynak kitaplığı kullanmak nadiren bir hatadır, çünkü işler güneye giderse her zaman çatallayabilirsiniz.

Projenin hata izleyicisine bakın. Birçok farklı kişi tarafından sunulan çok sayıda bilet ve çeşitli kişilerden gelen yanıtlar görüyorsanız, bu iyi bir işarettir. Daha fazla hata bileti == daha büyük kullanıcı topluluğu == sizin tarafınızdan üretime hazır olma olasılığı daha yüksektir.

Haberler iyi değil, ama bu yanlış olduğu anlamına gelmiyor: Bilmiyorsunuz.

Üretimde benzer uygulamalar olsaydı, bunun mümkün olduğunu bilirsiniz, ancak dediğin gibi hiçbir "büyük oyuncu" projeyi kullanmaz.

Evde geliştirseydiniz, bilirsiniz, ama dediğin gibi, kaynaklara sahip değilsin.

Bilmek istemek mantıklı, ama ... bilmiyorsun.

Umarım bu cevap yardımcı olur, çünkü bağlı olduğunuz ancak kontrol etmediğiniz herhangi bir teknolojinin fişini çekmek için beklenmedik durum planlarınız olmalıdır ve bunun güvenilir olup olmadığını bilmediğinizi bilmek bu yönde bir adımdır.

Soru farklı şekilde sorulmalıdır. Gerçekten sorduğunuz şey , bu açık kaynaklı projeyi ürünü geliştirmenin en iyi yolu mu?

Bu sadece söz konusu açık kaynak projesini değil, aynı zamanda diğer seçeneklerinizi de içerir. Tek seçeneğiniz her şeyi kendiniz yazıyorsa, projeyi değiştirmek için yeterince kodunu anlayabiliyorsanız, projeyi kullanmaktan daha iyidir.

Elbette diğer soru, projenizin hiç uygulanabilir olup olmadığıdır. Yani açık kaynak koduyla sağlamayı umduğunuz işlevselliği düzeltmek veya tamamlamak zorunda kalma riskini içeren çabayı tahmin etmeniz gerekir. Proje yaygın olarak kullanılmıyorsa, bunun için kodu gözden geçirmeniz gerekecektir.