TÜBİTAK

TÜBİTAK'çının kafasına bir fiske vurduğunuzda çıkan ilk ses "TÜ" olur. Kafa içerisinde oluşan ilk yankı "Bİ" sesini verir, üçüncü ve son yankının verdiği ses ise "TAK"tır. Yankılardaki ses değişimi, içerideki bilgi yığınından kaynaklanır:Yaratıcılık azaldıkça yankı sayısı artar. "TÜBİTAKTOKSEKSEK" gibi...

TÜBİTAK ve Mantıksız Çeviri Mantığı

Bugüne kadar hiçbir TÜBİTAK çevirisini 20 sayfadan fazla okuyamadım. Bilim dilini bu derece kabızlaştıran yankılı kafa, bir süredir PARDUS adında ulusal bir işletim sistemi pompalıyor. Öğrenimim ve iş deneyimim sırasında farklı işletim sistemi türleri gördüm fakat ulusal olanına rastlamamıştım. Ulusal İşletim Sistemi'ne karşı, Zaman Gazetesi sponsorluğunda Ilımlı İslâmî İşletim Sistemi...

Tekimcil Halayık Damacanası

Geçen gün bir internet sitesinde rastladım; sivri zeķâlı bir arkadaş "Design Pattern"ı "Tasarım Örüntüsü" olarak çevirmiş. Kanaatimce, Design Pattern kavramını sen ortaya atmadıktan sonra ister "Tasarım Örüntüsü" de, ister "Halayık Damacanası" de, fark etmez. Örnek: Singleton Design Pattern yerine Tekimcil Halayık Damacanası. Aynı şekilde, işletim sistemi kavramını temelinden sallamadıktan sonra ister ulusal işletim sistemi hazırla, ister ahlaklı çevik sportif işletim sistemi hazırla, fark etmez, memleketi kurtaracak değilsin.

Yani?

İlle de çevireceksek, çevirilerde birebir kelime karşılığı değil, anlam karşılığı kullanmalıyız. Örnek olarak, Çözüm Kalıbı, kavramı temsil etmekte Tasarım Örüntüsü'nden daha başarılı görünüyor. Tasarım Kalıbı da kullanılabilir. Tasarım Şablonu kullananlar da var, fakat Almanca kökenli "şablon" kelimesini telaffuz ederken ağzımın aldığı şekilden hoşlanmıyorum.

Hepsi Boş

Kendi kafamızla düşünüp üretmek neden bu kadar zor?

İsâbet

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.

Open Source for the Enterprise - Ya Da - Siz Söylemeyin, Analize Söyletin - Bölüm 4

Siz söylemeyin, analiz söylesin. Bu bölüm Return on Investment (ROI), yani yatırımın geri dönüşü kavramının açık yazılıma uygulanmasına ayrılmış. ROI raporu, tahmin edileceği gibi, yönetime sunuluyor ve IT'cilerce pek kanıksanmıyor, çünkü:

• ROI incelemesinin sonuçları öznel nitelikte olduğundan yapılan kabullere göre değişebiliyor.
• Açık yazılımın sistem mimarisine getirdiği sadeliği ve esnekliği rapora dahil edemiyorsunuz, yani sadelik ve esneklik kendi başına para etmiyor.
• IT'ciler kullanılan yeni teknolojinin gelirleri nasıl artıracağını kestirmekte zorluk çekiyor, ya da kestirmek istemiyor.

Fakat IT'ciler istemese de yöneticiler ve finansçılar ROI'ye bayılıyor ve ROI güzelce kullanılıyor. Kısaca, allem edip kullem edip, kabulleri esnetip ROI'yi makul değerlere çekiyorsunuz ve yönetime kabul ettiriyorsunuz. İkna meselesi.

AÇIK YAZILIM İÇİN ROI

ROI'nin formülü şu şekilde verilmiş:

(Geri Dönüş)/(Yatırım) = ROI

Geri Dönüş = (Kar Artışı + Tasarruf)
Yatırım = (Değerlendirme Masrafı + Lisans ve Bakım Masrafı + Kurulum Masrafı + Entegrasyon ve Özelleştirme Masrafı + Operasyon ve Destek Masrafı)

Bu denklemin anlamlı olabilmesi için bilinmesi gerekenler:

• Değerlendirilecek zaman dilimi nedir? 1 sene mi? 2 sene mi?
• Mukayese edilecek alternatifler mevcut mu? Kısa zamanda çok kar mı istiyoruz, uzun vadeli tasarruf mu istiyoruz?
• Şirketin beklediği en düşük ROI nedir?
• Masraflara altyapı giderleri (elektrik, barındırma, vs.) dahil edilecek mi?

Birden fazla alternatif için ROI hazırlanıyorsa, yukarıdaki konularda tutarlı olmak gerekiyor.

Şimdi payda kısmında bulunan masrafları inceleyelim:

• Değerlendirme Masrafı: Açık yazılımın değerlendirilmesi önce bulunmasını, ardından bir makinaya kurulup kurcalanmasını gerektiriyor. Bu işlemin süresi de yazılım ekibinin kabiliyetine göre değişiyor. Önceki bölümlerde anlatılanları biliyorsak, bu sürecin maliyetini az çok kestirebiliriz. Ticari yazılımda ise analiz rolünü IT değil yönetim alıyor.
• Lisans ve Bakım Masrafı: Açık yazılımın her zaman bedavaya gelmiyor: Red Hat ve SuSe Linux kurulum ve güncelleme paketlerine üyelik için, JBoss dökümantasyon için, Resin ise ticari kullanım için belli bir ücret istiyorlar. Birtakım şirketler de açık yazılım danışmanlığı yaparak sistemin kurulumu ve bakımı için belli bir ücret alıyorlar.
• Kurulum Masrafı: Açık yazılımda kurulum sihirbazları olmadığı için, yine IT ekibinin kabiliyet seviyesine göre kurulumun zaman maliyeti oluyor.
• Entegrasyon ve Özelleştirme Masrafı: Halihazırdaki sistemle uyum sağlamak için açık yazılıma eklenti yazılması gerekebilir, veya başka yazılımların kullanılması gerekebilir. Bu masraflar açık yazılım için daha yüksek oluyor çünkü ticari yazılım, birtakım platformlar için genişletilmiş oluyor. Fakat tabii ki açık yazılım kullanmak esnekliği artırıyor ve iyi bir IT takımıyla ticari yazılımın destek veremeyeceği bir platforma entegre edilebiliyor. Kullanılacak açık yazılıma ve IT ekibinin kapasitesine bakarak hazırlanan entegrasyon ve özelleştirme masrafı da paydaya ekleniyor.
• Operasyon ve Destek Masrafı: Sistemi kullanmaya devam ettikçe doğacak masraflar bu kaleme dahil edilmiş: test ortamının sağlanması, sistemin genişlemesi için yeni sunucuların eklenmesi, yedekleme veya çökmeye karşı kullanılacak yeni sunucular, vs. Yapılan analizin vadesi ve sistemin gerektirebileceği değişiklikler göz önünde bulundurularak bu kalem de kolayca hesaplanabilir.

Bu bilgileri kullanarak detaylı bir analiz yapıyorsunuz, Microsoft'un Linux ROI'sini Windows'tan düşük gösterirken yaptığı gibi kabulleri esnetiyorsunuz ve ROI'ye ne istiyorsanız onu söyletiyorsunuz. Güzel giyinin ve güzel kokun. Unutmayın ki, analizler, kendilerine istediğiniz şeyi söyletmeniz için vardır.

J7BE - Java 7 Bakkal Edition

Java'nın etrâfındaki kaosu dindirecek, dimağımı bulandıran sis perdesini yırtacak, basit olanı anlaşılmaz hâle getiren onlarca pazarlama numarasını tuzla buz edecek çözüm: Java 7 Bakkal Edition.

Ya Java'yı sâdeleştirin, ya da ölümüne razı olun.

Özgür zeķâya nasıl muhtâcız...

Open Source for the Enterprise - Ya Da - Ehline Helaldir, Naehle Haram - Bölüm 3

Bu bölümde yazar, bir kurumun açık yazılım kullanmak için sahip olması gereken yeteneği irdelemiş. Hangi olgunluk seviyesindeki açık yazılımı kullanmak için hangi yeteneklere ihtiyaç var? Elemanlarınızın yetenek seviyesini ve alabileceğiniz riskin büyüklüğünü nasıl tespit edersiniz? IT departmanınızın açık yazılım yeteneklerini nasıl geliştirirsiniz?

Yazar harika bir örnek vermiş: Yönetime açık yazılım kullanmak için başvuran yazılım ekibini, ailesinden eve yavru köpek almasını isteyen çocuğa benzetiyor. Aile "bakacaksan olur tabii" diyor. Çocuk hevesini alıp acı gerçekleri fark edince hayvancağızla ilgilenmeyi kesiyor, pisliği temizlemek de anne babaya kalıyor. Bu kabusu yaşamamak için yazılım ekibinizin yetenek seviyesini belirlemeniz gerekiyor.

AÇIK YAZILIM YETENEK SEVİYELERİ

Yukarıdaki grafikten anlaşılacağı gibi, en büyük azınlığı yenilikçi dahiler oluşturuyor. Başka bir azınlıksa statükocular. Toplumun genelinin kafa yapısını da yansıtan bir grafik olduğunu fark ettiniz mi?

Şimdi bu seviyeleri kısaca inceleyelim:

1. Başlangıç Seviyesi
   
   1. Açık yazılım paketlerinin kurulumu ve bu kurulumda kullanılan araç-gerecin (compiler, rpm, vs.) kullanımı hakkında yüzeysel bilgi sahibidir.
   2. Kullanılan işletim sistemi ve network sisteminden bihaberdir. Armut piş, ağzıma düş diyerek bu tür işleri operasyon ekibine yükler.
   3. Yazılım ayarlarından sadece temel olanlarıyla ilgilenirler: loglama konumunun belirlenmesi, portların seçimi, vs.
   4. Programın çalışması esnasında da sadece temel kontrolleri yapabilirler: program düzgün çalışmaya devam ediyor mu, donanım kaynakları yeterli mi, vs.
   5. Birden fazla açık yazılım birarada çalışıyorsa bunların arasındaki bağlantıyı sağlayabilir.
   Bu seviyedeki kullanıcılar bile açık yazılım kullanımı konusunda sıradan bilgisayar kullanıcısından epey öndedirler. Temel Linux, Apache, MySQL ve Mozilla Firefox bu seviyedeki kullanıcıların baş edebileceği seviyede örnekler...


2. Orta Seviye: Bu seviyedeki kullanıcının başlangıç seviyesinin üstünde sahip olması gereken yetenekler şu şekilde:
   
   1. Kurulum sırasında derleme yapabilir.
   2. Programın ayarları için gerekirse koda girerek temel değişiklikler yapabilir. Bu değişikliğin ardından kodu tekrar derleyip kurulumu yeniler.
   3. Açık yazılım community'sine aşinadır. Forumlarda etkindir, soru da sorar cevap da verir.
   Bu seviyeden sonra bir çıta var; bu çıtayı yukarıdaki grafikte de görebilirsiniz. Ne mutlu "Ben bu çıtayı atladım" diyene.


3. İleri Seviye: Çıtayı atlayan yazılımcının meziyetleri:
   
   1. Proje kodunun herhangi bir yerinde değişiklik yapabilir. Örneğin Linux çekirdeğine dalıp kafasına göre takılabilir.
   2. Proje kodunu, işletim sistemini, donanım kaynaklarını ve network'ü en iyi performans için evirip çevirebilir.
   3. Programın çalışması esnasında her türlü incelemeyi yapar, gerekirse çakılmaya karşı programlar yazar. Programın çalışmasına tamamen hakimdir.
   4. Kullanılan açık yazılımın kullandığı tüm framework'lere ve diğer açık yazılım araçlarına tamamen hakimdir. Gerekirse başka yazılımlarla beraber çalışması için koda kanca takar.
   5. Açık yazılımın yazıldığı programlama dilini adı gibi bilir. Ufak bug-fix'ler yapar, kodda istediği değişikliği yapar. Rahattır.
   6. Community'de kilit adamlardan sayılır. Açık yazılım camiasından güzel çevre yapmıştır, icabında uzman arkadaşlarından anında yardım alır.
   Bu kadar donanımlı bir adamı kadrolu çalıştırmanın ciddi bir tehlikesi var: işten çıkarsa göt gibi ortada kalırsınız. Yazarın bu tehlikeye karşı önerdiği çözüm bu seviyedeki yazılımcıları sadece kiralayarak, dış-kaynak olarak kullanmak.


4. Uzman: Açık yazılım dünyasının yıldızları olan bu zatların donanımını anlatmaya pek gerek yok. Uzman işte. Ünlü oluyorlar genellikle.

Şimdi ekibinizdeki yazılımcılara bakın, yeteneklerini belirleyin; bir de kullanacağınız açık yazılımın olgunluğuna bakın. Mümkün görünüyor mu?

YETENEK VE RİSK

Açık yazılım kullanarak geliştirdiğiniz yazılımın kaldırabileceği risk seviyesi de kararınızda etkili olmalı. İşte risk toleransına göre projeler:

1. Deneysel: Uçuş serbest. Dilediğiniz gibi bozun yapın.
2. Düşük Öncelik: Kullanılan sistemlerdir fakat uzun süreli çakılmalar pek önem taşımaz. Proje yönetimi için kullanılan Wiki siteleri bu sınıfa örnek gösterilmiş.
3. Bu Sınıfa İsim Bulamadım, Kitapta Operational Diyor: Bu uygulamaların 1-2 saatten fazla çakılı kalmaya tahammülü yoktur.
4. Kritik: Mesela bankaların ATM sistemleri bu sınıfa giriyor. En küçük çakılmaya tahammülü yoktur. Kullanılan açık yazılımda risk varsa bu sınıf için pek de makul bir seçim olmaz.

AÇIK YAZILIM YETENEĞİNİN GELİŞTİRİLMESİ

Bu mesele bir gecede olacak iş değildir. Eğitimi de zaman ve emek yatırımıdır. Ticari yazılıma para yatırırsınız, açık yazılıma zaman yatırırsınız; yani yine para yatırırsınız. Para para para. Demir ustası demiri döve döve öğrenir. Yazılımcı da yapa boza öğrenir. Ticari yazılıma yatırımla kıyaslandığında daha avantajlıdır, şöyle ki, açık yazılım konusunda kendini eğiten bir IT ekibinin yeni açık yazılım projelerini benimseme süresi gitgide azalır. Açık yazılım eğitimi bir şirket politikasıdır, bir düşünce biçimidir. Sevgiler.

İş Görüşmelerinden - Sürrealizmin Doruklarında - #1

Bir keresinde büyük bir IT firmasıyla iş görüşmesine girmeden önce kağıda SQL ve Java kodu yazmam istenmişti. Yazılımcının kağıt üzerine kod yazmasının bir benzeri, edebiyatçının çekiç ve çiviyle duvara hiyeroglif yazması olsa gerek. Yine aynı görüşmede beni sınayan cingöz mühendis:

- Peki design pattern'lar?

sorusunu patlatırken, o zamanlar halen "buzz"ını koruyan bu kavramı dağarcığından akıtmanın zevkini burun kanatlarını titreterek yaşıyordu. Sorunun genelliği ve anlamsızlığı karşısında afallayan ben:

- Hangisi?

bile diyemeyecek bir tutulma yaşamıştım. Hangi koşullarda? Hangi sorun için? Kimin design pattern'ı?

Sanatı sorunun içinde çözüm üretmek, hatta bunu bazen zevk için yapmak olan mühendisin kabiliyetini buna benzer sığ yöntemlerle ölçmeye çalışan insan kaynakları personeline birer kaynak makinası hediye etmek istiyorum. Bir sanat öğrenmek isteyen insan kaynakçıları bu makinayla en yakın kaynak ustasına başvurabilirler. İşinin hakkını veren sanatçı insan kaynakçıları müstesna...

İş görüşmesi maceralarımı paylaşmaya ilerleyen günlerde devam edeceğim. Açık yazılım serisinin 3'üncü bölümü ise yarın karşınızda olacak; biraz özleyin istedim.

Open Source for the Enterprise - Ya Da - Bazıları Olgun Sever - Bölüm 2

Evet, bazıları olgun sever. Açık yazılımın olgunluğu daha fazla döküman ve online bilgi, daha az bug ve daha çeşitli platform için destek ve uyumluluk anlamına geliyor. Peki açık yazılımın olgunluğu nasıl anlaşılır? Bu sorunun cevabını yine kullanıcı bulmak zorunda. Kitabın bu bölümü bu soruya sağlıklı bir cevap bulmanın yönetimi anlatıyor.

Açık Yazılımın Tuzakları

Açık yazılım seçiminde yapılacak hataların hazin sonuçları:

• Beklenenden daha fazla emek ve zaman istiyor
• Kullanılan sistemle uyumsuz
• Yazılımı geliştiren ekipten veya community'den destek almak imkansız

Yukarıdaki durumlara düşmek istiyorsanız, çok zekisiniz tebrik ediyorum, şu listedekileri eyleme koyunuz:

1. IT departmanınızın seçtiğiniz açık yazılımla ilgili deneyimi ve bilgisi olmasın.
2. Community desteği bulunmayan açık yazılımları seçmeye özen gösterin. Örneğin projenin forumuna en son post Mart 2002'de yapılmış olsun.
3. Projenin adı çok fazla duyuluyor diye, sadece popülaritesine bakarak seçim yapın.
4. Lisansında sorun olan, ticari babalarla başı belada olan projeleri tercih edin.
5. Projenin daha olgunlaşmadan yavaşlamış olmasına dikkat edin. En son bug-fix seneler önce yapılmış olsun.
6. Kullandığınız platform için uygun olmayan açık yazılımı tercih edin. Örneğin MS IIS, Oracle ve Solaris kullanıyorsanız Apache, MySQL ve Linux için yazılmış projelere yönelin.

"Yok, hayır, istemem, istediklerim aksi yöndedir" diyorsanız, buyrun size olgunluğu belirleyen etkenler.

Açık Yazılımın Olgunluğunu Belirleyen Etkenler

1. Liderlik ve Proje Kültürü: Daha önce de community'sine bak, open source'u al şeklinde ifade ettiğim gibi, açık yazılımın kalitesini proje lideri ve çevresindeki community belirliyor. Büyük açık yazılım projelerinin liderleri açık yazılım dünyasına katkıları sebebiyle haklı bir şöhrete sahipler (Gavin King->JBoss, Scott Ferguson->Resin). Proje liderinin tutumu da projenin kültürünü etkiliyor. Örneğin her eleştiriden kıl kapan bir liderse proje gelişemiyor. Bu yüzden, projenin olgunluğunu anlamaya çalışırken projenin liderine ve oluşturduğu kültüre bir göz atmak akıllıca.
2. Community'nin Şekli Şemali: Projenin kullanıcıları ve geliştiricileri arasında belirli bir ayrım oluştuysa, bu projenin olgunluğuna bir işaret olabiliyor. Forumlarda verilen cevaplara bakarak projenin community'si hakkında genel bir fikir edinmek mümkün. Ayrıca community'nin aktif üyelerinin çokluğu, download sayısının yüksekliği de iyiye işaret.
3. Destek Kalitesi: Yine forumlardaki aktiviteye, sorulan sorular ve verilen cevapların derinliğine ve -mevcutsa- Sıkça Sorulan Sorular bölümüne bakılarak destek kalitesini anlamak mümkün. Herhangi bir sorun yaşamanız durumunda ne kadar sürede ve ne kadar doyurucu bir cevap alabileceğinizi kestirebilirsiniz.
4. Kurulum Paketi Kalitesi: Açık yazılım projelerinin genellikle kurulum paketi falan olmuyor. Hatta büyük kısmını download ettikten sonra compile etmeniz gerekiyor. Eğer farklı işletim sistemleri için kurulum paketi varsa, pek şüpheniz olmasın, proje gayet olgundur, afiyetle yenilebilir.
5. Kod ve Dizayn Kalitesi: Ortalama bir yazılımcı, kodu ve dosyalandırma yapısını biraz incelediğinde kalitesini az çok anlar. Projenin kaynak kodunu inceleyerek geliştiricilerin projeyi ne kadar ciddiye aldığını anlayabilirsiniz. Olgun açık yazılım projelerinde bu konuya çok önem veriliyor, hatta bazı projelerde liderin elinden geçmeden tek satır kod commit edilmiyor. Koda bakınız, olgunluğu anlayınız.
6. Mimari Kalitesi: Bir önceki maddeye benzer bir madde. Kod mimarisini incelerseniz özenli mi özensiz mi olduğunu anlayabilirsiniz.
7. Test: Kodun içerisinde bol bol unit ve integration test bulunuyorsa iyiye işaret.
8. Diğer Projelerle Uyum: Projenin, depend ettiği diğer projelerin eski ve yeni versiyonlarıyla uyumu da olgunluğuna işaret ediyor. Farklı versiyonda bir dependency kullandığınızda çakılıyorsa, proje henüz gençtir, hayattan öğrenecekleri vardır. Bırakın öğrensin. Olgunlaştığında yersiniz.
9. Proje Web-Sitesinin Kalitesi: Kitapta bu madde sonlara konulmuş fakat bence ilk sıralara konulabilir. Projenin sitesini biraz kurcalarsanız projenin hangi aşamada olduğunu, ne kadar destek alabileceğinizi vs. kısa zamanda anlayabilirsiniz. Bu noktada yazar kendini tekrar etmeye başlamış.
10. Lisans Türü: Bu maddenin projenin olgunluğuyla pek alakası yok aslında. Yani projeyi kendi ürününüzle dağıtacaksanız tabii ki lisansının buna izin verip vermediğini bilmeniz gerekiyor. Ne alakası var bunun olgunlukla?
11. Baba Desteği: Projenin arkasında para babası şirketlerin desteği varsa (IBM ve Apache örneği) gönlünüz rahat olsun.

Bu bölümün sonunda, yukarıdaki kıstaslar kullanılarak projenin olgunluğuna not verebilmek için bir tablo konulmuş. Bu şekilde notlamaya ne kadar gerek var bilemiyorum. Projeyi kullanacak yazılımcıların bilgi ve deneyim seviyesini biliyorsanız, yukarıdaki kıstasları kullanarak yazılımın sizin için uygunluğunu değerlendirmeniz mümkün.

Başta da söylediğim gibi, bazıları olgun sever.

Open Source for the Enterprise - Ya da - Ucuz Etin Yahnisi - Bölüm 1

Ucuz etin yahnisi ne kadar iyi olabilir? Eti alan kişi etin kalitesinden anlıyorsa, yemeği pişiren kişi bu etten en lezzetli yemeği yapacak gönüle ve yeteneğe sahipse, yemeği yiyen kişi de yemek yeme adabını iyi biliyorsa ve damak tadı gelişmişse, ucuz etin yahnisi çok güzel olabilir.

Bu kitap, ucuz etten yahni yapmak isteyen IT departmanları için yazılmış. Cevaplanmasına yardımcı olduğu soru: Ucuz etten ne kadar iyi yahni yapabiliriz? Tabii ki bu sorunun cevabını vermiyor, fakat sağlıklı cevabı bulmak için sağlıklı yöntemler sunuyor. Ucuz etin getirileri kısaca şöyle:

• Sizi kendisine bağımlı hale getiren kasaplardan bağımsızlık
• Maliyetlerdeki muhteşem düşüş
• Ucuz mal pazarındaki binlerce bağımsız kasap, manav, mefruşatçı ve diğerlerine erişim (SourceForge, FreshMeat)

Açık yazılım kullanabilmek için gerekenler ise şu şekilde:

• Seçilecek etin kalitesinin, şöyle ete bakıldı mı hemen anlaşılması
• Hem seçim, hem pişirme, hem de saklama süreçlerindeki ustalığın çalışanlarda geliştirilmesi
• Yapılan yemek satılacaksa, kullanılan malzemenin lisansının gerektirdiklerinin anlaşılması (bu madde atılabilir, pek kimse takmıyor genellikle)

Açık Yazılım Tartışması

Yazılımcının ustası açık yazılımı sever çünkü: açık yazılım özgürleştirir, ucuzdur ve daha çok kontrol imkanı verir, sizi kontrol etmez, siz onu kontrol edersiniz.

Yönetici kısmısı ise genellikle açık yazılım istemez çünkü: bu malı bana satan yok, biraz tuhaf; hem bu yazılımcılar 3 gün derler, 5 günde yaparlar, bir sürü para... Bir de açık yazılımın desteği yok dökümanı yok belli bir firması yok... İşler kötü giderse ben kime bağırıp çağırayım? Yazılımcılara bağırıp çağırılmaz bırakıp giderler Allah korusun.

Akla en uygun yol ise, yahniyi yapmadan önce, kurumun ucuz etten ne kadar iyi yahni yapabileceğinin iyice düşünülmesi ve ona göre karar verilmesi. Kurum birikimsiz ve hımbıl ise en güzel ambalaj seçilecek, yetenekli ve zeki ise (Amazon, Google) açık yazılım seçilecek.

Açık Yazılıma Ne Kadar Hazırsınız?

Bu sorunun cevabı alınan etin kalitesine ve aşçıların ustalığına bağlı. Bir kısım açık yazılım, destek ve döküman eksikliği sebebiyle çok ciddi bilgi gerektirirken MySQL, Apache, PHP gibi daha olgun projeler ciddi bir bilgi birikimi gerektirmiyor. Kurumun yeterince parası varsa, takımını ucuz etten en iyi yahniyi yapacak şekilde eğitebiliyor, bunun için gereken zamana ve emeğe kıyabiliyor. İyi de yapıyor, çünkü IT takımı cin gibi oluyor ve kurumu havalara uçuruyor. Ne de olsa bir kurumu taşıyanlar önce hizmetliler, daha sonra IT'cilerdir.

Karar verilirken sorulacak sorular:

• Yapılacak yemek nedir?
• Bu yemeğin malzemesini sağlayan açık kaynaklı manavlar ve kasaplar mevcut mu?
• Mevcut kasap ve manavların malzemeleri ne kadar kaliteli? Bu kaliteyi değerlendirecek akıl sizde var mı?
• Bu akıl sizde yoksa ne kadar zamanda edinebilirsiniz? Bir bilene danışsanız olur mu?
• Bütün masraflar toplanınca "Yahu Migros'tan alsak daha ucuza gelirdi ve daha kaliteli olurdu" deniliyor mu?

Kısaca, açık yazılım kullanmak bilgi-işlem birimine ciddi bir sorumluluk getiriyor. Bulunması ise ticari yazılım kadar kolay değil çünkü reklam yapılmıyor, arayıp bulacaksınız. Bu da gayet normal çünkü bu yazılımı üreten adamların "pazarlama bütçesi" gibi kavramlarla pek işi olmuyor.

Açık yazılımın dökümantasyonu da sağlıklı olmuyor çünkü hiçbir yazılımcı döküman yazmayı sevmez. Açık yazılım, yazılımcılar için yazılımcılar tarafından geliştirilir. MySQL ve Apache gibi büyük projeler hariç bilgi düzeyi düşük sıradan kullanıcı genellikle umursanmaz.

Fakat; açık yazılım beleştir, ve kaliteli olma ihtimali vardır. Bugünlerde bazı açık yazılım kuruluşları 24/7 kurumsal destek için ücret alıyorlar fakat ticari yazılımla kıyaslandığında halen çok ucuz kalıyor.

Açık Yazılım Nasıl Oluşur, Nasıl Yaşar, Nasıl Ölür, Cennete mi Gider Cehenneme mi?

Programcının biri kendi sorununa çözüm üretmek için bir program yazar. Bu ilk çözümü aynı sorunu yaşayan diğer yazılımcılarla paylaşır. Proje ilgi görürse daha çok katılımcı ve kullanıcı bulur. Projenin lideri ve yönetim biçimi ortaya çıkar ve proje sürekli hale gelirse olgunlaşmaya başlar. Başarı devam ederse büyük şirketlerden ve hatta devletlerden de maddi manevi destek alır ve yazılımcılar dışında da kullanıcı bulmaya başlar(OpenOffice).

Proje bu aşamaların herhangi birisinde ölse bile kodları internette bulunabilir, dileyen kişi alıp geliştirmeye devam edebilir. Yani açık yazılım projesinin ölmesi yoktur, durması vardır. MySQL örneğinde olduğu gibi ateş tarafından yutulursa ne olur, onu da ilerleyen zamanda göreceğiz.

Projenin değerlendirilmesi için çevresindeki topluluğa bakmak önemlidir. Yani, community'sine bak, open source'u al durumu vardır.

Ürünleştirme: Açık Yazılımda Sanki Birşeyler Eksik Ama Ne?

Yazılımcıların yüzde 99'u ürünleştirmeden, pazarlamadan anlamaz. Açık yazılım bu yüzden solgun ve renksiz gözükür. Rengi verecek olan kullanıcıdır. Açık yazılım kullanacak kurumun bunu göze alması gerekir.

Ticari Yazılım ve Açık Yazılımın Risk Karşılaştırması

Sıkıldım. Bu kitap aynı şeyleri tekrar edip duruyor. Bu bölümü de sizin hayalgücünüze bırakıyorum. Buraya kadar sabredip okuduysanız gerisini tahmin edersiniz. Sevgiler.

Açık Kaynak Kodlu Kurumsal Çözümler

Bir süredir açık kaynak kodlu yazılımın kurumsal çözümlerde ne kadar kullanım alanı bulabildiğini, kurumların açık kaynak kodlu yazılıma geçişte yaşayabileceği sorunları ve bu geçiş sonucu alacakları riski ve elde edecekleri faydaları merak ediyordum. Biraz araştırma yaptıktan sonra bu konu üzerine Dan Woods ve Dani Guliani tarafından yazılmış bir kitap buldum: Open Source for the Enterprise.

Kitapta seçim ve uygulama süreci başından sonuna kadar bütün aşamalarıyla incelemeye alınmış. Açık kaynak kodlu yazılımın bir kurum için ne gibi riskler taşıyabileceği, kurumun bu risklere karşı yazılımın seçimi ve uygulanması aşamalarında ne gibi önlemler alabileceği ve açık kaynak kodlu yazılımın firmalara sunduğu geniş olanaklar detaylı olarak incelenmiş. İnceleme birçok noktada yaşanmış örneklerle zenginleştirilmiş.

Kitap toplam on bölümden oluşuyor. Yarından itibaren her gün bir bölüm olmak üzere kitabın özetini burada yazacağım.

IBM'in Eclipse IDE'yi açık kaynak kodlu hale getirmeden önce projeye 40 milyon dolar yatırdığını biliyor muydunuz?

Yapılacaklar Listesi

Planlar ölü doğar. Kendi tecrübeme dayanarak söyleyebilirim ki işe yarayan plan değil, planlamadır. Bu planlamanın ürünü sabit bir plan değil, her an değişebilen bir haritadır. Kağıt üzerinde bu esnek ortamı sağlamak benim için mümkün olmuyor. Bir ara Google Calendar kullandım; tasarımı gayet güzel ve kullanışlı fakat internete bağlanmak zorunda olmam Google'ın çözümünden vazgeçmeme sebep oldu.

Bu iş için kullanılabilecek ücretsiz bir yazılım buldum: Swift To-Do List. Programı şu adresteki "Download Now" linkinden indirebilirsiniz:

http://www.dextronet.com/swift-to-do-list.php

Şimdilik Türkçe desteği yok fakat yakında olabilir. Görsellik açısından biraz zayıf olsa da çok hafif ve kullanışlı bir program.