Berita dan Organisasi 

Cara Menjadi anggota KPLI-Jakarta

1. ABSTRAK

Ulasan oleh Eric S. Raymond

Metode Open Source (OS) adalah suatu metode pengembangan piranti lunak yang berintikan suatu model pengembangan, penerapan, dan perbaikan yang berjalan secara paralel dan dengan kecepatan yang menakjubkan. Sebagai konsekuensinya, Metode OS telah menghasilkan suatu ancaman yang bersifat langsung, baik pada pasar maupun penghasilan (revenue) Microsoft (MS). Lebih jauh lagi, meski model yang bersifat paralel dan terbuka ini sangat baik, kita (MS) tidak dapat melakukan hal yang sama. 

{Pernyataan ini memperlihatkan bahwa MS telah menyadari apa yang sedang terjadi. MS akan menganggap suatu produk sebagai suatu ancaman jika memenuhi salah satu kriteria ini : 

1. Memberikan alternatif produk – seseorang akan membeli produk non-MS.
2. Memberikan alternatif platform -- MS akan kehilangan posisi monopolinya.
3. Memberikan alternatif developer – orang akan membuat suatu aplikasi untuk produk non-MS.

1. PIRANTI LUNAK BERLISENSI OPEN SOURCE
1. Apakah Open Source itu ?

Piranti lunak berlisensi OS selalu didistribusikan atau dapat diakses bersama-sama dengan kode asalnya, umumnya secara gratis. Piranti lunak ini biasanya disalahartikan sebagai shareware atau freeware. Ketiganya tidaklah sama karena ada perbedaan yang mendasar antara model lisensi dan proses yang terjadi pada ketiga jenis piranti lunak tersebut. 

2. Metode Open Source Sangat Mempengaruhi Microsoft

Hal ini disebabkan latar belakang : 

1. Proyek-proyek Open Source telah mencapai kualitas komersial

Masalah utama yang dihadapi oleh piranti lunak berbasis OS ialah anggapan pengguna bahwa piranti lunak tersebut berkualitas buruk. Di sisi lain para pendukung OS menyatakan bahwa banyaknya developer yang bekerja bersama-sama telah menghasilkan piranti lunak dengan kualitas yang lebih baik dari piranti lunak komersial. 

Berbagai studi kasus akhir-akhir ini membuktikan terjadinya perubahan yang dramatis di mata pengguna, yakni kualitas komersial ternyata dapat dicapai oleh proyek-proyek OS. Bagaimanapun juga, belum ada bukti yang jelas mengenai hal ini kecuali hal-hal yang sifatnya anekdot. 

{Paragraf ini sangat kontradiktif, di satu hal menyebutkan "dramatis" tapi di bagian lain menyebutkan "anekdot". Bagaimanapun juga, penyebutan anekdot tidaklah tepat. Suatu paper berjudul Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services membahas hal ini dengan tepat. 

Dalam paper ini dijelaskan bahwa tingkat kesalahan (failure rate) produk UNIX komersial bervariasi dari 15-43 %. Namun untuk hal yang sama pada Linux, angka ini berada pada kisaran 9 %. Ini membuktikan bahwa produk OS – Linux – memiliki kualitas yang lebih baik.}

2. Proyek-proyek Open Souce kini berskala besar dan kompleks

Besar proyek-proyek OS kini telah menyamai proyek-proyek komersial. Sebagai contoh ialah Linux dan XFree86 GUI. 

Angka-angka di bawah ini dapat memberikan penjelasan mengenai besarnya proyek-proyek OS. 

Proyek	Jumlah baris kode
Linux Kernel (khusus x86)	500,000
Apache Web Server	80,000
SendMail	57,000
XFree86 X-windows server	1.5 juta
"K" desktop environment	90,000
Distribusi komplit Linux	~10 juta

3. Metode Open Source memiliki model pengembangan yang unik termasuk kelebihan/ kelemahannya
Metode ini sangat unik baik dalam memotivasi pesertanya maupun dengan tersedianya berbagai fasilitas untuk menyelesaikan suatu masalah. Dengan demikian, metode OS jelas memiliki suatu ke-khas-an yang unik dan tidak dapat diduplikasi (non replicable asset) oleh pihak manapun. 

{Terminologi menarik yang dipakai oleh MS – non replicable asset – yang memperlihatkan modus operandi MS biasanya ialah menyalin atau menjiplak apa saja yang dikerjakan oleh orang lain. Sayangnya hal ini tidak dapat dilakukan dalam menghadapi OS.} 

 

2. Proses Open Source

Proses pengembangan piranti lunak komersial biasanya berdasarkan pada sasaran ekonomis. Pada metode OS, uang bukanlah sasaran utama. Oleh karena itu pemahaman ancaman oleh OS memerlukan pengertian yang mendalam mengenai proses dan motivasi komunitas pengembang (developer) OS. 

Dalam kata lain, untuk bersaing dengan OS kita harus memfokuskan diri pada prosesnya dan bukan pada perusahaan atau institusi yang berdasarkan OS. 

{Ini adalah titik yang sangat penting, satu hal yang saya harapkan MS tidak melihatnya. Pertarungan yang terjadi bukanlah antara NT vs Linux, atau MS vs RedHat/Caldera/SuSE, tapi adalah antara pengembangan piranti lunak model tertutup dengan pengembangan dengan model terbuka. Metode katedral melawan metoda bazar. 

Hal ini juga berlaku untuk sebaliknya. Target komunitas OS bukanlah MS. Mereka adalah gejala-gejala, tapi bukan penyakit itu sendiri. Saya mengharapkan para pengguna Linux sadar akan hal ini. 

Dari segi praktisnya, ini berarti kita secara realistis harus sadar bahwa mesin propaganda MS akan diarahkan pada proses dan model OS, dan bukan pada suatu perusahaan.} 
 

1. Tim Pengembang Open Source

• Secara geografis sangat berjauhan. Beberapa developer utama Linux sebagai contoh, tersebar di Eropa, Amerika, dan Asia.

• Banyaknya kontributor yang berpartisipasi. Sebagai contoh Linux, memiliki lebih dari 1000 orang yang secara rutin mengirimkan patches, bug fixes, dsb dan memiliki lebih 200 orang yang memberikan sumbangan langsung pada kernel.
• Tidak termotivasi karena uang (setidaknya sampai saat ini). Para kontributor ini umumnya para penggemar komputer yang merelakan waktu dan energi mereka untuk mengembangkan proyek OS sementara tetap bekerja sebagai biasa. Hal ini mulai berubah dengan mulai tersedianya versi komersial Linux.

1. Koordinasi Pengembangan Proyek Open Source
1. Forum komunikasi - internet

• Email
• Newsgroups
• Situs-situs OS

1. Kesamaan arah
2. Kesamaan sasaran

Sasaran yang sama berupa visi yang senantiasa diterapkan pada pembuatan keputusan untuk seluruh tim pengembang OS. Suatu arahan yang ringkas dan jelas (contohnya "melahirkan Unix kembali") jauh lebih efisien dikomunikasikan kepada grup-grup yang tersebar dibanding dengan dengan arahan yang bersifat abstrak (contohnya "membuat sistem operasi yang lebih baik"). 
 

3. Kesamaan latar belakang

Latar belakang barangkali adalah faktor paling penting yang dapat menjelaskan perkembangan yang pesat dan rapi dari proyek-proyek OS seperti sistem operasi Linux. Karena hampir seluruh komunitas Unix telah memiliki pengalaman bekerja dengan berbagai sistem operasi UNIX lainnya, mereka dengan mudah dapat melihat – tanpa harus melalui bentuk-bentuk konfrontasi – apa yang dapat dilakukan dan apa yang tidak dapat dilakukan. 

Tidak banyak perdebatan yang muncul misalnya mengenai cara penggunaan editor teks – semua sudah menggunakan "vi" sehingga pengembangan selanjutnya dengan mudah dapat dilaksanakan. 

Dengan melihat ini, komunitas OS didukung oleh kepemimpinan yang kuat dan bervisi jauh ke depan. 

{Kesimpulan ini jauh dari kenyataan. Kita tidak dapat menghasilkan Emacs atau Perl atau World Wide Web atau bahkan kernel Linux berdasarkan model-model UNIX terdahulu saja} 
 

4. Kesamaan keahlian

NatBro menjelaskan perlunya keahlian-keahlian sebagai syarat awal untuk pengembangan OS. Hal ini berkaitan erat dengan point 3.2.4 di atas. Menurutnya : 

"Hal penting … ialah kesamaan keahlian UNIX/gnu/make yang membuat OS dapat berkembang dan maju. Saya fikir proses ini tidak akan berjalan jika tidak demikian halnya. Dengan kata lain – tidaklah sulit bagi developer dalam proyek OS untuk bekerja karena segala sesuatunya telah dibuat dengan metode yang sama, dst." 
 

5. The Cathedral and the Bazaar

• Setiap produk piranti lunak yang baik biasanya dimulai dari rasa ingin tahu, keinginan untuk "ngoprek".

• Programmer yang baik mengetahui cara menulis program. Programmer yang hebat mengetahui cara untuk menulis ulang dan memanfaatkan program yang sudah ada.

• Buatlah satu buah dan lemparkan, cepat atau lambat anda akan tahu hasilnya.

• Perlakukan pemakai sebagai rekan pengembang (co-developer) dalam proses pengembangan yang cepat dan efektifkan proses debugging.

• Rilislah cepat. Rilislah sering. Dengarkan kata pengguna.

• Dengan adanya cukup banyak beta-tester dan rekan pengembang (co-developer), hampir seluruh masalah dapat diidentifikasi sehingga penyelesaian dapat dengan mudah dilakukan.

1. Pengembangan Secara Paralel

• Tersedianya cukup banyak tim-tim tersebut.
• Tersedianya kerangka pembuatan piranti lunak tersebut (misalnya arsitektur UNIX untuk proyek Linux).

1. Debug Secara Paralel

Argumen vital yang dikemukakan oleh Eric Raymod ialah berbeda dengan model pengembangan piranti lunak yang lazim, pada model OS proses debugging merupakan aktivitas dengan efisiensi yang nyaris sama dengan jumlah orang yang bekerja di proyek itu. Hampir tidak diperlukan proses manajemen maupun biaya untuk kegiatan ini. 

Menurut Linus Torvald proses debugging Linux ialah sebagai dikutip berikut : 

Pengertian awal saya ialah bahwa setiap masalah "akan jelas di mata seseorang". Seseorang yang dapat memahami dan menyelesaikan masalah tidaklah harus atau bahkan akan berbeda dengan seseorang yang pertama mengidentifikasikannya. Namun kedua hal ini cenderung untuk terjadi dengan cepat. 

Salah satu keuntungan dari metode ini ialah masalah-masalah (bugs) yang muncul dapat diidentifikasi, dipecahkan, dan disebarkan dalam tempo yang jauh lebih cepat dari proses konvensional. Sebagai contoh ketika TearDrop IP attack telah diketahui, dalam waktu kurang dari 24 jam, komunitas Linux telah menghasilkan pemecahannya yang dapat diambil dari situs-situs Linux di internet. 

Raymond juga menambahkan munculnya metode baru yang ia namai "impulse debugging". Pada sistem operasi Linux misalnya. Ketika si pengguna memasang Linux ke komputernya, yang terjadi ialah ia juga menambahkan suatu lingkungan untuk proses pengembangan dan debugging. Mengapa ? Jika ia menemukan suatu masalah pada Linux yang relatif mudah dipecahkan, ia mampu untuk memecahkan masalah itu sendiri. Ini berarti ia telah melakukan proses debugging dan pengembangan ! Selanjutnya ia akan menginformasikan hasil kerjanya ini di forum komunikasi Linux agar dapat dimanfaatkan oleh orang lain. Inilah yang disebut sebagai impulse debugging. 
 

2. Penyelesaian Konflik yang Terjadi

Untuk kasus Linux, Linus Torvalds merupakan pemimpin proyek ini. Biasanya ia mendelegasikan komponen-komponen proyeknya pada "bawahan-bawahan" yang ia percayai yang seterusnya juga meneruskan tanggung jawab itu ke "bawahan-bawahannya". Demikian seterusnya. 

Menurut Eric Raymond, proyek-proyek OS yang lain menghindari diri dari konsep yang dipakai oleh Linux. Pada Apache misalnya, para pengembang utama tergabung dalam komite yang memutuskan hal-hal yang penting secara bersama-sama. Pada Perl, tampuk kepemimpinan digilir secara rutin di antara para senior di proyek tersebut. 
 

1. Kekuatan Open Source
1. Open Source Memiliki Atribut yang Eksponensial
1. Open Source mengikuti perkembangan internet

Seperti telah dijelaskan di atas, salah satu masalah utama bagi proyek OS ialah menemukan cukup banyak pengembang yang dapat bekerja untuk proyek tersebut. Dengan berkembangnya internet, masalah ini ternyata dengan mudah teratasi. 

2. Proses Open Source menganut prinsip "sang pemenang mengambil semuanya"

Seperti halnya piranti lunak komersial, proyek OS yang paling maju, dalam jangka panjang, akan menyedot sumber-sumber proyek OS lainnya. Sebagai contoh Linux telah 'membunuh' BSD Unix dan menyedot hampir seluruh ide-idenya. 

3. Para pengembang cenderung akan membantu platform OS yang terbesar
4. Proyek Open Source yang besar cenderung lebih cepat berkembang
Makin besar proyeknya, makin banyak proses pengembangan/debugging. Akibatnya makin berkembang proyeknya sehingga makin banyak orang yang menggunakannya. Demikian seterusnya. 
 
2. Kredibilitas Jangka Panjang
Binaries may die but source code lives forever

Salah satu implikasi paling menarik dari lingkungan OS ialah kredibilitas jangka panjangnya. 

1. Pengertian Kredibilitas Jangka Panjang

Kredibilitas jangka panjang hanyalah ada jika tidak ada kemungkinan bagi anda untuk gagal di pasar (driven out of business) dalam jangka waktu tertentu/dekat. Hal ini menyebabkan kompetitor anda harus merubah cara menghadapi anda. 

{Komentar Tom Nadeau : 

Perhatikan terminologi yang dipakai di sini yakni "driven out of business''. MS menganggap bahwa mengeluarkan perusahaan lain dari pasar bukanlah sekedar akibat sampingan dari suatu persaingan, tetapi justru merupakan strategi utama bisnisnya. Ingat Netscape dengan browsernya ? Sebagai contoh ialah sebagai berikut. Bisnis dianggap sebagai perlombaan mobil balap. Strategi MS ialah menyingkirkan mobil balap lain dari perlombaan dengan berbagai cara sehingga akhirnya hanya MS yang mencapai garis finish. Pada perlombaan yang sehat, yang terjadi ialah banyak mobil balap yang mencapai garis finish, sehingga ada juara I, II, III, dst. Pada model MS, hanya ada 1 juara. Sekarang, dapatkah anda melihat bahwa MS dan "kebebasan memilih" adalah benar-benar 2 hal yang bertolak belakang ?} 
 

2. Open Source memiliki kredibilitas jangka panjang

Sistem OS systems dapat dianggap memiliki kredibilitas panjang dengan tersedianya kode asal di jutaan tempat dan orang di dunia ini. 

Sebagai contoh ialah membandingkan Apache Web Server dan WordPerfect. Hilangnya Apache dari pasar tidaklah dapat dibandingkan dengan hilangnya WordPerfect, yaitu hilangnya executable (binary) file. Apache baru benar-benar hilang jika kode asalnya benar-benar hilang dan pengetahuan orang mengenainya juga turut musnah. Seorang pengguna Apache menyatakan bahwa ia menggunakan akal sehatnya untuk memakai Apache untuk situs e-commerce-nya. Kenapa ? Karena ia tidak harus tergantung pada orang lain. Kode asalnya tersedia, sehingga cukup baginya untuk merekrut seorang pengembang untuk melakukan pemeliharaan, peningkatan, dsb untuk jangka waktu yang ia dapat tentukan sendiri. 
 

3. Tidak adanya Code-Forking menambah kredibilitas jangka panjang

Code-Forking ialah keadaan yang terjadi jika dua tim pengembang bergerak ke arah yang berbeda tanpa ada usaha untuk mempersatukan arah tersebut. Sehingga akan terjadi 2 variasi yang makin lama makin jauh satu sama lain. 

Model lisensi GPL dan implikasinya tidak memungkinkan code-forking terjadi sehingga para pengguna yakin bahwa mereka tidak akan terjebak dalam suatu produk yang tidak dapat berkembang lagi dan pada akhirnya mati (evolutionary 'dead-end'). 

{Tepat sekali. Kalau sang penulis dokumen ini lebih jujur sedikit, ia seharusnya menambahkan bahwa yang terjadi sekarang ini ialah justru MS yang hampir berada pada kondisi di atas. Berkembangnya kerumitan, bergeser jadwal pelepasan, dan perubahan nama "Windows 2000" merupakan tanda bahwa produk tersebut sudah hampir mencapai kondisi 'evolutionary dead-end'. 

Sang penulis tidak menyebutkan hal ini. Tapi kita harus.} 
 

4. Debugging secara paralel

Linux dan berbagai proyek OS lainnya telah berhasil untuk membuat argumen yang cukup baik dan beralasan bahwa produk yang dihasilkan sama atau bahkan melebih produk komersial. Hal ini ditunjang dengan internet merupakan media utama yang berfungsi seperti layaknya sebuah etalase toko kepada komunitas TI di dunia. 

{Dan itu semua dikerjakan oleh para amatir, yang hampir semuanya bekerja dengan gratis, bekerja paruh waktu, melawan mesin propaganda jutaan dollar yang dijalankan oleh spesialis-spesialis di bidang bisnis pemasaran teknologi. 

Para amatir ini telah "membuat argumen yang cukup baik dan beralasan". Dilihat dari konteksnya, MS sebenarnya mengakui bahwa sebenarnya kita MENANG.} 
 

5. Kecepatan pelepasan versi terbaru
Karena proyek OS senantiasa terbagi-bagi, maka pelepasan suatu komponen tanpa harus menunggu komponen yang lain selesai dapat terjadi, bahkan dengan frekuensi yang tinggi. Sebagai konsekuensinya, proyek OS senantiasa bergerak dengan cepat dan dalam frekuensi yang tinggi. 
 
2. Kelemahan Open Source

Secara umum terbagi dalam 3 kategori : 
 

1. Manajemen

Masalah utama proyek OS terkait erat dengan perkembangannya yang demikian pesat, baik dari segi ukuran maupun dari segi ide-ide yang dihimpun di dalamnya. Hal ini mengakibatkan adanya limitasi dari perkembangan suatu proyek OS. 
 

1. Memulai proyek Open Source sangat sulit

Menurut Eric Raymond jelas bahwa tidaklah mungkin untuk memulai penulisan program dengan model bazar. Linus tidak melakukannya. Demikian pula ia sendiri. Suatu program dasar yang telah berjalan dan disenangi banyak oranglah yang dapat menjadi awal suatu proyek OS. 

2. Kredibilitas bazar

• Ide/proyek tersebut haruslah sedemikian menariknya sehingga hasil pengembangannya seimbang dengan waktu yang telah dikorbankan. Linux merupakan contoh dari kriteria ini.
• Ide/proyek tersebut haruslah penting atau telah dipakai oleh cukup banyak orang. Apache Web server adalah contohnya.
• Penyelesaian jumlah masalah-masalah yang muncul haruslah dalam proporsi yang optimal. Jika terlalu banyak akan menyebabkan kebanyakan orang lebih berfungsi sebagai tester ketimbang sebagai seorang pengembang. Sebaliknya jika jumlahnya terlalu kecil orang akan kurang tertarik untuk bergabung karena masih banyaknya masalah yang belum terpecahkan.

1. Tersedianya utilitas-utilitas pendukung

Hal lain yang menarik untuk dicermati ialah melihat kemampuan proyek OS dalam memberikan fungsi-fungsi yang 'tidak menarik tetapi perlu'. Dalam suatu sistem operasi ini misalnya manajemen sumber tenaga (power management), suspend/resume, GUI, infrastruktur manajemen, dsb. Untuk kasus Apache misalnya fungsi-fungsi administrator pemula seperti wizards. 
 

2. Model arsitektur/integrasi

1. Proses

Beberapa kelemahan proses OS ialah : 

1. Proses iterasi

Frekuensi iterasi proses OS sangat tinggi (proses iterasi Linux dapat terjadi beberapa kali dalam 1 hari !). Pengguna di dunia bisnis mengatakan pada kami untuk mengurangi pelepasan rilis produk-produk kami. 

{Saya jadi bertanya-tanya apakah pernyataan dunia bisnis ini akan berubah jika versi upgrade MS tidaklah mahal ? 

Menjawab hal di atas, inilah yang menyebabkan para distributor komersial Linux hadir – untuk memberikan filter antara proses pengembangan yang cepat dengan para pengguna yang tidak ingin mengikuti secara detil. Sebagai contoh, meski kernel mungkin berubah dengan cepat, tetapi RedHat hanya melepas rilis baru setiap 6 bulan.} 

2. Umpan balik para newbie
Linux tidak dikembangkan untuk para pengguna dengan kemampuan teknis sedikit, tetapi lebih cenderung untuk para pengguna yang mahir. Hal yang sama untuk Apache yang lebih difokuskan pada situs-situs besar dengan operator, dan bukan untuk suatu departemen dari suatu perusahaan. 

Masalah yang utama di sini, OS tidaklah memiliki proses pemasaran dan umpan balik – sehingga pengembangannya lebih didominasi oleh keinginan para pengguna yang mahir. 

Satu pelajaran yang dapat dipetik oleh tim pengembang di MSFT ialah kemudahan penggunaan, GUI, dan lain-lain haruslah dibangun dari awal dan tidak bisa dibangun di kemudian hari setelah suatu produk selesai dikerjakan. 

{Pernyataan ini harus dikomentari – karena meski secara teori benar, namun dalam kenyataan yang dipraktekkan oleh Microsoft hasilnya ialah terbalik. Hal ini berakibat pada timbulnya berbagai kelemahan pada GUI yang dikembangkan oleh MS. 

Ada dua cara untuk membangun "kemudahan penggunaan". Yang pertama (cara MS) yaitu dengan membangun aplikasi monolitik yang didefinisi dan didominasi oleh User Interface (UI). Ini cenderung menghasilkan "Windowsitis" – kaku, mudah mengandung bug, ganjil dengan penampilan yang mengkilap untuk menutupinya. 

Program yang dibangun dengan cara ini akan terlihat mudah (user-friendly), meski pada akhirnya akan menyerap waktu dan tenaga yang tidak sedikit untuk jangka panjang. Program ini hanya dapat dipertahankan dengan propaganda pemasaran, dengan tujuan memperdaya penggunanya bahwa (a) semua bug merupakan fasilitas atau (b) semua bug semata-mata karena kesalahan pengguna, atau (c) semua bug akan diperbaiki jika si pengguna meng-upgrade produk tersebut. Pendekatan ini tentunya salah. 

Cara yang kedua ialah metode Unix/Internet/Web, yang memisahkan engine (yang melakukan kerja sesungguhnya) dari User Interface (yang memberikan view dan kontrol). Pendekatan ini memerlukan adanya protokol yang terdefinisi secara jelas untuk memudahkan komunikasi antara engine dan UI. Sebagai contoh sederhana ialah browser dengan web server. Web server sebagai engine, browser sebagai UI, dan protokol TCP/IP sebagai alat komunikasi antara keduanya. 

Dengan cara yang kedua ini, tingkat kerumitan menurun jauh sementara tingkat kehandalan (realibility) meningkat. UI dengan mudah dapat diubah, diperbaiki, disesuaikan dengan kebutuhan, karena UI tersebut tidak berhubungan dengan engine. Bahkan mungkin saja untuk memiliki beberapa UI untuk memenuhi kebutuhan pengguna. 

Cara kedua ini secara arsitektur selaras dan siap untuk diterapkan pada level enterprise yang memerlukan administrasi secara remote. Pendekatan ini berjalan, dan inilah cara komunitas OS untuk menghadapi MS. 

Hal yang terpenting di sini ialah jika MS ingin berkompetisi dengan OS pada UI, maka biarkanlah mereka – karena kita pun dapat memenangkan kompetisi itu, dengan cara kita sendiri. Mereka dapat mengembangkan Windows monolitik yang makin teliti dan rumit yang menyatu anda erat dengan application-server console yang ia miliki. Kita akan menang jika kita dapat mengembangkan aplikasi yang terdistribusi secara baik dan mempengaruhi internet dan web. Juga tidak lupa tentunya dengan membuat UI yang bersifat pluggable.} 
 

2. Kredibilitas Organisasi

Bagaimana OS dapat memberikan support yang diharapkan oleh penggunanya ? 

1. Model support

Support biasanya adalah masalah pertama yang akan ditanyakan oleh para calon pengguna produk OS. Dilihat dari kenyataan, mayoritas proyek OS dikerjakan oleh para pengembang dengan latar belakang yang sangat baik. Menaikkan struktur support ini ke level yang diharapkan seperti layaknya suatu produk komersial merupakan tantangan yang berarti. Terdapat perbedaan yang cukup jelas antara pengguna dan pengembang pada kompetisi IIS vs Apache. 

{Kalimat terakhir paragraf di atas sungguh tidak jelas. Mengapa ? Karena si penulis tidak mau menyatakan bahwa kenyataan pasar membuktikan bahwa Apache sedang mengrogoti pasar IIS (Apache menguasai pasar 54 % dan terus naik sementara IIS berkisar 14 % dan terus menurun). 

Hal ini memperlihatkan dua latar belakang yang sayangnya kedua-duanya tidak mendukung Microsoft. Latar belakang yang pertama ialah mungkin karena support yang bersifat informal dari Apache menghasilkan penampilan yang lebih baik dari pada yang dapat ditawarkan oleh MS IIS. Jika ini benar, maka secara prinsip sulit ditolak bahwa latar belakang ini akan terjadi juga bagi proyek-proyek OS yang lainnya. Artinya proyek-proyek OS lainnya juga akan mengungguli produk-produk MS. 

Latar belakang yang kedua ialah Apache memperlihatkan penampilan yang sangat baik sehingga tidak memerlukan support yang berarti. Jika ini benar, maka sistem support Microsoft dan mesin propagandanya dengan dukungan biaya yang besar merupakan investasi yang salah ! Daripada memperkuat barisan support dan propaganda, yang seharusnya MS lakukan ialah memperbaiki produknya sehingga mencapai kualitas yang tidak memerlukan banyak support. 

Kedua penjelasan di atas berimplikasi hal yang berbeda tetapi sama-sama bersifat strategis. Yang pertama yaitu membangun suatu produk sedemikian baiknya sehingga tidak memerlukan support yang berarti. Yang kedua ialah dengan mengoptimasi model support informal seperti mailing list, newsgroups, FAQ, dll. Rekan saya yang pernah bekerja dengan MS menyatakan dengan NT 5.0 MS berencana untuk menyatakan adanya kenaikan penggunaan IIS di pasar. Hal ini karena IIS dibangun lekat dengan kernel NT, berfungsi untuk memantau seluruh komunikasi eksternal TCP (mail, HTTP, dll). Produk MS Office juga direncanakan untuk menggunakan IIS dalam berkomunikasi dengan NT atau Exchange.} 
 

2. Strategi ke depan