Açık kaynak yazılım
Açık kaynak yazılım geliştirme > Geliştirme modeli

Açık kaynak hareketinin öncülerinden Eric Raymond, 1997 tarihli Katedral ve Pazar isimli yayınında açık kaynak yazılım geliştirme için katedral ve pazar(çarşı) adını verdiği iki modeli tarif etmekte ve pazar modelini önermektedir.
Raymond, yazılımın geleneksel yöntemlerle geliştirilmesini, bireylerin veya küçük grupların dikkatli ve izole bir çalışmasıyla bir katedral inşa etmeye benzetiyor ve yazılımların pazar tarzı kullanılarak, farklı gündem ve yaklaşımlarla geliştirilmesi gerektiğini öne sürüyor. Katedral modeli olarak adlandırdığı geleneksel geliştirme modelinde ilerleme merkezi bir şekilde gerçekleşir. Roller açıkça tanımlanmıştır, projeyi yönetmekten sorumlu kişiler ve uygulamadan sorumlu kişiler bellidir. Geleneksel yazılım mühendisliği katedral modelini takip eder. Ancak pazar modeli farklıdır. Bu modelde roller açıkça tanımlanmamıştır. Pazar modeli kullanılarak geliştirilen yazılımın aşağıdaki özelliklere sahip olması beklenir.
Kullanıcılara ortak geliştiriciler gibi davranılmalıdır: Kullanıcılara ortak geliştiriciler gibi davranılır ve bu nedenle yazılımın kaynak koduna erişimleri olmalıdır. Ayrıca, kullanıcıların yazılıma eklemeler, kod düzeltmeleri, hata raporları, belgeler vb. göndermeleri teşvik edilir. Daha fazla ortak geliştiriciye sahip olmak, yazılımın gelişme hızını artırır.
Erken sürümler: Yazılımın ilk sürümü, ortak geliştiricileri erken bulma şansını artırmak için mümkün olduğu kadar erken yayınlanmalıdır.
Sık entegrasyon: Proje yaşam döngüsünün sonunda çok sayıda hatanın düzeltilmesi yükünü önlemek için kod değişiklikleri mümkün olduğunca sık entegre edilmelidir (paylaşılan bir kod tabanına birleştirilmelidir). Bazı açık kaynaklı projeler, entegrasyonun otomatik olarak yapıldığı gecelik yapılara sahiptir.
Çeşitli versiyonlar: Yazılımın en az iki versiyonu olmalıdır. Daha fazla özelliğe sahip daha hatalı bir sürüm ve daha az özelliğe sahip daha kararlı bir sürüm olmalıdır. Hatalı sürüm yani geliştirme sürümü, en son özelliklerin anında kullanılmasını isteyen ve henüz kapsamlı bir şekilde test edilmemiş kodu kullanma riskini kabul etmeye istekli kullanıcılar içindir. Kullanıcılar daha sonra ortak geliştirici olarak hareket edebilir, hataları bildirebilir ve hata düzeltmeleri sağlayabilir.
Yüksek modülerleştirme: Yazılımın genel yapısı, bağımsız bileşenler üzerinde paralel geliştirmeye olanak sağlayacak şekilde modüler olmalıdır.
Dinamik karar alma yapısı: Değişen kullanıcı gereksinimlerine ve diğer faktörlere bağlı olarak stratejik kararlar veren, resmi veya resmi olmayan bir karar alma yapısına ihtiyaç vardır.
Açık kaynak geliştirme süreci, geliştiricilerin yeni özellikler eklemeleri gerekip gerekmediğini veya projelerinde bir hatanın düzeltilmesi gerekip gerekmediğini değerlendirdikleri gereksinimlerin ortaya çıkarılmasıyla başlar. Bu, açık kaynak yazılım topluluğuyla hata raporlama ve izleme veya e-posta listeleri ve proje sayfaları gibi yollarla iletişim kurularak sağlanır. Daha sonra, açık kaynak yazılım geliştiricileri bir görev seçer veya bu göreve atanarak çözüm aranır. Açık kaynak yazılımda çözümler için çoğu zaman birçok farklı olası yol olduğundan, en iyi çözüm dikkatlice düşünülerek ve hatta bazen geri bildirimi ile seçilmelidir. Geliştirici daha sonra kodu geliştirmeye ve işlemeye başlar. Kod daha sonra meslektaşları tarafından test edilir ve incelenir. Geliştiriciler, sürekli entegrasyondan elde edilen geri bildirimler yoluyla kodlarını düzenleyebilir ve geliştirebilirler. Liderlik ve topluluk projenin tamamından memnun kaldıktan sonra kısmen yayınlanabilir ve kullanıcı talimatları belgelenebilir. Proje yayınlanmaya hazırsa dondurulur ve yalnızca ciddi hata düzeltmeleri veya güvenlik onarımları yapılır. Sonunda proje tamamen yayınlanır.