Açık Kaynaklı bir projenin hangi aşamasında topluluktan katkıları davet etmelisiniz? [kapalı]

Ekibimin geliştireceği yeni bir açık kaynaklı ürüne katkıda bulunmayı merak ediyorum. Elimizden geldiğince geniş bir topluluktan daha fazla destek almamız için cesaretlendiriyoruz, ancak ofis dışında bulunan 3. tarafların kod kalitesi gibi şeylerle ilgili olduğundan emin olmak için bu emiciliği çok fazla zaman görebilirim. Ayrıca, projenin başlangıcında çekirdek ekibin içinde sistemin tasarımı, sivri uçlar vb. İle ilgili pek çok gayrı resmi görüşme yapıyoruz ve bunları topluluğun katılımını sağlamak için çevrimiçi hale getirmek zaman alacak ve hayal edebiliyorum. tartışma daha az etkili.

Muhtemelen göz önünde bulundurulması gereken daha insani bir husus var: tasarım sürecine toplumun dahil olmasına izin verilmesi, projenin algılanan mülkiyeti ile ilgili yararları da olabilir ve her zaman erken katılımın çekirdeğin karşılaştığı sorunlara yakalanma şansı vardır. takım farketmedi.

Öyleyse soru: Açık Kaynaklı bir projenin hangi aşamasında topluluktan katkıda bulunmalısınız?

Tam başlangıçta! Topluluğunuzun projenizde gerçek bir hisselerinin olduğunu hissetmesini istersiniz, aksi takdirde serbest emek olarak kullanıldıklarını hissederler.

Tüm iletişim, halka açık bir posta listesi veya forum üzerinden yapılmalıdır, bu da topluluk fikrini geliştirir.

İlk gönderilerinizde posta listesine açık bir vizyon koyarak, 'tasarım komitesine göre' sorununu azaltabilirsiniz, örneğin;

“Öyleyse Evcil Hayvan Mağazamızı temsil etmek için bir etki alanı modeline bakıyoruz (JIRA-4'e göre). Bu modelle ilgili herhangi bir önemli sorunu gören var mı?”

Gerçek fiziksel katkıları kabul etmek için yamaları kabul ederek ve üzerlerinde genel kod incelemeleri yaparak başlamalısınız. Bu şekilde katkıda bulunanlar ne tür kodlama standartlarına uymaları gerektiğini kamuya açık bir şekilde görebiliyorlar. Taahhütlerinizin bir taahhütlü posta listesinde de mevcut olduğundan emin olun - aynı standartlara uymanız gerekir!

Aynı zamanda bir Wiki veya böyle bir belge üzerinde proje standartlarına sahip olmak için öder.

Başarılı bir açık kaynaklı projenin nasıl yürütüleceği hakkında daha fazla bilgi için http://www.producingoss.org adresini okuyun .

Bu, uzun zamandır tartışılan Google IO konuşmasında Genious programcı Myth, Brian Fitzpatrick ve Subversion'dan Ben Collins-Sussman tarafından tartışıldı. Kısacası, henüz orada hiçbir şey olmadığı kadar erken olmaması gerektiğine karar verdiler (yani, "harikulade projeme bakın! Burada henüz pek bir şey yok ama çok fazla harika şeyler planlandı!") Veya çok geç bu yüzden tüm kararlar zaten verildi (solo bir projede yer almak zor.)

Ben Martijn Verburg katılıyorum . En başından itibaren katkı payı almaya başlamalısınız. Bu konuda biraz daha önce yazdım .

Bu yazının özeti, yazılım çürükleridir. Taze tutmak istiyorsanız, bakım yapmanız gerekir. Bir proje ne kadar popüler hale gelirse, o kadar fazla böcek bulunacak, daha fazla özellik eklenecek ve bu bakım işi sizi daha da yavaşlatacak.

Aslında, bu çok yaygın bir sorundur. Fat'ın Açık Kaynak Nedir ve Neden Bu Kadar Suçlu hissediyorum? İzlemenizi şiddetle tavsiye ettiğim bu konuşmada, OSS projelerinden birinin hikayesini anlatıyor ve zamanının çoğunu boş zamanlarının çoğunu bilet triyajı ve yönetim işleri yaparak geçirirken buldu. Ve bunun ne kadar zarar verdiği hakkında konuşuyor. Bu tamamen empati kurabileceğim bir şey.

Çözüm, elbette, insanları projeye erken ve sık sık eklemektir. Zamanınız sınırlı ve değerli. Katkıda bulunan tabanınızı büyütmek için yatırım yapın ve sorunlarınızın geri kalanı kendileri ile ilgilenmeye başlar.

Yazımın sonunda söylediğim gibi: "Projeniz için daha önemli olan şey: özellikler veya gelecek? Birini seçin ve çabalarınızı buna göre önceliklendirin."