Ticari yazılım ürünlerinde açık kaynak kodunu kullanma bilgeliği

ASP.NET web uygulamamda (özellikle dapper ) bazı açık kaynak kodlarını kullanıyorum . Yönetim bir hayran değil, çünkü açık kaynak bizi daha önce ısırmış bir risk olarak görüyor. Görünüşe göre önceki geliştiriciler, açık kaynak bileşenleri başarısız olduktan sonra şeyleri yeniden yazmak zorunda kaldılar.

Profesyoneller şöyle görünüyor:

• Aksi takdirde çok sayıda kazan plakası kodu veya Microsoft'un önerilen ancak daha yavaş çözümü (Entity Framework) içerecek çok şey yapıyor.

Eksileri:

• Üretimde aniden başarısız olursa, düzeltmek için zorlanacağım kadar karmaşıktır. Ancak, benimkinden çok daha yüksek trafikli bir sitede kullanılıyor, bu yüzden projenin yüksek riskli bir parçası olacağını düşünmüyorum.

Buradaki fikir birliği nedir? Projemde bilmediğim / anlamadığım ve kendi kodumu yaptığım açık kaynak kodunu kullanmak akıllıca değil mi?

Belirli koşullara göre yapmanız gereken bir seçimdir. Risklerinizi aşağıdaki yollarla azaltabilirsiniz:

• çerçeveyi iyice test etmek, kötü sürprizlerin bir üretim ortamında sizi ısırma olasılığından kaçınmak ve
• doğrudan çerçeveye bağlı kod miktarını en aza indirmek için gevşek bağlantı kullanarak tüm ürününüzü yeniden yazmak zorunda kalmadan kendi uygulamanıza geçebilirsiniz.

Nihayetinde, yoğun olarak kullanılan açık kaynaklı bir projeyle, kendi başınıza yazmak için karşılaştığınız birkaç sorunu düzeltmekten çok daha fazla zaman harcayabilirsiniz.

İlk tepkiniz başka birinin yazıp yazmadığını görmek yerine kendiniz bir şeyler yazmaksa, başarısız olmaya mahkum olduğunuzu söyleyeceğim. Ana açık kaynak projelerine giren tüm çalışma saatlerini ve hata düzeltmelerini hafifçe yapmayın.

İşletme alanınıza girmeye başladığınızda, ihtiyaçlarınızı karşılayan OSS'yi bulmak daha zor olacaktır. Ancak başka bir ORM ürününün yeniden uygulanmasına gerek yoktur. Doldurucu kodlarını hata ayıklamak ve düzeltmek mümkün olmayacak kadar karmaşıksa, tüm adam saatlerini sıfırdan yazmayı nasıl haklı gösterirdiniz? Ayrıca, NoSQL çözümlerinde her zaman kutunun dışına bakarken (gerekir mi?).

Linus bile Git'i geliştirmeden önce tüm kriterlerini karşılayan bir SCM çözümü bulmaya çalıştığını itiraf etti. En azından mevcut çözümlerin hiçbirinin neden yeterince iyi olmadığını açıklayabildi.

Hayatımın bir noktasında her şeyi kendim yeniden yazmak istemeyi bıraktım ve gerçek dünya problemlerini çözmeye odaklanmak istedim. Bir işletmede çözülmesi gereken sorunların çoğu alana özgüdür. Daha az kod yazmanın yollarını bulun.

Not: Microsoft çalışanı değilim. Görüş tamamen kişiseldir. Birçok düşünce, son 5-7 yıl boyunca her iki açık kaynağı geliştirici olarak büyük satıcılarla birlikte kullanmaktadır.

Monokültür iyidir: ASP.NET için kişisel kuralım Microsoft'u tercih etmektir ve başka seçenek yoksa 3. taraf kodunu (açık kaynak veya değil) seçmektir. Monokültür ödüllendirici, çünkü büyük bir satıcı tarafından taşınıyorsunuz ve aynı deneyimi tekrarlayan kullanıcı sayısı, yardım almak ve geçici çözüm bulmak için yeterince büyük.

Hayalet kasabalar: 2012'de açık kaynakla ilgili sorun, artık 2000 veya 2005 olmadığıdır. Kullanıcı, evlat edinme, katkıda bulunanların miktarı yıllar önce yaklaşık olarak aynı olduğunda, proje miktarı büyümeye devam etmektedir. Seyirciler ince gerilir. Birçok ilginç proje bayat, terk edildi. Açık kaynak proje bütçesi diye bir şey yoktur. Yani ilgi sona erdiğinde, dürüstçe desteğin bittiğini açıklayan ve ışıkları kapatan kimse yoktur. Halkın dikkatini daha iyi ve yeni bir şeye bırakmak için projeler asla ölmez. Dolayısıyla açık kaynak her zaman büyümeye ve parçalanmaya devam edecektir. Parasal ödül ya da mali ölüm şeklinde geri bildirimleri olmayan, ölümsüz varlıklardır, sonsuz zafer uğruna var olurlar.

20 derece ayrılık: Her yeni kütüphaneyi benimsemeniz sizi ana akımdan ayırır, sizi uç vakaların azınlığına kaydırır. Güvenlik yapılandırmasını seçmek, belirli bir sürümü, çerçeveyi, eklentiyi vb. Kullanmak gibi 20 adımdan sonra, çözümünüz, küresel olarak tek bir ayrıntı birleşimi haline gelir. Google, yalnızca sorunun ne kadar nadir veya benzersiz olduğunu kanıtlamaya yardımcı olur. Her zaman kendi kendine hizmet veren bir problemdir, tamamen tekniktir. Asla gerçek iş ile alakalı bile değil.

Kalite odaktan gelir, para önemsizdir: Açık kaynaklı veya ticari yazılımlardan bağımsızlık yoktur. Bütün devellopers topluluğu her zamanki gibi sadece bir topluluktur. Büyük sağlayıcılar, kodu daha iyi koşullarda, açık kaynak gruplarına göre daha geniş kitlelerle daha uzun yaşlandırma avantajına sahiptir.

Fikir birliği: Fikir birliği olup olmadığını soruyorsunuz. Muhtemelen hayır. Maalesef büyük miktarda açık kaynak kullanıcısı çok fazla politikleştirilmiştir. Sonuçta açık kaynak sosyal bir harekettir. Açık kaynak eleştiriye karşı bağışık değildir, çünkü çoğu zaman olumsuz görüş anti-teknolojik, kişisel saldırı olarak algılanacaktır. Kişisel görüşüm: Microsoft'a bağlı kalmak.

Önemli miktarda açık kaynaklı yazılım kullanan büyük bir şirket için bir dizi başarılı projede çalıştım. Özellikle, son kullanıcılara gönderilen başarılı projelerde çok büyük bir şirket için Curl, SQLite ve Webkit'i kullandım. Diğerlerinin söylediği gibi, bu sadece lisanslar konusunda dikkatli olmak ve ideal olarak bir avukata bakmaktır.

Yüzlerce açık kaynak lisansı vardır, ancak bunlar genellikle BSD tarzı ve GPL tarzı olmak üzere iki kategoriye ayrılır. BSD tarzı lisanslar, kendi kodunuzu açık kaynaklamanızı gerektirmez ve genellikle bir tür ilişkilendirme maddesine sahiptir. GPL tarzı lisanslar, kendi kodunuzu açık kaynaklamanızı gerektirir. Çoğu şirket (benimki de dahil olmak üzere) genel olarak buna çok benziyor, böylece GPL tarzından kaçınmak isteyeceksiniz. Dapper, BSD tarzı Apache lisansını kullanıyor gibi görünüyor. Kodlamaya başlamadan önce her zaman genel lisans koşullarının ne olduğunu öğrenin.

Ayrıca, ikili bir sınıra erişimi kısıtlarsanız kendi kodunuzu açmadan kullanabileceğiniz ilginç bir sınır durumu olan LGPL de var. (Kütüphaneye sadece dinamik bir kütüphane olarak erişiyorum.) LGPL kütüphane kullanımı çok yapılabilir, sadece daha dikkatli olmalısınız.

Deneyimlerime göre, açık kaynak kodunun ücretli veya başarısız çözümlere dönüşmesi veya bu nedenle kendi çözümlerinizi üretmesi daha olası değildir. Daha belirgin açık kaynak araçlarından bazılarına bakarsanız, kalite çok yüksektir.

Muhtemelen küçük veya tamamlanmamış projelerden kaçınmak istersiniz. İhtiyaçlarınızı karşılayacak gibi görünen bir şeyi kapmak cazip gelebilir, ancak eğer birkaç kişi tarafından bir araya getirilmiş, hiç tamamlanmamış ve desteklenmeyen bir şey olsaydı, muhtemelen çabaya değmez. (Doğrudan kod üzerinde çalışmaya istekli olmadığınız sürece.)

Daha önce hiç tescilli bileşen başarısız olmadı mı? Büyük ve küçük firmaların yazılımlarında birçok hatayla karşılaştım. Bu sorun kendi başına açık kaynakla ilgili bir sorun değil, daha çok proje olgunluğu ile ilgilidir.

Destek sunan olgun projeleri kullanmak istediğiniz anlaşılıyor. Bazı açık kaynaklı projeler ücretli destek sunar veya herkese açık bir forumda yanıt alabileceğiniz kadar geniş bir topluluğa sahiptir. Belki kapalı ya da açık kaynaklı bir kütüphane seçerken olgunluk ve destek kriterleri önceliklerini belirlemelisiniz.

Olgunlaşmamış veya sınırlı desteğe sahip bir proje kullanmaya karar verirseniz daha fazla risk aldığınızı kabul etmeniz gerekir. Bu nedenle, risk azaltma planınızın ne olduğunu belirlemeniz gerekir. Örneğin, üçüncü taraf yazılımları üzerinde daha fazla test yapabilirsiniz.

Lisanslama sorunlarının burada bir sorun olmadığını varsayalım: Dapper'a hızlıca baktığımda, sadece 2255 iyi belgelenmiş, okunabilir kod satırına sahip olduğunu fark ettim . Yani

• aynı kalitede karşılaştırılabilir kalite kodu üretmek için birkaç gün veya hafta yatırım yapabileceğiniz kadar büyük
• ne yaptığını anlayabilecek kadar küçük ve üretimde görünüyorsa bu koddaki hataları düzeltebilirsiniz

Eğer kendi başınıza böyle bir şey yazacaksanız ve "tekerleği yeniden icat edecekseniz", kendi kodunuzun üretimde hatalar gösterme riski çok daha yüksektir ve siz de "bunları düzeltmek için gerçekten zorlanırsınız".

Eğer projeye açık kaynak böyle bir parça tanıtmak eğer, ancak, burada yapmak zorunda Sonra ne sen almak zorunda tüm sorumluluğu size kendiniz yazmış gibi eğer bu kodu. Kodun gerektiğinde koruyabileceğiniz bir durumda olduğundan emin olun. Bir şey beklendiği gibi çalışmazsa, bu kodun "yazarlarını" suçlamayın.

Projelerimizden birinde, Dapper gibi küçük boyutlardan yaklaşık 20K ila 30K kod satırına sahip kütüphanelere kadar bazı açık kaynak bileşenleri tanıttık. Her zaman bazı değişiklikler yapmak, bazı hataları düzeltmek, bir şey küçültmek vb. Vardı, ama beklediğimizden beri o was ok. Hata ayıklama zamanı da dahil olmak üzere, açık kaynak kullanımı bize çok fazla iş kazandırdı.

Burada düşünülmesi gereken bir şey var: Sizin durumunuzda, büyük bir tedarikçiden (MS Entity Framework, herhangi bir ekstra lisans ücreti ödemek zorunda kalmayacağınız) geniş çapta kabul gören bir alternatif olduğunu belirtiyorsunuz. Performansla ilgili nedenlerden dolayı kullanmak istemezsiniz. Performansın göz önünde bulundurulması gereken tek veya birincil nokta olmasına izin vermemeyi kesinlikle tavsiye ederim. Burada sormanız gereken sorular: Dapper, şu anda ve yazılımınızın beklenen ömrü boyunca ihtiyacınız olan tüm işlevselliğe sahip mi? Ya da Dapper'in sınırlarına hızlı bir şekilde ulaşacağınızı ve EF'e ilk başta kullanmaya karar vermiş olsaydınız muhtemelen bir sürü eksik işlevsellik eklemeniz gerekeceğini tahmin edebilir misiniz? İkincisi ise, Dapper'ı kullanmamanızı tavsiye ederim. Ayrıca kendinize sorun: EF uygulamanız için gerçekten yeterince hızlı değil,

Gördüğüm gibi, bu dengeleyici bir eylem.

Kendinizi bir satıcıya bağımlı yaparsanız, desteğin çok geçmeden kaybolacağı neredeyse kesindir

• Ödeyecek programcıları olduğundan, yeni sürümler yapmaya ve eskilerinin edinilmesinin imkansız olduğundan ve artık (daha yeni platformlarda) çalışmadığından emin olmaları gerekiyor, böylece yenileri bir pazara sahip olacaklar.

• Bir iş modelini haklı çıkaracak kadar satamazlarsa, A şirketinden B şirketine C'ye geçerler, her biri onu tekrar yeterince değiştirir, yenisini yeniden programlamadan kullanamazsınız ve ' t Eski olanı alın.

• Sadece artık desteklemeyeceklerine karar veriyorlar çünkü çok fazla sorun var ve içinde para yok. Tüm para yeni uygulamalarda.

Bu nedenle, her birkaç yılda bir sürekli olarak yeniden yazılması gerekmeyen bir şey oluşturmak istiyorsanız, açık kaynak arkadaşınız olabilir.

Yeterli bir özen gösterilmesi akıllıca olur ve belli bir projenin tarihi ve faaliyeti ile ilgili olarak zaten bazı ödevler yapmışsınızdır. Kaynak koddaki özellikleri genişletme / ekleme özelliği de büyük bir profesyoneldir. Yeterli testler ile karşı taraftaki riski en aza indirebilirsiniz. Kodunuzdaki tüm bağımlılıkları tamamen anlamak zordur, ancak en azından bu durumda gerekirse kodu tamamen hata ayıklayabilir ve görüntüleyebilirsiniz.

Yönetimden neden daha önce başarısız olduğunu sorun, durum tespiti için yeterli miydi?

jquery, MIT lisansını kullanma seçeneğine sahiptir, bu nedenle birçok ticari ve resmi web sitesi de jquery kullanır. Microsoft'un web sitesi de jquery kullanıyor! Yani endişe lisanslama. GPL / LGPL kullanmaktan kaçının yeterlidir.

"Bildirilen bir hatanın düzeltilmesi ne kadar sürer?" Hatayı bildirdikten sonra dakikalar, saatler veya günler içinde düzeltilebilir. Acil bir durum için, personel sadece kaynak almak ve derlemek için "git pull" olabilir. Sadece "v1.2.3-101-gd62fdae" gibi sürümü izlenebilir yönetime rapor eder.

Açık kaynak kod kalitesiyle değil, yasallıkla ilgilidir. İyi ve kötü açık kaynaklı ürünler olduğu gibi, iyi ve kötü açık kaynaklı ürünler de vardır. İkileminizin bir gönüllü topluluğu tarafından geliştirilen bir projeyi kullanıp kullanmayacağına inanıyorum.

Yönetim sorununun teknik kaygılar olduğundan emin misiniz?

Bunu işletim sistemi ve ticari faaliyetlerin karıştırılması yasal bir maden alanı olarak söylüyorum ve birden fazla menajer yasal ekipten / CEO'dan veya daha kötüsü başka bir kuruluştan "Lütfen Açıklayın". Tanıdığım çoğu yönetici, hatta OS yazılımını aktif olarak kucaklayanlar bile, (haklı olarak) oluşumunu ortaya koydukları yasal durumları tam olarak anlamak için çok dikkatli davranıyorlar. İşletim sistemi yazılımını benimser ve değişiklik yaparsanız, bu değişiklikleri topluluğa iade etmeniz gerekir. Bazı durumlarda, bu yükümlülük yasal, diğerlerinde ahlaki olarak geçerlidir. Bazı işletim sistemi lisanslarında, yaptığınız her şey yalnızca onlara bağlayarak işletim sistemi haline gelir.

Teknik açıdan bakıldığında, bu sadece rakip ürünler arasındaki bir karardır - Bazı temel sorular sorun - Seçtiğiniz paket için ihtiyacınız olan desteği alabilir misiniz? geliştirici, her yıl veya bir kapalı vb.

Ve hatırlanması gereken bir nokta daha var: "Hiç kimse IBM'i satın almaktan kovulmadı". (yani yönetim "Çok fazla para harcarsanız, ücretsiz olandan daha iyi bir ürün olmalıdır" anlamına gelir.