Açık kaynak kodlu yazılımı çok yakında serbest bırakmak [kapalı]

Açık kaynak kodlu yazılımı piyasaya sürmenin ahlaki sorumluluğu nedir? Örneğin, tamamen test edilmemiş tamamlanmış bir ürün.

Programcının beklentisi nedir? Tamamen sınanana kadar bekleyin veya açık kaynağa bırakın ve daha sonra geliştirme, test etme ve ilerlemelere devam edilsin mi?

Korku, yazılımın açık kaynaklı olması ve potansiyel olarak tüketiciler için sorunlara yol açmasıdır.

Bu temelsiz bir korku mu?

Aksine, açık kaynak kodlu bir yazılımı mümkün olan en kısa sürede piyasaya sürmeniz gerektiğine inanıyorum. Bunun için "çok yakında" yoktur (ancak derlenmesi gerekir).

^{Ya da en azından kaynak kodu çok erken ve sürekli olarak yayınlayın (örneğin, github'a sık sık basıldığında ), resmi yayınlar yapmadan .}

Ancak, alfa veya beta aşaması olarak işaretlemek ve mümkünse (örneğin bir READMEveya TODOdosyada ve bazı bloglarda, vb.), Eksik olan, test edilmemiş veya kötü durumda olanları söylemek çok önemlidir . Bu bilgileri iletmek için sürüm numarasını da kullanmalısınız .

İle özgür yazılım , gerçekleşmesi gerektiğini iyi kaynak koduna birisi bakışlar ve sana bunu geliştirerek küçük yama öneriyoruz. Bu yüzden yazılımınızı serbest bırakıyorsunuz!

^{Bu nedenle, günlük çalışmanızı özgür yazılımınız üzerinde görülebilir hale getirmeniz gerekir! Düzeltme ekleri, yeni yazılım kaynak kodunuzla birlikte çalışmazsa veya kopyası yoksa işe yaramazsa, dış katkı yapanlar kızarlar.}

Korkmanız gereken şey, yazılımınızla ilgilenmeyen (ve buna katkıda bulunan) hiç kimse. Dışarıdan özgür bir yazılıma ilgi duymak (özellikle dış katkı sağlayanları çekmek) uzun bir yolculuktur.

TL; DR:

Erken bırakın. Genellikle bırakın.

Kişisel fıkra:

Üzerinde çalıştığım proje için çok heyecanlıydım. Gibi, gerçekten heyecanlı. Geceleri uyuyamadım heyecanlıydı. Bu yüzden ortak çalışmamdan istediğimden daha hızlı v1.0 yayınlamaya başladım.

Berbattı. Hiçbir şey olması gerektiği gibi işe yaramadı. Her fırsatta hatalar vardı, ama biz onları kaydettik ve düzelttik. Hatta birkaç erken evlat edinen bulamadığımız hataları da gönderdik. Bir veya iki hafta sonra birçok konuyu ele alan yeni bir sürüm yayınladık ve sonra yeni özellikler oluşturmaya geri döndük.

Erken tahliye, yapabileceğimiz en iyi şeydi. Ürünümüzü gerçek kullanıcıların önüne koydu. Bu açığa çıkan böcekleri yaparak projemizi daha iyi bulup bulmamış veya yapmamış olabiliriz. Aynı zamanda, erken evlat edinenlerin bu proje hakkında ciddi olduğumuzu bilmelerini sağladı. Daha fazla sürümler ve aktif gelişme olacak.

Yine de kolayca diğer tarafa gidebilirdi. Bu hata raporlarını görmezden gelebilirdik. Ya da hızlı tepki veremezdik. Birkaç hafta yerine v1.1'i piyasaya sürmemiz 3 ayımızı aldıysa farklı bir hikaye olabilirdi.

Kapalı kaynak yazılımı ile aynıdır. İletişim önemlidir.

Kullanıcılara yazılımın durumunun ne olduğunu ve neden indirilebileceğini bildirin.

Yazılım tamamen test edilmiş olsun veya olmasın, müşteri sorunlarına yol açacaktır. Çoğu müşteri bu gerçeği kabul eder ve bazı müşteriler asla kabul etmez. Ancak, yazılım makul bir şekilde beklenenden daha fazla soruna yol açarsa, müşteriye aldıkları riski bildirmek için ahlaki bir zorunluluk vardır. Bilgi hem kısa hem de ("Alpha / Beta / EarlyAccess" etiketler) * şeklinde ve detaylı olarak belirtilmelidir: * Bilinen sorunların, geçici çözümlerin ve özel durumların bir listesi, örneğin verilerin bozulma olasılığı varsa.

* Bazı büyük yazılım şirketleri tarafından, kullanıcıların yazılımın oldukça sağlam olduğu bir durum olarak "Beta" yı düşünmeleri için eğitilmiş olduklarını unutmayın, bu nedenle kullanıcıya yazılımın "Beta" olduğunu genellikle yeterli bilgi olmadığını söyleyin.

Hiçbir ahlaki sorumluluk yoktur. Kimse yarı pişmiş yazılımınızı kullanmaya zorlanmıyor.

Endişelenecek tek şey senin güvenilirliğin olacak.

Benim deneyimim, ulaşılması gereken bir denge olduğu.

Şu anda, yazdığım kodu kullanan çok heyecan verici bir FOSS projesi gibi görünen bir üretici üreten bir geliştiriciyle çalışıyorum (soruları yanıtlamak ve geliştirme önerileri sağlamak için herhangi bir kod görmeden) çalışıyorum. Kamuya açıklanması, projeyi uzun vadede daha iyi hale getirecek, ancak zaten yazılmış ve zaten “çalışmakta olan” önemli kod yeniden yazmalarını gerektiren tasarım değişikliklerinin gerçekleşmesiyle defalarca ertelendi. Benim görüşüme göre, çalışacak ancak kusurlu bir yayın yapıldığı zaman, göstermeye çalışan bir şey olduğu taktirde, değişiklikler için (ve gerçek yamalar) fikirleri bu projeyle ilgilenen daha geniş bir topluluktan gelip ilerlemekten ziyade daha geniş bir topluluktan gelebilirdi. Sorunlar yavaş yavaş, her seferinde bir geliştirici bunları düşünür ve kendimden ve topluluğun diğer ilgili üyelerinden tasarım geribildirimi ister. Bu yüzden, bu açıdan, "erken bırakma, sık sık bırakma" konusunda bir savunucuyum.

Öte yandan, düşük kaliteli sürümler yeni bir projeyi yerden bile önce kötü görünmesine neden olabilir. Gördüğüm bazı tuzaklar şunlardır:

• Arayüz tanımlarına sahip iskelet ağaçları ancak kod yok.
• Geliştiriciden başka hiç kimse için başarıyla derlenmeyen kod.
• Programın nasıl oluşturulacağı / çalıştırılacağı hakkında talimat yok.
• Hangi yönlerin işe yarayacağına dair hiçbir belge yok.
• Programın ne yaptığını ya da ne yapacağını net olarak bilmiyoruz.
• Yararlılık göstergesinin olmaması.

Son nokta için, şöyle şeyler düşünüyorum:

• Merhaba dünya tipi bir programı bile derleyemeyen / çalıştıramayan derleyici / tercüman.
• En azından bir çeşit örnek program çalıştıramayan ya da başka bir şey yaptığını gösteremeyen emülatör.
• Hiçbir şey yapamayan görüntü işleme aracı, değiştirilmemiş görüntüyü yükleyip yeniden kaydeder.
• Başlık ekranı dışında hiçbir şey olmayan oyun.

Bu tür sorunlar, başlangıçta çalışma kodunun eksikliği konusunda çok açık olmadıkça, titremesi zor bir "buharlı yazılım" imajına neden olur.

Son olarak, sürüm numaralarınızı anlamlı hale getirin. Projenizi "1.0" olarak adlandırmayın, kullanıcılar çökmesini beklemeden ne beklerse onu yapmayın. İlk kamuoyunu serbest bırakmak için "0.5" civarında sürüm numaralarını kullanma ve oradan gitme konusunda her zaman şansım oldu, ama aynı zamanda "0.1" veya "0.10" gibi şeyler de mantıklı geldi.

Özgür yazılımı piyasaya sürmenin olumsuz sonuçları olabilir. Bazı şartnameler, halka dağıtılan tüm uygulamaların, ilk yayınlandığında tamamen şartnameye uyması şartıyla halka lisanslanır. Yayıncı, şartnamenin devam eden bir çalışmasını uygulamanızı yasal olarak yasaklar. Özelliğin yayıncısından belirli bir anlaşmalı lisans olmadan, tüm testleri geçinceye kadar onu kimseyle paylaşmamalısınız. Bu, spesifikasyonun uygulanmasında bir “katedral modelini” (Eric S. Raymond'ın dediği gibi) zorlar.

Böyle bir lisans kapsamındaki özelliklerden biri Java Dili Belirtimidir . Bu kısıtlama, JVM ile uyumlu sanal makinelerin geliştiricileri için geçerlidir, ancak neyse ki JVM'de çalışan uygulamaların geliştiricileri için geçerli değildir.

Makale " Microsoft'un 'Açık Kaynak' NET Yaklaşık 4 Shifty Detaylar Liu Qihao & Ciaran O'Riordan tarafından" yorumlama ihtimalini bahseder NET Kütüphaneler ve çalışma zamanı bileşenleri için Microsoft Patent Promise benzer bir şekilde CLR eksik uygulamalarını dışlamak . Ancak yine de, bu CLR'de çalışan uygulamalar için geçerli değildir.