Paris Komününün Sesleri

Çevirisini yaptığım, Mitchell Abidor'un derlediği Paris Komününün Sesleri kitabı, Kafka Yayınevi tarafından, Alternatif Medya ve Toplumsal Hareketler dizisinin 10. kitabı olarak yayınlandı. Aşağıda kitabın tanıtım yazısını paylaşıyorum:

“1871 Paris Komünü, çoğunlukla katılımcıların kendi deneyimleriyle ilgisi olmayan, birçok ideolojik tartışmanın konusu oldu. Bu hayati önemdeki haftalarda gerçekten ne olduğunu öğrenmek istiyorsanız, bu tanıkların anlatımlarını okumak zorunludur.” —Gabriel Kuhn

İşçi sınıfının ilk iktidar deneyimi olan 1871 Paris Komünü, sayısız kere yorumlandı; düşmanları tarafından ayaktakımının kanlı baküs şenliği olarak kötülenirken, destekçileri tarafından eyleme geçmiş proleter anarşizmin bir örneği olarak övüldü. Hem öykünülecek bir model hem de kaçınılacak bir hata olarak değerlendirildi. Bütün değerlendirmeler taraflıdır. Tarihçiler, işçi sınıfının üç aylık iktidarını, zamansal ve mekansal olarak uzak olan kendi merceklerinden geçirip inceliyorlar.

Paris Komününün Sesleri farklı bir yaklaşım sergiliyor. Bu kitapta yalnızca 1871 baharında mevcut olanların, Komün süresince yaşayan ve ona katılanların sesi var. Paris Komününün canlı bir basını vardı ve bu basın burada en önemli gazetesiyle, birinci enternasyonal üyesi Jules Vallès’ın Halkın Çığlığı ile temsil ediliyor. Herhangi meşru bir hükümet gibi, Paris Komünü de meclis oturumları düzenliyordu ve ateşli, çekişmeli tartışmaların günlük tutanaklarını, diktatörlük suçlamasını yalanlayacak bir şekilde yayınlıyordu. Bu derlemede, Komünün, yenilgiden yalnızca birkaç gün önceki, Kamu Güvenliği Komitesi kurulmasına ve Komün tarafından tutulan, nihayetinde öldürülecek olan rehinelerin kaderine ilişkin görüşmenin tutanakları da yer alıyor. Son olarak, Paris Komününün Sesleri, olaydan yirmi yıl sonra La Revue Blanche tarafından gerçekleştirilen, katılımcılardan Paris Komününün başarılarını ve hatalarını değerlendirmelerini istediği entelektüel incelemeden bir seçkiyi de içeriyor. Bu bölüm, bu çığır açan olaya ilişkin etkileyici bir çeşitlilikteki fikirleri sunuyor.

Dijital Emek ve Karl Marx

Senem Oğuz ile birlikte çevirdiğimiz, Ümit Akıncı'nın editörlüğünü, Diyar Saraçoğlu'nun yayın editörlüğünü ve redaksiyonunu yaptığı Dijital Emek ve Karl Marx kitabı Notabene Yayınları'ndan çıktı. Janus'un Çehresi'nin üçüncü kitabı da yayınlanmış oldu böylece.

Bilişsel Kapitalizm! Eğitim ve Dijital Emek

Bir bölüm çeviriyle katkıda bulunduğum Bilişsel Kapitalizm! Eğitim ve Dijital Emek kitabı Notabene Yayınları tarafından yayınlandı. Günümüzdeki kapitalizmin eğitim ve dijital emek bağlamında analiz etmeye çalışan yazılar içeren kitap, değerli yazılar içeriyor. Notabene Bilişim - Janus'un Çehresi kapsamında benzer bir çok kitap yayınlanacak, ilgilisine duyurulur (daha önce bu seri kapsamında Marx Geri Döndü yayınlanmıştı).

Git Başlangıç Rehberi

Eğer GNU/Linux kullanıcıysanız bir şekilde Git adını görmüş veya duymuşsunuzdur, mesela yeni bir programı indirirken veya CVS ile Subversion gibi sürüm kontrol sistemlerini incelerken. Git değişiklik kontrol sistemidir. Linux çekirdeğinin ünlü geliştiricisi Linus Torvalds tarafından var olan çözümlerle yaşadığı tatminsizlik nedeniyle geliştirilmiştir. Tasarımdaki ana odak hız veya daha belirgin söyleyeceksek, verimliliktir. Git varolan sistemlerin bir çok eksikliğini adresliyor ve hepsini kısa bir zamanda yapıyor.

Git ne yapar

Farzedelim ki bir müşteri için bir web sitesi yaratmakla uğraşıyorsunuz. Onlar ne istediklerini söylüyor, siz tasarlıyorsunuz, gözden geçiriyorlar ve değişiklikler, ayıklamalar, tekrarlar yapıyorlar. Müşteriden gelen her bir değişiklik için, site değişiyor ve büyüyor. Daha sonra müşteri “geçen eylüldeki halini daha çok sevmiştim” diyor. Normal koşullarda problem yaşarsınız. O zamana ait olan tüm dosyaları ve veriye sahip olmayabilirsiniz, ve kodunuz geri alamayacağınız kadar çok değişmiş, işinizi zorlaştıran bir durumda olabilir.

Değişiklik kontrol sisteminin amacı yukarıdaki paragraftaki neredeyse tüm problemleri çözmektir. Kodunuzdaki ve dosyalarınızdaki her değişikliği izleyebilir, istediğiniz bir tarihe, noktaya geri dönebilirsiniz.

Git nasıl çalışır?

Her bir proje dizininin kendisi bir Git deposudur. Projenizin tüm dosyalarını bu dizinde saklarsınız ve belli aralıklarla Git'e dosyaların o anki durumlarını gönderip bilgisini güncellemesini istersiniz. Bu Git'e durum saklama sürecine teslim etmek, sunmak (commit) adı verilir. Her yeni sürüm sunduğunuzda (bunu sık sık yapmanız iyidir) Git izlemekle yükümlü kılındığı dosyalara bakarak bu dosyalarla elindeki sürümleri arasındaki farkları (ve yeni dosyaları) .git dizinine saklar. Her bir sunma projenizin geliştirilmesi açısından bir yeni kayıt noktası olur.

İsteğe bağlı olarak, yerel git deponuzu dışarıdaki bir sunucuya, github.com gibi, koyabilirsiniz. Bu bir projeye birden fazla kişinin katkı vermesini sağlar. Bu kişiler yerel depoların sık, hızlı kayıtlar yapıp, daha sonra tüm bu yerel kayıtları çevrimiçi depoya tek bir güncelleme olarak sunarlar. Bu git diğer sürüm kontrol sistemlerine göre daha hızlı yapan özelliklerden biridir: her yaptığınız değişiklik için yükleme yapmak üzere band genişliğini ve zamanı boş yere kullanmadan yerel deponuza sık kayıtlar yapabilirsiniz.

Git kurulumu

Çoğu GNU/Linux kullanıcısı Git'e (paket ismi olarak git-core) kendi dağıtımlarının standart yazılım depolarından ulaşabilir. Ubuntu kullanıcıları bağlantıya tıklayarak veya uçbirimde aşağıdaki komutla kurabilirler (ayrıca yazılım paket yönetisinde git-core paketini arayıp kurarak):

sudo apt-get install git-core

Eğer başka bir platform veya dağıtım kullanıyorsanız, bu tarz yazılım depoları kullanamıyorsanız paketleri şuradan elle indirip kurabilirsiniz. Her ne kadar anlatacaklarımız GNU/Linux için olsa da, Git tarafından desteklenen tüm platformlar için aynıdır.

Git kullanımı

Yerel Git deposu yaratma işlemi hızlı ve kolaydır. Projeniz için kullanmak üzere bir dizin yaratın ve bu dizin içerisinde bir uçbirim açın. Komut satırında aşağıdaki komutu kullanarak depoyu başlatın:

git init

Bu komut depo bilgisini saklayan .git dizinini yaratacaktır. Daha sonra, bazı dosyalar eklemek isteyebilirsiniz. Basit bir OKUBENİ dosyası yaratarak başlayacağız, dosyayı izlenecek dosyalar listesine ekleyeceğiz, daha sonra dosyayı depoya sunacağız.

#Yeni bir dosya yaratalim
echo "TODO: Belgeleri hazırla" > OKUBENI.txt
#Simdi Git'e bu dosyadaki degisiklikleri izlemesini soyleyelim
#Bu her dosya icin sadece bir kere yapilmalidir
#(bu konudan ileride tekrar bahsedecegiz)
git add README.txt
#Simdi durumu git deposuna kaydedelim
git commit README.txt

Karşınıza bir metin düzenleyici çıkacaktır (hangi metin düzenleyicinin çıkacağı kullandığını dağıtım ve yapılandırmaya göre farklılık gösterecektir), bu metin düzenleyicide depoya sunma işleminiz hakkında notlar, yorumlar girmeniz gerekmektedir. Bunlar genellikle bir önceki depoya kayıt işleminden beri yapılan değişikliklerin bir özetidir. Kaydedip metin düzenleyiciden çıktığınızda depoya sunma, kayıt işlemi başarıyla tamamlanmış olacaktır.

Esas olarak ilgili dosyanın şu anki halinin bir örneğini yaratmış olduk. Daha sonra yapılacak değişikliker (depoya kaydettiğimiz) bu örneğin üzerine kaydedilecektir.

Her dosyayı yukarıdaki örnekte olduğu gibi gitin izlemesi için tek tek eklemek usandırıcı olabilir. Buna çare olarak, dizindeki tüm dosyaları aşağıdaki komutla izlemeye aldırabilirsiniz:

#sondaki "." isaretine dikkat!
git add .

Ve tüm bilinen, değiştirilen dosyaları aşağıdaki komutla depoya tek seferde sunabilirsiniz:

git commit -a

Bazı işe yarar diğer git komutları şunları içerir:

#Varolan bir deponun tam bir kopyasini olusturun (ornegin bir yazilim projesinin #websitesinden indirilebilir)
git clone (URL, örnek: git://github.com/github/linux-2.6.git)
#Bir dosyayi tasiyin/ismini degistirin. Bu sizi dosyayi depodan silme ve tekrar ekleme is #yukunden kurtarir
git mv (kaynak) (hedef)
#Bir dosyayi silip Git deposundan kaldirin
git rm (hedef)
#Depodaki dallari gormek icin
git branch
#Git agacinda yeni bir dal yaratin
git branch (yeni dal ismi, örnek: "experimental")
#Bir daldan diğerine atlayin, degistirin
git checkout (dal adı, örnek: "experimental")
#Dali guncel dalla birlestirin
git merge (dal)

Bu elbette git ile yapabileceklerinizin sadece başlangıcıdır. Eğer yararlı bulursanız size ısrarla resmi Git Topluluk Kitabını öneririm, bu kitapla bu zeki yazılım parçasını nasıl kullanabileceğinize dair daha derin bilgiler alabilirsiniz.

Not: Git Başlangıç Rehberi'nden çevrilmiştir.

Ek Bağlantılar
Introduction to Git
Top 10 Git Tutorials for Beginners

Bilgisayar Bilimcisi Gibi Düşünmek

GÜNCELLEME: Bilgisayar Bilimcisi Gibi Düşünmek: Python ile Öğrenme 3. baskı Özhan Fenerci tarafından çevriliyor.

Bilgisayar Bilimcisi Gibi Düşünmek: Python ile Öğrenme 2. baskının Türkçe çevirisini uzun bir zamandan sonra bitirdim. 3 Ekim 2008'de başlamıştım, araya

giren bir çok iş ve nedenden dolayı 9 Şubat itibariyle bitirdim. Tam bitirdim de sayılmaz aslında, önsöz, giriş, gasp, dizin bölümleri çevrilmeden duruyor. Fırsat bulunca onları da çevireceğim. Yine de yararlı olacağına inanıyorum, Türkçe bir kaynak olarak. Çevirinin PDF haline de aynı sayfadan ve bu bağlantıdan ulaşabilirsiniz.

Çeviriyle ilgili, kitapla ilgili her türlü düşüncenizi bana iletmeyi unutmayın. Yanlışlar, anlaşılmayan yerler, kötü çeviriler gibi. Bunların çevirinin iyileştirilmesi anlamında yararı olacaktır. Kitabın Python öğrenmek isteyen ve Türkçe bir kaynaktan yararlanmak isteyen herkese yararlı olmasını diliyorum.

Ek bağlantıları paylaşıyorum:
http://www.slideshare.net/tekrei/bilgisayar-bilimcisi-gibi-dnmek-python-ile-renme
https://docs.google.com/open?id=0B6Q0hgaZhD5KMTJlNGU1MTItMDgzNS00YWM3LThkZDYtZDg5NDIyY2M3Nzgy
 

GNU'da Türkçe Çeviriler

Özgür Yazılım ve Özgür Toplum kitabı çıktıktan sonra içerisindeki yazıları bir de GNU sitesinde paylaşmak gerekti. Bugüne kadar yayınlanmış çevirilerin bağlantılarını paylaşayım dedim. Çeviri ile ilgili önerileriniz için sayfaların en altındaki bilgileri kullanabilirsiniz.

http://www.gnu.org/events/rms-nyu-2001-transcript.tr.html
http://www.gnu.org/gnu/thegnuproject.tr.html
http://www.gnu.org/philosophy/words-to-avoid.tr.html
http://www.gnu.org/philosophy/push-copyright-aside.tr.html
http://www.gnu.org/philosophy/misinterpreting-copyright.tr.html
http://www.gnu.org/copyleft/copyleft.tr.html
http://www.gnu.org/gnu/manifesto.tr.html
http://www.gnu.org/philosophy/right-to-read.tr.html
http://www.gnu.org/philosophy/free-doc.tr.html
http://www.gnu.org/philosophy/shouldbefree.tr.html
http://www.gnu.org/philosophy/lessig-fsfs-intro.tr.html
http://www.gnu.org/philosophy/can-you-trust.tr.html
http://www.gnu.org/philosophy/university.tr.html
http://www.gnu.org/philosophy/selling.tr.html
http://www.gnu.org/philosophy/pragmatic.tr.html
http://www.gnu.org/philosophy/open-source-misses-the-point.tr.html
http://www.gnu.org/philosophy/copyright-and-globalization.tr.html

Yazılım Mühendislerinin Bilmesi Gereken 10 Kavram

Yazılım mühendislerinin bilmesi gereken 10 kavram başlıklı bir yazı. Aşağıda yazdığım 10 kavramın yazılım mühendisleri tarafından bilinmesi gerektiği söyleniyor yazıda. Ayrıca yazıya yapılmış yorumlarda farklı kavramların da eklenmesi gerektiği önerilmiş. Yazının İngilizce olduğunu hatırlatırım.

1. Arabirimler (Interface)
2. Kurallar ve şablonlar
3. Katmanlama
4. Algoritma karmaşıklığı
5. Hashing
6. Önbellekleme
7. Koşut zamanlılık (Concurrency)
8. Bulut Hesaplama (Cloud Computing)
9. Güvenlik
10. İlişkisel Veritabanları

MVC ile Java SE ortamında uygulama geliştirme

Model-View-Controller (MVC) nedir?

Grafiksel kullanıcı arayüzü (GUI – Graphical User Interface) kütüphanelerini (AWT, Swing, ..) kullanarak yazılım geliştirdiyseniz, MVC tasarım deseniyle karşılaşmış olmanız oldukça olasıdır. MVC ilk olarak 1979 yılında Xerox Palo Alto araştırma merkezinde Smalltalk geliştiricisi olan Trygve Reenskaug tarafından, veri erişimi, iş mantığını ve kullanıcıya gösterilen davranışları birbirinden ayırmak için ortaya atılmıştır. Daha kesin olarak açıklayacak olursak MVC üç parçaya bölünebilir:

Model: Model veriyi ve bu veriye erişim ile güncellemeyi yöneten kuralları temsil eder. Kurumsal yazılımlarda, model genellikle gerçek yaşam sürecinin yazılım karşılığı olarak hizmet eder.

Görünüm (View):Görünüm modelin içeriğini ortaya çıkarır. Model verisinin tam olarak nasıl gösterilmesi gerektiğini tanımlar. Eğer model verisi değiştiğinde, gerektiğinde görünümde temsili güncellemelidir. Bu itme (push) yaklaşımı kullanımıyla yapılabilir, bu yaklaşımda görünüm model üzerindeki değişiklikler için kendini kaydeder (değişiklik durumunda model katmanı görünümü tetikler). Bir diğer yaklaşım olan çekme (pull) yaklaşımında ise görünüm en güncel veriye ulaşmak için modeli çağırmakla yükümlüdür.

Denetleyici (Controller): Denetleyici kullanıcının görünümle olan etkileşimlerini, modelin gerçekleştireceği eylemlere çevirir. Standalone GUI istemcisinde kullanıcı etkileşimli düğme tıklamaları veya menü seçimleri olabilir, kurumsal web uygulamalarında ise GET ve POST HTTP istekleri olarak gözükürler. Kapsama bağlı olarak, denetleyici kullanıcıya göstermek için yeni bir görünüm üretebilir(sonuçların web sayfası gibi).

Her ne kadar farklı mimariler bu üç bileşenin farklı şekillerde etkileşmesini sağlasa da, Şekil 1'de MVC tasarım deseninin genel kabul görmüş bir gerçekleştirimini görebilirsiniz (Sun BluePrints Catalog'dan alınma):

Şekil 1. Genel kabul görmüş bir MVC gerçekleştirimi

MVC Bileşenleri Arasında Etkileşim

Bu bölümde Şekil 1'deki gerçekleştirime Java platformu (Java SE 6) bağlamında daha derinlemesine bakacağız. Model, görünüm ve denetleyici nesneleri ilklendiği anda aşağıdakiler oluşur:

1. Görünüm kendisini model üzerinde dinleyici olarak kaydeder. Modelin altındaki verideki herhangi bir değişimde doğrudan değişim bildirimi yayını ortaya çıkar, bu görünüm tarafından alınır. Bu daha önce bahsettiğimiz itme yaklaşımının bir örneğidir. Bu yaklaşımda model ne görünüm, ne de denetleyicinin farkında değildir, sadece değişim bildirimlerini tüm ilgilenen dinleyiciler için yayınlar.


2. Denetleyici, görünüme bağlanmıştır. Bu tipik olarak görünümde gerçekleştirilen herhangi bir kullanıcı eyleminin, denetleyici sınıfında kayıtlı bir dinleyici metodunu başlatması (invoke) anlamına gelmektedir.


3. Denetleyici alttaki modele bir referans barındırır.

Kullanıcı görünümle etkileştiği anda, aşağıdaki eylemler oluşur:

1. Görünüm bir oluşan GUI eylemini -örneğin bir düğmeye tıklamak veya kayan çubuğu hareket ettirmek- algılar. Bunu bu tip bir eylem oluştuğunda çağrılmak üzere kaydedilmiş bir dinleyici metodu kullanarak gerçekleştirir.


2. Görünüm denetleyici üzerindeki uygun metodu çağırır.


3. Denetleyici modele erişir, kullanıcının eylemine bağlı olarak uygun bir şekilde güncelleme yapma ihtimali vardır. Eğer model değişirse, ilgili dinleyicileri, görünüm gibi, değişim hakkında bilgilendirir. Bazı mimarilerde, denetleyici ayrıca görünümü güncellemekle de sorumlu olabilir. Bu Java tabanlı kurumsal uygulamalarda sık karşılaşılan bir durumdur.

Şekil 2 bu etkileşimi daha ayrıntılı olarak göstermektedir.

Şekil 2. MVC kullanan bir Java SE uygulaması

Daha öncede söylendiği gibi, model görünüme bir referans içermez, ancak eylem bildirme yaklaşımını değişimle ilgilenen taraflar için kullanır. Bu güçlü tasarımın bir sonucu birden fazla görünüm aynı alt modeli kullanabilir. Modelde bir değişim olduğunda, her bir görünüm bu özellik değişiminden haberdar olarak, kendisini gerektiği şekilde güncelleyebilir. Örneğin Şekil 3 aynı veri modelini kullanan iki farklı görünümü göstermektedir.

Şekil 3. Aynı modeli kullanan birden fazla sayıda görünüm

MVC Tasarımını Değiştirmek

Son zamanlarda daha fazla geçerli olan bir MVC tasarımı denetleyiciyi model ve görünüm arasına yerleştirmektedir. Bu tasarım, Apple Cocoa anaçatısında sıklıkla görülür, Şekil 4'te görülebilir.

Şekil 4.Denetleyicinin Model ve Görünüm arasında olduğu bir MVC tasarımı

Bu tasarımla, daha geleneksel sürüm arasındaki birincil fark, model nesnelerindeki durum değişimlerinin bildirimlerinin görünüme denetleyici aracılığıyla aktarılmasıdır. Böylece, denetleyici model ve görünüm arasındaki veri akışını iki yönlü olarak yönetmiş olur. Görünüm nesneleri, her zaman olduğu gibi, kullanıcı eylemlerini model üzerindeki özellik güncellemelerine dönüştürmek için denetleyiciyi kullanır. Ek olarak, model durumundaki değişiklikler görünüm nesnelerine uygulamanın denetleyici nesneleri üzerinden iletilir.

Böylece, bütün üç bileşende ilklendiğinde, görünüm ve modelin ikisi de denetleyiciye kaydedilir. Kullanıcı görünümle etkileştiğinde, olaylar neredeyse aynıdır:

1. Görünüm bir oluşan GUI eylemini -örneğin bir düğmeye tıklamak veya kayan çubuğu hareket ettirmek- algılar. Bunu bu tip bir eylem oluştuğunda çağrılmak üzere kaydedilmiş bir dinleyici metodu kullanarak gerçekleştirir.


2. Görünüm denetleyici üzerindeki uygun metodu çağırır.


3. Denetleyici modele erişir, kullanıcının eylemine bağlı olarak uygun bir şekilde güncelleme yapma ihtimali vardır. Eğer model değişirse, ilgili dinleyicileri, görünüm gibi, değişim hakkında bilgilendirir. Ancak bu durumda değişim denetleyiciye gönderilir. Denetleyicide gerekli görünüm değişiklikleri için Görünüm katmanıyla haberleşir.

Bu tasarım neden kullanılmalıdır? Bu değiştirilmiş MVC, modeli görünümden tamamen ayırmak için yardımcı olur. Bu durumda, denetleyici kayıtlı olduğu bir veya daha fazla modelde bulmak istediği model özelliklerini zorlayabilir. Ek olarak, kayıtlı olan bir veya daha fazla görünüm için modelin özellik değişimlerini etkileyen metotları sağlayabilir.

Kaynak:Java SE Application Design With MVC

Açık Standartlar: İlkeler ve Pratik (Çeviri)

Açık Standartlar:İlkeler ve Pratik
Açık standart bir belirtimden daha fazlasıdır. Standartın ardındaki ilkeler ve standartın işletilmesi ve önerilmesindeki ilkeler o standartı açık yapan nedenlerdir.

İlkeler
Elde edilebilirlik (Availability): Açık standartların herkesin okuyabilmesi ve gerçekleştirebilmesi için elde edilebilirdir.

Son kullanıcının seçeneklerini arttırma: Açık standartlar gerçekleştirimler için adil, rekabete dayanan bir pazar yaratırlar. Müşteriyi (kullanıcıyı) belli bir marka veya grubun egemenliğine sokmazlar.

Telif hakkı yok: Açık standartlar herkesin gerçekleştirmesi için ücretsizdir, telif hakları yoktur. Standartlar kuruluşu tarafından verilen uygunluk sertifikası bir ücret gerektirebilir.

Ayrım yok: Açık standartlar ve standartları yöneten kuruluşlar bir gerçekleştiriciyi diğer gerçekleştiricilere göre sağlayıcının gerçekleştiriminin teknik standartlara uyması dışında bir nedenle tercih edemezler, kayıramazlar. Sertifikasyon kuruluşları düşük veya sıfır maliyetli gerçekleştirimlerin doğrulanması için bir yöntem sağladıkları gibi, gelişmiş sertifikasyon hizmetleri sunabilir.

Genişletme veya Alt Küme: Açık standartların gerçekleştirimleri genişletilebilir veya alt kümeler biçiminde önerilebilir. Ancak, sertifikasyon kuruluşları alt küme gerçekleştirimlerini sertifikalandırmayı reddedebilir, ve genişletmeler için gereksinimler koyabilir (Bkz: Yağmacı Pratikler).

Yağmacı Pratikler: Açık standartlar standartın kabul et ve genişlet (embrace-and-extend) biçimindeki tahriplere karşı standartı koruyan lisans şartları içerebilir. Standarta iliştirilmiş olan lisanslar genişletmelerin referans bilgisini yayınlamayı ve diğerlerinin genişletmelerle uyumlu yazılım yaratma, dağıtma ve satmasına yönelik lisans gerektirebilir. Bir açık standart genişletmeleri başka türlü yasaklamaz.

Pratik
Elde edilebilirlik: Açık standartlar herkesin okuması ve gerçekleştirmesi için elde edilebilir durumdadır. Bu nedenle
1.Standartın metni ve referans gerçekleştirimleri internet üzerinden ücretsiz olarak indirilebilir bir şekildedir. ,
2.Herhangi bir yazılım projesi standartın bir örneğini (kopyasını) herhangi bir zorlukla (mali, yasal) karşılaşmadan elde edebilmelidir. Maliyet bir üniversite ders kitabının maliyetini aşmamalıdır.
3.Standart belgelerine eklenmiş lisanslar, standartın gerçekleştirimini herhangi bir yazılım lisansı kullanarak üretmeyi kısıtlamamalıdır.
4.Yazılım referans platformlarını lisanslamanın en iyi pratiği (yöntemi) yazılım lisanslarının tüm türlerini, özgür yazılım olsun sahipli yazılım olsun, desteklemesidir. Ancak, yazılım referans platformları için uygun olabilecek lisans kısıtlamaları için “Yağmacı Pratikler” i tekrar incelemek gereklidir.

Son kullanıcının seçeneklerini arttırma: Açık standartlar, standartın gerçekleştirimleri için adil, rekabetçi bir pazar yaratırlar.Bu nedenle
1.Geniş çerçevede; özel sektör, akademi ve kamu projeleri olabilecek gerçekleştirimlere izin vermelidirler.
2.Çok pahalıdan, maliyetsiz üretime kadar geniş bir aralıkta ücretlendirme politikasına da izin vermelidir.

Telif hakkı yok: Açık standartlar, herkesin geliştirmesi ve gerçekleştirmesi için ücretsiz olmalıdır, telif hakkı veya ücret istememelidir. Uyumluluk sertifikası standart organizasyonu tarafından bir ücret karşılığı verilebilir. Bu yüzden;
1.Standart içerisindeki patentler telif hakkı istemeyen bir şekilde lisanslanmış olmalıdır ve herhangi bir ayrımcı şart içermemelidir.
2.Sertifika programları düşük veya sıfır maliyetli sertifikalandırma içermelidir, ancak yüksek maliyetli geliştirilmiş markalı programlar da içerebilir.

Ayrım yok: Açık standartlar ve standartları yöneten kuruluşlar bir gerçekleştiriciyi diğer gerçekleştiricilere göre sağlayıcının gerçekleştiriminin teknik standartlara uyması dışında bir nedenle tercih edemezler, kayıramazlar. Sertifikasyon kuruluşları düşük veya sıfır maliyetli gerçekleştirimlerin doğrulanması için bir yöntem sağladıkları gibi, gelişmiş sertifikasyon hizmetleri sunabilir. Bu nedenle,
1.Kendisini sertifikasyon markalandırması yöntemiyle kendisini desteklemek isteyen bir standart organizasyonu bir özel yöntem (“premium track”) sunduğu gibi düşük maliyetli veya maliyetsiz bir yöntemde sunmalıdır. Özel yöntem sağlayıcının gerçekleştirimini ve geliştirilmiş markalandırmasını doğrulamak için sağlayıcının tesislerinin dışında bir sertifikalandırma laboratuvarı sağlayacaktır. Sertifika işareti daha standart için yüksek oranda bir doğrulama ve finansal desteği gösterecektir. Düşük maliyetli veya maliyetsiz yöntem, sağlayıcı ve temel markanın kendi kendini sertifikalandırmasını kastetmektedir.

Genişletme veya Alt Küme: Açık standartların gerçekleştirimleri genişletilebilir veya alt kümeler biçiminde önerilebilir. Ancak, sertifikasyon kuruluşları alt küme gerçekleştirimlerini sertifikalandırmayı reddedebilir, ve genişletmeler için gereksinimler koyabilir (Bkz: Yağmacı Pratikler).

Yağmacı Pratikler: Açık standartlar standartın kabul et ve genişlet biçimindeki tahriplere karşı standartı koruyan lisans şartları içerebilir. Standarta iliştirilmiş olan lisanslar genişletmelerin referans bilgisini yayınlamayı ve diğerlerinin genişletmelerle uyumlu yazılım yaratma, dağıtma ve satmasına yönelik lisans gerektirebilir. Bir açık standart genişletmeleri başka türlü yasaklamaz.
1.Standart organizasyonu Sun Industry Standards Source License'a benzeyen bir antlaşmayı standart belgesine ve beraberindeki referans gerçekleştirime uygulamak isteyebilir. Sun antlaşması referans gerçekleştiriminin (asıl ticari gerçekleştirim değil) herhangi bir gerçekleştirimle beraber yayınlanmasını gerektirir. Bu yöntem, standart organizasyonunun yenilikçiliği boğmadan birlikte çalışabilirliği korumasına olanak sağlar.

Sözlük
Kabul et ve genişlet (embrace-and-extend): Pazardaki hakim durumdaki standart sağlayıcı bir firmanın kullanabildiği bir yağmacı pratiktir. Diğer sistemler (gerçekleştirimler) pazardaki büyük çoğunluğu oluşturan ve hakim durumdaki firmanın ürettiği sistemlerle uyumsuzluğa düşmüş olurlar. Hakim durumdaki firma patentleri veya telif hakkını kullanarak diğer firmaların yeni genişletmelerle uyumlu sistem gerçekleştirmelerini engellemeye başlar. Bu standart üzerinde bir tekel kilidi yaratmış olur. Kullanıcı böylece diğer kullanıcılarla uyumlu olabilmek için hakim sağlayıcının gerçekleştirimini kullanmaya zorlanmış olur.

Özgür yazılım: Bilgisayar yazılımı veya diğer ortam üreticilerinin özgürce kullanma, dağıtma ve değiştirme haklarını diğerlerine aktardığı bir paradigmadır. Bu, bu tür işler üzerinde herkese açık geniş bir işbirliğini doğurur. Özgür yazılım tarafından kullanılan lisanslama Açık Kaynak Tanımıyla uyumludur. Ancak Özgür Yazılım ve Açık Kaynak aynı şeyin iki farklı yüzüdür. Özgür yazılım promosyonu, yazılım kullanıcılarının sivil özgürlüklerinin üzerinde dururken, Açık kaynak promosyonu gücünü iktisadi faaliyet (“business”) içerisinde kullanıma yoğunlaştırmıştır.

Açık Kaynak: Özgür yazılıma benzer, ancak iktisadi faaliyette kullanıma odaklanmış, bilgisayar kullanıcısı veya geliştiricisinin sivil özgürlüklerine vurgusu azdır. Açık Kaynak Tanımı : http://www.opensource.org/docs/definition_plain.html Bruce Perens'in (bu yazının yazarı) bu konudaki görüşleri : http://perens.com/OSD.html 

Açık Standartlar: İlkeler ve Pratik, Açık Kaynak Tanımını ve Debian Sosyal Antlaşmasını da hazırlayan Bruce Perens tarafından hazırlanmıştır.

Metnin Aslı: Open Standards: Principles and Practice

Açık Kaynak Yazılım Hakkındaki 10 Mit Cevaplandı, Yazan: Carlo Daffara

Bu makale AB projesi FLOSSMetrics'teki araştırmaların bir parçasıdır. Bu araştırma kapsamında küçük ve orta ölçekli işletmelerin özgür ve açık kaynak yazılımı (Free/Libre/Open Source Software - FLOSS ) benimsemelerine yardımcı olmak amacıyla bir rehber yazılması amaçlanmaktadır. Bu rehberin ilk sürümü yakında hazır olacaktır.

Carlo Daffara
Yazının Aslı : http://www.groklaw.net/articlebasic.php?story=20070828132340846

Türkçe'ye çeviren : Tahir Emre Kalaycı (http://www.tekrei.org)

Açık Kaynak Yazılım Hakkındaki 10 Mit Cevaplandı

1999 yılında, açık kaynak yönelimli yayımevinin kurucusu Tim O'Reilly Fortune 500 yöneticilerinden oluşan katılımcılara yönelik "Açık Kaynak Yazılım Hakkında On Mit" adında bir konuşma yapmıştır. Günümüzde bu mitlerin hala doğru olarak kabul edildiğini güncel bazı raporlar[1] göstermiştir ve bunlar FLOSS benimsenmesi önünde bir engel olarak yer almaktadır. Bu makale kapsamında bu öğretici cevaplar vermeye çalışacağız:

Mit #1: Açık kaynak Linux'e karşı Windows olayıdır

FLOSS hakkındaki güncel tartışmalar hepsi veya hiçbiri algılamasına odaklanmaya devam etmektedir, örneğin bir şirkete FLOSS'u tanıtmak için tam bir yazılım aktarımı gereklidir. Bu ve geniş olarak bilinen FLOSS projeleri (Linux, Apache, OpenOffice.org vb.) dışındaki projeler hakkında sınırlı bilgi bulunduğu gerçeği, çoğu FLOSS projesinin Microsoft ürünlerinin doğrudan rakibi olmak üzere tasarlandığı ve yönetildiği algısını oluşturmuştur. Gerçek ise Bilgi Teknolojilerinin (BT) hemen hemen her alanında, işe özel ERP sistemleri de dahil olmak üzere, muazzam sayıda etkin proje var olduğudur ve bu projelerin çoğu etkin projeler olup platform bağımsız ve Microsoft Windows, Apple's OSX (ki kendisi 300 açık kaynak projeye dayanmaktadır) veya Linux üzerinde çalıştırılabilmektedir. (FLOSS projeleri genel görünüm boyutu hakkındaki bir tahmin için "Estimating the number of active and stable FLOSS projects" yazısını inceleyebilirsiniz.)

Mit #2: FLOSS ne güvenilir ne de desteklidir

Bu yanılgı FLOSS'un koordine olmamış veya yapısal olmayan bir şekilde gönüllü yazılımcılar tarafından geliştirildiği idrakına dayanmaktadır. Bu bakış açısında bir çok hata vardır:

Gönüllülük: Büyük ölçekli projeler gönüllü katkısı önemli bir parçasını (bazen çoğunu) oluştursa da, geliştiricilerin %50'si FLOSS projeleri için çalışmalarından dolayı ya doğrudan projeyi geliştirmek için ödenerek veya destek şeklinde finansal bir karşılık aldılar. Bu güncel çalışmalardan [2] ve yazılım endüstrisindeki yazılım ürünlerinin %68'inin doğrudan FLOSS'tan türetilmiş kod içerdiği gerçeğiyle anlaşılabilir.

Ücretli programcılar daha iyidir: Her ne kadar gönüllülerin katkısı yüksek olsa da, kaliteli yazılım üretmek için finansal bir dürtü olmamasından dolayı düşük kaliteli yazılım düşüncesi vardır. Bu, bazı durumlarda içsel (yaratılıştan kaynaklanan) dürtülerin parasal dürtülerden daha etkili olduğu ve bazen kullanıcıların kullandıkları yazılımı düzeltmeye yönelik ilgileri olduğu [3] gerçeklerini yadsımaktadır. Bu ikinci etkinin, kullanıcı güdümlü yenilikçilik (user-driven innovation), önemli bir güç olduğu geçmiş çalışmalarda gösterilmiştir. Örneğin, yazılım güvenliği, baskılı devre kartları (printed circuit board) CAD sistemleri, ve kütüphane yazılımları gibi alanlardaki yeniliklerin %25 civarında bir kısmı gelişmiş kullanıcılar tarafından tasarlanmış ve tanıtılmıştır. Aynı etki temel tasarım geri bildirimine olanak sağlar, büyük bir proje olarak yazılımı kullanmadaki iyi ve kötü deneyimlerin toplanmasını sağlar Örneğin Ubuntu Linux Tanıklık ve Deneyimler Sayfası ("Testimonial and Experiences Page") projenin kullanıcı güdümlü bir yönlendirilmesine ve arıza noktalarının tanımlanmasına olanak sağlar.

Destek yok: Çoğu geniş ölçekli proje, sahipli yazılım şirketlerine benzeyen ve paralı destek sağlayan şirketlere sahiptir. Kaynak kodun mevcudiyeti ve değiştirme hakları ayrıca (etkinliğini yitirmiş projeler için bile) ek destek sağlanması avantajını doğurmaktadır. Sahipli yazılımda edinme kontratında kaynak emanetine dair madde olmadığı durumlarda bu temel bir farklılık olmaktadır.

FLOSS doğasında güvenilmezdir: Çoğu kişi FLOSS'un sahipli yazılımlara nazaran doğasında daha düşük kalitede olduğuna inanmaktadır. Gerçek ise çoğu FLOSS projesinin yarı katı yapıyla yönetildiğidir, sadece bazı çok modüler projeler doğuştan "pazar tarz"ına ve geniş ölçekli içsel ayrıma izin vermektedir. Bir çok araştırma bildirisinde FLOSS tipi geliştirmenin etkisi değerlendirilmiştir, ve örneğin bir yazılım mühendisliği makalesinde [4] aşağıdaki ifade bulunmuştur:

"Açık kaynak yazılımın yaratıcılığı arttırdığı hipotezi analizimizle desteklenmiştir. Büyüme ortanı, veya eklediğimiz işlev sayısı açık kaynak projelerde kapalı kaynak projelere göre daha büyüktü. Bu açık kaynak yaklaşımın zamanla kapalı kaynak yaklaşımına göre daha fazla özellik sağlayabileceğine işaret etmektedir. Uygulayıcıların market payını arttırma ilgileri nedeniyle ek özellikler sağlamaları, açık kaynak yöntembilimine hedeflerine erişmek için kullandıkları bir yöntem olarak baktıklarını gösterir. Kusurlar açısından analizimiz, değişme oranı veya değiştirilen işlevlerin toplam işlevlere oranının açık kaynak projelerinde kapalı kaynak projelerine göre yüksek olduğunu bulmuştur. Bu sonuç kusurların açık kaynak projelerinde kapalı kaynak projelerine göre daha hızlı bulunup çözüldüğü hipotezini desteklemekte ve açık kaynak yazılım geliştirme modeli kullanmanın ek bir faydası olarak görülebilmektedir."

Bu ifade, yazılım kusur tanımlama aracı üreticilerinin sonuçlarıyla tutarlıdır. Örneğin Reasoning aracı çalışmalarında hata yoğunluğu oranının başlangıç proje sürümlerinde sahipli yazılımlarla bir olurken, sürekli iyileştiği ve bazı projelerde kusur yoğunluğunun ortalama sahipli koda göre oldukça düşük olduğu ortaya çıkmıştır. Reasoning ile MySQL konusunda yapılan bir çalışma aşağıdaki sonuçları üretmiştir:

"Her KLOC (1000 Satır Sayısı) için 0.09 kusur yoğunluğu halinde, incelenen MySQL sürümünün ortalama karşılaştırılabilir sahipli projelere göre 6 kat daha az kusur yoğunluğuna sahip olduğu görülmüştür."

Bu Coverity raporları gibi diğer çalışmalarla da doğrulanmıştır.

FLOOS'un genelde güvenilir olduğu gerçeği daha önce bahsedilen CIO Insight taraması gibi taramalarla da çıkarsanabilir. CIO Insight taramasından "Şirketimin Linux dışındaki açık kaynak ürünlerle deneyimi çok iyi oldu ve kullanımlarını arttırmayı düşünüyoruz" sorusuna cevap verenlerin %79'u olumlu bir yanıt vermiştir.

Mit #3: Büyük şirketler Açık Kaynak yazılım kullanmıyor:

Bu çürütülmesi en kolay mittir: büyük BT şirketlerinin (IBM, HP, Sun ve Oracle) etkin olarak Açık Kaynak yazılımı teşvik etmesinin dışında Fortune 1000 şirketlerinin yaklaşık %86'sı FLOSS'u konuşlandırmakta veya sınamaktadır, ve benzer sonuçlar Avrupa'da da vardır [5]. Bu şirketlerin, %35 veya daha fazlası sistemlerinin %20'sinden fazlasını FLOSS olarak konuşlandırmakta, ve şirketlerin %11'i uygulamalarının %20'sinden fazlasının Açık Kaynak yazılım olduğunu bildirmektedir. Sunucu merkezli ve BT altyapılarında kullanım daha sık karşılaşılan bir durum olsa da, büyük şirketlerin %26'sı masaüstü bilgisayarlarda Linux kullanımından ve daha büyük bir oranda şirket OpenOffice.org ve Firefox gibi diğer FLOSS'ların Microsoft Windows masaüstü bilgisayarlarda kullanımından bahsetmektedir. Diğer taramalardan ortaya çıkan ilginç bir gerçek çoğu şirket ve kamu yönetimlerinin kendi içsel FLOSS kullanımlarından haberdar olmadıkları gerçeğidir. Bunun nedenleri arasında basit bir lisans bilgisizliğinden ve bazen kullanılan sahipli yazılımın içermesi sayılabilir (Örneğin çoğu güvenlik ve ağ ürünleri FLOSS'u içsel olarak kullanmaktadır).

Mit #4: Açık Kaynak yazılım, "fikri mülkiyet"e düşmandır

Bu mit açısından farklı ifadeler vardır:
GPL lisansı viraldır: En çok kullanılan lisans, GPL yazılım kodundan üretilmiş yazılım ürünü tekrar dağıtılacağı zaman, tüm ürün aynı lisans altında dağıtılmalıdır şeklinde özel bir ifadeye sahiptir. Bu "GPL'in viral etkisi, GPL kullanan herhangi bir organizasyonun fikri mülkiyetine karşı tehlike yaratmaktadır" şeklinde iddiaları ortaya çıkarıyor. Çoğu senaryo için gerçek ise, yukarıdaki ifade basitçe kodun katkı sağlayanlarını ve üreticilerini belirtmeden kullanılmasını önlemektedir. Bu ayrıca çoğu geliştiricinin GPL lisansını diğer lisanslara tercih etmesinin nedenlerinden biridir. Açık Kaynak yazılımın "basitçe" kullanımı içsel olarak geliştirilen yazılımın lisansını değiştirme gereksinimi yaratmamaktadır ve çoğu şirket sahipli yazılımlarını GPL ile lisanslanmış örneğin Linux kerneli gibi yazılımlar üzerinde çalıştırmaktadır.

Özgür Yazılım ("Free Software") topluluğu diğer şirketlerin fikri mülkiyetini çalıyor: Bu ifade, SCO Group şirketinin 2003 yılında IBM'in Linux çekirdeği içerisinde telif hakkı olan materyal kullandığı iddiasıyla dava açmasıyla ortaya çıkmıştır. Asıl iddiada IBM "SCO'nun gizli ve sahibi olduğu bilgilerin Linux, özgür işletim sistemi, içerisine koyduğu" ve çekirdek içerisinde milyonlarca satır kodun SCO'nun Unix kaynak kodundan alındığı şeklinde suçlanmaktadır. Halbuki, kamuya ihlal edilmiş kodun bulunduğuna dair bir bilgi verilmediği gibi, iddianın muhatabı topluluktan bir talepte de bulunulmamıştır. Şimdi, dört yıl sonra, suçlamada milyonlarca satır kodun bulunmadığı gibi, mahkeme Ağustos 2007 tarihinde UNIX ve Unixware telif haklarının, SCO'nun 1995 yılında aldığını iddia ettiği gibi Novell'den SCO'ya geçmediğini ortaya çıkarmıştır. Telif hakları SCO'ya ait olsa bile, davanın son durumunda 300 satırdan daha az kod bu suçlama içerisinde yer almaktadır ve bu kodun genellikle standart arayüz kodu olması nedeniyle kim sahip olursa olsun telif hakkı koruması altında bulunamayacağına çoğu kişi inanmaktadır. Bu 6 milyon satırlık Linux çekirdeği içerisinde 300 satırdır.

Daha sonra, Microsoft, CEO'su Steve Ballmer aracılığıyla Linux'un "bizim patentlenmiş fikri mülkiyetimizi kullanmaktadır" şeklinde sadece patentlerle ilgili olarak benzer suçlamaları ortaya atmıştır. Ancak, bir kere daha, ayrıntılar açıklanmamıştır. (Craig Mundie'nin, Microsoft yardımcı başkanı, New York Üniversitesi Stern Business School'da 2001 yılında yaptığı konuşma incelenebilir, bu konuşmada kaynak kodu kamu alanına aktarmanın "sağlıksız" olduğunu, güvenlik riskleri oluşturduğunu ve "tarihin gösterdiği gibi, bu tip bir model yer bulsa da, büyük bir market kurmak, tüketicilerin erişebildiği güçlü ve kullanımı kolay bir yazılım üretmek için başarılı olmadığı"nı söylemiştir. Bill Gates GPL için "ticari bir şirketin bu tip bir işi kullanması ve üretmesini olanaksız kıldığını" söylemiştir. Steve Ballmer'ın "Linux bir kanserdir, dokunduğu herşeye kendisini fikri mülkiyet düşüncesiyle iliştirir...eğer herhangi bir açık kaynak yazılım kullanırsanız, geri kalan tüm yazılımlarınızı açık kaynak yapmanız gerekir" şeklinde ünlü bir söylemi de vardır.)

Gerçekte ise, yapısal FLOSS projeleri katı bir yama kabul politikalarına sahiptir, örnek olarak Eclipse projesinin katı önlem süreci vardır, bu süreç dışsal katkıları, kod hakları görevleri, kod gözden geçirme ve lisans uyumluluğunu kapsamaktadır. Eclipse kurumu ayrıca kod kopyalama ve yasal öneme sahip anahtar kelime taraması için otomatikleştirilmiş kontrol ve kodun güncellenmesiyle ilgili kontrollü sürüm gözden geçirme gibi araçlara sahiptir. Benzer süreçler diğer FLOSS projelerinde de mevuttur [6].

Mit #5: Açık kaynak yazılım tamamen lisanslarla ilgilidir

FLOSS tanımı her ne kadar lisans sistemini kapsasa da, kodun "açıklık" tanımının genişletilmesi, farklı gruplar arasındaki geliştirme çabalarının paylaşılması kavramını (altmışların erken kullanıcı gruplarına benzer bir şekilde) ortaya çıkarır. Bu bağlamda, Eric Raymond "The Cathedral and the Bazaar" makalesinde paylaşımlı geliştirme kavramınıtanıtmıştır, her geliştiricinin kodun hangi parçası üzerinde çalışacağını seçme özgürlüğüne sahip olduğu "pazar" yöntemini, yapısal ve katı resmi geliştirme yaklaşımı "katedral" yöntemini karşılaştırmıştır.

Kavram çabucak kabul görmüş olsa da, gerçekte işbirliğiyle geliştirilen projelerin katedral ve pazar modelleri arasında bir yöntemle geliştirilme yönelimi vardır. Örneğin, çoğu proje için resmi bir yapı (bir çok alt proje, dış katkılara daha fazla açık olması gibi) varken, bazı projeler için (örneğin FLOSS'u sertifikalandırılmış havacılık veya güvenlik kritik sistemler) daha katı bir resmi yapı sözkonusudur. Raymond tarafından vurgulanan önemli bir nokta, hem kodlama hem de yardımcı etkinliklerin (hata düzeltme ve belgelerin üretilmesi gibi) büyük bir topluluk tarafından paylaşılabileceği, böylece "sanal yazılım evleri" duygusunun çaba ve kaynak sağlayan gönüllü bir şekilde yaratılabileceğidir. Bu ayrıca geniş uzman kullanıcı topluluğu için bir kaldıraç görevi görerek, bu kullanıcıların önemli bir ölçüde katkı sağlamalarını destekler. Bu sonuçlar Von Hippel'in makalelerinde de gösterilmiştir.

Bu şekilde bir işbirliği gerçekleştiğinde, sadece kaynak kodu biçiminde olmayabilir, örnek olarak [7]:

"2000 yılında, Open Cascade'e dışarıdan 50 katkı sağlayıcı farklı çeşitlilikte yardım sağlamışlardır: yazılımı diğer sistemlere aktarmak (IRIX 64 bits, Alpha OSF), kusurları düzeltmek (hafıza sızıntıları, vb.) ve öğrenceyi İspanyolca vb. diğer dillere çevirmek gibi. Şu anda 70 etkin katkı sağlayıcı var ve hedef bu sayıyı 100'e ulaştırmak. Bu dışarıdan gelen katkı sağlayıcılar önemlidir. Open Cascade bu katkı sağlayıcıların yazılım değerinin %20'sini temsil ettikleri şeklinde bir kestirimde bulunmaktadır."

Open Cascade, 3B CAD/CAM sistemleri yaratmak için karmaşık ve gelişmiş bir araç kutusudur.

Benzer bir görüş Aaron Seigo'nun Akademy KDE konferansında 2006 yılında sunulmuştur, bu sunumda gönüllülerin KDE içerisinde genellikle aşağıdaki alanlarda katkı sağladığını söylemiştir:

• Sanat ("Artwork")


• Belgeleme


• İnsan Bilgisayar Etkileşimi


• Pazarlama


• Kalite Güvence


• Yazılım Geliştirme


• Çeviri

Eğer toplam yazılım uygunluğu düşünülürse, kod olmayan katkıların da en az kaynak kod kadar önemli olduğu açıktır; örneğin, çeviriler, belgeler ve toplam kalite yazılım dünya çapında son kullanıcılar tarafından benimsenmesi için yaşamsal öneme sahiptir.

Bu şekilde bir işbirliği rakip şirketler arasında bile gerçekleşebilir, örneğin potansiyel güvenlik açık duyuruları farklı rakip Linux üreticileri arasında çoğunlukla paylaşılmaktadır. Red Hat'ten Marx Cox iki yılın olay tepkilerini ve bilgi kaynaklarını incelediğinde açık ortaya çıkarmada en büyük kaynak olarak FLOSS dağıtıcılarının olduğunu bulmuştur.

Mit #6: Eğer yazılımımı Açık Kaynak toplulukuna verirsem, binlerce geliştirici birden benim için karşılıksız çalışmaya başlar

Kaynak kodu basitçe topluluka bırakmanın FLOSS projesini ortaya çıkaracağı garantisi yoktur, ve bu tip bir davranışın olumsuz etkiler doğurduğunu gösterecek bir çok örnek vardır, çünkü topluluklar bu davranışı kod "çöplük boşaltma"sı olarak görebilir. Gerçekte ise işbirlikçi bir topluluk oluşturmak için, en başta iyi bir iletişim ve etkileşim stratejisi oluşturmak ve temel gereksinim olarak çaba göstermek zaruridir. Ayrıca, topluluk yaratmaya ve çabaları yaymaya yönelik yatırım iki yönlü çaba paylaşımını arttıracaktır. Önemle vurgulanması gerekir ki, OSSWatch veya CIO Insight tarafından yapılan araştırmalarla şirketlerin ve kamu yönetimlerinin önemli bir kısmının (%14 ve %25) yama desteği verdiği veya FLOSS topluluklarına etkin olarak katıldığı ortaya çıkmıştır.

Mit #7: Açık kaynak yazılım sadece programcılar için önemlidir, çünkü çoğu kullanıcı motor kapağının altına hiç bakmaz

Çoğu kullanıcının kaynak kodla ilgilenmediği gerçeği, kaynak kodu birlikte vermenin gereksiz olduğunu ortaya çıkarmaz. Bir çok olumlu açı tanımlanabilir:
Kodun mevcudiyeti son kullanıcının, FLOSS projesi kaybolur veya etkinliğini yitirse bile değişiklikler ve bakım için parayla birinden yardım almasına olanak sağlar
"Motor kapağının altında" sadece kaynak kod değil, kod olmayan bir çok ürün de vardır, ve bu ürünler (çeviriler, belgeler, örnekler ve daha fazlası) proje açısından hayati önem taşırlar. Çoğu kullanıcı (programcı olmayanlar bile) bu tip açılardan da katkı sağlayabiliyor.
Bazı projeler için, kaynak koda sahip olmak ciddi bir maliyet azalmasına veya önerilen çözümün esnekliğinin artmasına neden olmaktadır. Örneğin, MuleSource (gelişmiş bir ara yazılım sistemi) adı verilen bir projede kullanıcıların %64'ü en azından bir kaynak kodu değişikliğini gerçekleştirmiş.

Sahipli dünya (bazen kod değerlendirilebilir ancak hiç bir şekilde değiştirilemez) ile önemli fark, kodun sadece alıcıların üreticinin iflası durumunda alıcılara garanti sağlayan değil, gerçek yaşayan bir öğe olmasıdır. Geliştirici olmayan kullanıcılar için kaynak kodun mevcudiyeti "garanti politikası" görevini gördüğü çıkarsanabilir. Gelişmiş kullanıcılar ve geliştiriciler için ise kaynak kod derin özelleştirme ve uyarlama olanağını sağlar.

Mit #8: Özgür yazılımdan para kazanılmaz.

Çoğu araştırmacı bir şekilde, özgür olarak mevcut olan kodun doğası gereği potansiyel ticari istismarı engellediğini beyan etmişlerdir. Örneğin [8] "GPL etkin olarak kar yapan firmaların,tüm türetilmiş ürünlerin de GPL lisansı altında dağıtılması gerekliliği yüzünden herhangi bir kodu kullanmasını önlemektedir". Bu elbette HP (2003 yılında Linux ile ilişkili 2.5Milyon$ gelir bildirmiştir) gibi, Red Hat gibi (2006 yılında 400Milyon$ gelir) firmaların ekonomik sonuçlarıyla çelişmektedir. Gosh tarafından yapılan bir ekonomik çözümlemede aşağıdaki değerlendirmeler yapılmıştır:
Geniş tanımıyla, FLOSS'la ilişkili servisler 2010 yılında tüm BT servislerinin %32'sine , ve FLOSS'la ilişkili ekonomi Avrupa GSYİH'sinin %4'üne ulaşabilir.
FLOSS, AB'nin içerde geliştirilen yazılımının %29'unu (ABD'de %43) doğrudan desteklemektedir.
FLOSS potansiyel olarak endüstrinin yazılım ArGe yatırımının %36'sını korumasına, böylece artmış karlar veya daha fazla yenilikçiliğe ayrılmasına olanak sağlar.
Avrupa'nın FLOSS yazılıma yatırımının değeri 22 Milyar Euro (Amerika'da 36 Milyar) olup, toplam yazılım yatırımının %20.5'ini (ABD'de %20) oluşturmaktadır.

Bu sonuçlar doğrudan önemli bir market olduğu şeklinde yorumlanabilir (Bunun ölçülmesi zordur, çünkü marketler sunucu marketindeki lisans satışlarıyla değerlendirilmektedir).

FLOSS'a dayanan bir çok potansiyel iş modeli vardır; 80 şirketi ve yaklaşımları için "Open Source Business Models: a Taxonomy of Open Source Firms’ business models" ve "Business models in FLOSS-based companies" incelenebilir.

Mit #9: Açık Kaynak hareketi sürdürülebilir değildir, çünkü geliştiriciler başkalarının kendi çabalarından para kazandığını görünce özgür yazılım geliştirmeyi bıracaklardır

Bu ikinci mitle ilişkilidir, FLOSS'un gönüllüler tarafından geliştirildiği , ve şirketlerin ücretsiz olarak ürettikleri kodtan sadece parazit yolla kar ettikleri düşüncesi. İlgili yerde tartışıldığı gibi, çoğu projede şirketler ve gönüllüler işbirlikçi ve rekabetçi olmayan bir şekilde katılım gösterir. Ayrıca en çok kullanılan lisans (GPL), şirketlerin emeklerinin karşılığını almaları için, GPL projelerinden türetilmiş kodların yayılması sözkonusuysa kaynak kodlarını zaruri olarak yaymaya zorlayarak karşılıklı olarak faydalanmaya olanak sağlar.

Mit #10: Açık Kaynak Microsoft ve ticari dünyayı yakalamak için uğraşıyor

Yazılım yenilikçiliği kavramı iki farklı açıya dayanmaktadır: teknik yenilikçilik ve alan yenilikçiliği. Teknik yenilikçilik genellikle kullanıcı tarafından görülmezken, "alan yenilikçiliği" (örneğin yeni bir tür uygulama) yüksek oranda görünürdür, ve bu konudaki geniş algı çoğu FLOSS yazılımın başka bir masaüstü yönelimli sahipli uygulamanın az ya da çok bir kopyası olduğu şeklindedir.

Gerçek ise çoğu sahipli yazılımın bu açıdan yenilikçi olmadığıdır; ve çok az sayıda yeni kavram (Dan Bricklin'in hesap çizelgesi fikri gibi) bulunabilirken çoğu uygulamanın kişilerin günlük olarak gerçekleştirdikleri görevlere yönelik, aşinalıktan uzaklaşma yenilikçiliğine karşı olmasıdır. 500 Sourceforge projesi hakkında yapılan bir çalışma [9] alan yenilikçiliği bakış açısına göre, proje örneklerinin, sahipli yazılım marketindeki orana göre karşılaştırılabilir bir oran olan %12'sinin yenilikçi sayıldığını ortaya çıkarmıştır. Teknik yenilikçilik açısından, daha önce belirtilen Succi, Paulson ve Eberlein çalışmasında [4] "Açık kaynak yazılımın yaratıcılığı arttırdığı hipotezi analizimizle desteklenmiştir. Büyüme ortanı, veya eklediğimiz işlev sayısı açık kaynak projelerde kapalı kaynak projelere göre daha büyüktü. Bu açık kaynak yaklaşımın zamanla kapalı kaynak yaklaşımına göre daha fazla özellik sağlayabileceğine işaret etmektedir" ifadesi ortaya çıkmıştır. Bu yüzden hem teknik hem de alan bakış açısından, FLOSS sahipli yazılıma denk veya daha iyi sonuçlar üretmektedir.

Kaynaklar:

[1] CIO Insight, CIO Insight OSS survey 2007. Evans Data, Open Source Vision report, 2005. Forrester consulting, Open Source Software’s Expanding Role in the Enterprise March 2007. IDC, Open Source in Global Software: Market Impact, Disruption, and Business Models. IDC report, 2006

[2] Gosh, et al. Free/Libre/Open Source Software Worldwide impact study: FLOSSWorld. FLOSSWorld project presentation.

Gosh, et al. Economic impact of FLOSS on innovation and competitiveness of the EU ICT sector.

[3] Von Hippel, E. and G. von Krogh, Open Source Software and the “Private-Collective” Innovation Model: Issues for Organizational Science. Organization Science, 2003. (2): p. 209-223. Von Hippel, E. Democratizing innovation. MIT press, 2005

[4] Succi, Paulson, Eberlein. An Empirical Study of Open-Source and Closed-Source Software Products, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, V.30/4, april 2004

[5] Augustin, L. Living with open source: the new rules for IT vendors and consumers. OSBC 2004 conference

[6] Rigby P.C., German D.M. A preliminary examination of code review processes in open source projects. University of Victoria technical report, 2006,

[7] Jullien N. (ed) New economic models, new software industry economy. RNTL report

[8] Hahn, W.R. (editor), Government policy towards open source software. AEI-Brookings, 2002.

[9] Klincewicz, K. Innovativeness of open source software projects. Technical report, School of Innovation Management, Tokyo Institute of Technology. 2005

Listener ve Adapter karşılaştırması

JavaBeans bileşen modeli (ve buna bağlı olarak Swing bileşen kümesi) özellikler ve eylemler üzerinde kurulmuştur. Özellikler setter ve getter'lar yardımıyla değerlerini kullandırmaktadır. Eylemler, oluşlarının farkedilmesi için dinleyicileri (Listener) kullanmayı ve arabirimleri (interface) gerçekleştirmeyi gerekli kılmaktadır. Özelliklerle çalışmak kolay olsa da, dinleyici nesnelerin -özellikle grafiksel kullanıcı arayüzü (GUI) dünyasında- nasıl çalıştığını anlamak için biraz açıklama yapmak gereklidir. Özellikle, bu yazıda hem dinleyici arabirimi hem de adaptör gerçekleştirimi sunan AWT ve Swing olay ilişkili sınıflarını açıklamaya çalışacağız.

Aşağıdaki sınıflar hem dinleyici hem de adaptör eşlerine sahip sınıflara örnek olarak gösterilebilir:
package java.awt.event
- ComponentListener / ComponentAdapter
- ContainerListener / ContainerAdapter
- FocusListener / FocusAdapter
- HierarchyBoundsListener / HierarchyBoundsAdapter
- KeyListener / KeyAdapter
- MouseListener / MouseAdapter
- MouseMotionListener / MouseMotionAdapter
- WindowListener / WindowAdapter

package java.awt.dnd
- DragSourceListener / DragSourceAdapter
- DragTargetListener / DragTargetAdapter

package javax.swing.event
- InternalFrameListener / InternalFrameAdapter
- MouseInputListener / MouseInputAdapter

Bu sınıf eşleri aynı işi yapmanın iki yolunu sunarlar. İlk olarak adaptör sınıfı sunmayan basit bir örneği inceleyelim. ActionListener sınıfı tek bir actionPerformed metoduna sahiptir. Anonim iç sınıf kullanarak, ActionListener sınıfını aşağıdaki şekilde kullanırız:

ActionListener listener = new ActionListener() {
public void actionPerformed(ActionEvent actionEvent) {
System.out.println("Olay gerceklesti");
}
};



Ayrıca ActionListener arabirimini daha yüksek bir sınıfta actionPerformed metodunu gerçekleştirerek kullanabiliriz:

public class MyClass extends JFrame implements ActionListener {
...
public void actionPerformed(ActionEvent actionEvent) {
System.out.println("Olay gerceklesti");
}
}

ActionListener arabirimi tek bir metoda sahiptir, ve arabirimin gerçekleştiricileri sadece bu tek metod için bir gerçekleştirim sunmak zorundadır.

Diğer dinleyici arabirimleri bu kadar kolay değildir. Örneğin, MouseMotionListener arabirimi iki metod içermektedir: mouseDragged ve mouseMoved. Arabirim gerçekleştirirken, arabirim tarafından tanımlanan bütün metodları gerçekleştirmeniz gerekmektedir:

MouseMotionListener listener = new MouseMotionListener() {
public void mouseDragged(MouseEvent mouseEvent) {
System.out.println("Surukleniyorum: " + mouseEvent);
}

public void mouseMoved(MouseEvent mouseEvent) {
System.out.println("Hareket ediyorum: " + mouseEvent);
}
};

Bazı durumlarda uygulamanızda belli bir dinleyici arabirimi için tüm olayları izlemeniz gerekmeyebilir. Örneğin kodunuzun dinleyici arabirimindeki sadece bir veya iki metoda karşılık vermesi yeterli olabilecektir. Örneğin sadece farenin hareket ettiğini mi yoksa sürüklemeyi mi (tuşa basılı hareket ettirme) takip etmek istiyorsunuz? MouseMotionListener'ın sadece bir metodunu gerçekleştirip diğerini dışarıda bırakamazsınız:


MouseMotionListener badListener = new MouseMotionListener() {
public void mouseDragged(MouseEvent mouseEvent) {
System.out.println("Surukleniyorum: " + mouseEvent);
}
};

Bu dinleyici gerçekleştirimi derleme zamanı hatasına neden olacaktır. Çünkü arabirimdeki tüm metodlar gerçekleştirilmemiştir. MouseMotionListener gibi arabirimler için bu çok ciddi problem yaratmayabilir. İlgilenmediğiniz metodları boş bırakabilirsiniz:


MouseMotionListener listener = new MouseMotionListener() {

public void mouseDragged(MouseEvent mouseEvent) {
System.out.println("Surukleniyorum: " + mouseEvent);
}

public void mouseMoved(MouseEvent mouseEvent) {
// Birsey yapma
}
};

Tüm dinleyici arabirimleri bu kadar küçük değildir. MouseMotionListener sadece iki metoda sahiphen MouseListener arabirimi 5 metod içerir:

void mouseClicked(MouseEvent mouseEvent)
void mouseEntered(MouseEvent mouseEvent)
void mouseExited(MouseEvent mouseEvent)
void mousePressed(MouseEvent mouseEvent)
void mouseReleased(MouseEvent mouseEvent)

Bir bileşene MouseListener eklemek istiyorsanız, arabirim gerçekleştiriminiz beş metodu içermelidir:

MouseListener mouseListener = new MouseListener() {
public void mouseClicked(MouseEvent mouseEvent) {
System.out.println("Tiklandim: " + mouseEvent);
}

public void mouseEntered(MouseEvent mouseEvent) {
System.out.println("Girdim: " + mouseEvent);
}

public void mouseExited(MouseEvent mouseEvent) {
System.out.println("Ciktim: " + mouseEvent);
}

public void mousePressed(MouseEvent mouseEvent) {
System.out.println("Basildim: " + mouseEvent);
}

public void mouseReleased(MouseEvent mouseEvent) {
System.out.println("Birakildim: " + mouseEvent);
}

};

Eğer uygulamanızın bir bileşen üzerinde farenin sadece basıldığı veya bırakıldığını bilmesi gerekiyorsa, diğer metodlar boş olup yok sayılacaktır. Bu metodlar dolayısıyla gereksiz kod parçaları olacaktır. Adaptör sınıfları, arabirim metodlarının sadece küçük bir kümesine ihtiyaç duyduğunuzda kullandığınız ve yazmanız gereken kod miktarını azaltan sınıflardır. Her adaptör sınıfı ilgili arabirimi (veya arabirimleri) tam olarak gerçekleştirir. Böylece, ilişkili metodların küçük bir kümesine ihtiyaç duyarsanız, sadece kullanmak istediğiniz metodu doldurarak kullanabilirsiniz. Aşağıdaki örnekte MouseAdapter kullanarak bu şekilde bir işlem gösterilmiştir:


MouseListener mouseListener = new MouseAdapter() {
public void mousePressed(MouseEvent mouseEvent) {
System.out.println("Basildim: " + mouseEvent);
}

public void mouseReleased(MouseEvent mouseEvent) {
System.out.println("Birakildim: " + mouseEvent);
}
};

Bu kod MouseListener yaratacaktır. Ancak, tüm metodları gerçekleştirmek yerine, MouseAdapter yardımıyla sadece ihtiyaç duyduğumuz metodlarını gerçekleştirmemiz mümkün olacaktır.

Her birden fazla metod içeren dinleyici için adaptör vardır. Elbette kendimiz de bir arabirim için adaptör sınıfı yaratabiliriz. Böylece sık kullandığımız arabirim kümeleri oluşturabiliriz. Java içerisinde olan sınıflardan yukarıda listelenmiş olan dinleyiciler adaptörlere sahiptir. Ayrıca unutulmaması gereken adaptörlerin gerçek birer sınıf olduğudur. Arabirimin gerçekleştirilmesi bu sınıf içerisinde yapılarak, adaptör kullananların metodları ezmesi (override) sağlanmış oluyor. Eğer kendinize özgü bir JButton altsınıfının MouseListener arabirimini gerçekleştirmesini istiyorsanız, bu sınıfınızın MouseAdapter'un altsınıfı olmasını yapamazsınız, çünkü bildiğiniz gibi Java'da tekli kalıtım desteklenmektedir. Örneğin aşağıdaki kod örneği derleme zamanı hatasına sebep olacaktır, çünkü aynı sınıf hem JButton hem de MouseAdapter'den kalıtılamaz:


public class BadJButtonSubclass extends JButton, MouseAdapter {
...
public void mousePressed(MouseEvent mouseEvent) {
System.out.println("Basildim: " + mouseEvent);
}
}

Eğer gerçekten bu JButton altsınıfının ayrıca MouseListener olmasını istiyorsanız bunu özellikle belirtmeniz ve arabirimin tüm metodlarını gerçekleştirmeniz gerekir:


public class GoodJButtonSubclass extends JButton implements MouseListener {
...
public void mouseClicked(MouseEvent mouseEvent) {
// birsey yapma
}

public void mouseEntered(MouseEvent mouseEvent) {
// birsey yapma
}

public void mouseExited(MouseEvent mouseEvent) {
// birsey yapma
}

public void mousePressed(MouseEvent mouseEvent) {
System.out.println("Basildim: " + mouseEvent);
}

public void mouseReleased(MouseEvent mouseEvent) {
// birsey yapma
}
...
addMouseListener(this);
...
}

Elbette, yüksek seviyeli sınıfınızın arabirimin kendisini gerçekleştirmesini sağlamak zorunda değilsiniz. Bu dinleyiciyi anonim veya iç sınıf olarak yaratmanıza karar vermek için iyi bir örnek olabilir.

Eğer kullanıcı arayüzü yaratmak için bir IDE (mesela Eclipse) kullanıyorsanız, IDE arabirim çatısını sizin için oluşturur. Sizin sadece ilgili arabirim metodlarının içerisine iş mantığı kodlarını yazmanız yetecektir. Bir IDE yardımıyla büyük arayüzler gerçekleştirme işiniz oldukça kolay olacaktır.

Bu konuda daha ayrıntılı bilgiye Java tutorial içerisindeki How to Write a Mouse Listener dersinden erişebilirsiniz.

Adaptörler sadece fare dinlemeyle kısıtlı değildir. Ancak, MouseListener içerisinde çok fazla metod olması nedeniyle MouseAdapter çok kullanılan bir örnektir. WindowListener arabirimi de bir başka büyük örnektir ve WindowAdapter sınıf adaptörüne sahiptir.

Bağlantılar:
Metnin İngilizce'si (Bazı yerlerde kendimden eklemeler bulabilirsiniz):Listeners vs Adapters
Kaynak kod biçimlendirme: Java2Html converter

Neden herkes GNU/Linux kullanmalıdır?

Bugün benim için internette dolaşma günü oldu resmen. İlginç yazılarla karşılaştım. Hemen bir tanesini size "Türkçeleştirmek" (çeviriyi aynen yapmıyorum kendi cümlelerimi yazmaya çalışıyorum, hatam varsa affola :) )istiyorum.

Bu yazıda neden GNU/Linux kullanmanız gerektiğine dair 5 neden sunuluyor. Ben de bu nedenleri tek tek yazacağım.

1. Eğlence: Windows XP uzun zamandır ortalıkta ve çok az değişti. Yeni Vista ise pahalı ve çoğu donanımda çalışamıyor. GNU/Linux bir kaç sene önce Windows XP'yi yakaladı ve çoktan geçti, Vista ile yarışmaya ise zaten çok önceden başlamıştı (3D Masaüstü, saydam pencereler, güvenlik, vb.). Temel olarak düşünürseniz yeni bir işletim sistemi ve uygulamalar öğrenmek başlı başına eğlencelidir.
2. Özgürlük: Kullanıcı dostu bir dağıtım indirip bir CD'ye çekip kullanabilirsiniz. Bunu özgür bir şekilde yapabilirsiniz. Maddi olarak bakarsak bile bu size sadece boş bir CD parasına mal olacaktır. Hiç kimse sizi bu CD'yi kopyalayıp arkadaşlarınıza dağıttığınız veya çok sayıda bilgisayara kurduğunuz için durdurmayacaktır, hatta destekleyecektir.
3. Topluluk: Geleneksel olarak işletim sistemleri ve yazılımlar kullanıcı rehberi ve yardım masası desteği ile gelir. GNU/Linux geniş bir kullanıcı ve geliştirici topluluğu ile gelir, böylece canınızı sıkan telefon görüşmeleri veya eksik belgeler olmaz. Elbette GNU/Linux ile birlikte uygulamaların kullanım rehberleri dğaıtılmakta ama takıldığınız bir şeyi internet üzerinde IRC veya forumlarda sorup öğrenme şansınız daha yüksek ;)
4. Sorumluluk: Sahipli yazılım aldığınızda yazılımınız belli derecede (kaçak olarak kullanmıyorsanız :D ) garantili olarak gelir. Ama GNU/Linux dağıtımları açıkça herşeyden sorumlu olduğunuzu belirtirler. Yaptığınız her hata, her değişiklik, her deneme sizin sorumluluğunuzdadır. Bu nedenle bir şey yapmadan önce yedeklemek, vb. eylemleri gerçekleştirmeniz yine sizin sorumluluğunuzda olacaktır. Özetle GNU/Linux yetişkinler içindir.(Bkz: 5. neden)
5. Güvenilirlik: GNU/Linux dağıtımları yeterince güvenilirdir. Siz deneme sürümü veya yeni yazılmış bir uygulama kullanmıyorsanız genellikle sisteminiz kolay kolay çökmez. Çökmesi için bayağı uğraşmanız gerekmektedir. Çökse bile bir parçası çöker, tüm sistem çökmez. (Eğer benim gibi unstable (=istikrarsız) sürüm manyağı değilseniz sisteminiz istikrarlı ve güvenilir bir şekilde hayatını sürdürecektir). Windows sistemlerle karşılaştırıldığı zaman virüs ve solucanlara karşı "doğuştan" bağışıklığı olduğunu söylemeye gerek yok sanırım :)

Buraya kadar 5 nedeni yazdım. Şimdi gelelim GNU/Linux kullanmanız için 10 öneriye:

1. Yeni kullanıcılar LiveCD (Yaşayan CD) kullanarak ısınma turları yapmalıdırlar.
2. Yaşayan CD'leri kullanarak Windows sisteminizi bile kurtarabilirsiniz.
3. Çoğu yaşayan CD dilediğinizde kullanmak üzere masaüstüne bir "Kur (Install)" simgesi koyar.
4. Kurulum yapmadan önce mutlaka verilerinizi yedekleyin. Hatta belli aralıklarla bilgisayarınızdaki önemli verileri yedekleyin.
5. Binlerce dağıtım arasından size en uygununu seçmeyi unutmayın. Başlangıç için Ubuntu, SUSE, Mandriva, Fedora veya Pardus (Ulusal dağıtım) deneyebilirsiniz.
6. Özgür yazılım geliştiricileri açık biçimleri (.xml, .jpg, .png, .odt, .html, .pdf) tercih ederler. Siz de kapalı biçimlerden (.xls, .doc, .wav,) ziyade bunları tercih etmeye çalışın.
7. GNU/Linux kullanırken sistem hakkında araştırma yaparak dizinleri ve anlamlarını (Türkçe kaynak) öğrenmeye çalışın. (/ ne demektir, /home/ nedir, vb.)
8. Çok sayıda var olan özgür ve açık yazılımlar Windows karşılıklarına göre daha başarılı sonuçlar üretebilmektedir.
9. Wine kullanmayı öğrenin. Oyunları oynamak istiyorsanız Cedega'dan yararlanabilirsiniz.
10. GNU/Linux ağ için vardır. Yeni başlayanların bile rahat bir şekilde ağ bağlantısı kurmasını sağlar.

Not: Yukarıdaki nedenleri ve önerileri arttırabilirsiniz. Her türlü öneriye açığım.

Yazıyı sonlandırırken son bir bağlantı vermek istiyorum. Bu bağlantıda GNU/Linux "podcast"leri bulabilirsiniz. İşinize yarayabileceğine inanıyorum. (Türkiye'de daha hızlı internet lazım)