ET's R'n'R Gumbo

Erkan Tekman'ın hayatı ve eserleri…

  • Bilişim Dergisi: “Açık Kaynak Var, Açık Kaynak Var…”

    Türkiye Bilişim Derneği‘nin Bilişim Dergisi‘nin Eylül sayısında yayımlanan Özgürlük İçin… köşesi:

    Açık Kaynak Var, Açık Kaynak Var…

    Bu yazıdan başlayarak birkaç yazımızda özgür yazılımı biraz daha ayrıntılı tanımlamaya çalışacağız. Dünyada artık altı ayda bir “özgür yazılım nedir?” (İngilizcesi ile “what is open source?”) tartışması yaşanıyor, biz de katkıda bulunalım bu süregiden tartışmaya…

    Kaynak Kodunu Açmak Özgür Yazılım için Yeterli mi?

    Özgür yazılımın dört şartını hızla anımsatalım: Kullanma, inceleme ve değiştirme, çoğaltma ve (değiştirerek) yeniden dağıtma. “İnceleme ve değiştirme” şartını yerine getirmenin tek yolu yazılımın kaynak koduna erişebilmek. “Yeniden dağıtma” şartı da dolaylı olarak açık kaynağa dayanıyor. Yani her özgür yazılım açık kaynak kodlu olmak zorunda. Ufak bir saptama: Bu önermenin tersi doğru değil, kaynak kodunun erişilebilir olması yazılımı özgür kılmıyor. Özellikle “yeniden dağıtma” şartı özgürlüğün oluşabilmesi için vazgeçilmez. Gerek Özgür Yazılım Vakfı (FSF – www.fsf.org) ve gerekse Açık Kaynak Girişimi (OSI – www.opensource.org) tarafından kabul gören bir özgür yazılım lisansı olabilmek için bu şartı sağlamak gerekiyor zaten.

    Yalnızca Ürün Değil, Süreç de Önemli

    Kaynak koduna geri dönelim: Evet, özgür yazılım için açık kaynak şart. Ve evet, yeniden dağıtımı sağladığınızda açık kaynaklı yazılımınız özgürleşiyor da. Ama kaynak koduna erişilebilen ve yeniden dağıtılabilen, yani formal olarak özgür yazılım sayılacak her yazılım ürününü aynı kategoride değerlendirmek mümkün değil. Örnek olarak zaman zaman rastladığımız bir uygulamayı vereyim: Bir kurum kendi kullanımı için bir yazılım sipariş ediyor bir şirkete ve kaynak kodunu ve dağıtım hakkını da talep ediyor ürün ile birlikte. Yazılım şirketi hesabını kitabını yapıyor, kurum da şirketin verdiği teklifi kabul ediyor. Şirket, sahipli yazılım geliştirme süreçlerini kullanarak, tümü kendi elemanları eliyle ve kapalı süreçlerle yazılımı oluşturuyor. Sonuçta çıkan ürünü, kaynak kodu ile birlikte kuruma teslim ediyor. Şimdi bu ürün özgür yazılım mı oldu?

    Doğrudur, bu şekilde bir uygulama kurum açısından son derece avantajlı, kaynak koduna sahip olduğu için hapsolma tehlikesi hayli azalmış durumda. Yazılımın bakım ve tutumunu, gerekirse hata giderme ve iyileştirme işlerini üretici şirket dışında bir üçüncü partiye yaptırabilir ve hatta kendisi de yapabilir. Ayrıca yeni kullanım durumları için yeniden lisans almak gerekmiyor, istedikleri gibi kullanıyorlar yazılımlarını.

    Buna karşın yazılım tümüyle sahipli yazılım geliştirme süreci ile geliştirilmiş. Meşhur “binlerce göz” testinden geçmemiş, tasarım ve gerçekleştirmesi tümüyle bağımsız zihinlerde değerlendirilip tartışılmamış, genel paylaşıma açılıp çok değişken şartlarda test edilmemiş … kısacası özgür yazılım geliştirme sürecinin özgüllüklerinden nasibini almamış, bildiğimiz bir kapalı kutu olarak üretilmiş teslim edilmiş.

    “Camiası Olmayan Özgür Yazılım Eksiktir”*

    Yazılım sahibi firma eğer özgür yazılımın özgüllüklerini kullanmak istiyorsa ürünü teslim aldığı andan itibaren bir camia oluşturmak zorunda. Hem geliştiricilerin, hem de kullanıcıların dikkatini çekmesi, ürünün geniş bir çerçevede kullanılmasını sağlaması, yazılımı daha iyi bir hale getirmeyi bağımsız geliştiriciler için ilginç ve iddialı bir iş haline getirmesi gerekiyor. Bunun için de hem yeni kullanıcıların yeni işlevsel beklentilerini yazılıma katmak (ya da katılmasına izin vermek), hem de geliştiricilerin ilgisini çekecek mimari ve teknoloji değişikliklerini yapmak (ya da yapılmasına izin vermek) zorunda.

    İlk başta basit bir yazılım tedariki olarak düşünülen süreç birdenbire bir camia geliştirme macerasına dönüşüveriyor böylece. Diğer seçenek ise yazılımı aynen sahipli yazılım kullanır gibi kullanmak, kaynak koduna müdahaleyi de yalnızca iç (ya da dışkaynaklanmış) bakım ve tutum işleri ile sınırlı tutmak. Bu seçenekte toplam sahip olma maliyetinin sahipli yazılım alternatifinden daha düşük olacağını söylemek ise o kadar kolay değil…

    İki temel sonuca varıyoruz böylece: Özgür yazılımın dağıtık ve paylaşımlı geliştirme ortamı en azından özgür lisansı kadar önemli. Öte yandan bir camiaya sahip olmayan, bir camia oluşturmadan geliştirilmiş “özgür” yazılımlar özgürlüğün pek çok özgüllüğünü kullanamıyorlar, ne yazık ki…

    *Özgürlük İçin (www.ozgurlukicin.com) camiası emektarlarından Ali Işıngör’ün bir sözünden türetilmiştir.

    ,

  • Bilişim Dergisi: “Bile Bile Lades”

    Türkiye Bilişim Derneği‘nin Bilişim Dergisi‘nin Ağustos sayısında yayımlanan Özgürlük İçin… köşesi:

    Bile Bile Lades

    Açık standartlar ve özgür yazılım konulu yazılarımıza geçen ay Pardus 2008 duyurusu için ara vermiştik; kaldığımız yerden devam edelim, hem de güncel bir gelişmeye gönderme yaparak.

    Birlikte Çalışabilirlik Neden Gerekli?

    Hemen her bilişim sistemi diğer bilişim sistemleri ile birlikte ve çoğu zaman bağlantılı olarak kullanılıyor, hayli uzunca bir süredir… Ne yazık ki (ya da “neyse ki” mi diyelim?) farklı işlevler için kullandığımız bilişim sistemleri, farklı ürünlerden, farklı tedarikçiler eliyle, farklı platformlara yerleştirilmiş, farklı farklı sistemler. Üstüne üstlük, yine pek çok kereler bu farklı sistemler şirketimizin, kurumumuzun farklı birimleri tarafından kullanılan ve işletilen altyapıların birer parçası. Teknik, operasyonel ve sosyal açıdan hayli karmaşık bu ortamda bilişim sistemlerinin birbiri ile sorunsuz veri paylaşabilmeleri hayli önemli bir problem. Bunun için bilişim sistemlerinin veri alışveriş arayüzlerinin düzgün tasarlanması gerekiyor, ta başından. Burada “düzgün” derken belli veri standartlarına uyulmasını kastediyoruz aslında, yani “birlikte çalışabilirlik” kurallarına.

    Birlikte çalışabilirliğin temel hedefi makineden makineye veri paylaşımını sağlamak. Bu şekilde işler çok daha hızlı, çok daha kolay, çok daha hatasız görülebilecek. Gerçek anlamda elektronik (yani e-) bir uygulamaya geçebileceğiz, sistemden sisteme elle ya da bir insan müdahalesi ile veri taşımak zorunda kalmayacağız. Birlikte çalışabilirliğin en güzel örneği kamu hizmetleri: Çok farklı devlet kurumlarının elindeki verilerin birarada kullanılması gerekiyor ki gerçek e-hizmet ortaya çıkabilsin. Örneğin askerlik işlemleri için nüfus kayıt bilgilerine, sağlık kayıtlarına ve eğitim kurumlarına erişmek gerekiyor; araç satışı için vergi dairelerine, emniyet bilgilerine, nüfus kayıtlarına, trafik tescil ve muayene kayıtlarına; ve benzerleri…

    Birlikte çalışabilirlik için tüm ilgili taraflar tarafından kabul edilmiş ve uygulanmakta olan kurallar olmadığı sürece e-devlet hayal olacaktır, her kurum kendi uygulamasını elektronik ortama aktarsa bile veri taşıması tümüyle elle yapılacağından.

    Birlikte Çalışabilirlik Nasıl Sağlanır: İki Senaryo

    Birlikte çalışabilirliği sağlamanın kolay (?) ve ucuz (?) yolu tek bir üreticinin ürünlerini kullanmak. Bu üretici tüm ürünlerini, doğal olarak, birbiri ile çalışacak şekilde tasarlayıp ürettiği için sizin birlikte çalışabilirlik sorununuz tümüyle ortadan kalkacaktır. Buna karşın nurtopu gibi bir tedarikçi tekeliniz oluşacaktır. Tedarikçinizin ürünlerine sürüm atlatması sırasında oluşacak veri yapısı değişiklikleri, geriye uyumsuzluklar, vs. de cabası.

    Bir de zor yolu var birlikte çalışabilirliğin: Açık standartları kullanmak. Bu yol zor, çünkü pek çok farklı üreticiyi aynı standartları kabullenmeye ve ürünlerini tasarlar ve üretirken bu standartlara uydurmaya ikna etmek gerekiyor. Üreticiler görünürde performans, geliştirme hızı ve kolaylığı, güvenlik, inovasyon gibi bahanelerle, ama aslında sizi ürünlerine hapsetme ve tekel durumu oluşturmayı tercih ettiklerinden, ortak ve açık standartlara uymayı kabul etmek istemeyecekler; kimi zaman ayak sürüyüp, kimi zaman kendi belirtimlerini birlikte çalışabilirlik kurallarına eklemeye çalışacaklardır. Ama eğer tarafsız ve açık bir birlikte çalışabilirlik kuralları dizisi oluşturabildiyseniz ve daha önemlisi bu kuralları uygulayabiliyorsanız, açık rekabet, dolayısı ile tasarruf imkanı ve inovasyon fırsatı açısından önemli kazanımlar elde etmişsiniz demektir.

    ODF, OOXML ve Birlikte Çalışabilirlik

    Gelelim güncele: Türkiye e-devletinin bir Birlikte Çalışabilirlik Kılavuzu var, hem de 2005 Ağustos’undan bu yana. Mevcut kılavuzda gelecek bir zamanda ofis dokümanları için OASIS tarafından geliştirilmekte olan ODF doküman formatının kamu kurumları arasında belge paylaşımı için tek standart olmasını öngörülüyor(du). Ama ne olduysa kılavuzun güncellenen yeni sürümünde ODF’in yanına Microsoft’un rekabet, tasarruf ve inovasyon yerine hapsolma ve tekel vadeden OOXML formatı da ekleniverdi. Hem de Microsoft dahil tüm taraflar ve tarafsızlar “format savaşları”nda galibin ODF olduğunu açık açık beyan ederken…

    Buna herhalde “bile bile lades” denir.

    , , ,

  • Komedi Devam Ediyor: OOXML’e İtirazlar Reddedildi

    Microsoft’un OOXML doküman belirtiminin bir ISO standardı haline gelmesi süreci üzerine duruşumu biliyorsunuz.

    Oylama sonrasında dört ülke, Güney Afrika, Brezilya, Hindistan ve Venezuella, ISO Teknik Yönetim Kurulu’na başvurarak bu kararı temyiz etmişlerdi. Bu başvuruların önemi hayli karmaşık oylama süreci ardından hala bu sonucu sorgulayan ulusal standart örgütlerinin varlığı idi. Özellikle Mark Shuttleworth’un Güney Afrika başvurusunu desteklemesi ve Hindistan’ın da (Microsoft’un tüm baskılarına karşın) temyizciler arasında bulunması iki önemli noktaydı. Bir de Danimarka’nın resmi olmayan mektubu vardı, oylama sürecini soruşturmakta olan Avrupa Birliği cephesinden…

    Sonunda ISO ve IEC üyeleri kararlarını verdiler: Temyiz başvuruları daha fazla araştırılmayı gerektirecek nitelikte bulunmadı ve reddedildi. Beklenen oldu… Cenevre’deki BRM Oy Çözümleme Toplantısı’nda yaşananlardan sonra zaten ISO’nun yanı ve yeri belli olmuştu. OOXML’in standartlaşma yolculuğunu “sorunsuz” tamamlaması için gerekenler yapılıyor…

    Yine de dört aylık gecikme işe yaradı: Bu arada kullanıcılarının baskısına dayanamayan Microsoft, Office ürününde 2009 yılında ODF desteği vereceğini ilan etti. OOXML desteği ise ufukta görünmüyor. Bu açıklama dahi ODF – OOXML çekişmesinde Microsoft’un OSP Açık Belirtim Taahhüdü’nün ne derece anlamsız ve alakasız kaldığını, tüm bu standart oyununun yeni bir hapsolma tuzağı olduğunu son derece net bir şekilde gösteriyor. Tabii ki gören gözlere, durumu farklı algılayanlar da var…

  • Bilişim Dergisi: “Özgürlük için… Bir Adım Daha”

    Türkiye Bilişim Derneği‘nin Bilişim Dergisi‘nin Temmuz sayısında yayımlanan Özgürlük İçin… köşesi:

    Özgürlük için… bir adım daha

    Yazılarımıza başladığımızdan bu yana özgür yazılım, inovasyon, açık standartlar gibi konularda ve biraz da kavramsal düzeyde sürdürdüğümüz diziye bu aylık ara vereceğiz. Çok daha somut ve güncel bir konuya değineceğiz bu kez. Hem de çok geçerli bir nedenle….

    Yöneticisi olduğum ve TÜBİTAK UEKAE bünyesinde yürütülmekte olan Pardus projesinin en son ürünü, Pardus 2008 geçtiğimiz günlerde tamamlandı ve kullanıcılara sunuldu. Pardus 2008, projenin 2004 sonbaharında başlayan dağıtım geliştirme çalışmalarının dördüncü ürünü. 2005 Şubat ayında temelde gösterim amaçlı yayınlanan, ÇOMAR’ın bir ön sürümünü içeren, PiSi ve YALI gibi Pardus teknolojilerini barındırmayan Pardus Çalışan CD ile başladık işe. 2005 yılının son günlerinde yayımlanan Pardus 1.0 bilgisayara kurulabiliyor ve masaüstü kullanıcısının hemen tüm gereksinimlerini karşılıyordu. Yine de gerek kararlılık, gerek işlevsellik ve gerekse Pardus teknolojilerinin olgunluğu açısından yapılacak çok şey vardı. Bir yıla varan çalışma sonrasında içimize çok daha sinen bir ürün çıkardık: Pardus 2007. Üründen memnun olan yalnızca biz değildik: Dünyanın dört bir köşesinden son derece olumlu değerlendirmeler geldi. Aylık bilgisayar dergileri ürünlerimizi dağıtmak için neredeyse sıraya girdiler, 800 bin civarında CD dağıttık geçen 1,5 yıl içerisinde. Pek çok kurum ve şirket Pardus ile çalışmak için bize başvurdular. Güncelleme ara sürümlerimiz Pardus 2007.1 Felis chaus, Pardus 2007.2 Caracal caracal ve Pardus 2007.3 Lynx lynx merakla beklendiler ve heyecanla karşılandılar. Aynı şekilde Pardus 2008’in de gerek kullanıcılarımız (mevcut ve potansiyel) arasında, gerek iş ortaklarımız (mevcut ve potansiyel) tarafından ve gerekse küresel özgür yazılım camiasında etkili olacağından şüphemiz yok.

    Pardus 2008 Neden Önemli?

    Pardus 2008’in teknik özelliklerini, sürüm numaralarını, Pardus teknolojilerine getirdiğimiz yenilikleri, vb anlatmayacağım. Bunlar, başta web sitemiz www.pardus.org.tr olmak üzere, çeşitli mecrada yazıldı, çizildi; yazılıyor, çizilecek…

    Ben, burada Pardus 2008’in Pardus projesi içerisinde nasıl bir değişime, dönüşüme işaret ettiğinden bahsetmek istiyorum. Evet, bir dönüşüm arefesindeyiz. Haydi Pardus 2008’i bir kilometre taşı olarak kullanıp Pardus’un bugününe ve yarınına bakalım:

    • Öncelikle Pardus 2008, birinci (ve birbuçuğuncu) nesil Pardus geliştiricilerinin azınlık olduğu, asıl ağırlığın ikinci nesil Pardus geliştiricilerine geçtiği bir ekiple tamamlandı. Özgür yazılım projeleri ve şirketlerine benzer bir sirkülasyon hızımız var, dolayısı ile bilgi birikimini kişilerden ekibe geçirmek zorundayız. Öyle anlaşılıyor ki bunu epeyce becermişiz. Ama bekleyin, asıl sınav Pardus 2009 için verilecek…
    • Pardus 2008, öncüllerinden farklı olarak daha beta ve RC (sürüm adayı) döneminde uluslararası düzeyde ilgi çekti ve olumlu değerlendirmeler aldı. Bu da Pardus’un kalıcılığının ve inovasyon özelliğinin küresel Linux camiasınca da onaylandığını gösteriyor. Artık Pardus’un ve Pardus teknolojilerinin dışarıdan çok daha dikkatle takip edileceğinden emin olabiliriz…
    • Pardus’un marka bilinirliği önceki sürümlerine göre hayli artmış durumda. Artık yalnızca bilişim meraklılarının bildiği bir isim olmaktan çıkıp sokaktaki vatandaşın aşina olduğu bir markaya dönüştü “Pardus”. Zihin payının (mindshare) artması pazar payını artırmanın önemli bir ön koşulu…

    Gelecek Pardus için Neler Vaat Ediyor?

    Kısa kısa tahminlerimizi yazalım:

    • Pardus iş ortaklarının sayısı ve çeşidi artacak. Önümüzdeki aylarda duyurularımızı takip edin…
    • Pardus göçleri hızlanacak ve büyüyecek. Özellikle kamu kuruluşlarında… Öte yandan KOBİ’ler için de ilginç haberlerimiz olacak!
    • Pardus’un finansal gücü artacak. Dolayısı ile ekip büyüyecek, iş kolları çeşitlenecek ve en önemlisi daha rekabetçi olmak için gereken hareket kabiliyetine sahip olacağız sonunda…
    • Sonuncusu ve belki de en önemlisi, Özgür yazılımın, açık inovasyonun ve bu ikilinin temsil ettiği yeni iş modellerinin başarılı olabileceği kanıtlanmış olacak…

    ,

  • Ah mazi… reloaded

    Arada bir Pardus projesinin geçmişini deşiyorum. Hem “nereden nereye” ya da “eskiden buralar dutluktu” nostaljisi yapmak babından, hem de bugünün geçmişin geleceği olması hasebi ile bugünden geçmişe bakmanın bugünden geleceğe bakış için de anahtar olacağı inancı ile. Sağlıklı birşey geçmişi deşmek, zaman zaman yapmak lazım 😉

    Bugün anılar kutumuzdan çıkan belge Proje Ana Sözleşmesi. Bu belge 2004 sonunda yeniden start alan Pardus projesinin o anki ve dört yıldır yürümekte olduğumuz yönün belirledi. İlginçtir, belgenin tam tarihine ulaşmak mümkün olmadı. Pardus web sitesinde 25 Şubat 2005 diyor, PDF dokümanı üzerinde 16 Mart 2005 tarihi var. Oysa bu doküman Eylül 2004’de o zamanki Pardus ekibi elinde şekillenip Ekim 2004’ün ilk haftasında yayınlanmıştı. Netekim yarı-resmi proje tarihçemiz (sevgil MEren’in kulaklarını çınlatalım bu noktada, bu güzel çalışma için) 16 Ekim 2004 gününe işaret ediyor. Enteresandır, o zamanlar tek listemiz olan Uludag’da Ekim 2004 boyunca bu konuda bir mesaj yok, nasıl ilan etmişiz Ana Sözleşme’yi merak ettim. LKD’nin Linux-sohbet listesinde sevgili Barış bir soruya yanıt olarak bahsetmiş Ana Sözleşme’den, tarih Kasım 2004. Neyse, bu kadar vakanüvislik yeter, Ekim 2004’ün ilk yarısı diyelim ve devam edelim…

    Uludağ Proje Ana Sözleşmesi tam olarak (bir iki yazım hatasını düzelttikten sonra) şu metin:

    Uludağ

    Proje Ana Sözleşmesi

    1 Giriş

    1.1 Vizyon

    Uludağ, UEKAE tarafından, 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ıdır.

    1.2 Destekleyici

    TÜBİTAK/UEKAE

    1.3 Yürütücü

    Erkan Tekman, Proje Yöneticisi

    1.4 Varsayımlar

    • Proje GPL lisanslı bir özgür yazılım projesi olacaktır.

    • Proje özgür yazılım felsefesine uygun olarak kamuya açık olarak yürütülecek ve katkıcıların yardımlarını kullanacaktır.

    • Proje diğer Linux dağıtımlarının mimarilerini ve bileşenlerini devir alabilecek, açık kaynak kodlu (dağıtım bağımsız) projeleri doğrudan kullanabilecektir.

    • Özgür yazılımlar için yapılan yerelleştirme (Türkçeleştirme) çalışmalarının ürünlerin doğrudan kullanılacaktır.

    2 Proje Tanımı

    2.1 Amaç

    Dürtücü Teknolojiler (DT) olarak adlandırılan dağıtım altyapısını, Harcıalem Dağıtım (HD) olarak adlandırılan klasik dağıtım anlayışı ile birleştirerek; kullanışlı, kararlı ve geliştirilebilir bir işletim sistemi oluşturmak.

    2.2 Sınırlar

    • Mevcut dağıtımların paketlere harcadıkları emek devir alınacak, paketlere (yazılımlara) dair yapılacak güncellemeler bunların üzerine yapılacak.

    • Kurulum uygulaması (installer), paket yönetim sistemi ve yapılandırma araçlarının ortak kullanacağı, merkezi bir altyapı (birleştirici katman) hazırlanacak.

    • Birleştirici katman hazırlanmadan önce kurulum uygulaması, paket yönetim sistemi ve yapılandırma araçları ya bu katman olmadan hazırlanacak ya da var olan özgür yazılımlardan seçilecek.

    • Dağıtım öncelikle Türkçe kullanan kullanıcılar için hazırlanacak.

    2.3 Kaynaklar

    • Özgür yazılımlar

    • Mevcut Linux dağıtımları

    • Açık standart komiteleri

    • Dürtücü Teknolojiler üreten, diğer yenilikçi projeler

    2.4 Kısıtlar

    • Proje Mayıs 2005 tarihinde yukarıdaki amacı gerçekleştirmiş bir deneme sürümü çıkarmak zorundadır.

    • Proje 2004 yılı içerisinde en fazla iki yeni eleman alabilecektir.

    3 Riskler ve Varlıklar

    3.1 İlk 10 Risk

    1. Ortak yol haritası oluşturamamak. Proje elemanlarının hedefe ulaşmak için tek bir yol ve ortak bir amaç üzerinde anlaşamamaları. Risk elemanlardan istenilen (ve beklenen) verimin alınamamasına neden olur.

    2. Terminolojide anlaşamamak. Tüm elemanların kullandığı ve tanımları yapılmış bir terminolojide anlaşamamak proje toplantılarının uzamasına, daha önemlisi kararların her eleman tarafından anlaşılamamasına neden olur. Alınan kararların anlaşılamamasından ötürü elemanlar görevlerini beklenen şekilde yerine getiremezler.

    3. Fikir/amaç uyumsuzlukları. Karar alma sürecine dahil olan elemanlar arasındaki fikir ve amaç uyumsuzluğu karar alma sürecini tıkar. Yavaş işleyen karar alma süreci verimi düşürür.

    4. Aldatıcı riskler üretmek. Tasarım toplantılarının yalnız fikir çatışması olarak görülmesi ve varsayımlar üzerinden yeni riskler üreterek tasarım toplantılarının değiştirilmesi.

    5. Uygulanmayan kararlar. Tüm ekip tarafından ortak karar ile kabul edilen ve/veya proje yöneticisi tarafından alınan kararların elemanlar tarafından uygulanmaması/uygulanamaması.

    6. DT’nin cazibesi. DT’nin cazibesine kapılıp HD bünyesinde yapılacak işlerin zamanından çalmak. Yapılacak tüm işi engeller, anlaşmazlıkları ortaya çıkarır.

    7. HD’nin gerekliliğinin abartılması. HD’nin gerekliliği nedeni ile DT’nin zamanından çalmak. DT’yi engeller, anlaşmazlıkları ortaya çıkarır, vizyonun gerçekleştirilememesine neden olur.

    8. Eldeki güce göre iş planı yapılamaması. Eldeki insan gücü (ve kaynağa) göre iş tanımı yapamamak, ulaşılması kaynaklar ile mümkün olmayan hedefler koymak.

    9. Yeni eleman alımında zorluklar. İstenilen yeteneklerde, gidilen yolu benimseyecek yeni elemanlar alamamak.

    10. Kullanılan araçlarda verimsizlik. Kullanılan geliştirme, iletişim, raporlama, vb. araçlarda; programlama dillerinde elemanların tam hakimiyet kuramamaları nedeni ile veya kullanılan araçların gerçekten verimsiz olmaları.

    3.2 Varlıklar

    • Uzun bir zaman dağıtımların teknik problemleri ve bu problemlerin çözümlerine dair fikir oluşturmuş olduk.

    • Şimdiye kadar tasarım/fikir oluşturma/üretim(kodlama)/bilgi aktarma konularında yaptığımız tüm yanlışlar bu yanlışları daha kolay tanıyabilmemize yardımcı olacaktır.

    • Daha önce bir dağıtım oluşturmuş, mevcut dağıtımların nasıl çalıştıklarını hızlı bir şekilde çözüp çıkartabilen elemanlarımız var.

    3.3 İş Durumu

    • Projenin bir iç ya da dış müşterisi bulunmamaktadır

    • UEKAE tarafından stratejik bir proje olarak değerlendirilmektedir.

    • Ürünün rekabetçi ve sürdürülebilir olması durumunda uygun iş modelleri oluşturulabilecektir.

    Bu metne bakınca, öncelikle bir koalisyon görüyorum. Bundan dört sene önceki Pardus ekibi, içerisindeki farklı yaklaşımlar ve o anda son derece soyut olan tartışmalara referans noktası oluşturabilecek bir öncülün olmayışı nedeni ile ana sözleşmeye öyle sözcükler ve ifadeler dahil etmişiz ki… Sonra hayli fazla muğlaklık görüyorum bu belgede. Örneğin, birleştirici katman diye birşeyden sözediyoruz, şimdinin COMAR’ına denk geliyor büyük ölçekte, ama tarifimiz pek tarif edici olmamış. Ama bu da anlaşılır, Ana Sözleşme sonrasındaki üç sürümde COMAR iki kere baştan yazıldı, sonraki bir sürümde de ciddi bir altyapı değişikliği geçirdi. Muğlaklığı pratikte kaldırmak dahi kaç yılımızı almış…

    Dikkatimi çeken bir nokta İlk 10 Risk listesi… Sevgili Barış tarafından ve ekibin görüşleri doğrultusunda oluşturulan bu liste ve sonrasında güncellemeleri ile projenin risk yönetimini yapmaya çalıştık. Çok yapısal bir çaba değildi, ama bence genelde başarılı da olduk. Dönüp baktığımda en çok 8 ve 9. risklerin başımıza bela olduğunu görüyorum. 8. risk her zaman, 9. risk özellikle 2006’nın ikinci yarısından itibaren. Ve şu anda da güncel bu riskler. Bir diğer önemli risk de 6. sıradaki, yine hala bu tehlikeyi yaşıyoruz, ve doğal olarak önlemlerimizi almaya çabalıyoruz diğer yandan da. Risk yönetimi çalışmalarına yeniden başlıyoruz, risk muhtarı olarak sevgili Ozan Çağlayan’ı belirledik; pek yakında ilk 10 Risk listesi ile karşımıza gelecektir diye ümit ediyorum.

    Son olarak da dehşet bir öngörü görüyorum Ana Sözleşme’de. Dikkat adiniz, bu belge Pardus projesinin sıkıntılı ve karanlık bir sürecinde, neredeyse bir son çareye başvurulduğu sırada kaleme alındı. Başarısızlığın karşılığı projenin kapatılması olacaktı. Ama iki-üç haftada üzerinde anlaşmaya varabildiğimiz bu doküman yalnızca günü kurtarmadı, projenin izleyen üç yılını da tarif etti. Üç yıl diyorum, Pardus 2007 sonrasında artık bu belge projeyi yönlendirmekte yetersiz kalmaya başladı, yavaş yavaş yeni ve gözden geçirilmiş bir Ana Sözleşme gereksinimi hissedilmeye başlandı; ama o günkü koşullarımız bu değişikliğe izin verecek şekilde oluşmamıştı, emektar belgemiz bizi bir yıl daha taşıdı.

    Evet, Pardus projesi takvim üzerinde 5. yılını tamamladı ve mevcut Proje Ana Sözleşmesi ile hemen hemen 4 yıl yürütüldü. Şimdi sırada yeni bir Ana Sözleşme hazırlamak var: Pardus’un 2009-2011 yılları için planlarını yaparken bize rehberlik edecek, ilk sürümüne göre çok daha sağlam temellere dayanan ve dolayısı ile ilkine göre çok daha iddialı olacak olan, ilkinin teknoloji ve sonra kullanıcı ağırlıklı yaklaşımını iş ve kullanıcı ağırlıklı bir yaklaşım ile değiştiren bir Ana Sözleşme…

    Çalışmalara başladık bile: Ben bir taslak üzerinde çalışıyorum. Kısa zamanda tamamlanacak olan taslağı Pardus ekibi ve UEKAE ile paylaşarak son halini vereceğiz. En sonunda da UEKAE yönetiminin onayı ile resmiyet kazanacak Ana Sözleşmemiz. Hedefimiz ilki gibi Ekim başı…

  • remember? “a new pardus… in town…”

    My experience with Pardus was quite positive. The attention to detail, right down to skinning Amarok with the Pardus colors, is matched by the elegance of the installer and the efficacy of Kaptan and PiSi. Booting and running Pardus is quite speedy on my old AMD Sempron 2800+ with 512MB RAM; other distributions with similar features (such as Ubuntu) run slower on the same hardware. In short, I think Pardus is a distribution worth looking at for any Linux users who aren’t happy with their current choice.

    yazının tümü burada // the article is here

    ,

  • Bilişim Dergisi: “Bir Hapsolma Masalı”

    Türkiye Bilişim Derneği‘nin Bilişim Dergisi‘nin Haziran sayısında yayımlanan Özgürlük İçin… köşesi:

    Bir Hapsolma Masalı

    Son olarak Microsoft OOXML örneği üzerinden giderek standartlaşmanın temeli ve açık standartların özgür yazılımın gelişmesi açısından önemine değinmiştik, oradan devam edelim. Donanımı ve yazılımı genelde tedarik eden kullanıcının, yani sizin, bilişim sistemlerindeki tek varlığınız bu sistemlere girdiğiniz bilgi: Veri, malumat, enformasyon, bilgi, bildirim… Ne isimle anarsanız ve hangi işlenmişlik düzeyinde olursa olsun, kısaca “bilgi”. Aslında tüm bilişim sistemi bilgilerinizi saklayacağınız ve işleyerek yeni bilgiler elde edeceğiniz bir depolama ve üretim ortamından başka bir şey değil. Bilişim sistemlerinizin (donanımın, yazılımın, vb) sahipliğini sorgulamayabilirsiniz, ama bilgilerinizin, özellikle bilişim sistemine girdikten sonraki, sahipliğine çok dikkat etmelisiniz. Sonuçta, dedik ya, bu sistemde sizin olan tek varlık bilgi!

    Bir varmış bir yokmuş…

    Bir bilişim sistemine belli bir yatırım yapıyorsunuz, donanımını ve yazılımını satın alıyorsunuz, kullanıcılarınızı eğitiyorsunuz, bakım ve desteğini alıyorsunuz, tedarikçilerinize tavsiye ediyor ve hatta zorunlu kılıyorsunuz, bu sistem üzerine size özel geliştirmeler ve değişiklikler yaptırıyorsunuz… Tüm bilgilerinizi bu sistemde depoluyor, işliyor ve yeniden depoluyorsunuz. Gittikçe daha yaygın ve daha etkin kullanmaya başlıyorsunuz bu sistemi… Bir süre sonra kendi üretim ve yönetim sistem ve süreçlerinizden biri haline geliyor…

    Ancak gün geliyor bu sistemle ilgili çeşitli soru işaretleri beliriyor zihninizde: Acaba çok mu para harcıyorsunuz bu sisteme? Alternatifleri daha çok işinize yarar mı görünüyor? Çok mu çağdışı kalmış sizin sistem, başkaları çok daha modern ve inovatif sistemler kurmuşlarken? Bakımı ve tutumu gittikçe daha zorlaşıyor ve pahalanıyor mu? Başka limanlara yelken açmanın zamanı gelmedi mi? Kararınızı veriyorsunuz: “Yarından tezi yok bu sistemden kurtulacağım, artık başka bir sistem kullanmam daha doğru!”

    Ve ertesi sabah acı gerçekle yüzyüze geliyorsunuz: Ne yazık ki epey bir zaman önce siz bu bilişim sistemine hapsolmuşsunuz, kurtuluş imkansız! İngilizce’ye lock-in diye yerleşmiş olan, bizim en yakın anlamı ile hapsolmak dediğimiz sendromun temelinde bilginize sahip olma/olamama çelişkisi yatıyor işte. Yıllarca büyük bir rahatlık ve güvenle bu bilişim sistemine girdiğiniz bilgiler geçen zaman içerisinde hayli evrilmiş ve artık yalnızca bu sistem tarafından işlenebilir hale gelmiş. Bu bir şey değil, artık bilgilerinizi bu sistemden alıp farklı bir sisteme taşımanız bile mümkün değil. Mümkün olsa bile çok yüksek maliyetle yapılacak bir iş, yeni sisteme geçişin size kazandıracağı pek çok avantajı bir kalemde silebilecek nitelik ve nicelikte bir maliyet!

    Mutsuz Son ve Mutlu Son

    Sizin açınızdan hayli hazinli bir son: Mevcut sistemle hayatınıza devam ediyorsunuz. Ne kadar çağdışı kalsa, ne derece performansı düşse, maliyeti ne kadar fahiş olsa da… Başka çareniz yok çünkü, dedik ya, hapsolmuşsunuz.

    Peki bu masalda mutlu kimse yok mu? Var tabii… Mevcut sistemi size satan, kuran, işletenler. Artık inovasyon yapmak, üretim maliyetlerini düşürmek, süreçlerini etkinleştirmek zorunda değiller. Çünkü onlara mahkumsunuz, hapsolmuşsunuz! Önünüze sürecekleri faturayı ödemekten başka çareniz yok.

    Bu masalın sizin için mutlu şekilde bitmesini sağlayacak bir sihirli değnek var aslında: Açık standartlar. Bilginin yalnızca bilişim sistemleri arasında gidiş gelişte değil, bir bilişim sisteminde depolanmışken de açık standartlara uygun bir yapıda olmasını talep etmek. Bu sayede bilişim sistemi üreticilerinin hapsetme olanaklarını (ya da heveslerini) engellemek; bu sayede donanım ve yazılım üreticilerinin performans, işlevsellik, güvenlik ve maliyet alanlarında rekabet etmelerini şart koşmak…

    Avrupa Komisyonu (EC) ile Microsoft arasında son yıllarda yaşanan anlaşmazlığın, yüz milyonlarca Avroluk cezaların, OOXML oylaması ile ilgili soruşturmaların… altında yatan temel sorunsal bu işte. EC Microsoft’un (haydi orada sınırlı tutmayalım, iTunes ve iPod ile Apple’ın da) bilgiyi hapsetmemesini istiyor. Yoksa bu firmaları yazılım ve ürün bazında sorgulamıyor ya da kısıtlamıyor, tam tersine rekabete açık bir ortamda bu yazılımların ve ürünlerin daha da iyileşeceklerini düşünüyor ve ümit ediyor. Temel endişesi Avrupalı kullanıcının hapsolmaması, bilgisine sahip çıkması ve sonuçta özgürleşebilmesi.

    Özgür olmak için sizin de bilginize sahip çıkmanız gerekiyor, bunun için de hapsolmamanız..

    Not: Yazının başlığı basılı dergide “Bir Mahkumiyet Masalı” olarak yer almış, doğrusu, yukarıda da yazdığı üzere, “Bir Hapsolma Masalı” olacaktı.

    ,

  • Yaşasın “Özgürlük İçin…”

    Özgürlük için Pardus...

    Özgürlük İçin… hareketinin doğumu Şubat 2007’de olmuştu sanırsam, bir Pardus geliştiricileri toplantısında. Sonrasında ismi ve alanadını bir portala çevirme işini yürütmek üzere UEKAE, sevgili Ali Işıngör’ün firması artistanbul ile sözleşme imzaladı. pardus-oyun.org ve pardus-linux.org sitelerinden kimi katılımlar oldu, pardus-linux.org sitesinden kimi itirazlar yükseldi, vb. Ardından da site yavaş yavaş ortaya çıkmaya başladı, ilk başta ittire kaktıra; sonrasında gümbür gümbür. Her geçen gün içeriği güçlendi, altyapısı sağlamlaştı ve katılımcı sayısı arttı Özgürlük İçin…’in. Yeni, bir görsel tasarım ve forum ile yeni bir atak yaptı sonrasında. Tabii ki OOXML’e Hayır kampanyası ile Türkiye özgür yazılım camiasının liderliğine soyundu, Ankaralar’a kadar bizimle geldi, devlet kademelerine OOXML’in hukuksal ve kavramsal sıkıntılarını anlattı. Seminerler vermeye başladı, üniversitelerde şenliklere, sivil oluşumlara katıldı… Sonrasında e-Dergi geldi, harika görsel tasarımı ve gittikçe sağlamlaşan içeriği ile… Artık bilgisayar dergilerinin aranan elemanlarıydılar “Özgürlük İçin… referanslı” genç yazarlar. Oyun sunucusu devreye girdi ve doldu doldu taştı… Bunları yazarken “yahu gerçekten bu işin başlangıcından bu yana yalnızca bir buçuk yıl mı geçti, 2006 olmasın?” diye düşünmekten alamıyorum kendimi.

    Muhteşem bir iş çıkardı camiamız, benim beklentilerimi kesinlikle aştı ve ileriye çok ümitle bakmamıza vesile oldu. artistanbul’un hakkı da ayrı; başta sevgili Ali, sonra Ahmet(ler), Akın ve Seda, hemen ardından Uğur, Denis ve Rasim; tüm takım sözleşmenin gerektirdiğinin kat kat fazlasını yaptılar, camiaya örnek oldular. Sonra camiadan arkadaşlarımız, Deniz Ege, Ekrem, Gökmen, Eren, adlarını şu anda anımsayamadığım için kendilerinden özür dilediğim onlarca diğeri… Pardus camiasının oluşmasına yaptığınız katkıların ne kadar önemli olduğunu söylememe gerek yok ve bunun Türkiye’de özgür yazılımın gelişmesine vereceği desteği. Ellerinize kollarınıza sağlık!

    Bunları neden yazıyorum ve neden bugün yazıyorum? Biraz önce öğrendiğime göre Linux Kullanıcıları Derneği‘nin geleneksel yarışmasında En İyi Basılı/Görsel İçerik dalında Özgürlük İçin…, Yılın Pengueni seçilmiş.

    Tüm Özgürlük İçin… camiasına tebrikler, yapacaklarınızın yanından şimdiye kadar yaptıklarınızın sönük kalacağından eminim, hatta bunu biliyorum. Yanınızdayız, arkanızdayız!

  • Bilişim Dergisi: “‘Tehlikenin Farkında mısınız?’”

    Türkiye Bilişim Derneği‘nin Bilişim Dergisi‘nin Mayıs sayısında yayımlanan Özgürlük İçin… köşesi:

    “Tehlikenin Farkında mısınız?”

    Birkaç yazıdır inovasyon üzerine yoğunlaşmış durumdayız. İnovasyon yeni şeyler yapma ya da eski şeyleri yeni şekillerde yapma durumuna verdiğimiz ad. İlla bir icat ya da keşif kadar çarpıcı ve parlak olmak zorunda değil. Ama sonuçta hızla yarara dönüşecek kadar gerçeğe yakın ve pratik olmalı. İş dünyasının gözünden baktığınızda onyıllar değil aylar ve yıllar içerisinde üretime aktarılabilecek ve rekabet avantajı ya da doğrudan kar getirecek bir şey. İnovasyonda her zaman daha öncekine göre bir farklılık ve yenilik var, ama her farklı ve yeni olan da inovasyon değil. Belki de inovasyon kavramının iş çevrelerinde bu derece cazip olmasının bir nedeni de bu muğlak tanımı…

    Standartlaştırma ise çoğu zaman inovasyona ters yönde, en azından inovasyonu engelleyici nitelikte bir hareket. İşlerin, şeylerin ne olduğunu ve nasıl yapıldığını herhangi bir şüpheye meydan vermeyecek şekilde iyi tanımlamak gerekiyor bir standart üretmek için. Çünkü standartlaşmanın temel amacı kaliteyi yükseltmek, maliyetleri düşürmek ve rekabeti artırmak. Standartların varlığı pazardaki büyük ve güçlü aktörlerin çok arzu ettiği bir şey değil, ama giriş engellerini düşürmesi nedeniyle yeni ya da küçük aktörler için bir güvence.

    Son kullanıcı ve tüketici açısından ise bu ikili yapının sürekli bir dönüşüm içerisinde olması en iyisi: Pazarın düşük fiyatları ve rekabeti tercih ettiği alanlarda standartlaşma yönünde baskı ve çabalar artıyor, yeni işlevsellik gerektiğinde ise standart dışına taşan inovatif değişimler ön plana çıkıyor. Bu sayede ne çağdışı kalmış standartlara mahkum kalıyoruz sürekli, ne de baş döndüren ama gerçek anlamda değer yaratmayan bir inovasyon çılgınlığına kapılıyoruz. Aslında hem o, hem de diğeri. Sektörün ve pazarın durumuna göre kimi standartlar onlarca yıl dayanabilirken, kimileri ancak sürekli güncellenerek gereksinimlere yanıt verebiliyorlar.

    Standart oluşturma, özellikle büyük aktörlerin baskın konum elde etmemeleri için, uluslar ve şirketler üstü tarafsız organlar (ISO ve TSE gibi) eliyle yürütülüyor. Bu sayede standartların gerçek amacı, yani rekabeti artırma işlevi yerine gelebiliyor. İnovasyon ise büyüklü küçüklü her türlü piyasa aktörü tarafından hayata geçirilebiliyor; her ne kadar yaygın kanı büyük aktörlerin inovatif olma konusunda biraz geri kaldıkları yönünde olsa da.

    Özgür yazılımların gelişmesi ve yaygınlaşması standartların açık ve hatta özgür olması ile son derece ilişkili. Sonuçta hiçbir bilişim sistemi tek başına işlev görmüyor artık, farklı sistemlerle birlikte çalışıyor, ya veri alıyor, ya veri gönderiyor; ya iş yaptırıyor, ya iş yapıyor başkalarına. Farklı sistemler arasındaki arayüzlerin “ne olduğunu ve nasıl yapıldığını herhangi bir şüpheye meydan vermeyecek şekilde iyi tanımlamak gerekiyor” birlikte çalışabilmeleri için. Özellikle özgür yazılım ürünleri genelde zaten sahipli ürünlerin mevcut olduğu sistemlere dahil edildikleri için bir tekel oluşmaması, ya da özgür yazılımların önüne bir engel çıkarılmaması için bu, yani standartlaşma son derece elzem. Tabii ki bu standartların özgür yazılım geliştiricilerine açık, kolayca erişilebilir olması gerekiyor; erişildiklerinde de makul bir çaba ile gerçeklenebilmeleri, herhangi bir fikri mülkiyet hakkı engeline ya da rüçhan hakkı ödemesine takılmadan kullanılabilmeleri. Aksi durumda mevcut sahipli yazılım ürünleri özgür yazılımlara birlikte çalışma fırsatı tanımadan bir tekel oluşturabiliyorlar.

    Geçtiğimiz ay Microsoft tarafından geliştirilen ve aslında bir standart değil de bir “ürün” olarak kabul edilmesi gereken Office Open XML (OOXML) dosya biçemi belirtimi, Microsoft’un dünya çapındaki lobi faaliyetleri ve kimi sorgulanabilir girişimleri sonucu ISO tarafından bir uluslararası standart (ISO/IEC DIS 29500) olarak kabul gördü. OOXML içerisinde neler yok ki: Mevcut ve hayli güncel bir uluslararası standart (ISO/IEC 26300 OpenDocument Format) ile büyük ölçüde çakışma ve çelişme, 8.000 sayfa civarında dokümantasyon, Microsoft dahil herhangi bir üretici tarafından gerçeklenmemiş bir belirtim, bol miktarda sahipli teknolojilere atıf, fikri mülkiyet (patentler vb) kapsamında korunmakta olan teknolojiler, daha neler neler… Şimdi yazdıklarımızı başından itibaren bir kez daha okuyun, “tehlikenin farkında mısınız?”

  • newspapers write it: “there is a new pardus in town”

    There are sporadic examples of Turkish open source projects. In August 2007 Turkey’s Military Recruitment Division, which is part of the Ministry of Defense, announced that it was switching to Pardus Linux on all of its 4,500 desktops and more than five hundred servers.

    Pardus is also being used by Turkish Radio and Television Supreme Council as part of its digital television archive and analysis project.

    […] Other early adepter success stories include Manisa Health Directorate, Petrol-Is, and Neziroglu Motors, all of which are using Pardus Linux.

    yazının tümü burada // the article is here

    ,