Open Source for the Enterprise - Ya Da - Açık Yazılım Stratejisi - Bölüm 5

Elimde bedâva Photoshop varsa Gimp kullanır mıyım? Hâyır. Photoshop'a 700 dolar ödemek zorundaysam Gimp kullanır mıyım? Evet. Gimp'in salak yaratığını sevebilir miyim? Hâyır. Açık yazılım maskotlarının neden bu kadar sevimsiz olduğunu açıklayabilir miyim? Belki. Örnek: Gimp yaratığı, Java Duke, Linux pengueni... Açık yazılımda ÇOK ciddî bir tasarım eksiği var. Örnek:Her neyse... Kitabın beşinci bölümü, bundan önceki bölümlerden faydalanarak sisteminize açık yazılımı dâhil edip yedirmeniz için izlemeniz gereken stratejiye ışık tutuyor.

ENJEKSİYON

Önceden de defalarca söylediğim gibi, açık yazılıma girişecekseniz takımınızın öğrenmeye açık ve zekî olması gerekiyor. Bilgiyi tek kişide toplamayın, takıma yayın. Böyle bir takıma sâhip olacak imkanlar mevcut değilse dışkaynak kullanımını düşünün. Başarılı bir stratejinin temel noktaları şunlar olabilir:

• Ekibinizi tanıyın ve neler yapabileceklerini bilin.
• Açık yazılımı güvenli bir ortamda deneyin, takımınıza yazılımı tanımak ve onunla oynaşmak için gerekli kaynağı verin.
• Takımın yeteneğini, önce değerlendirme, ardından kurulum ve ayarlama ve son olarak uygulama ve bakım alanlarında belli bir süreye yayarak kuvvetlendirin.
• Bu yeteneği ve bilgiyi kişilerin değil, kurumun yetenek ve bilgisi haline getirin (ortak bilgi veritabanı, bilgiyi kişilere yaymak, vs.).
• Bilgi ve yetenek arttıkça ve fırsat oldukça daha çok açık yazılım kullanın.

Ekibin yetenek seviyesine göre uygulanabilecek adımlar:

1. Kundak Safhası:
   • Kurulumu ve ayarlaması en kolay açık yazılımı kullanın.
   • Kurulum ve destek için gereken yeteneği takımda oluşturun.
   • Hangi dilde ve hangi alanda yazılmış açık yazılımın takım için daha uygun olduğuna karar verin.
   • Takımı Linux'a ucundan bulaştırın.
2. Emekleme Safhası:
   • Daha ileri seviye açık yazılımın kurulumu, ayarlanması, çalıştırılması ve gözlemlenmesi için gereken yeteneği takımda geliştirin.
   • Odağı belli bir alana ve programlama diline yöneltin.
   • Linux'un çözümün bir parçası olup olmayacağına karar verin.
3. Yürüme ve Koşma Safhaları: Efendim bu aşamaya geçmeden önce kendinize bir sorun: Bu kadar ileri gitmeye gerçekten gerek var mı? Cevap evet ise bu noktadan sonra bilgiyi ve yeteneği kuruma yaymanız çok zor, kilit adamlar oluşacaktır. Sizin için güzel bir alternatif, açık yazılım danışmanlık şirketlerinden sürekli destek almanız olabilir. İlle takımı bir önceki aşamadan bu aşamaya geçirmek istiyorsanız açık yazılım projelerine eklentiler geliştirmeye başlayabilir, Linux çekirdeğinde değişiklikler yaptırabilirsiniz.

UYGULAMA

Bu kısımda birkaç gereksiz sınıflandırma var. Enjeksiyon başlıklı kısımdaki bilgi yeterlidir.

YÖNETİM

Kurumun boyutuna göre açık yazılım kullanımının yönetimi değişiyor. Küçük firmalarda takım ve lider(ler) biraraya gelip sözlü ve esnek bir anlaşma sağlayabilirler fakat büyük kurumlarda bu işin resmîyete dökülmesi gerekiyor: raporlar, imzâlar, mühürler, kilitler, vs. Bu resmî stratejiyi oluşturacak sorulara şunlar dâhil olabilir:

1. Hangi alanlarda ve hangi durumlar için açık yazılım kullanılacak?
2. Açık yazılım bünyeye dâhil edilmeden hangi kıstasları sağlaması gerekiyor?
3. Hangi durumlar için hangi lisanslar kabul edilebilir?
4. Açık yazılım ürün ortamında kullanılacak mı?
5. Kurum açık yazılım geliştirilmesine destek verecek mi? Geliştirilen kod umuma açılacak mı?
6. Açık yazılım geliştilmesinde kaç kişilik bir takım çalışacak?

Büyük bir kurum bunları kağıda dökerse ileride doğabilecek felâketlerden kendini koruyabilir. Sonuna kadar katılıyorum. Hattâ küçük firmalar da bu konuları kağıt üzerinde sabitlemeli. Disiplin için bu gerekiyor. Sözler havada esniyor hâfızada değişiyor, yazı kalıyor. Ciddiyim. Kağıda dökünüz.