Bir devrin sonu…

Pardus proje yöneticisi iken Özgür Yazılım, Linux ve Pardus ile ilgili günlük girdilerimi Pravda Pardus adını verdiğim pardus.org.tr alanında yayınlıyordum. 2008 yılında Avrupa Komisyonu’nun benim de katıldığım bir toplantısı / çalışması ile ilgili olarak yazdığım eleştiri neredeyse bir diplomatik krize yol açayazınca kişisel görüş içeren yazılarımı kişisel günlüğüme, ET’s R’n’R Gumbo‘ya taşıdım, Pravda’da yalnızca kuru resmi duyuruları yapmaya başladım. Pravda, Pardus’tan ayrıldığım gün durdu, yeni TÜBİTAK kaldırana kadar donmuş haliyle yayında. Bugün itibarıyla, Pardus için son yazımı yazdığıma göre, R’n’R Gumbo da bu açıdan işlevini tamamladı. Artık burada Özgür Yazılım ve Linux üzerinde yazmayacağım…

Peki bu konularda hiç mi yazmayacağım? Yoo, yazacağım. Hatta geçtiğimiz yıllara göre daha fazla yazmak niyetindeyim. O zaman nerede yazacağım? Yeni blog alanımda yazacağım. Henüz hazır değil, ama blog.linuxera.com/tekman gibi bir adresi olacak muhtemelen. Zaman zaman kontrol edin bakalım adres hayata geçmiş mi?

Peki burada ne yazacağım? Burası yeniden kişisel web günlüğüm olacak. Seyahatlerim (geçtiğimiz haftalarda bir Antakya gezimiz oldu, yazacağım), yediklerim içtiklerim (örneğin National Geographic Türkiye‘nin geçen aylarda dağıttığı 50 Meyhane ekinde yer alan mekanları 2015 sonuna kadar tamamlamak niyetindeyim, oraları yazacağım), pek acemisi olduğum sportif hobilerim (yelken ve uzun zamandır ara verdiğim SCUBA), pahalı (?) meraklarım (kalem, mürekkep, saat ve puro), okuduğum kitaplar (birkaç tane yelken kitabı bitirdim, onları belki toplu halde, birkaç tane ekonomi, birkaç tane cumhuriyet “tarihi” kitabı okuyorum, onları da bitince), izlediğim filmler ve dinlediğim müzikler ve diğer şeyler hakkında yazacağım burada. Epey zamandır sessiz ve durgundu, twitter başta olmak üzere hızlı sosyal ağlar sağolsun, inşallah yeniden canlandıracağım buraları…

Son olarak bir ifşaatta bulunayım, merak edenleriniz vardır belki: Blogun adı neden ET’s R’n’R Gumbo? Çünkü benim ilk blogumun adı buydu. “Başka blogun mu vardı, bu senin ilk blogun” diyeceksiniz, demeyin… Yanılmıyorsam 1994 yılında, internet daha fena halde körpe, Mosaic ve www memlekete yeni gelmişken, ben Bilkent Üniversitesi Fen Fakültesi’nde bilişim işlerini yürütürken… bir “blog” oluşturdum kendime. Son derece basit ve sade bir web sayfasında, tam da biraz önce yazdığım şeyleri, birer-ikişer sözcük ve ufak birer resim ile anlatan. Bir süre güncellemeye çalıştım, ama benden başka okuyanı olmadığını görünce ve zaman sıkıntısı yaşamaya başlayınca bıraktım. Taa 10 yıl sonrasına kadar. İşte o web sitesinin adı R’n’R Gumbo idi, pek severek dinlediğimiz Professor Longhair‘in meşhur ve efsanevi Rock ‘n Roll Gumbo albümüne ithafen. Gumbo ise özellikle New Orleans yöresinde pişirilen karışık deniz mahsulü ve sebze çorbasına verilen isim. Eh, burası da bendenizin, özellikle rock ‘n roll eğilimli, ortaya karışık web günlüğü ya 🙂

“yapma demiyorum, yine yap …”

18 Aralık 2011’de o zamanki mesai arkadaşlarıma gönderdiğim ve Pardus’tan ayrılışımı bildiren e-postada

Her işime yaptığım muameleyi buna da yapacağım: “Kapıdan çıkınca kafandan da  çıkar!” Bu nedenle Pardus’un geleceği, şusu, busu konusunda orada  ya da  burada ahkam kesmeyeceğim;

sonra da 2 Ocak 2012’deki tweet’imde

az kaldı, 12 saat sonra içinde “Pardus” geçen cümleler kurmamaya başlayacağım… ya sabır!

demiştim. Ama sözümde dur(a)madım, ayda/iki ayda bir (nasıl saydığımıza bağlı olarak) Pardus ile ilgili bir tweet yapmışım, birkaç kez tweeter sohbetine/tartışmasına dalmışım… Dahası, Danışma Kurulu ve eski ve yeni TÜBİTAK yönetimleri üzerine blog girdileri yazmışım. Allah ıslah etsin, ne diyeyim…

Bu yıl başında, özellikle yeni girişimimiz / işimiz ile tam ve fazla zamanlı ilgilenmeye başlayınca bu kez kendime söz verdim, ve sözümü tutuyorum. Bu istisna hariç: TÜBİTAK’ın “Pardus” adı altında çıkardığı dağıtım  ile ilgili olarak, ve aslen tarihe kayıt düşme görevini yerine getirmek amacıyla, birşeyler yazmak zorundayım. Tartışanlara, yapan ve yapmayanlara (isterlerse) yardımcı olması için; damdan düşmüş olmam hasebiyle…

TÜBİTAK UEKAE bünyesinde Eylül 2003’de başlatılan ve adını, Ulusal Dağıtım’dan, uludağ koyduğumuz projenin daha yön belirleme safhasında, o zamanlar proje yöneticisi olan Alp Öztarhan, ilk teknik elemanlarımız sevgili Barış Metin ve sevgili Serdar “Hoca” Köylü ile, zaman zaman da Görkem Çetin’le seçeneklerimizi tartıyorduk. Başbakanlık, bir “milli işletim sistemi” geliştirilmesini düşünüyordu, arada “açık kaynak” lafı geçiyordu; hepsi bu! Boşlukları doldurmak bize düşmüştü. Biz de dört seçenek belirledik (ilki hariç kod adlarını şimdi koyuyorum, açıklama ve değerlendirmeleri de 9 sene öncesine arada edindiğim tecrübeyi de katarak yapıyorum)…

“Red Hat Türkiye”

Nedir: Özgür Yazılım felsefesi ve pratiği açısından her dağıtım “bizim” ve “milli/ulusal” dağıtımımız sayılabilir, sözcükleri azcık eğip bükersek. Dolayısı ile aslında bir dağıtım/işletim  sistemi geliştirmeye gerek yok. Herhangi bir “özgür” dağıtımı “milli işletim sistemi” olarak belirlemek mümkün. Sonuçta Başbakanlık “üretin” demiyor ki, kullanmak için istiyor. Alalım bir (örneğin Linux) dağıtımı, belki üzerine az-biraz görsel makyaj, tamam! Asıl enerjimizi milli işletim sisteminin kullanılmasına verelim. Marka/fikri mülkiyet konusunda hassassanız ve başka planlarınız varsa CentOS gibi bir “temizlik” yapabilirsiniz, kendi markanızı kullanırsınız; yoksa doğrudan adıyla sanıyla seçtiğiniz dağıtımı…

Avantajı/Dezavantajı: Temel avantaj, tabii ki, maliyet etkinliği. Neredeyse hiçbirşey yapmadan bir “milli işletim sistemi” sahibi oluyorsunuz. Dezavantajları çeşitli: Bilgi birikimi oluşturamıyorsunuz, özellikle bir dağıtımın/işletim sistemi iç işleyişi konusunda (ki bu özellikle Alp’in altını kalın kalın çizdiği bir gerek, neredeyse ön şart idi). Avantajı, altyapı yerine uygulamalara ağırlık verebiliyorsunuz (ki bu noktayı daha en başlarda zamanın LKD yönetimi ısrarla vurgulamış ve bir dağıtım geliştirme işine hiç girişmememizi önermişti). Dezavantajı, bu şekilde Amerika’nın Seattle kentinde işletim sistemi geliştiren bir şirketle işbirliği yapmaktan çok da uzağa gidemiyor oluşunuz (Özgür Yazılım vurgusunu kaldırırsak). Bir başka dezavantaj yol haritasına hakim olamamak, yarın bürgün Başbakanlık “ben milli işletim sisteminde şöyle şöyle özellikler istiyorum” dediğinde, “ama efendim, şu şu firması/dağıtımı onu yapmadan bizim yapabilmemiz pek mümkün değil” demek zorunda kalmak.

Netice: Bu seçenek hızla elendi 🙂 Nedenleri çeşitli: Bilgi birikimi yolunun kapalı olması, TÜBİTAK çatısı altında yürütülecek bir araştırma ve/veya geliştirme projesinden çok bir “iş geliştirme” işi olması, yol haritası bağımlılığı, …

“Törkiş Ubuntu”

Nedir: Kendi dağıtımımızı yapmak, ama iş yükünün hallice kısmını ana kaynağa (upstream) itelemek. Bu sayede bir yandan gerçekten bir “milli işletim sistemi” geliştiriyor olacağız, diğer yandan da binlerce (o sıralarda debian paket sayısı 18 binlerdeydi, yanlış anımsamıyorsam)  paketi yapma ve entegre etme işi ile uğraşmamız gerekmeyecekti. Bir süredir aramızda konuşup analiz ettiğimiz “mevcut Linux dağıtımlarının yanlışları”, “neden bu yıl da masaüstünde Linux’un yılı ol(a)madı”, vb konularda doğrusunu yapma olanağı da bulacağız,  çünkü “Red Hat Türkiye”den farklı olarak kaputu açacağız ve elimizi pisleteceğiz bu sefer. Tam bir Özgür Yazılım metodolojisi uygulaması…

Avantajı/Dezavantajı: Yine önemli bir avantaj maliyet, örneğin yüzlerce geliştiricisi olan debian’ı temel alsanız ne biçim işgücü tasarrufu sağlarsınız, değil mi? Bilgi birikimi konusunda da özellikle “Red Hat Türkiye”ye göre avantajlı, kaynak kodunun içine girip gerekli yerlerde elliyorsunuz bile,  örneğin siz de fedora geliştiricisi oluyorsunuz… Yol haritası konusunda bağımlılık kısmen devam ediyor, ama “Red Hat Türkiye” kadar değil. Gereken bir özelliği girip kendiniz ekleyebiliyorsunuz. Ama örneğin Ubuntu’nun Unity seçimi gibi tmel yol ayrımlarında temel aldığınız dağıtıma bağlısınız. Burada temel sorun çatallanacağınız ana dağıtımı bulmak / karar vermek! Vurgulamak istiyorum: Vakit  2004 başı, Red Hat daha yeni fedora’yı çıkarmış ortaya, SuSE’yi Novell almış, geleceği belirsiz, debian kararlı sürüm çıkaramıyor… Ubuntu daha ortalıkta yok, Mark Shuttleworth ilk uzay turisti olmanın keyfini sürüyor daha 🙂 En yakın aday Mandrake, onun da iş planı karmaşık, yarı açık-yarı kapalı… Gentoo teknik ekibin iştahını kabartıyor gibi görünse de hedeflediğimiz masaüstü kullanıcısı için fazlasıyla hantal ve teknik!

Netice: O aralarda bu seçeneğin destekçisi çoktu. Başta Alp geliyor, aklımda kalan bir başkası Recai Oktaş, sanırım 19 Mayıs Üniv’den, yanılmıyorsam Görkem de bu yola yönlenmemizi istiyordu, açık ve net bir şekilde söylememiş olsa da. Çok yakın vakitte, daha geçen ay, Umman’da ulusal Özgür Yazılım girişimlerini anlattığım konferansın dvetli konuşmacılarından birisi de laf arasında “neden yeni bir dağıtım neden -örneğin- debian değil” diye sordu; yani son derece geçerli bir seçenek! Bu seçenek “Pardus” ile birlikte sona kaldı, ama mevcut Linux dağıtımlarının çatallayarak düzeltilemeyecek denli büyük ve kronik sorunları olduğu saptamasına (siz isterseniz NIH – Not Invented Here sendromu da diyebilirsiniz) dayanarak elendi sonunda.

“VanX”

Nedir: “Tam milli” işletim sistemi! İlk satırından sonuncusuna kadar bizim yazdığımız, içinde ne olduğunu en iyi ve en ok bizim bildiğimiz (biz koyduk çünkü) bildiğimiz… Finlandiya’da üniversite öğrencisi yapmış, biz niye yapmayalım. Ne fikri mülkiyet sorunu var (ister GPL yap, ister BSD, ister kendi lisansını), ne “milli/ulusal” olmasında dert. Neden VanX mi? Onu da sevgili Onur Küçük’e soracaksınız, Pardus içi anı/anekdotlardan biri 🙂

Avantajı/Dezavantajı: En büyük avantajı bilgi birikiminde: Sıfırdan bir işletim sistemi yazıyorsunuz, bunu getireceği bilgi ve tecrübeyi başka ne getirebilir? Yol haritası tümüyle bağımsız, istediğinizi koyun, yarın beğenmediniz -hoppa- çıkartın! Dezavantajı ise öldürücü: Maliyet! O sıralarda ya da hemen sonrasında Linux Vakfı’nın yaptırdığı araştırma Linux çekirdeğinin “maliyet”ini 800 milyon ABD Doları olarak buluyordu. Nereden baksanız en az 7.000 kişi-yıl karşılığı bir emek…  Memleketteki tüm bilgisayar mühendisi ve programcıları dizseniz (ve 9 kadının 1 ayda bebek doğurabileceğine inansanız) bile 1 yılda tamamlanacak bir proje. Ki bu karmaşıklıkta bir proje milyonlar ve milyonlar harcandıktan sonra tamamlanamayacağı anlaşıldığı için kapatılır ve rafa kaldırılır genelde. Üniversitede dönem ödevi olarak yapacaksanız, ne ala! Ama “milli işletim sistemi” yapmak istiyorsanız, olmayacak dua 🙁 Pardus ortaya çıktığında ve popülerleştiğinde bu işe soyunduğunu ilan eden C ve Sistem Programcıları Derneği de havlu atmış anlaşıldığı kadarı ile, çünkü olmaz. Biz de yıllarca “bu Linux, bunun neresi milli” diyenlere bunu anlatmaya çalıştık, ama hala duymayan / anlamayan kalmıştır mutlaka 😉

Netice:  İlk anda elendi ve bir daha konuşulmadı…

ve … Pardus

Nedir: Linux ve Özgür Yazılım temelini kullanarak, ama “mevcut Linux dağıtımlarının yanlışları”, “neden bu yıl da masaüstünde Linux’un yılı ol(a)madı”, vb konularda doğrusunu yaparak bir dağıtım geliştirmek. Yeni bir paket sistem şart, çünkü mevcutlar şişmiş, kendi işini bırakıp sistem yönetmeye kalkmış, başarısız (biz söylemiyoruz, 2002 yılında dpkg lider  geliştiricisi söylüyor) ve yeniden yazılmalı… Yapılandırma yönetim çerçevesi ve sistemi gerekli, çünkü masaüstü Linuxlar insan evladı için değil (işte Ubuntu’nun mottosu…). E bunlar işin içine girince ilkinden sonuncusuna tüm paketleri de biz (yeniden) yapacağız…

Avantajı/Dezavantajı: Avantajları çok: Bilgi birikimi, yol haritası bağımsızlığı… Öte yandan olurluğu var, “VanX” gibi değil: en erken hesaplarımıza göre  15 kişilik bir ekiple, 1 yılda, 10 kişi-yıl çaba harcayarak (“VanX”in neredeyse binde biri!), 500.000 “milyon TL” harcayarak (Kasım 2003 parası, enflasyonu hesaba katsak herhalde şimdinin 1,5-2 milyon TL’si)  cillop gibi bir dağıtım çıkarmak mümkün. Dezavantajı tek: Dağıtım oluşturmak için gereken her işi kendiniz yapacaksınız… Dağıtım için upstream sizsiniz, sırtınızı yaslayacağınız kimse yok. Bu bir yandan projenin karmaşıklığını artırırken aynı zamanda maliyetini de yükseltiyor…

Netice: Biliyorsunuz… Pardus seçildi ve yüründü. Kim mi seçti? Yukarıda adı geçen ekip elemanları tavsiyesi ve yönlendirmesi ile UEKAE’de projeyi izlemek ve yönlendirmek üzere kurulmuş gayrı resmi bir kurul (ben “YönK” adını vermiştim) ve zamanın UEKAE Müdürü. Ama aslen biz… Pardus ekibi!

2004 başlarında kimi sıkıntılar, farklı yaklaşımlar söz konusu oldu; Eylül 2004’de yeniden yapılanmaya gidildi; Şubat 2005 Çalışan CD (dikkat ediniz, ilk kez Live CD’ye Türkçe bir karşılık getirdik, sevgili Gürer’in kulakları çınlasın, “Çalışan” CD!) ve 26 Aralık 2005 Pardus 1.0… Kasım 2003’de zamanın UEKAE Müdürü’ne 15 kişiye ulaşacak bir ekiple ve 500.000 “milyon TL” harcayarak Pardus 1.0’ı (o zamanki kod adını duymak bile istemezsiniz 🙂 27 Aralık 2004 tarihinde yayımlama vaadinde bulunmuştum. Eylül 2004’de projenin başına geldikten sonra ben dahil 10 kişiyi zar-zor bulan bir ekiple, projenin başından itibaren (ki sürtünmesi yüksek 4 + beyhude geçen 4 ay da dahil buna) maliyeti 755.000 “milyon TL” olacak şekilde ve de arada bir de Çalışan CD çıkarak, Pardus 1.0’ı 26 Aralık 2005 günü  yayımladık… Bunu başaran adıyla sanıyla Pardus Ekibi‘dir, ben olsa olsa onların önünü açtım. Ekim 2003’ten Aralık 2005’e giden yol her açıdan yaşanmaya değerdi! Proje başında ve  ben yönetimi aldıktan sonra YönK ve UEKAE Müdürü’ne yaptığım sunular, proje plan ve ölçeklemeleri, … bence çok değerli ve dersler içeren belgeler. Belki 10. yıl dolduğunda paylaşırım internetten 🙂

ve şimdi…

Seçimimizden pişman mıyım? Kesinlikle hayır. O zaman, verilenler ve istenene bakınca, kimi kısıt ve diğer etkenleri katınca, en doğru kararı verdik. “Törkiş Ubuntu” yönünde bir karar versek daha mı iyi olurdu? Pek birşey farketmezdi, olsa olsa Pardus’un uluslararası camiada görünürlüğü ve bilinirliği biraz daha az olurdu. Bakmayın “paket sayısı az olduğu için Pardus yaygınlaşamadı” geyiğine, kurumsal kullanıcıların istediği paketler ve diğer özellikler anında eklendi; MSB projesinde upstream olan LTSP’yi sollayıp, iki yıl da fark atıp Pardus Terminal Sunucu Projesi’ni hayata geçirdik, 5 buçuk yıl tık demeden, son üç yılı sıfır bakımla çalışan sistem bu. “Törkiş Ubuntu”nun da sonu aynı olurdu, ayrıntısını merak eden Pardus’un Makus Tarihi‘ni okusun… Orada paket sayısı, teknik zorluklar, şu-bu geçiyor mu hiç?

Peki bugün aynı işle görevlendirilsem, yine aynı seçimi mi yaparım? Kesinlikle hayır! Geçen 9 yılda Linux dağıtımları, özellikle kullanışlılık açısından, çok yol katettiler; artık ana dağıtım olarak kullanılabilecek birden fazla alternatif var. Şimdi benim seçimim “Törkiş Ubuntu” olurdu. Umman’da konuşmamdan sonra bir Ummanlı sordu, “biz de ulusal bir dağıtım geliştirmek istiyoruz, neye dikkat edelim” diye, ben de “sakın yapmayın, Ubuntu kullanın” dedim, ben öyle yapıyorum 🙂 2003’ün doğruları 2013’te geçerli değil, hayal görmeyelim…

Peki, yeni TÜBİTAK ne yaptı? Öncelikle Pardus seçimini tartışır gibi yapıp, “paket sayısı az” argümanını merkeze alarak, maddog ve Alex gibi şahitler eşliğinde, bu seçimin yanlış olduğuna karar verdiler. Ama bu tartışmayı düzgün, açık ve şeffaf bir şekilde yapmadılar. Bu bir… Sonra teknik ekibi çeşitli yol ve yöntemlerle tasviye ettiler, projeyi elemansız bıraktılar. Tüm bilgi birikimi, tecrübe, içtimai sermaye gitti. Ki projeyi bırakın, Özgür Yazılım camiasına, onu geçtim Türkiye’ye yapılan en büyük kötülüktü bu. Bu iki… “Törkiş Ubuntu” seçeneğine yöneldiklerini söylediler, ama gereklerini yerine getirmediler (o zaman endişe ve düşüncelerimi yazmıştım).  Sonunda döndüler “Red Hat Türkiye” yaptılar. Bunu yaparken de son derece ketum, kapalı ve merkezci bir tavır ve yöntem kullandılar.  Bu üç ve dört…Ve  -ki benim açımdan en kötüsü- yeni dağıtımlarına “Pardus” adını verdiler. Bu da beş…

Şunu vurgulayalım: Pardus, TÜBİTAK’ın markası. İstediğini yapar, istediği gibi kullanır. Yine de kamu hizmeti görmesi, kamu kaynağı kullanması, Özgür Yazılım’a bağlılığını önce ve şimdi dile getirmesi, camia(lar)a karşı sorumluluk taşıması, … nedenlerle tam da öyle değil.  Bizler de, Pardus adının bir marka haline gelmesinde emeği geçenler, vefa ilkesi çerçevesinde bazı şeyleri -en azından etik anlamda- sorgulama hakkına sahibiz!

ve sonra…

Bir kere, Pardus yalnızca bizim dağıtımımızın adı değildi. Pardus, Özgür Yazılım yolu ile Türkiye bilişim pazarını dönüştürme projesinin adıydı. PiSi ve ÇoMar’dan başlayıp  bireysel ve kurumsal sürümlere, oradan Pardus Göç ve Eğitim Ortakları’na, taa FATİH projesine ve Türkiye’de Özgür Yazılım üretme ve kullanma politikasına uzanan bir proje… Bu proje aşağı (teknik) katmanlarda başarılı oldu, orta (iş) katmanlarda elinden geleni yaptı, ama üst (politika) katmanlarda sınıfta kaldı. Ayrıca değerlendirilir… Ancak şu anda bu projenin çoğu unsuru ve katmanı ortadan kaldırılmış durumda. Yeni teknoloji üretmiyorsunuz, bilgi birikimi harcanmış, FATİH’deki “Pardus” (daha doğrusu debian) göstermelik, Microsoft ile pazarlık amacıyla orada, politika namevcut… Yalnızca “Pardus” markasının, eski ekibin, eski UEKAE çalışanlarının kazandırdığı kurumsal “müşteri”lerle, ve yetkinliklerini geçtim, kimlikleri belirsiz bir takım “iş ortakları” ile, yeni TÜBİTAK’ın büyük desteği ile oluşan büyük fonlarla bir ekonomi oluşturmaya çalışıyorsunuz. Bu ekonomi bir tüketim ve tedarik ekonomisi olur, “Pardus”un amaçladığı ve hedeflediği üretim ve büyüme ekonomisi olamaz. Bu ekonomi, Daron Acemoğlu ve James Robinson‘a inanırsak, sürdürülebilir bir ekonomi olmaz, sonunda çöker… Ama pek çok istihraç modeli gibi bir süre başarılı görünebilir, yeni “müşteri”ler bulursunuz, yeni “iş ortakları” edinirsiniz. Ama sonunda kralın çıplaklığı ortaya çıkar ve tıkanır kalırsınız…

Ha, açılır ve şeffaflaşırsanız… “Pardus” adını kullanmaktan vazgeçip “Red Hat Türkiye” modelini benimsediğinizi ilan ederseniz; ya da bence daha iyisi gerçekten “Törkiş Ubuntu”ya dönerseniz… Süreçlerinizi daha katılımcı hale getirirseniz… Tedariğe olduğu kadar üretime (gerçek üretime, şu anki dağıtımınızda olan (daha doğrusu olmayan) üretime değil) değer vermeye başlarsanız… Ulusal politikalar geliştirilmesi yönünde doğru adımlar atar, farkındalığı artırıcı çalışmalar yaparsanız (ki bunların her ikisini yapmak için kaynaklarınız ve daha da büyük kaynaklara erişiminiz var, görebiliyoruz)… hem sürdürülebilirliğinizi sağlarsınız, hem Özgür Yazılıma katkı yaparsınız, hem de Türkiye’ye gerçekten değer katarsınız.

Ama bunları yapsanız dahi o dağıtıma “Pardus” demeyin, o Pardus değil çünkü…

Bir de, her halükarda, Pardus’un tasviyesinin muhasebesi yapılmalı zaman içerisinde, her yönüyle…

Evet, son duamız ile bu yazı tamamlandı. Artık Pardus hakkında yazacak birşeyim kalmadı diye düşünüyorum: En başını anlattık, ortasını anlattık, sonunu biliyorsunuz… Sözümü tutup çenemi kapatıyorum, belki 10. yılda yayımlayacağım bir dizi belge dışında 🙂

Birkaç feragat cümlesi: Red Hat ve Ubuntu sahiplerinin tescilli markaları, burada mecazi olarak kullanıldılar, “Red Hat Türkiye” ve “Turkish Ubuntu” diye oluşumlar / ürünler yok. VanX’de Van şehri adının kullanılmasının hiçbir açık ya da kapalı amacı yok, Onur Küçük teyit edecektir bunu 🙂 Şu anda çalışmakta olduğum firma Linux ve Özgür Yazılım konusunda faaliyet göstermekte ve kurumlara çözüm ve hizmetler sağlıyor. Yazıyı arzu eden TÜBİTAK ile olası rekabet durumumuz merceğinden okuyabilir. Bununla birlikte firmamın mevcut durumda bir “Pardus” “iş ortağı” olmak gibi bir niyeti yok, hatta eğlenceli bir şekilde adını mecazen kullandığım Red Hat firması ile ileri düzeyde iş ortağı durumundayız. Mevcut durum benim tarif ettiğim şekilde değişirse dahi TÜBİTAK iş ortağı olmak gibi bir niyetimiz de yok, Red Hat ile ortak olmaktan son derece memnunuz.

Pardus Havlu Attı mı?

Geçenlerde yazdığım Mobil, Pardus, vb. girdisinden hareketle sevgili Hakkı Alkan Pardus Erken Havlu Attı şeklinde bir yazı yazmış. Yanlış anlaşılmayı gidermek için birşeyler çiziktirmek gereği duydum.

Pardus tablet konusunda, ya da daha spesifik konuşursak FATİH Projesi bağlamında öğrencilere sağlanacak tabletler konusunda havlu atmadı! Mecbur kalmadıkça havlu atmak niyetimiz de yok…

Pardus’un tablet işine girmesinin basit bir teknoloji işi olmadığını; tam tersine çok ciddi bir iş modeli geliştirme, organizasyon ve icraat işi olduğunu söylüyoruz. Pardus’un FATİH tabletlerinde kullanılmasının şartnameye konulacak bir iki sözcük ya da cümle ile halledilemeyecek bir iş olduğunu söylüyoruz.

Mobil cihazlar bağlamında düşündüğümüzde bir işletim sisteminin seçiminin ardından işletim sisteminin sürdürülebilirliğini sağlama, içerik ve uygulama geliştirme, üretim ve dağıtım kanalları oluşturma, finansal fizibiliteyi sağlayacak bir pazar payı elde etme gibi teknik kısmı hayli az, iş (business) kısmı hayli çok bir dizi konunun modele dahil edilmesi gerektiğini düşünüyoruz. FATİH Projesi, Pardus doğru bir şekilde konumlandırılırsa, bu konuların hemen tümüne oldukça ciddi açılımlar vadediyor. Ancak bunun için, FATİH Projesi ve Pardus çerçevesi dışında ve çok üstünde, Milli Eğitim Bakanlığı, TÜBİTAK, ve hatta Bilim, Sanayi ve Teknoloji Bakanlığı, Ulaştırma Bakanlığı, Kalkınma Bakanlığı düzeyinde politikalar belirlenmesi, planlar yapılması ve uygulamaya geçirilmesi gerekiyor. Bunlar yapılırsa bırakın Pardus’un FATİH Projesi’nin gereksinimlerini karşılamak, küresel ölçekte rekabet eden, yüksek katma değer üreten bir çözüm oluşturacağını, Türkiye’nin bilişim ithalatını azaltacak, üstüne yazılım ihracatını artıracak bir yola girmenin mümkün olduğunu iddia ediyoruz.

Bunları yalnızca burada yazmıyoruz; kamudaki muhataplarımıza, özel sektörden potansiyel iş ortaklarımıza, burada da olduğu üzere kamuoyuna, elimizin ulaştığı dilimizin döndüğü herkese açıklıyoruz.

Pardus projesinin, özellikle 2007 sonrasında, önemli bir eksiği Amerikalıların deyişi ile “put your money where your mouth is” alanında geri kalınması idi. DPT, yeni adı ile Kalkınma Bakanlığı arz tarafında üretimi desteklerken talep tarafında, özellikle kamu alımlarında ve kamunun özgür yazılım politikalarında, gerekli ve/veya yeterli adımlar atılmadı. Pardus’un yaygınlaşması, hem de hayli oturmuş, güçlü aktörleri belirlenmiş ve fiili tekelin hüküm sürdüğü bir pazarda, Pardus projesi ve UEKAE’nin pazarlama ve ikna yeteneği ile sınırlı kaldı. Bu durumda da, ne yazık ki, umulan ve beklenen patlama yaşan(a)madı, 2007-2008’de oluşan momentum doğru şekilde kullanılamadı. Yalnızca birkaç cesur erkenci (early adaptor) tercihini Pardus’tan yana kullandı.

Bizim şu anda soğuk baktığımız aynı durumun, bu kez de Pardus isminin tablet şartnamesinde yalnızca bir seçenek olarak sokulması yolu ile, bir kez daha başımıza gelmesi…

Umarım açıklayıcı olmuşumdur…

Six Success Factors for National Open Source Projects

I have participated to the 2nd International Free/Open Source Software Technologies Workshop in Riyadh, Saudi Arabia few weeks ago. The Workshop was organized by and took place in the King Abdulaziz City of Science and Technology (KACST), an impressive campus for advanced technology research and development. Before the Workshop, my expectation was that I was here to share my experience and expertise with the participants. Nevertheless, the talks have proven me wrong, that there were very interesting developments taking place in Arabic open source community, and at the end I’ve learned much more than I’ve “taught”.

On the first day of the Workshop I delivered a talk on Pardus, spending few minutes on the lessons we have learned from the successes and failures of the last 7 odd years. I think it may be wise to summarize this part of the talk for those that are or may in the future walk the same walk. The title has “national” in it, but the same success factors should apply to regional and local governments, companies and other organizations alike, after a simple conversion of scales and terms.

Here are the six success factors for your open source project:

FINANCE

You have to have enough of it, throughout the project. If at any point of time you are short in cash, you should expect lots of other problems arise, closely and remotely related. At the beginning the requirements are modest, and you may easily find a sponsor/investor for your project. But you have to grow as the demand grows, which sometime means lots of money and in short notice. You should warn your sponsors/investors beforehand, or have a B-plan in case they do not/cannot provide the necessary cash.

Pardus project has gained momentum throughout 2006 and 2007, where we had Pardus 1.0 and Pardus 2007, the former being a very impressive debut release and the latter being the distro of its time. We had to act fast and grow by the second half of 2006. But being an internally funded project in TUBITAK UEKAE, we were stuck to a team of 15 or so. We have requested central budget support from DPT for 2007, but some unfortunate events shut those doors close. We have even contacted VCs for outside funding, to no avail, “this may be a 20-50 million $ company, but surely not a billion $ company” we were told. At the end the necessary funding came in 2010, 3 years too late. And by then part of the momentum was lost, and lots of opportunities have been missed, and things have never been the same as late 2007.

TEAM

Being in software and/or services sector, your most important assets are your human resources. Both the quality and, as time proceeds, the quantity counts. The caliber of your product is very much correlated to the expertise, creativity and passion of your team. You have to take good care of your team, and be prepared to extend it without sacrificing the quality.

The first generation Pardus team in TUBITAK was top notch, very likely the dream team of open source in Turkey. They have conceptualized, designed and developed one of the best debut distros (Pardus 1.0) and the best distro ever (Pardus 2007). Unfortunately we have not been able to hold most of them with us afterwards. And again unfortunately the Turkish open source sector was not mature enough to make good use of them. We are happy to see them executing very serious work elsewhere, and a bit sad that they are not with us anymore.

Don’t get me wrong, we still have the most impressive team in open source in Turkey, and right now we have one first, one first-and-a-half and one second generation developer in the executive board of Pardus project. Nevertheless I’d like to have the dream team with us, guiding these fine youngsters; in spite of the potential manageability problems that we might have 😉

Among the things that you may control to have a good team and keep them are working environment (or lack of thereof), intellectual and/or technical challenges (which attract best of the breed), career path, other team members, and last but not the least the compensation.

PRODUCT

When I say “project” I mean a “product” project, such as a distro (like Pardus), some certain software, some service bundled to an existing open source product, etc. You have to keep in mind that the important word is product and not project. The number of successful open source products is much less than the number of successful open source projects. Definitely the process counts, but as an asset and not at the centerstage. You have to achieve and sustain the rigor, consistency, continuity, dependability, and, if you wish, marketability of a product as in proprietary software world, or in a market economy in general. You may not like this, but c’est la vie, these are the things that convince the ordinary user/customer to use your product, and not the competition .

We have had release managers for each release in Pardus, and the outcome depended much on the their (sometimes personal) choices. Pardus 1.0 and 2007 were releases to attract the (wo)man on the street, and it showed. Pardus 2009 and 2011 were, on the other hand, tried to satisfy the needs of the more advanced Linux users, and the ease of use was somehow sacrificed. If we had had some stronger product policy, maybe a product manager (we’ve tried to use some community representative to fill this void, but execution was not as brilliant as the idea), or even a marketing manager we would have a straighter evolution line. Now even our dedicated users are asking “why you released 2011, it’s almost 2009”, and they are right…

Again, don’t get me wrong, 2009 and 2011 are very fine Linux distros. Some usability studies say 2009 performing better in some end-user usability measures than its predecessors. Still, I personally think that, as compared to their contemporaries, 2009 and 2011 are steps backward in general audience attractiveness…

With these observations at hand, we are reorganizing our release policies and processes. We are going to put some brief but strict definitions for the target user of the Pardus 2000 series, the requirements for the product in order to be competitive for this target group, the technical requirements for the individual pieces in order to be in line with these general requirements and finally a new organizational/procedural structure in order to make all these policies work, without being dependent on any person… We hope to be back on track with Pardus 2012 and hope that the succeeding releases will get better…

COMMUNITY

There is one slogan I’ve heard from a former community manager “An open source project without a community is deficient.” and this may not be more true. You are likely to have your product (or a subset) to be available publicly with an open source license, and very likely you are not going to provide support for this “community edition”. As the name implies, the support for this edition is the community. In addition community is (or may be) part of QA, part of marketing, part of product management, part of several essential components of the product lifecycle. This is what make an open source software different than a proprietary competitor. The “community” includes your (outside) developers, your ecosystem (mostly companies) and your users. You have to take good care of your community in order to succeed and do so repeatedly. A strong community means a strong product. You have to support your community in order them to get flourished, but you have to keep in mind that eventually your community should become self sustained…

Regarding user communities, we have outsourced the community building and management task since the very early days. The contractor has performed surprisingly good in the first few years, and in some areas. Once a marketing consultant unofficially auditing us (in spite of the fact that he disagreed with outsourced community management) have given them full grade, even more… Still, things did not work as planned. As time passes the community folded onto itself, the newcomers were not as many as they used to be, the gap between the developers and users widened, and so on…

Very recently we have decided to do community management in house, assigned some big talent and hired an expert for the task. The first diligence they have carried out was not very optimistic: Apparently the user community has some problems with governance, always seeking external directives. Right now we are trying to encourage the community veterans to take hold of the control of the existing portal. Almost 4 years of hard work, and with a simple change of coordination everything starts trembling… Not very impressive, we would’ve paid much more attention to governance and self sustainability of the community, much earlier 🙁

We have tried to start some partnership programs almost 3 years back, but the outcome is not very convincing. The larger firms have not been interested much, the smaller ones lack the necessary means for marketing and product development. At the end, we had to become the main contractor and subcontract the parts to our partners. This works well for supporting the ecosystem, but neither is consistent with our business model nor in the benefit of the customer on the long run. As the current projects approach to end with successful results, we hope to have more interest from the existing IT companies.

Universities should be an important part of your community. One part they are the sources of the advanced users, which affect their surroundings in their professional and business life. One the other hand they may be your developers, with lots of youngsters looking for exciting and challenging projects. Our collaboration with one such university have been very fruitful, in the first year they have built the 64-bit infrastructure and right now they’re incorporating other desktop environments in Pardus. We definitely plan to extend this collaboration model into other universities…

USER

We have stressed the importance of the product before, but it never suffices. It may be possible to continue a project without financing, a team and a community; but if you do not have any users, you are doomed. Don’t forget you are responsible to create awareness about your product in the user base. Don’t expect the users flock to your site and start downloading. Once you have users do not try to shape them, instead listen to them. If what they are telling is completely out of line, you have reached wrong user base. If that makes sense consider reshaping your product accordingly so as to expand your user base.

As most of other software, Pardus has been designed and developed for a hypothetical user, initially. Apparently the hypothesis was accurate, and especially Pardus 2007 has been accepted by the targeted users. I have to add that the failure of Microsoft Vista helped much to this result. With later releases we have lost focus on the user, or the user base we have acquired by the earlier releases, and that showed in the slow (or non-existent) adoption rate. In addition, in relation to the community issues, we have somehow lost the direct connection with the user, which is also bad for the user adoption.

We have tried to keep in touch with the user base, using proxies (once under the name Product Manager, and once under the name Release Community Representative), which were right steps forward. Nevertheless the execution have not been as expected for neither one, due to several factors.

We have to reshape our relation to the user, especially for the “community edition” we are going to have. It is not clear yet how we are going to do that, but we are aware of the problem and working on it…

POLICY

The “National Open Source Project” is a supply-side action and most of the above success factors are also related to production and development. It is very likely that your product facing severe competition, very likely from proprietary software and very likely to hold some almost-monopoly position in the market. Hoping to have “fair” competition and market forces play their role for the better and more efficient product (that is yours, right?) take over the market share is highly optimistic (even wishful thinking). A reasonable demand-side support does not hurt… Policies to encourage migration to open source, to consider open source solutions before making an acquisition, to reuse already existing solutions, to use open standards, etc may be put in place so as to have a better Return on Investment for your project.

For Pardus this may be one of the weakest points. The e-Conversion Turkey master project have had actions related to use of open source in government, but it was for having something related to open source, and far from being some policy precursors. We, as the Pardus project, had to struggle to prevent Office Open XML from becoming and ISO standard or to keep Microsoft formats out of interoperability guidelines.

Without much policy backing, only eraly adopters and risk takers from the government have considered using Pardus and open source. And this cycle for adoption is slow in both time and growth. The enterprise users/customers are still only a handful after 6+ years.

These six factors are the ones that I think of utmost importance. If you have fulfilled all of them, but still your project is struggling, let me know. If you have spectacular success in your project, with one or few of the factors missing, let me know again. I’ll appreciate your help to keep this list accurate and up-to-date…

LinuxCon 2010: Öznel Bir Özet…

Linux Vakfı’nın düzenlediği ve geçtiğimiz yıl Portland’da -Linus Torvalds’ın memleketi- başlayan LinuxCon yıllık konferansları bu sene Yeni İngiltere’nin kalbi Boston’daydı. Tabii ki bendeniz de orada…

OSDL ve FSG’nin birleşerek Linux Vakfı’nı kurmasına, ve hatta vakfın adına şüpheyle yaklaşmıştım zamanında. Ama gerek Jim Zemlin önderliğinde yaptıklarına ve gerekse sadece LinuxCon toplantılarına bakınca ne kadar yanıldığımı görebiliyorum. Linux Vakfı gerçekten Linux’un, ve neredeyse daha geniş çerçevede özgür yazılımın, marka ve satıcı bağımsız sözcüsü ve önderi haline geliyor yavaş yavaş.

Birinci Gün

Boston’a dönelim… Konferans’ın açılışını Jim Zemlin yaptı ve bombayı patlattı: Özgür yazılım lisans ihlali yapan firmaların çoğu bunu kasıtlı olarak yapmıyorlardı ve alsında hemen hepsi lisans uygun davranmayı tercih edecek durumdalardı. İhlalin temel nedeni bilgi eksikliği idi. Ve Linux Vakfı özgür yazılım ürünlerini kullanarak türev ürünler üreten firmaların lisans uyumlarına yardımcı olabilmek için yeni bir program başlatıyordu: The Linux Foundation Open Compliance Program, yani Linux Vakfı Açık Uyumluluk Programı. Eğitim, Araçlar, SPDX, Değerlendirme kontrol listesi, Uyumluluk rehberi ve FOSS Bazaar bileşenlerinden oluşan program ilerleyen sat ve günlerde tüm katılımcılardan son derece olumlu tepkiler aldı. Bir Linux Vakfı kazanımı daha…

Açılış konuşmasını Oracle’dan Wim Coekaerts yaptı ve Oracle/Sun ekseninde (MySQL eksenini biraz es geçip) özgür yazılım perspektifini anlattı. Yeni ve ilginç bir veri Oracle’ın kullanıcı temelinin %20’nin üzerinde Linux kullanmakta olduğu idi, karşılaştırma için Solaris %27’de. İkinci konuşmayı Qualcomm’dan Rob Chandhok verdi ve ismi özgür yazılımla pek yanyana gelmeyen Qualcomm’uın mobil özgür yazılım geliştirme amacıyla QuIC: Qualomm Innovation Center ismiyle bir şirket kurduğunu (ki Chandhook bu şirketin başında) ve QuIC’in başta kernel MSM bakıcılığı olmak üzere şimdiden çeşitli işlere girmiş olduğunu gururla ilan etti kendisi.

Paralel oturumlarda geleneksel iş – hukuk çemberini kırmak istedim bu kez ve daha teknik konuşmaları izlemeye çalıştım. Varşova Üniversitesi ve SuSE’den Rafael Wysocki çalışma zamanı güç kontrolü gibi son derece ilginç bir başlık altında son derece sıkıcı ve dağınık bir sunuş yaptı. Ardından Smack grubundan Casey Schaufler’in dosya içeriği temelli erişim kontrolü konuşmasını izledim, pek güzel ve heyecanlı bir konuşma idi. Olay soru-cevapta çıktı, meğersem bu amca SELinux’çuların ile kanlısıymış, epeyce bir atışma oldu. Ama asıl kızılca kıyamet paralel Android oturumunda yaşanmış, Android’in kernel ağacından uzak kalması zaten bir tartışma konusu, konuşmalar hararetlenince sesler yükselmiş, sonunda konuşmacı bir izleyiciyi salondan kovmuş, vb.

Öğleden sonra teknik yazar Jeff Osier-Mixon’ın dağıtım kapışması vardı. Geleneksel hale gelen bu kapışma önde gelen üç masaüstü dağıtımının (fedora, openSuSE ve Ubuntu) 7 alanda (kurulum, açılış zamanı, uygulama yükleme, sistem yapılandırma, çevrimiçi yardım, yeni donanım ve ağ servisleri kurma) hız, kullanışlılık ve estetik açıdan değerlendirilmesine dayanıyor. Sonuçlar oldukça yakın çıktı: Ubuntu 156, openSuSE 155 ve fedora 144. Pardus’umuzu bu kapışmaya soksak sanırım 120-130 arası bir puan alır, hala gidecek hayli yolumuz var yani. Konuşmadan önemli bir tartışma dağıtımların kullanıcı sayısı üzerine idi, fedora (milyonlarca kullanıcı) ile openSuSE (3 milyon kullanıcı) bu sayılara nasıl ulaştıklarına dair ayrıntılı bir metodoloji açıklarken Ubuntu (12 milyon kullanıcı) yalnızca şakadan bir sayı çıkarıyor denildi. Pardus’un kullanıcı sayısı hakkında ettiğimiz lafların güvenilirliğini en başta ben sorguluyorum, biline…

Günün en eğlenceli oturumu basın gözünden Linux üzerine paneldi. 2000’lerin en büyük Linux hikayesi için SCO, IBM’in desteği, RHEL, mobil, Ubuntu yanıtları geldi. Özellikle openSuSE’nin eski camia yöneticisi Joe Zonker Borckmeier fedora ve openSuSE’nin Ubuntu’nun çıkışı sonrasında kendilerine çeki düzen verdiklerini, yoksa RedHat ve Novell’in camia dağıtımlarını pek de takmaz bir halde olduklarını iddia etti. Bugünün büyük hikayesi olarak da Android, Chrome OS, Linux Vakfı, mobil gösterildi. Ardından analistlerin rakamları konuşuldu ve bolca atıldı analiz firmaları ardından. Neden büyük Linux haberleri yapılmadığı tartışıldı ve temel neden olarak Linux’un artık her yerde ve harcıalem olması gösterildi, yani bu iyiye bir işaretmiş. Linux haberlerini daha çok teknoloji meraklılarının okuduğu, Microsoft’un bolca reklam verdiği, firmaların bloglar vb. aracılığı ile “yayıncılık”a soyunmasının alışıldık medya için aslında çok da bir tehdit oluşturmadığı vb. konuşuldu. Pek güzeldi…

İlk günün kapanış oturumu yine geleneksel kernel paneli idi. Geçtiğimiz yılın kernel olayını James Bottomley “barriers’in ölümü” olarak ilan etti, depolama altsistemindeki gelişmeler tüm panelistler tarafından taktirle anıldı. “Kimse ana kerneli test ediyor mu? Yoksa herkes bir çatalını mı kullanıyor” gibi kışkırtıcı bir soru ile devam edili. Dave Jones yükselen kaliteye koşut olarak Linux kerneline girişin gittikçe daha zor olduğunu vurguladı, hem iyi hem de kötü bir şey olarak. Ted T’so RedHat ve SuSE’nin kernel’i çok daha fazla çatallamasına karşın paparayı Google ve Android’in yemesinden şikayet etti.

İlk günün sosyal etkinliği -yine geleneksel- bowling partisi idi. Yerel biralar eşliğinde hoş ve eğlenceli bir akşam geçirdik.

İkinci Gün

Ana konuşmada Novell’den Markus Rex inovasyon politika ve tekniklerini anlattı. Forrester’dan Jeffrey Hammond rakamlarla Linux’un artık gelecekteki bir olay olmaktan çıkıp bir olgu haline geldiğini gösterdi. Önemli bir bilgi geliştiricilerin (Eclipse geliştiricileri üzerine yapılan bir araştırma sonuçlarını verdi) hem geliştirme ve hem de üretim ortamında dağıtım olarak Ubuntu’yu tercih etmesiydi. Üretimde RHEL ciddi bir paya sahip, ama bir numara değil!

Paralel oturumlarda önce IBM’den Jean Staten-Healy sunumuna gittim. Masaüstünde Linux’un kullanılabileceğini ZSL inc’de Ubuntu, Cybernet-SlashSupport’ta RHEL örnekleri ile anlattı. Artık CIO’ların Linux’u stratejilerinin bir parçası yapmak istediklerinden bahsetti. Dünya ile Türkiye’yi karşılaştırıp moralimi bozmaya devam ettim ben de 🙂

Scott James Remnant’ın Ubuntu’yu daha hızlı başlatma üzerine bir konuşmasına takıldım. Moblin kazanımları üzerine bir-iki ufak numara dışında fazla bir şey yoktu, etkilenmedim.

İkinci günün bombası Monty Widenius’un MariaDB (ya da My’ya karşı Maria) konuşması idi. Votkalı çikolata ile başlayıp kara votka ile bitmesini geçeyim oturumun, içerik ile ilgili yok. Monty, bildiğiniz Linus’un veritabanı hali… Zaten o da Finlandiya’dan ve MySQL’den kazandığı milyonlarca dolara karşın tam bir geek görünümünde. MySQL’in 2002’den başlayarak nasıl camiaya sırtını döndüğünü ve nasıl “son”unu hazırladığını anlattı. Yeni özellik ve yamaların camiaya verilmeden yalnızca kurumsal ürüne konulmasının nasıl müşterilerin sorunlarını ve test zamanlarını katladığını söyledi. MySQL’in bir ürün olarak başarılı olduğunu, ama bir proje olarak battığını iddia etti. MariaDB’nin bir ürün değil bir proje olduğunu söyledi. Son derece keyfili bir oturumdu…

IDC’den Al Gillen ilk önce “dün gazeteciler bizim hakkımızda atıp tutmuşlar, onlardan kimse var mı bu salonda” dedi, olanlar indiler yerlerinde, biz de ispiyonlamadık. Yine rakamlarla Linux’un ne kadar iyi durumda olduğunu anlattı… Solaris’in zayıflamasını ve bulut bilişimi Linux için önemli fırsatlar olarak saydı. SuSE Studio’dan beğeni ile söz etti. Gerek Forrester ve gerek IDC konuşmacılarının vurguladığı birşey vardı: “Tebrikler, kazanan takımdasınız!”, artık Linux “geliyor mu, gelecek mi” diye sorulan, az bilinen ve merak edilen birşey değil, bilişim dünyasının, -hem de son derece önemli- bir parçası. Özellikle bulutun yaygınlaşması ile masaüstü işletim sistemlerinin alakasızlaşması süreci tamamlanınca Linux her alanda mücadelesini kazanmış olacak, dünya hakimiyeti!

Geleneksel hukuk oturumlarıma döndüm sonunda, Eben Moglen’den harika bir konuşma izledik. ABD patent sisteminin çöküşü konusu etrafında mükemmel bir yolculuğa çıkardı bizi Eben, her zamanki gibi muhteşemdi… Dinlemekle konuşmayı sindirmeye çalışmak arasında gidip geldik.

Gün MeeGo oturumu ile tamamlandı, Nokia ve intel temsilcilerinin katıldığı bir mini panel şeklinde. Önemli haber 2011 başında Nokia’nın ilk MeeGo telefonunu çıkaracağı idi. Özellikle MeeGo’nun ne kadar anakaynağa yakın durduğu vurgulanarak “Android gibi herşeyi çatallamıyoruz, ağır entegre bir sistem de yapmıyoruz, burada herkese ekmek var” mesajı verildi. Güzeldi… Nokia’nın Symbian’ı ve ovi dükkanı ilginç sorular arasındaydı.

İkinci günün sosyal aktivitesi Boston körfezinde tekne gezisi oldu. Monty ile aynı masaya düşmeyi becerebildiğimden sohbeti genişlettik. Ekim ayında İstanbul’da yapacakları geliştirici toplantısında birlikte neler yapabilirizi konuştuk, kara votka ile beyaz rakı birlikteliğine kadar uzattık hikayeyi. Serin güvertede Boston’un ışıklı silüetini izleyerek günü tamamladı penguenler…

Üçüncü Gün

Ana konuşmacı GNOME Vakfı’nda Stormy Peters idi, buluttaki verilerin güvenliği ve gizliliğinden bahsetti, internet servisi olarak da özgür alternatifleri seçmemiz gerektiğini vurguladı. GNOME ve Stormy’nin tüm konuşmaları gibi özgürlüğe vurgu yapan pek güzel bir çağrıydı…

Bir kullanıcı olarak Virgin havayollarından Ravi Simhambhatla geldi sonra, Linux’u nasıl kullandıklarını anlattı. Ravi yanılmıyorsam OSBC’de de konuşmuştu, aynı kurumsal kullanıcıyı 6 ay ara ile iki kez konuşturmak ters geldi bana. Türkiye’de olsa “zaten kaç kurumsal kullanıcımız var ki” diyeceğim, ama küresel ölçekte olmamış…

Yine hukuk ve RedHat’ten Richard Fontana katkıcı politikaları anlatıyor. fedora’nın yeni katkıcı sözleşmesinin hikayesini genel bir perspektifle öyle güzel verdi ki, tam da camia tartışmalarımız arasında ilaç gibi geldi. Soru-cevapta bir yandan Eben Moglen, diğer yandan Canonical’ın baş hukuk danışmanı konuya girince oturum iyice şenlendi…

Canonical’an Matt Asay’in yönettiği “What Next for Linux?” paneline girdim öğleden sonra. Asay son derece kötü yönetti paneli, izleyicilerin soruları da olmasa tam bir fiyasko olacaktı. Sonuçta Linux’un masaüstünde başarısız, mobilde başarılı olduğunu öğrendik 😛

Bdale Garbee bu kez gerçekten roket anlatıyordu. Kapalı sistemlerin nasıl sakıncalı olduğunu ve kendi özgür platformlarını nasıl oluşturduklarını bir dizi embedded ve Make geek’i ile bana anlattı, her zamanki gibi pek güzeldi…

Yavaş yavaş kapanışa geldik. Geleneksel geek’ler nerd’lere karşı yarışması ile sona erdi konferans. Nerd’ler ağır bir yenilgiye uğrattılar geek’leri, Zemlin’in bütün çabasına karşın…

Boston, dedim ya, Yeni İngiltere’nin kalbi. Hafifi İngiltere’yi çağrıştıran 19. yy mimarisi, limanı ve Charles nehri, deniz ürünleri, MIT ve Harvard başta üniversiteleri ile hoş bir şehir. ABD’nin her büyük şehri gibi yaşaması kolay, özellikle paran varsa 🙂 Gelecek yıl Kanada’ya geçiyor LinuxCon ve Vancouver’a gidiyor…

UEKAE Dergisi: “Pardus Projesi ve Türkiye Yazılım Sektörü”

UEKAE tarafından yayınlanmakta olan UEKAE Dergisi‘nin 3. sayısında Pardus ve yerli yazılım üzerine bir yazım yayımlandı. Zaman zaman alevlenen ve bugünlerde yine revaçta olan “Pardus ulusal mı, %100 yerli mi, …” tartışmalarına ışık tutması açısından yararlı bir veri noktası oluşturacağını düşünüyorum.

Pardus Projesi ve Türkiye Yazılım Sektörü

Pardus Projesi Vizyon ve Hedefleri

TÜBİTAK, 2003 yılı başında Başbakanlık tarafından milli bir işletim sisteminin olurluğunun araştırılması ve geliştirme işinin projelendirilmesi işi ile görevlendirildi. Bu kapsamda yapılan beyin fırtınası çalışmaları ardından, 2003 yılı sonbaharında, daha sonra Pardus adını alacak olan Özgür Yazılım Geliştirme ve Üretim (ÖZGÜR) projesi başlatılarak bir çekirdek ekip oluşturulması yoluna gidildi. ÖZGÜR projesi birkaç aylık bir değerlendirme sonucunda olurluk ve projelendirme çalışmalarından daha önemli ve öncelikli gördüğü işletim sistemi geliştirme işine yoğunlaştı. Uzunca süre UluDağ adıyla anılacak ve kimi yanlış anlaşılmalara yol açacak Ulusal Dağıtım projesi bu aşamada şekillendirildi. UluDağ kapsamında önce teknik olurluk çalışmaları ve değerlendirmeler yapıldı, kimi tasarım kararları verildi. Projenin başlamasından yaklaşık bir yıl kadar sonra, 2004 sonbaharında daha sistemli bir yaklaşım geliştirilmesi gereği duyularak bir Proje Ana Sözleşmesi oluşturuldu.

Proje Ana Sözleşmesi’nde Pardus şöyle tanımlanmakta:

"… bilişim okur-yazarlığına sahip bilgisayar kullanıcılarının temel masaüstü ihtiyaçlarını hedefleyerek; mevcut Linux dağıtımlarının üstün taraflarını kavram, mimari ya da kod olarak kullanan; otonom sisteme evrilebilecek bir yapılandırma çerçevesi ve araçları ile kurulum, yapılandırma ve kullanım kolaylığı sağlamak üzere geliştirilen bir GNU/Linux dağıtımı …"

Bu tanımdan Pardus projesinin Başbakanlık görevlendirmesinde vurgulanan ulusal güvenlik gereksinimlerine yoğunlaşmak yerine daha farklı bir yol seçtiğini görebiliyoruz: Pardus genel kullanıma yönelik bir işletim sistemi ve hatta bir işletim sistemi platformu oluşturmayı hedefliyor.

Proje Ana Sözleşmesi ile aynı zamanda inşa edilen proje misyonu da bu kanıyı güçlendirir yönde:

  • Ulusal teknolojik bağımsızlık, tasarruf ve güvenlik sağlamak,
  • Yerel bilgi birikimini artırmak,
  • Yüksek katma değerli üretim yapmak,
  • Ürün yol haritasına hakim olabilmek.

İlk misyon maddesi TÜBİTAK UEKAE’nin misyon cümlesinden alınma ve UEKAE’de yürütülen tüm projelerde ön planda tutulan ilkeleri içeriyor. Ancak Pardus Başbakanlık’ın "sipariş ettiği" ürünü gerçeklemeden önce bilgi birikimi sağlamayı (UEKAE içinde ve dışında) ve üretim yapmayı (yine UEKAE tarafından ve diğer) hedefliyor. Bu ufak gözlem dahi Pardus projesinin basit bir Linux dağıtımı işi olmaktan öte geçen, Türkiye yazılım sektörü ile ilgili çeşitli hedefleri olan bir çalışma olduğunu gözlemek için yeterli.

Pardus projesinin tarihçesi bundan yaklaşık 5 yıl önce, 3 Şubat 2005’te, Gaziantep Üniversitesi’nde düzenlenen Akademik Bilişim kongresinde Pardus Çalışan CD‘nin yayımlanması ile devam ediyor. Ancak bu yazı bağlamında tarihi gelişime yoğunlaşmak yerine stratejik plan ve uygulaması üzerinde duracağız. Yukarıda sözü geçen misyon kapsamında ortaya konan hedefler bir sacayağı yapısında:

  • Yaygın bir işletim sistemi dağıtımı,
  • Sürdürülebilir organizasyon,
  • Teknolojik inovasyon.

Geçen 5 yıl sonunda 200 bin üzerinde kullanıcı tarafından tercih edilen Pardus halen Türkiye’nin en yaygın Linux dağıtımı, pazar payının yaklaşık %2-3 civarında olduğunu tahmin ediyoruz. Sınırlı tanıtım olanakları ve fiili bir tekel ortamında ulaşılan bu düzey, yeterli olmamakla ve daha gidilmesi gereken çok yol olmakla birlikte, ümit verici.

Sürdürülebilirlik yalnızca finansal anlamda, projenin makul bir özyeterlilik sağlayacak gelirleri olması bağlamında ele alınmıyor. Bilgi birikiminin, insan kaynağının sürdürülebilirliği de en azından bu kadar önemli. Pardus’un yalnızca UEKAE bünyesinde yürütülen bir proje olmaktan çıkması ve geniş bir geliştirici camiası tarafından sahiplenilmesi bu noktada en önemli kazanım. 2008 yılında ufak çapta başlayan ve 2010 yılından itibaren ölçek değiştirerek devam eden milli bütçe (DPT Yatırım Planı kapsamında) desteği de vurgulanmaya değer.

Son olarak da proje kapsamında yapılanların basit bir entegrasyon ve adaptasyon çalışması olmanın çok ötesinde, teknoloji üretmeyi, üretilen teknoloji ile kullanıcıya değer katmayı hedefleyen bir yapı kurmaya yönelik olduğu görülüyor.

Pardus projesinin temel taşlarını hızla gözden geçirdiğimizde Türkiye yazılım sektörü ile ilgili önemli fikirlerle ve tasarımlarla karşılaşıyoruz. Dahası üretmeye, geliştirmeye niyetli gençlere, girişimcilere, bilişim yolu ile rekabet avantajı yaratmayı amaçlayan dinamik firmalara manifesto niteliğinde bir çağrı çıkıyor karşımıza.

İzleyen bölümlerde bu çağrının önemli bileşenlerini temel felsefe, mevcut durum ve gelecek planları ile büyüteç altına alacağız.

İş Ortakları

Pardus yazılım dizisinin özgür yazılımları kullanacağı ve özgür lisanslarla dağıtılacağı projenin başlangıcından itibaren biliniyordu. Yaygınlaşma ve iş geliştirme alandaki hedef de bir "iş platformu" oluşturmak şeklinde belirlenerek ve neredeyse tek bir satır kod yazılmadan, 2004 baharındaki Linux Şenliği’nde, ilan edilerek açık ve katılımcı yapının geliştirme ve dağıtım modelleri ile sınırlı olmayacağının altı çizildi. Pardus projesi, UEKAE ve TÜBİTAK oluşacak fikri mülkiyeti kamu yararına dönüştürmeyi ön plana alacak, kamuya açık bilginin kullanılması ile yaratılacak özel yarar için patent, lisans vb. tarzından bir mülkiyet talebinde bulunmayacaktı.

Bu yaklaşım ilk bakışta sürdürülebilirlik, özellikle finansal sürdürülebilirlik açısından doğru bir hamle olarak görülmese de biraz yakından incelendiğinde durumun bunun tam tersi olduğu görülecektir. Pardus’u ve Pardus üzerinde koşacak özgür yazılımları kamu ve özel sektörde, kurum / şirket boyundan bağımsız olarak ve Türkiye’nin her yerinde yaygınlaştırmak, TÜBİTAK ve UEKAE’nin misyon ve vizyonları, örgütlenme ve çalışma şekilleri ile uyuşmayan görevlerdir. Özellikle ulusal güvenlik birimleri ve kritik özellikteki kamu kurumları için bu görevler doğrudan UEKAE tarafından üstlenilse dahi hedef kitlenin çok büyük bir kesiminde bu operasyonu yürütmek için iş ortaklarına ihtiyaç duyulmaktadır. Ancak bu şekilde hem coğrafi dağılım ve hem de proje sayısı açısından ölçeklenebilir bir organizasyon oluşturulabilecektir.

Bu değerlendirmeler ışığında 2008 yılı sonunda Pardus Göç Ortaklığı programı ilan edilerek ilk iş ortakları ile sözleşmeler yapılmaya başlanmıştır. Nisan 2010 itibarı ile sayıları 20’ye varan Pardus Göç Ortağı (PGO) geniş bir yelpazede Pardus tanıtım ve pazarlama çalışmaları yürütmekte ve hayata geçmekte olan göç projelerinde aktif olarak katkıda bulunmaktadırlar. UEKAE dahil her PGO’nun yaptığı göçlerden elde edilen bilgi birikimi ortak bir havuzda toplanmakta ve diğer iş ortakları ile paylaşılmaktadır. PGO’lar tarafından yürütülen göç çalışmaları UEKAE müşteri temsilcileri tarafından sürekli izlenmekte ve belirli bir kalite düzeyi tutturmaları sağlanmaktadır. Şimdilik yalnızca büyük şehirlerde yoğunlaşan PGO’ların 2010 yılı içerisinde tüm Türkiye sathına yayılması planlanmaktadır.

Göç projelerinin temel bileşenlerinden biri kurumların iş mantıklarını üzerinde çalıştıracağı uygulama yazılımlarıdır. Kurumsal kaynak planlama (ERP), imalat kaynak planlama (MRP), doküman ve içerik yönetimi, iş akış sistemi, müşteri ilişkileri yönetimi (CRM), veri madenciliği, iş zekası (BI) ve benzeri kurumsal yazılımlar ve bunlar üzerine kuruma özgü geliştirilen sistemler olmadan çoğu kurumun Pardus’a göçünü sağlamak mümkün olmayacaktır. Kurumların özellikle ilgilendikleri iş süreçlerini yönettikleri bu uygulama yazılımlarıdır, işletim sistemleri (ve işletim sistemleri ile kurumsal yazılımlar arasındaki katmanda yere alan web sunucular, veritabanı yönetim sistemleri, uygulama sunucular, uygulama çerçeveleri vb.) yalnızca bu yazılımlar için bir platform oluşturur. TÜBİTAK ve UEKAE’nin kurumsal yazılım geliştirme ve kurumlara özgü çözüm geliştirme görevlerini üstlenmesinin, özellikle ölçeklenme sorunları ve dikey pazar dinamikleri gözönüne alındığında, olurluğu bulunmamaktadır. Kurumsal yazılım ve çözümler konusunda da iş ortakları ile çalışmak doğru yol olarak görünmektedir.

Gerek kurumlar ve gerekse bireyler için işletim sistemi edinme yolları arasında en yaygını yeni donanım alımıdır. Dolayısı ile yaygın bir işletim sistemi dağıtımı olmayı hedefleyen Pardus’un yeni bilgisayarlarda ön-yüklü olarak satılıyor olması önemli bir gerektir. 2008 yılında bu yönde yapılan bir iş ortaklığından oldukça olumlu sonuçlar alınmıştır. Özellikle Pardus’un özgür yazılım olması sonucu yüksek sayıda Pardus yüklü bilgisayarın satılmakta olduğu da açık bir bilgidir. Buna karşın Pardus ön-yüklü satılan bilgisayarların önemli bir kısmının lisanssız sahipli yazılımlar ile çalıştırılmaya devam edildiği de bilinmektedir. 2010 ve özellikle 2011 yılı için hedeflenen bir yandan yeni donanım iş ortaklıkları ile bilgisayarların son kullanıcıya Pardus yüklü ulaşmasını sağlamak, diğer yandan da bu bilgisayarların Pardus kullanmaya devam etmesini sağlayacak şekilde tanıtıma ve destek hizmetlerine ağırlık vermek olacaktır.

Özgür yazılım ile dikey pazarlar için donanım/yazılım/servis tümleşik çözümler oluşturulması son derece kolay bir şekilde gerçekleştirilebilmektedir. Geliştirme maliyetlerinin düşüklüğü, pazara sunma zamanının kısalığı, dağıtım modellerinin serbestliği gibi özellikleri ile küçük firmalar ve genç girişimcilere son derece cazip iş fırsatları sunmaktadır. Pardus projesi girişimci iş ortakları ile ve gerekli durumlarda büyük sektör aktörlerinin de katkısı ile böylesi çığır açan ürünler geliştirmesine katkıda bulunmayı hedeflemektedir. Bu ürünleri yalnızca Türkiye çapında değil, küresel ölçekte de pazarlanabilir kılacak şekilde bir teknoloji içeriği oluşturmak yönünde üzerine düşenleri yapmaya hazırdır.

Eğitim Projeleri

Gerek Pardus kullanan kurumların ve gerekse bu kurumlara ürün ve çözüm üreten iş ortaklarının sayısının artması ile Pardus konusunda bilgi sahibi deneyimli işgücü ihtiyacı ciddi şekilde artacaktır. Bu ihtiyacın hızlı ve aynı zamanda belirli kalite düzeyinde karşılanması için en uygun çözüm standartlaşmış eğitim programları olacaktır. Bilişim sektöründe yaygın olarak kullanılmakta olan bu yöntem Pardus projesi tarafından da benimsenerek 2010 yılı ilk yarısında hayata geçirilmektedir.

Pardus eğitimlerinin profesyonellere hitap etmekte ve kariyer geliştirme amacına yönelik olarak tasarlanmaktadır. Birbiri ardına ya da bağımsız olarak izlenecek kurlar şeklinde kurgulanan bu eğitimler sonucunda TÜBİTAK gözetiminde yapılacak sınav sonrasında sertifikalandırma yapılacaktır. Mevcut ve geliştirilmekte olan kurlar şunlardır: Pardus Destek Elemanı (PDE), Pardus Destek Uzmanı (PDU), Pardus Sistem Yöneticisi (PSY), Pardus Sistem Uzmanı (PSU), Pardus Kullanıcı Eğitmeni (PKE) ve Pardus Yazılım Geliştiricisi (PYG). TÜBİTAK onaylı Pardus Eğitim Merkezleri’nde (PEM) sertifikalı eğitmenlere tarafından verilecek bu eğitimler kariyerini Pardus ve özgür yazılım çevresinde şekillendirmek isteyen bilişim profesyonelleri düşünülerek tasarlanmaktadır.

Bilgisayarları işinin bir parçası olarak kullanacak kişiler için de temel Pardus eğitimleri tasarlandı ve şekillendiriliyor. Genel bilgisayar oqkur-yazarlığının belgelendirilmesi niteliğindeki European Computer Driving License (ECDL) benzeri bir temel Pardus ehliyeti müfredatı Milli Eğitim Bakanlığı Halk Eğitim Genel Müdürülüğü ile işbirliği halinde geliştirilmektedir. Ortaya çıkacak ve Halk Eğitim onaylı bu müfredat öncelikle Halk Eğitim merkezleri, belediyeler, sivil toplum örgütleri gibi kanallarla işsizler, kadınlar ve gençlere sunulacak ve bu kesimlerin istihdama katkılarının artırılması hedefine odaklanılacaktır.

Eğitimin Pardus’un yaygınlaşmasındaki önemli bir işlevi de alışkanlıkların oluşturulması ve tanımlanması olacaktır. Bu nedenle özellikle Milli Eğitim Bakanlığı ile ortak yürütülecek çalışmalara önem verilmektedir. Halen Milli Eğitim Bakanlığı Eğitim Teknolojileri Genel Müdürlüğü (EĞİTEK) ile yapılan bir protokol kapsamında formatör bilişim öğretmenlerine farklı seviyelerde Pardus ve özgür yazılım eğitimleri verilmektedir. Bu eğitimlerden geçen öğretmenlerin Türkiye sathında eğitim programları düzenleyerek diğer öğretmenlere bilgi aktarımında bulunması planlanmaktadır. Bu sayede her yıl 3.000’in üzerinde bilişim öğretmeni bu birincil ve ikincil eğitimlerden geçerek ilgili derslerde Pardus ve özgür yazılımlar konusunda eğitim verir hale geleceklerdir.

Üniversiteler ve Ar-Ge

Eğitim çalışmalarının son kademesi üniversiteler olacaktır. Bu aşamada ortak çalışmaları yalnızca eğitim ile sınırlı görmemek, üniversitelerin asli görevlerinden araştırma-geliştirmeyi de ufuk dahilinde görmek gereği açıktır. Seminerler, konuk dersler, bitirme projeleri, staj programları bu kapsamda gözönünde bulundurulan araçlardır. Pardus projesi, özellikle teknolojik inovasyon vizyonu ile, üniversite öğrencilerinin ilgisini çekecek niteliktedir. Nitekim 2007 yılından bu yana yürütülen staj programlarına gösterilen yoğun ilgi bunun bir göstergesidir. Önümüzdeki dönemde bu çerçevede yapılanları çeşitlendirerek artırmak hedeflenmektedir.

Üniversitelerle yürütülecek ortak çalışmalar arasında önemli yer tutan tematik ortak geliştirme projeleri olacaktır. Bunun ilk örneği Çanakkale Onsekiz Mart Üniversitesi (ÇOMÜ) ile yapılan 64-bit projesi olmuştur. ÇOMÜ’de bir öğretim görevlisi önderliğinde bir grup öğrencinin oluşturduğu proje ekibi, UEKAE Pardus ekibinin de katkı ve desteği ile, 2009 yılı ortasından itibaren Pardus’un 64-bit sürümünü hazırlamaya başlamış ve 2010’un ilk aylarında bu çalışmalar ana geliştirme deposuna dahil edilmiştir. Artık Pardus’un 32-bit ve 64-bit sürümleri aynı kaynak deposundan ve aynı anda üretilebilecektir. Özgür yazılım yaklaşımı ile ve fakat belli bir organizasyonel yapı dahilinde yürütülen çalışmalar benzer projelerin oluşturulması için bize ilham vermiştir. Önümüzdeki günlerde çok sayıda üniversite ile benzer yapıda tematik ortak geliştirme projeleri başlatma hazırlıklarını yürütüyoruz.

Özellikle üniversite öğrencileri tarafından ilgi gören bir başka çalışma Google Summer of Code (GSoC) programıdır. Google’ın dünya çapında özgür yazılım projelerini desteklemek amacıyla uzun süreli stajyer öğrencilere ve ustalarına maddi destek vermesine dayalı program 2005 yılından bu yana yürütülmektedir. Pardus projesi 2008 yılından bu yana ve her yıl 5 öğrenci/proje ile GSoC programına dahil olmaktadır. Bu kapsamda öğrencilere doğrudan ürün ağacına katkıda bulunma ve Pardus geliştiricileri ile birebir çalışma olanağı sağlanmaktadır.

Staj, tematik proje ve GSoC programına dahil olan öğrencilerin gelecekte kariyerlerini özgür yazılım çerçevesinde şekillendirmelerini ümit ediyoruz. Bu sayede yalnızca Pardus ekibine nitelikli bir insan kaynağı yaratılmakla kalınmayıp Türkiye özgür yazılım camiasına da yeni yüzler kazandırılabilecektir. Orta vadede hedefimiz bu programlarda yılda 400 öğrencinin yetişmesi planlanmaktadır. Mezun olduklarında doğrudan üretime katkıda bulunacak şekilde donanımlı ve yetkin bir çalışmadan geçen bu genç geliştirici ve girişimcilerin yazılım ve bilişim sektörüne katkıları büyük olacaktır.

Pardus Ekosistemi

Orta vadede PGO’lar, yazılım ve çözüm ortakları, donanım ortakları, eğitim merkezleri ile çeşitlenen ve genişleyen Pardus ekosisteminin Türkiye yazılım ve bilişim pazarında önemli bir ağırlık oluşturacağını öngörüyoruz. Bu ekosistem kurumsal göç projelerinde işbirliği ve sinerji ilkesini ön planda tutarak hızlı, ekonomik, güvenilir ve kaliteli çözümler üretir hale gelecektir. Türkiye çapında hizmet veren, çeşitli dikey pazarlarda yetkinleşmiş, tüm kurumsal yazılım dizisine hakim bir ekosistem, Pardus’un en güçlü varlığı haline gelebilecektir. Öngörümüz orta vadede Pardus ekosisteminin 2.000 kişiye doğrudan istihdam sağlayacağını (mevcut istihdamın yaklaşık %5’i) ve yıllık 50 milyon ABD Doları büyüklüğe ulaşacağını tahmin ediyoruz. Bu sayede Türkiye yazılım sektörünün yeni ve değişik bir gelişme / genişleme alanı ortaya çıkacak, küresel rekabet avantajı oluşturma yönünde bir fırsat yakalanabilecektir.

Bu sayede ulusal güvenlik kaygısı ile ve ürün odaklı başlatılan bir proje, yalnızca 8 yıl içerisinde istihdam yaratan, yüksek katma değerli üretimi hedefleyen, mikro ve makro ölçekte rekabet avantajı oluşturan önemli bir ekonomik enstüman haline gelecektir. Dünyada esmeye başlayan özgür yazılım rüzgarının Türkiye’de hem temsilcisi ve hem de önderi Pardus olacaktır. Pardus projesi artık hedefini "Türkiye bilişim sektörünün evriltilmesi" şeklinde çizmektedir…

Özgürlükİçin: “Özgür Yazılım Lisansları – IV”

Özgürlükİçin.com‘un aylık e-dergisinin Eylül sayısında yayımlanan bu yazı ile özgür yazılım lisansları etrafındaki gezintimiz sona eriyor…

Özgür Yazılım Lisansları
Hukuksal Açından

Özgür yazılım lisanslarını incelememizi bu ay, konuya giriştiğimiz nokta olan hukuksal açıdan irdeleyerek tamamlıyoruz. Yazının başında alışıldık “ben avukat değilim, ama …” şeklinde sorumsuzluk beyanımı yapayım da sonra sıkıntı yaşanmasın.

Mevcut Yasal Yapı

Türk hukukunda yazılımlar 5 Aralık 1951 tarih ve 5846 sayılı Fikir ve Sanat Eserleri Kanunu (FSEK) çerçevesinde düzenlenmektedir. Bu yasa 1983, 1995, 2001 ve 2004 yıllarında çeşitli değişikliklere uğramıştır. 1995 yılındaki değişiklik Gümrük Birliği’ne uyum, 2001 yılındaki değişiklik bu değişiklik sonucu ortaya çıkan çarpıklıkları giderme ve 2005 yılındaki değişiklik de AB mevzuatına uyum amaçlıdır. Yazılımların “bilgisayar programı” adı altında yasaya girişleri 1995 değişikliği ile olmuştur.

FSEK uyarınca “[…] her biçim altında ifade edilen bilgisayar programları ve bir sonraki aşamada program sonucu doğurması koşuluyla bunların hazırlık tasarımları,” birer ilim ve edebiyat eseri sayılırlar, buna karşın “Arayüzüne temel oluşturan düşünce ve ilkeleri de içine almak üzere, bir bilgisayar programının herhangi bir ögesine temel oluşturan düşünce ve ilkeler” eser sayılmazlar. Yasa koyucu bu ifadeler ile yazılımları ürün aşamasında eser olarak değerlendireceğini, düşünce aşamasında bir kapsama sağlamadığını açıkça ifade etmektedir.

FSEK’e göre “Bir eserin sahibi, onu meydana getirendir.”, ayrıca “Birden fazla kimsenin iştirakiyle vücuda getirilen eser ayrılmaz bir bütün teşkil ediyorsa, eserin sahibi, onu vücuda getirenlerin birliğidir.” Yani paylaşımcı bir geliştirme ortamında ve açık olarak geliştirilen özgür yazılımların “sahip”i, Türk hukukuna göre, o yazılımın ayrılmaz parçası haline gelmiş bir katkıda bulunmuş tüm geliştiricilerdir.

FSEK ayrıca “Diğer bir eserden istifade suretiyle vücuda getirilip de bu eserlere nispetle müstakil olmayan” eserleri de “işlenme eser” adı altında sınıflandırıyor ve “Bir bilgisayar programının uyarlanması, düzenlenmesi veya her hangi bir değişim yapılması” sonucu ortaya çıkan yazılımı da bir işlenme eser sayıyor. “Bir işlenmenin […] sahibi, asıl eser sahibinin hakları mahfuz kalmak şartıyla onu işleyendir.” diyerek de işlenme eser sahipliğine açıklık getiriyor.

Sonuçta FSEK, gerek özgür yazılım üretim sürecine ve gerekse özgür yazılımlardan türetilen eserler konusunda uygulanabilir kurallar koyuyor.

Özgür Yazılım ve FSEK

FSEK’in koca bir kısmı eser sahiplerinin Manevi (Umuma Arz, Adın Belirtilmesi, Eserde Değişiklik Yapılmasını Men, vb) ve Mali (İşleme, Çoğaltma, Yayma, Temsil, vb) Hakları’na ayrılmış durumda. Ve genel olarak her türlü hak için “münhasıran eser sahibine aittir.” diyerek, en azından kağıt üzerinde, önemli bir güç veriyor eseri meydana getiren(ler)e. Yukarıdaki özgür yazılım ve işlenme eserler ile baktığımızda, gerek hoşgörülü ve gerekse copyleft lisansları eser sahiplerinin eser üzerindeki haklarını düzenleyen birer hukuksal metin olarak görmek ve FSEK’te tarif edilen işleyişin ayrıntısını düzenlediğini düşünmek mümkün.

FSEK ile özgür yazılımların uyumu konusunda sıkıntı yaratabilecek ayrıntılar yok mu? Var tabii ki… Ama genelde yazılımlar için benzer sıkıntılardan söz etmek de mümkün. Yazılımların oluşturulması ve dağıtılması süreci ve FSEK’in değişiklik tarihleri düşünüldüğünde bu tip sıkıntıların olmaması şaşırtıcı olurdu.

Ne yazık ki Türk hukukunda özgür yazılım lisans sözleşmelerinin hukuksal süreçlerde irdelenmesi ve FSEK kapsamında içtihat oluşturulması için bir örneğe rastlayamadım. Hatta Google’da “FSEK özgür yazılım” şeklinde bir arama yapınca gelen ilk sonucun benim bir web günlüğü girdim olması da düşündürücü. Bu konularda daha fazla çalışmaya ihtiyacımız var, kesinlikle…

FSEK ile ilgili önemli bir saptama da bu yasanın ilk ortaya çıkışından bu yana, tüm değişiklikler de dahil, temel güdü olarak eser sahiplerinin haklarını korumanın temel alınmış olması. Özgür yazılım bağlamında, birkaç yazıdır değindiğimiz gibi, geliştirici yanında kullanıcının ve genelde kamunun yararları da son derece önemli. Kanımca FSEK’e bu açıdan yeni bir bakış da çok yerinde olacaktır…

Özgürlük İçin e-dergisini okuyun, okutun…

Özgürlükİçin: “Özgür Yazılım Lisansları – III”

Özgürlükİçin.com‘un aylık e-dergisine Ağustos sayısında yayımlanan yazım:

Özgür Yazılım Lisansları
Felsefi Açısından

Geçtiğimiz aylarda hoşgörülü ve copyleft özgür yazılım lisanslarını önce geliştiricileri sonra da iş modelleri açısından karşılaştırıp irdelemiştik. Şimdi sırada daha derin bir konu var, aynı lisansları felsefesel ve “özgürlük” kavramı açısından karşılaştırmak.

Özgürlük Nedir?

Hep yararlı gördüğümüz şeyi yapalım ve TDK Güncel Türkçe Sözlük’e bakalım özgürlük sözcüğünün lafzi anlamı için:

Özgürlük: Herhangi bir kısıtlamaya, zorlamaya bağlı olmaksızın düşünme veya davranma, herhangi bir şarta bağlı olmama durumu, serbestî.

İlk adımda sert bir kayaya çarptık, gördüğünüz gibi. Her lisans sözleşmesi bir dizi şart içerir, bu hali ile zaten “özgürlük” sözcüğünün lafzi anlamı ile çelişirler. Ufak bir araştırma ile “şarta bağlı olmama” kısmını ön plana çıkardığımızda “özgürlük”ten “başıboşluk”a gittiğimizi görebiliriz. Eğer bu sözcüğü kullanacaksak, yazılımı başıboş bırakmanın tek yolu kamusal alana bırakmak, yani herhangi bir telif işareti koymamak. Kimi yazılımcılar gerçekten bu yolu seçiyor ve eserlerini kamuya devrediyorlar. Bunun sonucu olarak da bu yazılımlardan türetilecek ürünler üzerinde herhangi bir söz hakları bulunmuyor.

Başıboş yazılım çok tercih edilen bir lisanslama yöntemi değil. Çünkü yazılımcılar ürettikleri ve kamu ile paylaşmaya karar verdikleri fikri mülkiyetlerinin ne şekilde kullanılacağı konusunda, özellikle özgürlük bağlamında söz hakkına sahip olmak istiyorlar. Bunun sonucu olarak da hoşgörülü ve copyleft özgür yazılım lisanslarından birini seçiyorlar.

Geliştiricinin Özgürlüğü, Kodun Özgürlüğü, Kullanıcının Özgürlüğü

Hoşgörülü lisanslar, bir açıdan bakınca, en geniş özgürlüğü sunan özgür lisanslar. Çünkü, adı üzerinde, bu lisanslar geliştiricilere özellikle türev ürünler için son derece geniş bir hareket serbestisi sağlıyorlar. Hoşgörülü bir lisansla yazılmış yazılımdan türeteceğiniz ürünü istediğiniz şekilde sunabiliyorsunuz kullanıcıya, hatta kodunu kapatarak. Apple’ın BSD çekirdeği üzerine inşa ettiği MacOS X’i sürekli örnek veriyoruz bu konuda, ama örnekler saymakla bitmez. Hoşgörülü lisanslar geliştiriciyi özgürleştiriyor, kısıtlarını kaldırıyor. Bu özellikleri ile kimi zaman “gerçek özgür lisanslar”ın hoşgörülü lisanlar olduğu savlanıyor.

Tabi bu noktada önemli bir soru ile karşılaşıyoruz: Özgürlüğü kimin için talep edeceğiz? Geliştiriciyi özgürleştiren lisanslar yazılımı da özgürleştiriyorlar mı gerçekten? Geliştiriciyi özgürleştirmek yönündeki her adım kullanıcıyı da daha özgür kılıyor mu?

Özgür Yazılım Vakfı’nın (www.fsf.org) buna yanıtı net: Hayır, geliştiriciyi özgürleştirmek önemli olmakla birlikte nihai hedef olamaz. Önemli olan kullanıcının özgürleşmesidir. Bu uğurda geliştiricilerin özgürlüklerinden fedakarlıkta bulunulabilir, hatta bulunulmalıdır da. Copyleft özgür lisanslar tam da bunu yapıyor, bir kez özgür kılınan yazılımın (aslen kaynak kodunun) her zaman özgür kalmasını şart koşuyorlar. Örneğin GPL ile lisanslı bir yazılımdan türetilen ürün kapalı kaynak kodu ile dağıtılamıyor. Geliştirici GPL koda el sürdüğünde bu şartı da kabul etmek zorunda. En güzel örnek daha birkaç gün önce Microsoft’un Linux çekirdeğine katkıda bulunmak için GPL lisansını kullanmak “zorunda kalması”.

GPL lisansının (burada kastettiğimiz 1991 tarihli sürüm GPLv2) kodun özgürlüğünü sağlarken kullanıcıyı özgürleştirmek için her zaman yeterince etkili olamadığını geçen onbeş küsur yıl gösterdi. Özgür yazılımları kullanan donanım ürünleri (örneğin en meşhur vaka TiVo) ya da internet bazlı servisler (örneğin Google arama aracı) kaynak kodlarını FSF’in amaçladığı kadar açmadan ve özgürleştirmeden de çalışabiliyorlardı. Bu sıkıntıları da gidermeyi hedefleyen GPLv3 çalışması 2007 yılında tamamlandı. Gittikçe daha fazla yaygınlık kazanan GPLv3 ve Affero GPLv3 lisansları ile kullanıcılar biraz daha özgür olabilecek.

Kişisel görüşüm ise, bu tip karmaşık sorunların yalnızca bir lisans metni ile çözülemeyeceği, özellikle yazılımın yeniden üretimi ve yenilikçi ürün geliştirime konusunda yeterince cazip yeni iş modelleri oluşmadan yapılacak lisans metni iyileştirmelerinin yalnızca sınırlı başarısı olacağı yönünde…

Özgürlükİçin: “Özgür Yazılım Lisansları – II”

Özgürlükİçin.com‘un aylık e-dergisine Temmuz sayısında yayımlanan yazım:

Özgür Yazılım Lisansları
İş Modelleri Açısından

Geçtiğimiz ay özgür yazılım lisanslarını, özellikle hoşgörülü ve copyleft lisansları geliştirici açısından karşılaştırıp irdelemiştik. Bu kez de iş modelleri ve “yazılımdan para kazanma” kapsamında aynı karşılaştırmayı yapacağız.

Copyleft Özgür Yazılımdan Para Kazanmak

GPL ve benzeri copyleft özgür yazılım lisansları, geçen yazımızda da irdelediğimiz gibi, kaynak kodunun türev eserlerden kapatılmasına izin vermiyor. Yani GPL bir kodu alıp bir ürün oluşturduğunuzda bu ürünü de açık kaynak kodlu olarak dağıtmak, satmak zorundasınız. Yani sizin koda eklediğiniz bilgi birikimini ürünü alan herkesle, bu arada rakipleriniz ve pazara yeni gireceklerle paylaşıyorsunuz. Bu durumda ürünün fiyatının düşmesini, sonuçta da sıfıra inmesini engelleyemiyorsunuz teorik olarak. Yani özgür yazılımı (free as in freedom) sonuçta bedava yazılım (free as in free beer) haline geliyor. Doğal olarak “aklı başında” herhangi bir yazılım şirketi de bu yola girmiyor, GPL bir yazılımı alıp para ile satılacak bir ürün haline getirmiyor. Tabii ki aklı başında olmayanlar istisna…

Örneğin RedHat. Tümüyle GPL Linux çekirdeği ve pek çok özgür yazılımdan oluşan bir işletim sistemi oluşturuyor, bu yazılımın kaynak kodunu da erişilebilir durumda tutuyor, hatta marka unsurları hariç kendi ürünü ile aynı (ve bedava yazılım) CentOS’u bir rakip olarak görmekle birlikte kullanıcılarına “istediğiniz zaman CentOS’a göç edebilirsiniz” bile diyor, ve tüm bunlara karşın ürününü satıyor. Binlerce kurum da satın alıyor, RedHat’in yıllık cirosu yarım milyar ABD Doları, piyasa değeri dört milyar ABD Doları’na yakın.

Biraz değişik bir örnek MySQL. MySQL’in farklılığı ürününü GPL olarak dağıtmakla birlikte tüm yazılımın aynı zamanda eser sahibi (yani telif hakları sahibi) olması. Bu sayede aynı ürünü istediğine GPL ile, istediğine daha farklı bir lisansla verebiliyor. MySQL farklı lisansla verdiği ürüne ek özellikler katıp bu özelliklerinin kaynak kodunu kapalı tutma yolunu da izliyor. Bu sayede ek özelliklere ihtiyaç duyanlar için fiyatı sıfıra inmeyecek (hem teoride, hem pratikte), dolayısıyla satılabilir, bir ürün çıkarıyor. Ayrıca MySQL türevi ürünler geliştirecek firmalar bu farklı lisans yolunu kullanıp kendi ürünlerini kapalı kaynak koduyla satabiliyorlar, büyük avantaj. MySQL bu nedenle bir milyar küsur ABD Doları’na satın alındı, Sun tarafından. “Çifte lisans” ya da “özgür çekirdek” diye adlandırılan bu yöntem ürününü GPL ile açmak isteyen pek çok özgür yazılım firması için can kurtarıcı.

Hoşgörülü Özgür Yazılımın Cazibesi

Hoşgörülü özgür yazılım lisansları için iş dünyası çok daha verimli. Aslında MySQL’den bahsederken “farklı lisans” diye adlandırdığımız lisans yine bir özgür yazılım lisansı, ama hoşgörülü. Aklı başında yazılım firmaları hoşgörülü lisansa sahip özgür yazılımları alıp, üzerinde değişiklikler yapıp, ortaya çıkan ürünü kaynak kodunu açmadan pazarlamayı pek seviyorlar. Bu nedenle işletim sistemi çekirdeği ve işletim sistemi olarak BSD (ve kardeşleri) pek revaçta yazılım firmaları açısından.

En baba örnek tabii ki Apple. BSD çekirdeği ve işletim sistemini, üzerine kurulu pek çok özgür yazılımı alıp Mac OS X haline getiren Apple. Hakkını verelim, BSD üzerindeki kimi iyileştirmeleri ana geliştirici ile paylaşıyor Apple. Apple’ın işe dahil olması BSD için iyi bir etki yarattı. Ama BSD’yi ana kaynağından alıp OS X gibi bir hale getirmek pek mümkün değil, çünkü aradaki yolun üzeri örtülmüş. Bu, tam olarak copyleft lisansların önlemeye çalıştığı şey.

Pek çok başka örnek var, isimle saymaya gerek yok. Herhalde meramımızı anlatabildik: Hoşgörülü lisans üzerine iş planı yapmak daha garantili yol, ama copyleft yazılımlardan yazılım satarak para kazananlar da var.

Özgürlükİçin: “Özgür Yazılım Lisansları – I”

Özgürlükİçin.com‘un aylık e-dergisine yazdığım yazılarda birkaç aydır özgür yazılım lisanlarını çeşitli açılardan inceliyorum. Özellikle hoşgörülü ve copyleft lisansların karşılaştırmasını yapmaya çalışıyorum. Geliştiriciler, iş modelleri ve felsefi açıdan değerlendirmelerin yer aldığı ilk üç yazıyı web günlüğüme aktarıyorum. Dizi, büyük olasılıkla, önümüzdeki ay yayımlanacak hukuk açısından değerlendirme yazısı ile son bulacak. İşte Haziran sayısında yayımlanan yazım:

Özgür Yazılım Lisansları
Geliştiriciler Açısından

Geçtiğimiz günlerde Bilgi Üniversitesi Fikri Mülkiyet Hukuku Uygulama ve Araştırma Merkezi (bilfim.bilgi.edu.tr) ile Bilişim ve Yazılım Eser Sahipleri Meslek Birliği (www.biyesam.org.tr) işbirliği ile düzenlenen Hukuki Boyutları ile Bilgisayar Programları konferansına izleyici olarak katıldım. Programda Dr. Emre Bayamlıoğlu’nun özgür yazılımlar ile ilgili bir konuşması bulunması benim için cazibe oluşturan unsurlardan biriydi. Konuşma sonrasında aklımda yer eden ana görüş özgür yazılımı hukukçulara anlatmada eksik kaldığımızı, bunun da özgür yazılım temelli iş modelleri ve iş planları oluşturacak firmalar için bir handikap oluşturabileceği idi. Bu saptama ışığında birkaç yazıda özgür yazılım lisansları ile iş modelleri arasındaki bağlantıyı irdelemeye çalışacağım.

Ortak Payda: Özgürlük

Özgür yazılım lisanslarına eğitimsiz ve deneyimsiz bir bakış ilk anda iki farklı lisans ailesi ve sadece nüanslara sahip iki yaklaşım arasında olmayan “çatışma”yı algılıyor. Bu bilişimciler için de geçerli, öyle anlaşılıyor ki hukukçular için de. Özgür Yazılım Vakfı (Free Software Foundation-FSF, www.fsf.org) tarafından kaleme alınan ve ısrarla savunulan GNU GPL ve uyumlu lisanslar ile Açık Kaynak Girişimi (Open Source Initiative-OSI, www.opensource.org) tarafından onaylanan daha geniş anlamda özgür yazılım lisansları aslında aynı ortak payda üzerine şekilleniyorlar: Özgürlük. Ayrıntılandırmak gerekirse dört temel özgürlük:

  • Özgürlük 0: Programı sınırsız kullanma özgürlüğü.
  • Özgürlük 1: Programın nasıl çalıştığını inceleme ve amaçlara uygun değiştirme özgürlüğü.
  • Özgürlük 2: Programın kopyalarını sınırsız dağıtma özgürlüğü.
  • Özgürlük 3: Programın değiştirilmiş halini dağıtma özgürlüğü.

Gerek GNU GPL, gerekse diğer OSI onaylı özgür yazılım lisansları bu özgürlüklerin karşılanmasını temel şart olarak ortaya koyuyorlar.

Ayrıldıkları nokta ise türev yazılımlarla ilgili şartlar ya da izinler. GNU GPL türev yazılımların da aynı lisansla dağıtılmasını, dolayısı ile bir kez özgürleştirilen yazılımın türevlerinin de kapatılamamasını şart koşuyor. Bu tip lisanslar copyleft ya da karşılıklı (reciprocal) olarak sınıflandırılıyor. Kimi özgür lisanslar ise (örneğin BSD, Mozilla Public License gibi sıkça kullanılan lisanslar) türev yazılımlar için herhangi bir şart koşmuyor, bu nedenle de hoşgörülü (permissive) lisanslar olarak anılıyorlar. Hoşgörülü lisanslar ile bir özgür yazılımı değiştirdiğinizde kaynak kodunu kapatma, türev yazılımı sahipli hale getirme “özgürlüğü”nüz de var. En popüler örnek Apple’ın BSD çekirdeği üzerine şekillenen OS X işletim sistemi. Evet, OS X özgür yazılım değil, ama bu durum BSD çekirdeğinin özgürlüğünü ortadan kaldırmıyor.

Yazılım Geliştirici Açısından Hoşgörülü Lisanslar

Özgür yazılım lisanslarına iş modelleri açısından yaklaşmadan önce yazılım geliştiricinin bakışından değerlendirelim: Karşılıklı lisanslar açık bir şekilde bir kez özgür dağıtılan kodun hep özgür dağıtılmasını şart koşuyor. Tabii tek eser sahibi için çift lisanslama olanakları mevcut, ama bu GNU GPL kodun ve türevlerinin özgürlüklerini etkilemiyor. Hoşgörülü lisanslar ise özgür dağıtılan kodun “sahiplenilmesi”ne olanak tanıyor. BSD çekirdeğine katkıda bulunan bir geliştirici bu kodun kapalı OS X işletim sisteminin başarısına da katkıda bulunacağını, yani özgür olmayan yazılımlara bir anlamda destek olduğunu biliyor.

Yazılımcı olmayan bir kişinin gözünden bakıldığında bu tümüyle bir yarar / zarar analizi ve hür iradeyle verilen bir karar. Kendini FSF felsefesine adamış birisi için kabul edilemez bir uygulama olabilirken olaya daha pratik / pragmatik açıdan yaklaşan birisi için özgür yazılım için elde edilecek fayda ön plana çıkabiliyor. Dolayısı ile hoşgörülü lisansları kullanan yazılımcıları copyleft lisansları kullanan yazılımcılardan daha az “özgür yazılımcı” olarak görmek gibi bir durum söz konusu olmamalı. Her ikisi de özgür yazılımların gelişmesi için çalışıyorlar. Ben, bu nedenle, Türkçe’de ve Türkiye’de “Özgür Yazılım – Açık Kaynak” diye bir ayrıma, FOSS, FLOSS gibi (bence) zorlama bölünmelere ve “çatışma”lara ziyadesiyle karşıyım. Tek bir özgür yazılım tanıyorum, ve her platformda bunu vurgulamaya çalışıyorum.

Gelecek ay hoşgörülü lisansların iş modelleri açısından önemine değineceğiz, işler biraz daha karışacak 🙂