Açık kaynaklı yazılım seçerken hangi uyarı bayraklarını izlemeliyim? [kapalı]


13

Açık kaynaklı projeleri ticari yazılımlarla ve hatta diğer açık kaynaklı projeleri karşılaştırırken, hangi durumlar kırmızı bayrağı kaldırır ve çıkart düğmesine basmanıza ve başka bir yere bakmanıza neden olur?

Yanıtlar:


17

Açık kaynak

Proje web sitesine bakın

  • Belgelere bakın
  • Posta listesi arşivlerine bakın
  • SCM'ye bakın (svn, git, hg, vb.)

Bunu yaparken, aşağıdaki noktaları toplayın ...

  • Yazılım ne kadar olgun
  • Kullanıcı tabanı boyutu nedir (birçok kişi mi? 3 kişi mi?)
  • Kullanıcı tabanındaki kişiler kimlerdir (kurumsal, ev kullanıcıları, küçük işletmeler vb.)
  • Geliştirme aktif mi? Ne zamandır aktif?
  • Posta listesi arşivleri, geliştiriciler arasında, diğer şeylerin yanı sıra "ekip ruhu" hakkında da çok fazla bilgi sızdırıyor. Sağlıklı, düşmanca, sıkılmış vb. Mi görünüyor?
  • Dokümantasyon iyi mi?
  • Paket / proje Fedora, Debian, RHEL, SLES, Ubuntu vb.Gibi herhangi bir Dağıtım'a kabul edildi mi? Eğer öyleyse - bu iyi bir şey - dışarıda en az bir kişi projeye inanıyor.
  • Sitenin uygun bir bilet sistemi var mı? Eğer öyleyse - 5 yıl önce kaç bilet açık? Bu, projenin ne kadar "canlı" olduğunun başka bir göstergesidir.

Ayrıca, yazılımın dağıtıldığı Lisansı not ettiğinizden emin olun. Bazıları ihtiyaçlarınız için uygun olmayabilir.

Kurumsal yazılım

Burada söyleyecek fazla bir şeyim yok ...

  • Uygulamanın çalışmadığındanroot emin olun (satıcıya sormayın - sadece yalan söyleyecektir) . Özellikle bir TCP / IP bağlantı noktasında dinleyecekse. * Satıcının itibarına bakmak
  • Satıcıların bu ürünü yöneten kişilerin (yani rooterişim verilmeyeceğini ve bu nedenle ürünün sudo'yu desteklemesi gerektiğini bildiğinden emin olun . sudoDesteklenmeyen herkes genellikle yaşlıdır, ancak onlar satıcıdır ve Sizi desteklemek zorunda olanlar olun - ürünü satın almak istemez ve daha sonra "Hayır sudo kullanamazsınız, root atmanız gerekir" der.
  • Hiçbir zaman hiçbir kapalı kaynaklı güvenlik yazılımı satın almayın - asla
  • (öznel): ... ve asla bir satış temsilcisinin söylediği hiçbir şeye asla güvenmeyin - hepsi yalancı ve yılan, istisna yok.

Bir programın olgunluğunu nasıl belirliyorsunuz? Sürüm numaraları bir şey ifade etmiyor ve birçok proje yıllarca tek kullanımlık sürümlerde oturuyor. (Sana NetworkManager'a bakıyorum). Kırmızı bir olgunlaşmamış bayrak ne olurdu?
jldugger

Doğru, sürüm numaralarının geliştiriciler için belirli bir anlamı olması mümkün olsa da, bu içsel bir şeydir - dış dünya sadece en iyi göstergedir - kurumsal yazılımın gülünç sürüm numarası atlamalarıyla denediği ve sömürdüğü bir şey . Olgunluk hakkında bir fikir edinmek için, özellikle biletleme sistemi - çok sayıda kene iyi bir şeydir - özellikle geliştiricilerin bunları düzeltmek ve kapatmak için gerçek bir çaba gösterdiklerini görebiliyorsanız, birkaç yere bakabilirsiniz. Öte yandan, biletiniz veya en kötüsü, biletleme sisteminiz yoksa, iyi bir başlangıç ​​değildir.
Xerxes

7
  • Faaliyet eksikliği. Proje yeni kod yayınlamamışsa, çok sayıda kapatılmamış hata (veya yeni hata içermeyen çok eski hatalar) gösterin veya çok yüksek spam / posta oranına sahip kullanıcı forumları varsa, bu kesinlikle bir koku çürüyen kod tabanı. Aktif projelerin düzenli sürümleri, yenilerinin açığa çıktığını gösteren hata-karmaşası ve eski etkinliklerin kapalı olmadığını ve günlük aktiviteye sahip kullanıcı forumları vardır. Bunların üçü de, kodu canlı tutmak ve iyi bir şekilde serbest bırakmak, geri bildirim ve hata ayıklama / yeniden düzenleme gibi önemli bir döngü oluşturur.

  • Etkinlik, kod tabanının boyutu, karmaşıklığı ve olgunluğu ile orantılıdır. Program / proje ne kadar büyük olursa, nokta salımları o kadar sık ​​görülmez, ancak tutarlı bir nokta salım akışı olmalıdır. Samba gibi büyük bir karmaşık kod tabanına sahip bir proje için, bir ay kadar sonra yeni sürümler bekliyoruz. Daha muhafazakar tasarım hedeflerine sahip olgunlaşmış bir kod tabanı olan gcc gibi bir proje için, nokta sürümleri daha uzun ama daha büyüktür. Çok az miktarda kod üzerindeki hızlı hareket eden hedefler de olası sorunları gösterir - geliştiricilerin hala hatalarla mücadele ediyor olması veya henüz tüm hedeflerin / özelliklerin kodlanmamış olması olabilir.

  • Kaynak kodu kolayca erişilebilir olmalıdır . Nokta boş, bu kadar eğer doğruysa açık kaynak, kaynak kodunu görmek için taşıdığı her türlü sihirli el sıkışma, vudu teklifleri veya mum ışığında büyüler olmamalıdır. CVS, SVN, Git, Mercurial veya hatta taşıyıcı güvercin aracılığıyla erişilebilir olması önemli değildir, ancak bir tıklama sarma lisans sözleşmesi olmadan bu şeye erişebilirsiniz. Bir feragat, NDA imzalarsanız veya duyulmamış bir lisans şemasını kabul ederseniz, açık kaynakla uğraşmıyorsunuz, kaynaklarını size açmayı kabul eden ticari bir satıcıyla uğraşıyorsunuz - bir fiyat için .


Etkinlik gereksinimleri için ++.
sh-beta

6

Gerçekten çok var.

Aldatıcı Lisanslama - Çok fazla çözüm nikel yapmaya ve beni ölümüne mahkum etmeye çalışıyor. Paketin maliyeti X, ancak reklamı yapılan seçenek 1, 2 ve 3'ü istiyorsanız, seçenek başına 500-1500 dolar daha fazla olacaktır. Hayır teşekkürler.

Kimse kullanmıyor - Ya da en azından, Google bu konuda konuşan kimseyi bulamıyor. Ya yepyeni (bu durumda, bir kobaysın) ya da o kadar kötü ki herkes daha iyi biliyor

Birkaç çatalın kökü - Bir şey defalarca çatallandıysa, bunun muhtemelen iyi bir nedeni vardır ve çatallardan biri sorunu kaynağından daha iyi çözmüştür. Bunları araştırın.

Sürekli olarak kötü arayüz tasarımı - sadece GUI demek istemiyorum. Çılgın, tanımlanamayan veya yanlış etiketlenmiş CLI bayrakları veya seçenekleri beni delirtiyor

İşe yaramıyor - ya da çözülmesi gereken bir durumun var olmaması (ya da olmaması) gibi davranıyor ve bu nedenle buna değinmiyormuş gibi yapıyor


1

Kod karmaşası oranının tutarlı olduğunu ve sadece birkaç kişi tarafından değil, birçok kişi tarafından yapıldığını da ekleyeceğim. Bir insanın projesi hakkında heyecan duyduğu zaman yarı zamanlı kod açmasını istemezsiniz, daha sonra bundan sıkılır ve topluluğun desteklemeye devam etmesi için ayrılır. Drupal ve Joomla iki iyi örnektir.


1

Şirketiniz için yazılıma bakıyorsanız, satmak, değiştirmek vb. İçin en önemli husus lisanstır. Meşgul kutusunun WLAN yönlendiricilerine dahil edilmesine ve yasal işlemlerin yapılmasına bakıldığında, şirketler "açık kaynak = ne istersen yap" diye düşünüyor.

Diğer bazı şeyler: Ayrıca son güncelleme tarihi ve aktif bir topluluk, yani forum, belki de konu olarak yazılım olan diğer sayfaları arıyorum.


1

Linux'ta, hangi yazılımın dağıtımınız tarafından paketlendiğini kontrol edeceğim. Paketlenmiş yazılımlar sadece openource / GPL ile sınırlı değildir - Ubuntu, Gentoo ve SLES en azından paket listelerinde özel yazılım içerir. Bu paketlerin dağıtımdaki temel yazılım kadar etkili çalışacağına dair bir garanti olmasa da, birisi bir paket hazırlamak için zaman ve çaba harcadı.


1

Ben esas olarak olgunluğa ve aktiviteye bakardım. Oldukça olgun görünüyor ve aktivite (örneğin forum veya wiki etkinliği) iyi bir miktar gibi görünüyorsa o zaman oldukça rahat hissediyorum. O zaman hataların çözülme şansı olduğunu ve ortaya çıkan sorunlarda yardım alabileceğimi biliyorum. Haftanın herhangi bir günü, mükemmel bir eşleşme gibi görünen ama ölü gibi görünen bir proje üzerinden, ihtiyaçlarıma mükemmel bir şekilde uymayan aktif bir proje seçerdim.

Olgunluk söz konusu olduğunda, amaçlanan kullanıma büyük ölçüde bağlıdır. Anında açmam gereken bir şeyse ve başarısız olmasına ya da belaya neden olmasına izin verilmiyorsa, olgunluk açıkçası oldukça önemli bir faktör olacaktır. Birkaç tuhaflık ile yaşayabiliyorsam ve bazı kesinti süreleri ile kritik değilse, gelecekteki görünüme bakmayı tercih ederim.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.