Wiki

18 Sep 2006

Bagi mereka yang belum tahu, wiki adalah website yang bisa diedit. Contohnya ada di Wikipedia

Biasanya wiki digunakan untuk membuat dokumentasi. Sifatnya yang bisa diedit siapa saja menyebabkan banyak orang bisa langsung berkontribusi mengisi wiki. Tidak perlu direpotkan dengan birokrasi aplikasi CMS seperti biasanya.

Ada banyak aplikasi wiki yang tersedia. Dibuat dalam berbagai bahasa pemrograman. Biasanya, aplikasi wiki diinstal di web server dan diakses oleh orang banyak.

Selain yang diinstal di web server, ada juga yang digunakan di desktop. Saya sendiri menggunakan Zim Desktop Wiki di komputer saya untuk menulis buku.

Buat yang malas (atau tidak bisa) menginstal, bisa menggunakan aplikasi wiki web based yang tidak perlu diinstal di server. Gunakan Tiddly Wiki. Wiki anda tinggal ditulis di komputer sendiri, kemudian diupload ketika sudah selesai.

Saking banyaknya orang yang membuat aplikasi wiki, akhirnya ada yang menyediakan one stop solution untuk memilih wiki. Silahkan kunjungi wikimatrix untuk membandingkan berbagai aplikasi wiki. Dia juga menyediakan wizard untuk membantu pemilihan aplikasi wiki yang sesuai.

Selamat mengeksplorasi. Semoga bermanfaat.

Technorati

31 Aug 2006

Orang-orang pada rame Technorati. Pengen tau barang apa sih ini.

Buat yang udah merasakan manfaatnya, tolong kasi masukan dong.

Terima kasih.

IPK Tiarap

29 Aug 2006

Disclaimer : tiap perusahaan dan interviewer beda-beda. Ini bukan patokan absolut. Yang saya tuliskan di sini hanyalah pengalaman pribadi disertai bumbu penyedap. Saya tidak bertanggung jawab atas segala rekomendasi di bawah. Penggunaan tips di bawah sepenuhnya adalah resiko pengguna.

Di milis Alumni STTTelkom, ada posting menarik, sebagai berikut:

mengapa sih perusahaan membuat rumusan sakral untuk rekrutasi pegawai yakni IPK >= 2.75 ???

Segera saja saya merasa berkompeten untuk menjawabnya. Bukan apa-apa, IPK saya yang cuma 2.69 kan termasuk yang melanggar rumusan sakral di atas :P.

Berikut jawaban saya, saya paste di sini supaya khalayak ramai bisa ikut membaca dan berkomentar.

Alasan utama membatasi IP adalah untuk menyusutkan jumlah pelamar !!!

Batasan ini biasanya ada di posisi yang demandnya dikit, tapi supplynya berlimpah ruah. Misalnya, entry level position, di mana kandidatnya adalah fresh grad semua :D.

Coba bayangkan Anda sebagai petugas penerima karyawan baru. Ada 15 tumpukan lamaran di meja Anda, masing-masing berisi 100 lamaran. Dan masih ada 23 tumpukan lagi di meja pojok ruangan. Kemudian office-boy datang dan mengantarkan 40 tumpukan lagi sambil berkata, “Di depan masih ada 4 kardus lagi Pak, sebentar saya mau ambil troli dulu .. gak kuat ngangkatnya.”

Nah, kuis singkat. Bagaimana cara memproses lamaran tersebut? Jawaban bisa dikirim ke 8080 dengan SMS KUIS

Eh, tidak perlu … akan saya jawab sendiri.

Begini caranya. Segera setelah si office-boy datang dengan troli dan 4 kardus lamaran, bilang ke dia, “Mas, tolong bantu saya ya. Coba ini lamaran dibuka, trus diperiksa satu-satu. Yang IPKnya lebih besar dari 2.75 kumpulkan di meja ini. Sisanya masukkan ke kardus kosong. Nanti kalo ada tukang loak lewat, dikiloin aja. Uangnya boleh buat Mas beli rokok.”

Beberapa jam kemudian, coba periksa hasil pekerjaan si Mas. Kalau tumpukan yang lolos masih tinggi, bilang ke dia, “Mas, revisi sedikit. Yang IPKnya lebih besar dari 3.00 kumpulkan di meja ini. Sisanya … bla .. bla … (silahkan diteruskan)”

Ulangi langkah di atas sampai jumlah lamaran < 20.

Wahh…. ternyata prosesnya begitu. Tapi, gimana kalo IPnya tiarap? Not to worry.

Dalam beberapa kesempatan sebagai decision maker rekrutmen, berikut faktor yang saya pertimbangkan:

1. Antusiasme, atau istilah kerennya, passion. Semangat itu harus ada dan berapi-api. Namanya juga fresh-grad .. masa gak semangat. Ini juga berkaitan dengan masalah motivasi. Orang yang udah dari sananya semangat, gak sulit disuruh-suruh. Gak perlu dibujuk, ditawari insentif macam-macam. Intinya adalah, saya cari yang memang menyukai pekerjaan yang ditawarkan. Jadi tidak sekedar kerja saja.

2. Smart. Biasanya di sini saya akan menanyakan problem solving question. Dari cara problem solvingnya, saya bisa menilai apakah seseorang smart atau tidak.

3. Get things done. Walaupun smart, tapi kalo gak bisa kerja percuma. Saya akan minta diperlihatkan produk-produk yang sudah dihasilkan kandidat. Kebetulan bidang saya adalah software development. Biasanya saya minta didemokan software yang pernah dibuat.

4. Inisiatif, atau ‘kemampuan mengerjakan hal yang tidak wajib atas kemauan sendiri’ Orang yang biasa ‘take extra mile’ biasanya lebih bagus pekerjaannya dan tidak butuh banyak supervisi dan motivasi.

5. Free time, waktu luang. Ini adalah indikator penting apakah kandidat tersebut ‘bisa berkembang’ atau tidak. Orang yang berkembang akan memanfaatkan freetime nya untuk belajar hal baru, walaupun tidak disuruh.

Lebih lanjut bisa baca panduan Joel dalam interview

Atau panduan mas Mbot di sini dan di sini.

Jadi, kalo IP anda tidak besar, jangan berkecil harapan, tips dari saya :

1. Punya koleksi portofolio hasil karya yang siap dipamerkan. Buat dalam bentuk CD yang siap didemokan.

2. Sering-sering terima pekerjaan freelance walaupun gratisan. Selain memperluas networking, juga tambah pengalaman dan mengasah problem solving skill. Kalau pekerjaannya tangible, tambahkan di koleksi portofolio

3. Latih inisiatif sehingga menjadi refleks. Salah satu caranya adalah dengan aktif mengerjakan pekerjaan rumah seperti membereskan kamar, mendekorasi ruang kerja, berkebun, dsb.

4. Isi waktu luang dengan banyak belajar. Sumber bisa diperoleh di internet atau toko buku

5. Banyak berkontribusi di komunitas, misalnya milis, forum, dsb. Ini akan membuat kita menjadi terkenal sehingga nilai jual meningkat.

6. Jual diri anda dengan cara memiliki personal website. Pasang semua portofolio di sana. Tulis artikel yang dapat menunjukkan kapabilitas dan kompetensi kita.

7. Giat beribadah dan berdoa. Penghasilan besar kalo korupsi percuma. Jadi berdoa supaya dapat gaji besar yang halal.

8. Kasihanilah office boy, maksudnya petugas penerima karyawan baru. Jangan melamar ke semua lowongan. Pilih yang benar-benar disukai dan dikuasai. Kalau belum menguasai, lihat #4. Bukan cuma perusahaan yang bisa selektif, kandidat juga dong.

9. Kalau Anda fresh graduate, jangan terlalu cerewet tentang salary. Fokus fresh graduate, apalagi yang IPKnya tiarap, adalah sesegera mungkin meninggalkan status fresh graduate. Gimana caranya? Tentu saja dengan memiliki pengalaman kerja. Carilah pekerjaan yang walaupun gajinya kecil, tapi variatif dan besar tantangannya, juga bisa membuat kita tambah pintar. Biasanya ini bisa diperoleh di perusahaan kecil di mana orang biasanya merangkap pekerjaan. Tenang saja, begitu kompetensi meningkat, salary pasti mengikuti. Keuntungan tambahan, sebagai pemilik IPK tiarap, persaingan di perusahaan kecil pasti tidak seketat di perusahaan besar yang pasang iklan di Kompas atau Republika.

Demikian, semoga bermanfaat.

Intro Framework

11 Aug 2006

Hari ini di milis jug ada yang bertanya tentang framework. Si penanya sendiri kelihatannya mengerti tentang framework, tapi kesulitan menjelaskan kepada orang lain.

Ini umum terjadi, apalagi kalau programmer Java berbicara dengan programmer dari dunia lain, seperti PHP, C, C++, dsb. Ini bisa disebabkan karena penggunaan framework tidak umum di dunia lain tersebut, atau simply karena programmer lain tersebut fakir bandwidth, sehingga gak aware terhadap tren terbaru.

Baiklah, mari kita bahas framework. Framework, sesuai dengan terjemahannya, adalah kerangka kerja. Jadi, di dalam framework ada beberapa kode program yang kalau kita gunakan, akan memberikan kerangka atau struktur ke aplikasi yang dihasilkan. Singkatnya seperti itu. Nanti akan lebih jelas setelah kita lihat contoh kasus dan contoh kode.

Untuk memahami framework, mari kita lihat ke dunia yang minim framework, yaitu PHP. Sebelum tahun 2005-2006 ini, (setau saya) programmer PHP di Indonesia masih asing dengan framework.

Misalnya saya buat aplikasi shopping cart. Aplikasi yang sangat umum dalam PHP. Setidaknya saya pernah mencoding ulang shopping cart minimal tiga kali. Dan semuanya arsitekturnya beda.

Pertama, waktu masih belajar. Semua kode campur aduk jadi satu. Kalau ada perubahan warna font, beberapa kode SQL harus ikut diupdate. Ubah nama tabel, 7 file kode harus diedit. Singkatnya, perubahan sedikit saja memaksa saya mengubah di banyak tempat di kode program.

Kemudian, setelah semakin banyak pengalaman, saya mulai memisahkan kode HTML dengan kode SQL. Dengan ini, aplikasi bisa berganti wajah dengan mudah. Cukup edit satu file konfigurasi, tampilan berubah seketika.

Terakhir, saya mulai mempertimbangkan multi bahasa. Semua string yang berkaitan dengan label, dikeluarkan dalam satu file sendiri. Jadi kalau kita mau ganti bahasa, cukup bikin replika file tersebut, dan terjemahkan. Kemudian edit file konfigurasi, dan bahasa berubah seketika.

Rapi dan bersih ..

Setelah mendapatkan struktur yang optimal, saya mulai me-reuse struktur tersebut. Kapan-kapan membuat aplikasi baru, saya akan langsung memisahkan kode HTML, SQL, dan bahasa.

Skenario di atas terjadi karena saya tidak menggunakan framework. Butuh banyak sekali trial and error buat saya sampai menemukan struktur yang rapi dan bersih. Setelah ditemukan, struktur tersebut saya jadikan framework. Kerangka untuk membuat aplikasi selanjutnya.

Sekarang kita pindah dari dunia yang minim framework, ke dunia yang kebanjiran framework, Java.

Di dunia Java, kelihatannya orang sangat suka coding framework, sehingga kalau kita search di sourceforge, mungkin lebih banyak framework daripada aplikasi siap pakai. Mengapa ini terjadi, saya tidak tahu. Yang jelas, kalau kita akrab dengan Java, pasti akan pakai framework.

Framework yang ideal harusnya merupakan intisari dari best practices. Pengalaman bertahun-tahun membuat aplikasi yang mirip, disimpulkan dan dibakukan menjadi framework siap pakai. Tapi saking banyaknya framework di Java, akhirnya banyak juga framework sampah. Artinya, dibuat bukan dari best practices dan experiences, tapi lebih menjadi ajang belajar membuat framework.

Penggunaan framework hasil belajar seperti ini sangat buruk dampaknya. APInya tidak stabil, sehingga kalau framework tersebut menerbitkan edisi baru, kode program kita harus diubah semua. Tentu saja, karena framework merupakan kerangka utama. Jadi kalau kerangkanya berubah, maka seluruh aplikasi akan terpengaruh. Selain itu, strukturnya juga belum terbukti keandalannya. Masalah sederhana menjadi kompleks, waktu banyak terbuang untuk ‘mengurusi’ framework. Menggunakan framework jelek lebih fatal akibatnya daripada tanpa framework.

Sampai sejauh ini, harusnya sudah ada gambaran tentang framework.

Framework vs Library

Jangan keliru membedakan framework dengan library. Framework, by definition, sangat invasif. Dia memaksakan bagaimana kita harus coding, bagaimana memberi nama class, di mana harus meletakkan file, dan banyak aturan-aturan lain. Sedangkan library, tinggal baca dokumentasi, daftar function, input dan output masing-masing function, selesai.

Dengan demikian, menggunakan framework lebih sulit daripada library. Coba kita bedakan framework dengan library Framework Java:

• Spring Framework
• Struts

Library Java:

• Joda Time
• JFreeChart
• Freemarker
• Jakarta Commons

Framework PHP:

• Seagull
• Cake

Library PHP:

• PEAR
• AdoDb
• Smarty

Ada lagi satu kategori, yaitu toolkit. Toolkit adalah kode yang kita gunakan dalam development, tapi tidak disertakan dalam produk akhir. Contohnya di Java antara lain: Ant dan CruiseControl.

Tapi ada juga beberapa yang tidak jelas pengelompokannya. JUnit misalnya, di satu sisi, dia menyediakan perlengkapan untuk testing sehingga bisa dikategorikan sebagai library. Di sisi lain, dia mengharuskan ada prefix test di setiap nama method, sehingga layak disebut framework.

Plus Minus

Sekarang pertanyaan yang penting. Apa keuntungan dan kerugian menggunakan framework? Asumsikan framework yang ingin digunakan bagus dan teruji.

Keuntungan

• Struktur yang konsisten. Sangat berguna bila developer banyak dan turnover tinggi.
• Struktur merupakan best practices. Semua sudah ditempatkan di tempat yang paling sesuai.
• Dapat belajar tentang desain aplikasi yang baik.

Kerugian

• Butuh investasi waktu belajar dan adaptasi
• Ada overhead. Untuk project sangat kecil, mungkin overheadnya lebih besar dari projectnya sendiri. Lagipula, tidak semua fitur framework kita pakai, sehingga cuma akan menjadi bloat.
• Menimbulkan dependensi. Ini terutama terasa di aplikasi yang berarsitektur plugin. Upgrade framework dapat merusak plugin.

Memilih Framework

Sekarang, bagaimana kita memutuskan pakai framework atau tidak? Kalau pakai, pilih yang mana? Sering sekali ada banyak framework yang menyelesaikan masalah yang sama.

Pertama, pertimbangkan benefit vs cost. Di beberapa project, saya lebih memilih tanpa framework, karena ukuran projectnya kecil.

Untuk playbilling, saya pakai iBatis alih-alih Hibernate yang lebih lengkap fiturnya. Pertimbangannya adalah, saya tidak menggunakan banyak tipe database. Sehingga cross-database tidak terlalu dibutuhkan. Sekarang saya sedang mempertimbangkan menghilangkan iBatis, dan pakai JDBC biasa untuk mengurangi dependensi dan ukuran donlod.

Kedua, lihat kualitas dokumentasinya. Alasan yang jelas adalah, kalau tidak ada dokumentasi, gimana tau cara pakainya? Kita butuh dokumentasi untuk bisa menggunakan framework.

Ada alasan kedua yang juga penting. Kualitas dokumentasi mencerminkan kualitas framework. Mengapa? Karena dokumentasi biasanya adalah by product (produk sampingan), apalagi di project open source. Logikanya, jika tim developer menghasilkan dokumentasi bagus, pasti kualitas dan desain frameworknya sendiri lebih bagus lagi.

Sejauh ini, kesimpulan saya konsisten. Framework terbaik secara desain dan kualitas kode adalah Spring Framework. Coba lihat dokumentasinya. Sangat rinci, detail, dan minim kesalahan. Contoh lain adalah Hibernate. Dokumentasinya sangat lengkap. Bahkan di dalamnya juga dijelaskan tentang konsep Object Relational Mapping. Dengan membaca dokumentasinya saja, kita akan menambah wawasan. Apalagi menggunakan frameworknya.

Ketiga, lihat aktivitas komunitasnya. Framework, apalagi open source, membutuhkan interaksi dengan sesama pengguna. Keuntungan utama tentu saja technical support dan tutorial gratis. Apalagi dengan perkembangan blog yang sangat pesat beberapa tahun terakhir. Semua pengalaman baik, buruk, mudah, sulit, semua diceritakan para pengguna framework di blognya masing-masing.

Kalau kita menggunakan framework minoritas, jarang digunakan orang, tutorialnya sedikit, diskusi di berbagai forum juga tidak banyak. Jadi, kalau kita search dengan Google, lebih sulit menemukan permasalahan (dan solusi) yang sama dengan kebutuhan kita.

Terakhir, learning curve, atau kurva belajar. Apakah framework tersebut sulit atau mudah dipelajari?

Di bagian atas tadi saya menyebutkan keunggulan framework adalah dia dapat menyeragamkan struktur kode di antara banyak developer. Jadi, agar efektif, semua developer harus bisa menggunakan framework tersebut.

Nah, seorang system architect, software designer, senior developer, development team leader, atau apapun istilahnya di tempat Anda, orang yang bertugas memilih framework, harus mempertimbangkan kurva belajar ini.

Ini sering diabaikan banyak orang. Sebagai pemilih framework, tentunya orang tersebut memiliki keahlian/pengalaman teknis di atas rekan-rekannya. Penting bagi orang tersebut untuk memperhitungkan keahlian/pengalaman anggota tim yang lain yang tidak secanggih dirinya pada waktu memilih framework. Jangan sampai framework yang dipilih terlalu rumit, sehingga bukannya di-reuse malahan di-abuse.

Demikian ulasan singkat tentang framework. Mudah-mudahan bermanfaat.

Bisnis Open Source

08 Aug 2006

Artikel ini, tidak seperti biasanya, ditulis berdasarkan request oleh teman saya. Selain itu, juga ada thread di milis JUG Indonesia yang membahas tentang bisnis open source. Di sana saya memberikan sedikit komentar yang secara singkat serupa dengan apa yang akan dijelaskan di sini.

Beberapa tahun belakangan ini, gema open source mulai ramai di dunia. Banyak orang yang tadinya skeptis dengan ide software gratis, mulai mencoba peruntungannya di dunia yang buka-bukaan ini. Banyak juga orang (salah satunya saya) yang bergembira dan sangat mendukung open source, terutama karena ke’gratis’annya semata.

Tidak kurang dari perusahaan besar di dunia seperti Oracle, IBM, Sun, dan masih banyak yang lainnya, merilis aplikasi mereka yang berharga jutaan dolar secara open source atau ‘gratis’.

Open source tidak selalu gratis, walaupun biasanya begitu. Dan gratis juga tidak selalu berarti open-source. Untuk menyederhanakan urusan, yang akan kita bahas di sini adalah software gratis. Terlepas dari apakah software tersebut open source atau tidak.

Orang-orang pun mulai bertanya, “Apa tidak rugi melepas aplikasi secara gratis? Dari mana keuntungannya? Padahal untuk membuat software tersebut, telah banyak biaya yang dikeluarkan.” Dan masih banyak lagi pertanyaan sejenis.

Tapi yang jelas, mereka tidak menjadi rugi karena melepas aplikasinya. Tindakan ini tentunya sudah didahului dengan kalkulasi bisnis yang matang dan tidak semata ikut-ikutan trend open source atau tiba-tiba menjadi ‘baik hati’ terhadap negara ketiga/miskin (misalnya, Indonesia). Nah, sekarang mari kita lihat, dari mana profitnya.

Setidaknya ada beberapa modus operandi penggunaan strategi gratis untuk perusahaan, sepanjang pengetahuan saya:

1. RND
2. Teaser product
3. Strategi Produk Komplementer
4. By product
5. Pendukung core business
6. Sebagai produk utama

Mari kita lihat satu per satu.

Disclaimer: semua yang saya tulis di sini merupakan pendapat pribadi saya, atas pengamatan tentang penggunaan strategi gratisan, yang tidak terbukti kebenarannya. Tidak ada pernyataan resmi dari perusahaan yang disebut di sini tentang strategi gratisnya. Silahkan tulis komentar anda di bawah kalau setuju/tidak setuju dengan pendapat saya ini.

Research and Development

Strategi ini digunakan oleh RedHat. Mereka membuat project open source Fedora sebagai lini depan riset Linux. Teknologi yang dihasilkan di project Fedora kemudian digunakan di lini produk komersilnya Red Hat Enterprise Linux. Dengan menggunakan project open source sebagai divisi RND, Red Hat mendapat keuntungan dari kontribusi tenaga kerja gratisan (baca: sukarelawan) baik di posisi developer, tester, dokumenter, public relation (dalam bentuk komentar positif, testimoni, word of mouth), dan juga technical writer (blog membahas penggunaan Fedora, support forum, mailing list, dsb). Seperti kita lihat di sini, sebenarnya Red Hat mendapat keuntungan besar, setidaknya dari sisi payroll dan marketing, dengan menggunakan strategi open source.

Latihan buat pembaca, sebutkan contoh lain perusahaan yang menggunakan open source sebagai divisi RND.

Teaser Product

Promosi produk yang terbaik adalah dengan cara memberikan produk tersebut ke konsumen, dan berharap mereka puas dan bercerita kepada teman-temannya (yang diharapkan akan membeli produk tersebut). Strategi ini digunakan Oracle pada saat mereka melepas produk Oracle 10g Express Edition. Harapannya adalah, dengan menggunakan produk gratis tersebut:

1. Lebih banyak orang yang familiar dengan produk Oracle
2. Pengguna merasa puas atau sudah terlalu terbiasa (baca: kecanduan) dengan Oracle
3. Pada suatu saat, pengguna gratisan tersebut merasa kurang dengan fitur yang ada, dan akan membeli versi berbayarnya
4. Jika pengguna gratisan diminta rekomendasi oleh bosnya/temannya, mereka akan merekomendasikan Oracle, karena itulah produk yang mereka kuasai, dan lagipula bukan mereka yang akan membayarnya.

Strategi pemasaran ini lebih efektif daripada memasang iklan di media. Banyak orang (termasuk saya) yang sudah sangat bosan dengan iklan, sehingga ada fitur ‘autoskip’ di otak saya yang secara otomatis menutup popup iklan, bahkan sebelum gambarnya selesai loading. Bahkan untuk kasus ekstrim, banyak orang mau bersusah payah yang memasang filter iklan seperti Adblock atau no-ads.pac untuk melucuti media dari semua iklan.

Dengan menggunakan ‘orang betulan’ yang tulus dan jujur untuk merekomendasikan produknya, lebih besar kemungkinan produk akan dibeli.

Strategi Produk Komplementer

Ada kalanya perusahaan menggratiskan suatu aplikasi karena aplikasi tersebut adalah komplementer dari produk utamanya. Contohnya adalah Acrobat Reader.

Waktu kita belajar di SMP dulu, kita belajar tentang produk substitusi dan komplementer. Produk substitusi adalah produk yang dapat menggantikan produk lain. Misalnya, Indomie adalah produk substitusi Mi Sedap.

Sedangkan produk komplementer adalah produk yang saling melengkapi dengan produk lain. Seperti yang sering kita lihat di tivi, salah satu iklan tag linenya adalah, “Apapun makanannya, minumnya tetap … (produk XXX)”. Nampaknya produsen minuman tersebut berusaha serakah dengan menjadikan produknya sebagai komplementer untuk semua makanan padat.

Acrobat Reader, adalah komplementer dari Acrobat Distiller. Dengan menggratiskan Reader, Adobe berharap penjualan Distiller akan meningkat. Sepertinya strategi ini cukup jitu, sehingga PDF bisa jadi standar format dokumen di internet.

Lebih lanjut tentang penggunaan strategi produk komplementer ini dijelaskan oleh Joel Spolsky. Silahkan baca sendiri di websitenya.

By Products

By products artinya produk sampingan. Misalnya kita membuka usaha jualan kelapa parut di pasar, kita akan mendapatkan banyak sekali air kelapa sebagai limbah. Mereka yang jeli akan segera beternak jamur di dalam air kelapa tersebut dan segera membuka lini produk baru, yang lebih tenar disebut dengan Nata de Coco.

Hal yang sama dilakukan oleh Martin Fowler dan gerombolannya. Bisnis utama mereka adalah software development dan konsultasi bagi perusahaan software development yang lainnya. Sebagai mana konsultan manajemen pada umumnya, mereka juga berjualan jargon. Salah satu jargon yang mereka perdagangkan adalah Continuous Integration. Ini tidak lain adalah istilah keren dari kompile sering-sering dan test sampai capek. Menyuruh programmer kompile lima kali sehari dan testing sepuluh kali sehari kemudian menulis hasilnya dalam format HTML adalah cara cepat untuk membuat programmer pensiun dini alias resign. Oleh karena itu, mereka membuat program kecil yang bisa melakukan kegiatan tersebut secara terjadwal dan terus menerus. Sehingga jargon Continuous Integration bisa dijual dengan sukses.

Program kecil tersebut adalah Cruise Control. Dapat Anda peroleh secara gratis di SourceForge.

Perhatikan di sini bahwa dagangan utama mereka adalah proses, bukan produk. Sehingga Cruise Control tersebut adalah by product belaka. Sama seperti ‘nata de coco’. Karena bukan produk utama, tidak ada kerugian dari melepas aplikasi tersebut secara gratis. Keuntungannya, para calon prospek akan berpersepsi bahwa Martin Fowler masih punya mainan lain yang lebih menarik yang tidak digratiskan. Sehingga dengan senang hati mereka akan mempekerjakan dia dan pasukan magangnya dengan tarif selangit.

Pendukung produk utama

Framework favorit saya, Spring Framework adalah contohnya. Produk utama Interface 21, perusahaan sponsor Spring Framework, adalah perusahaan software development. Berbagai perusahaan besar di dunia mempercayakan pengembangan aplikasi bisnisnya pada Interface 21. Jadi, produk utama Interface 21 adalah software development. Dalam mengembangkan aplikasi pesanan client, Interface 21 membutuhkan framework berkualitas tinggi dan berarsitektur bagus. Di situlah peranan project Spring Framework, sebagai produk pendukung aktivitas bisnis Interface 21.

Produk Utama

Ada juga beberapa perusahaan yang menjadikan aplikasi gratisnya sebagai produk utama. Lalu datang pertanyaan, “Kalau produk utama digratiskan, dari mana dapat uangnya?”. Ada beberapa jalur lain di luar penjualan software: training, buku, dan customization. Jalur ini ditempuh JBoss dan Hibernate. Dokumentasi utama JBoss tidak gratis. Kita harus membeli dengan sistem berlangganan di websitenya.

Hibernate, mendapat pemasukan dari penjualan buku. Pembuatnya, Gavin King dan Christian Bauer mengarang buku yang bagus sekali, Hibernate in Action. Isinya menjelaskan desain aplikasi pada umumnya, dan penggunaan framework Hibernate. Dengan semakin banyaknya pengguna Hibernate, buku dan training akan semakin laku.

PlaySMS dan PlayBilling, mendapat pemasukan dari customization. Para pelanggan seringkali membutuhkan fitur khusus yang belum ada di rilis open source. Untuk itu, mereka membayar developer untuk menambahkan fitur yang dibutuhkan. Siapa yang lagi yang lebih berkompeten menulis tambahan fitur selain pengembang aslinya?

Demikianlah uraian tentang bisnis open source. Jadi, hilangkan ilusi bahwa perusahaan besar sekarang menjadi dermawan, karena memberikan aplikasinya secara gratis. Ada kepentingan pemegang saham di baliknya, yang tentu saja, tidak mau rugi.

Walaupun demikian, kita lihat ada situasi win-win di sini. Pengguna diuntungkan dengan adanya software gratis. Perusahaan juga diuntungkan dari promosi gratis, tenaga sukarela, dan berbagai keuntungan lainnya.

Oleh karena itu, mari gunakan aplikasi gratis. Kalo bisa gratis, kenapa harus bayar? Kalo ada yang gratis, kenapa masih membajak?

:D