Beberapa tahun yang lalu, saya pernah berpikir untuk mempelajari Perl. Saya mendapatkan sebuah manual bebas, namun manual tersebut sulit untuk dimengerti. Ketika saya menanyakan kepada pemakai Perl perihal bacaan alternatif, mereka mengungkapkan bahwa ada beberapa manual untuk pemula yang lebih baik, namun tidak bebas.
Mengapa hal ini dapat terjadi? Penulis manual yang baik telah menuliskannya untuk O'Reilly Associates, yang menerbitkannya dengan ketentuan yang ketat--tidak boleh digandakan, tidak boleh dimodifikasi, serta tidak tersedia source file-nya--yang memisahkannya dari masyarakat pengguna perangkat lunak bebas.
Masalah ini bukan yang pertama-kalinya terjadi, dan (bagi komunitas kita merupakan kerugian besar) hal ini telah berlangsung lama. Terlebih, para penerbit manual berpemilik telah memperketat aturan penggunaan manual kepada para pengarangnya. Sering saya mendengar seorang pengguna GNU dengan bersemangat mengungkapkan tentang manual yang sedang ditulisnya, yang ia harap dapat membantu proyek GNU. Lalu harapan menjadi buyar, begitu ia lanjutkan bahwa ia telah menekan kontrak dengan penerbit yang jelas-jelas akan memperketat ketentuan penggunaan manual tersebut, sehingga akan mempersulit untuk dapat menggunakannya.
Melihat kenyataan bahwa tulis-menulis yang baik merupakan kemampuan yang jarang dimiliki oleh para pemrogram, dengan cara ini, kita harus membayar mahal dengan kehilangan manual.
Dokumentasi bebas, seperti halnya perangkat lunak bebas, merupakan masalah kebebasan, dan bukan masalah harga. Masalah perihal manual ini bukan karena O'Reilly Associates telah menetapkan harga untuk penggandaan cetakannya--hal itu sendiri bukan masalah (Free Software Foundation--FSF; Yayasan Perangkat Lunak Bebas--juga berjualan cetakan dari manual-manual bebas GNU). Namun, manual GNU melampirkan source code, sedangkan manual berpemilik hanya tersedia dalam bentuk kertas. Manual GNU diizinkan untuk digandakan dan dimodifikasi, akan tetapi manual Perl tidak. Hal pengetatan pembatasanlah yang menjadi masalah.
Kriteria untuk manual bebas mempunyai masalah yang mirip dengan perangkat lunak bebas: merupakan suatu masalah untuk memberikan para pengguna sebuah kebebasan. Pendistribusian ulang (termasuk distribusi ulang secara komersial) harus diizin, sehingga manual tersebut dapat disertakan dalam setiap salinan program, on-line atau kertas. Perizinan untuk memodifikasi merupakan masalah yang penting juga.
Sebagai ketentuan umum, saya tidak yakin ini merupakan masalah yang esensial bagi setiap orang untuk memiliki izin dalam memodifikasi semua artikel dan buku. Masalah penulisan itu tidak sepenting masalah perangkat lunak. Sebagai contoh, saya tidak yakin anda atau saya berkewajiban untuk memberikan izin untuk memodifikasi artikel yang menggambarkan kegiatan atau pandangan kita.
Namun, ada sebuah alasan khusus--mengapa kebebasan untuk memodifikasi dokumentasi perangkat lunak bebas--merupakan hal yang penting. Ketika seseorang melakukan hak mereka untuk memodifikasi suatu perangkat lunak, dan menambahkan atau mengubah fitur yang ada, jika mereka teliti mereka akan mengubah manualnya juga--sehingga mereka dapat memberikan dokumentasi yang akurat dan dapat digunakan sesuai dengan program yang telah dimodifikasi. Suatu manual yang menghambat seorang pemrogram untuk lebih teliti dalam meyelesaikan pekerjaan mereka, atau lebih lebih tepatnya yang mengharuskan mereka untuk menulis manual baru dari awal jika mereka merubah programnya, tidaklah sesuai dengan kebutuhan kita.
Pelarangan total untuk memodifikasi memang tidak dapat diterima, namun beberapa pembatasan cara memodifikasi bukanlah merupakan masalah. Sebagai contoh, tidak ada masalah dengan ketentuan-ketentuan seperti ketentuan untuk tetap mempertahankan hak cipta asli dari pengarang semual, ketentuan distribusi, atau pun ketentuan daftar pengarang. Juga tidak ada masalah untuk melindungi versi yang sudah dimodifikasi yang menyertakan pesan bahwa versi tersebut telah mengalami perubahan, bahkan untuk seluruh bagian yang tidak boleh dihapus atau diubah, selama bagian tersebut berhubungan dengan masalah non teknis (Beberapa manual GNU ada yang seperti itu).
Ketentuan pembatasan tersebut bukanlah suatu masalah, karena secara praktis--tidak menghalangi para pemrogram dari mengadaptasi manual untuk membetulkan program yang telah dimodifikasi. Dengan kata lain, hal tersebut tidak menghalangi masyarakat pengguna perangkat lunak bebas untuk memaksimalkan penggunaan manual.
Bagaimana pun, merupakan hal yang mungkin untuk merubah semua isi teknis dari manual, dan kemudian mendistribusikan semua hasilnya dalam media semula, melalui semua jalur semula. Jika tidak, ketentuan itu akan membatasi masyarakat, manual menjadi tidak bebas, sehingga dibutuhkan manual yang lain.
Tetapi sayangnya, sangatlah sulit untuk menemukan seseorang untuk menuliskan manual lain jika manual berpemiliknya tetap ada. Penghalangnya ialah banyak pengguna yang berpikir bahwa manual berpemilik tidak apa-apa--sehingga mereka tidak melihat ada kebutuhan untuk menulis sebuah manual bebas. Mereka tidak melihat bahwa sistem operasi bebas mempunyai rintangan yang perlu ditanggulangi.
Mengapa para pengguna berpikir bahwa manual berpemilik cukup baik? Beberapa tidak mempedulikan permasalahannya. Saya harap tulisan ini akan mempunyai pengaruh untuk merubah hal tersebut.
Para pengguna lainnya berpendapat bahwa manual berpemilik dapat diterima dengan alasan yang sama dengan pendapat bahwa perangkat lunak berpemilik juga dapat diterima: mereka mempertimbangkan berdasarkan kepraktisan, serta tidak menggunakan kebebasan sebagai kriteria penilaian. Mereka memang mempunyai hak untuk mempertahankan pendapat mereka, namun berhubung pendapat tersebut berdasar pada nilai-nilai yang tidak menyertakan kebebasan, pendapat tersebut tidak dapat digunakan oleh pihak-pihak yang menghargai nilai kebebasan.
Marilah ikut menyebar-luaskan masalah ini. Kita secara terus menerus kehilangan manual karena jatuh ketangan para penerbit berpemilik. Jika kita menyebarkan pandangan bahwa manual berpemilik tidak mencukupi, maka mungkin ada yang ingin membantu GNU dengan menulis dokumentasi akan menyadari, sebelum terlambat, bahwa ia harus membuatnya menjadi bebas.
Kita juga dapat mengajak para penerbit komersial untuk menjual manual yang bebas ber-copyleft daripada manual yang berpemilik. Anda dapat membantu kami, dengan mengutamakan memilih dan membeli manual bebas dari pada manual berpemilik. Lebih afdol lagi, jika manual tersebut mengikuti ketentuan copyleft dari pada yang tidak.
[Catatan: Kami sekarang mengelola halaman web yang memuat daftar terbitan buku yang merupakan dokumen bebas]
Sejarah rekayasa perangkat lunak
Rekayasa perangkat lunak telah berkembang sejak pertama kali diciptakan pada tahun 1940-an hingga kini. Fokus utama pengembangannya adalah untuk mengembangkan praktik dan teknologi untuk meningkatkan produktivitas para praktisi pengembang perangkat lunak dan kualitas aplikasi yang dapat digunakan oleh pemakai.
Daftar isi |
1945 - 1965: Awal
Istilah software engineering digunakan pertama kali pada akhir 1950-an dan awal 1960-an. Saat itu, masih terdapat debat tajam mengenai aspek engineering dari pengembangan perangkat lunak.Pada tahun 1968 dan 1969, komite sains NATO mensponsori dua konferensi tentang rekayasa perangkat lunak, yang memberikan dampak kuat terhadap perkembangan rekayasa perangkat lunak. Banyak yang menganggap bahwa dua konferensi inilah yang menandai awal resmi profesi rekayasa perangkat lunak. jangan pernah menganggap kalau software itu akn menjadi yang terbaik karena itu adalah sebuah karya yang bersifat sementara.
1965 - 1985: krisis perangkat lunak
Pada tahun 1960-an hingga 1980-an, banyak masalah yang ditemukan para praktisi pengembangan perangkat lunak. Banyak projek yang gagal, hingga masa ini disebut sebagai krisis perangkat lunak. Kasus kegagalan pengembangan perangkat lunak terjadi mulai dari projek yang melebihi anggaran, hingga kasus yang mengakibatkan kerusakan fisik dan kematian. Salah satu kasus yang terkenal antara lain meledaknya roket Ariane akibat kegagalan perangkat lunak.1985 - kini: tidak ada senjata pamungkas
Selama bertahun-tahun, para peneliti memfokuskan usahanya untuk menemukan teknik jitu untuk memecahkan masalah krisis perangkat lunak.Berbagai teknik, metode, alat, proses diciptakan dan diklaim sebagai senjata pamungkas untuk memecahkan kasus ini. Mulai dari pemrograman terstruktur, pemrograman berorientasi object, perangkat pembantu pengembangan perangkat lunak (CASE tools), berbagai standar, UML hingga metode formal diagung-agungkan sebagai senjata pamungkas untuk menghasilkan software yang benar, sesuai anggaran dan tepat waktu.
Pada tahun 1987, Fred Brooks menulis artikel No Silver Bullet, yang berproposisi bahwa tidak ada satu teknologi atau praktik yang sanggup mencapai 10 kali lipat perbaikan dalam produktivitas pengembangan perangkat lunak dalam tempo 10 tahun.
Sebagian berpendapat, no silver bullet berarti profesi rekayasa perangkat lunak dianggap telah gagal. Namun sebagian yang lain justru beranggapan, hal ini menandakan bahwa bidang profesi rekayasa perangkat lunak telah cukup matang, karena dalam bidang profesi lainnya pun, tidak ada teknik pamungkas yang dapat digunakan dalam berbagai kondisi.
sumber:
http://www.gnu.org/philosophy/free-doc.id.html
http://id.wikipedia.org/wiki/Sejarah_rekayasa_perangkat_lunak