Author: zs Date: Tue Aug 7 22:14:03 2007 New Revision: 897 Log: several more translated
Modified: trunk/ml/ch01.xml Modified: trunk/ml/ch01.xml ============================================================================== --- trunk/ml/ch01.xml (original) +++ trunk/ml/ch01.xml Tue Aug 7 22:14:03 2007 @@ -42,8 +42,8 @@ Memang, bahagian penting dalam menjalankan projek sumber terbuka ialah bekerja dengan lancar bersama yang lain, projek berkaitan. Dalam jangka panjang, setiap projek yang berjaya menyumbang kepada kesejahteraan keseluruhan, badan sedunia bagi perisian percuma. </para> - </simplesect> + <simplesect> <para> @@ -69,8 +69,8 @@ persoalan mereka untuk sementara waktu sebelum melihat sebarang faedah atas kehadiran mereka. Sebagai pembangun Jamie Zawinski menyatakan masalah ini pada peringkat awal projek Mozilla: </para> -<blockquote> +<blockquote> <para> <emphasis> Sumber terbuka memang berkesan, namun ianya pasti bukan penyelesaian. @@ -80,284 +80,254 @@ </emphasis> </para> -<para>(from -<emphasis role="bold"><ulink - url="http://www.jwz.org/gruntle/nomo.html"/> -</emphasis>) +<para>(from <emphasis role="bold"><ulink + url="http://www.jwz.org/gruntle/nomo.html"/></emphasis>) </para> </blockquote> <para> -A related mistake is that of skimping on presentation and -packaging, figuring that these can always be done later, when the -project is well under way. Presentation and packaging comprise a wide -range of tasks, all revolving around the theme of reducing the barrier -to entry. Making the project inviting to the uninitiated means -writing user and developer documentation, setting up a project web -site that's informative to newcomers, automating as much of the -software's compilation and installation as possible, etc. Many -programmers unfortunately treat this work as being of secondary -importance to the code itself. There are a couple of reasons for -this. First, it can feel like busywork, because its benefits are most -visible to those least familiar with the project, and vice versa. -After all, the people who develop the code don't really need the -packaging. They already know how to install, administer, and use the -software, because they wrote it. Second, the skills required to do -presentation and packaging well are often completely different from -those required to write code. People tend to focus on what they're -good at, even if it might serve the project better to spend a little -time on something that suits them less. <xref -linkend="getting-started"/> discusses presentation and packaging -in detail, and explains why it's crucial that they be a priority from -the very start of the project.</para> - -<para>Next comes the fallacy that little or no project management is -required in open source, or conversely, that the same management -practices used for in-house development will work equally well on an -open source project. Management in an open source project isn't -always very visible, but in the successful projects, it's usually -happening behind the scenes in some form or another. A small thought -experiment suffices to show why. An open source project consists of a -random collection of programmers—already a notoriously -independent-minded category—who have most likely never met each -other, and who may each have different personal goals in working on -the project. The thought experiment is simply to imagine what would -happen to such a group <emphasis>without</emphasis> management. -Barring miracles, it would collapse or drift apart very quickly. -Things won't simply run themselves, much as we might wish otherwise. -But the management, though it may be quite active, is often informal, -subtle, and low-key. The only thing keeping a development group -together is their shared belief that they can do more in concert than -individually. Thus the goal of management is mostly to ensure that -they continue to believe this, by setting standards for -communications, by making sure useful developers don't get -marginalized due to personal idiosyncracies, and in general by making -the project a place developers want to keep coming back to. Specific -techniques for doing this are discussed throughout the rest of this -book.</para> - -<para>Finally, there is a general category of problems that may be -called "failures of cultural navigation." Ten years ago, even five, -it would have been premature to talk about a global culture of free -software, but not anymore. A recognizable culture has slowly emerged, -and while it is certainly not monolithic—it is at least as prone -to internal dissent and factionalism as any geographically bound -culture—it does have a basically consistent core. Most -successful open source projects exhibit some or all of the -characteristics of this core. They reward certain types of behaviors, -and punish others; they create an atmosphere that encourages unplanned -participation, sometimes at the expense of central coordination; they -have concepts of rudeness and politeness that can differ substantially -from those prevalent elsewhere. Most importantly, longtime -participants have generally internalized these standards, so that they -share a rough consensus about expected conduct. Unsuccessful projects -usually deviate in significant ways from this core, albeit -unintentionally, and often do not have a consensus about what -constitutes reasonable default behavior. This means that when -problems arise, the situation can quickly deteriorate, as the -participants lack an already established stock of cultural reflexes to -fall back on for resolving differences. </para> - -<para>This book is a practical guide, not an anthropological study or -a history. However, a working knowledge of the origins of today's -free software culture is an essential foundation for any practical -advice. A person who understands the culture can travel far and wide -in the open source world, encountering many local variations in custom -and dialect, yet still be able to participate comfortably and -effectively everywhere. In contrast, a person who does not understand -the culture will find the process of organizing or participating in a -project difficult and full of surprises. Since the number of people -developing free software is still growing by leaps and bounds, there -are many people in that latter category—this is largely a -culture of recent immigrants, and will continue to be so for some -time. If you think you might be one of them, the next section -provides background for discussions you'll encounter later, both in -this book and on the Internet. (On the other hand, if you've been -working with open source for a while, you may already know a lot of -its history, so feel free to skip the next section.)</para> - -</simplesect> - -<!-- ========================== SECTION =========================== --> -<sect1 id="history"> -<title>History</title> - -<para>Software sharing has been around as long as software itself. In -the early days of computers, manufacturers felt that competitive -advantages were to be had mainly in hardware innovation, and therefore -didn't pay much attention to software as a business asset. Many of -the customers for these early machines were scientists or technicians, -who were able to modify and extend the software shipped with the -machine themselves. Customers sometimes distributed their patches -back not only to the manufacturer, but to other owners of similar -machines. The manufacturers often tolerated and even encouraged this: -in their eyes, improvements to the software, from whatever source, -just made the machine more attractive to other potential -customers.</para> - -<para>Although this early period resembled today's free software -culture in many ways, it differed in two crucial respects. First, -there was as yet little standardization of hardware—it was a -time of flourishing innovation in computer design, but the diversity -of computing architectures meant that everything was incompatible with -everything else. Thus, software written for one machine would -generally not work on another. Programmers tended to acquire -expertise in a particular architecture or family of architectures -(whereas today they would be more likely to acquire expertise in a -programming language or family of languages, confident that their -expertise will be transferable to whatever computing hardware they -happen to find themselves working with). Because a person's expertise -tended to be specific to one kind of computer, their accumulation of -expertise had the effect of making that computer more attractive to -them and their colleagues. It was therefore in the manufacturer's -interests for machine-specific code and knowledge to spread as widely -as possible.</para> - -<para>Second, there was no Internet. Though there were fewer legal -restrictions on sharing than today, there were more technical ones: -the means of getting data from place to place were inconvenient and -cumbersome, relatively speaking. There were some small, local -networks, good for sharing information among employees at the same -research lab or company. But there remained barriers to overcome if -one wanted to share with everyone, no matter where they were. These -barriers <emphasis>were</emphasis> overcome in many cases. Sometimes -different groups made contact with each other independently, sending -disks or tapes through land mail, and sometimes the manufacturers -themselves served as central clearing houses for patches. It also -helped that many of the early computer developers worked at -universities, where publishing one's knowledge was expected. But the -physical realities of data transmission meant there was always an -impedance to sharing, an impedance proportional to the distance (real -or organizational) that the software had to travel. Widespread, -frictionless sharing, as we know it today, was not possible.</para> - -<!-- ========================== subsection ========================== --> -<sect2 id="propertization"> -<title>The Rise of Proprietary Software and Free Software</title> - -<para>As the industry matured, several interrelated changes occurred -simultaneously. The wild diversity of hardware designs gradually gave -way to a few clear winners—winners through superior technology, -superior marketing, or some combination of the two. At the same time, -and not entirely coincidentally, the development of so-called "high -level" programming languages meant that one could write a program -once, in one language, and have it automatically translated -("compiled") to run on different kinds of computers. The implications -of this were not lost on the hardware manufacturers: a customer could -now undertake a major software engineering effort without necessarily -locking themselves into one particular computer architecture. When -this was combined with the gradual narrowing of performance -differences between various computers, as the less efficient designs -were weeded out, a manufacturer that treated its hardware as its only -asset could look forward to a future of declining profit margins. Raw -computing power was becoming a fungible good, while software was -becoming the differentiator. Selling software, or at least treating -it as an integral part of hardware sales, began to look like a good -strategy.</para> - -<para>This meant that manufacturers had to start enforcing the -copyrights on their code more strictly. If users simply continued to -share and modify code freely among themselves, they might -independently reimplement some of the improvements now being sold as -"added value" by the supplier. Worse, shared code could get into the -hands of competitors. The irony is that all this was happening around -the time the Internet was getting off the ground. Just when truly -unobstructed software sharing was finally becoming technically -possible, changes in the computer business made it economically -undesirable, at least from the point of view of any single company. -The suppliers clamped down, either denying users access to the code -that ran their machines, or insisting on non-disclosure agreements -that made effective sharing impossible.</para> - -<sect3 id="history-conscious-resistance"> -<title>Conscious resistance</title> - -<para>As the world of unrestricted code swapping slowly faded away, a -counterreaction crystallized in the mind of at least one programmer. -Richard Stallman worked in the Artificial Intelligence Lab at the -Massachusetts Institute of Technology in the 1970s and early '80s, -during what turned out to be a golden age and a golden location for -code sharing. The AI Lab had a strong "hacker -ethic",<footnote><para>Stallman uses the word "hacker" in the sense of -"someone who loves to program and enjoys being clever about it," not -the relatively new meaning of "someone who breaks into -computers."</para></footnote> and people were not only encouraged but -expected to share whatever improvements they made to the system. As -Stallman wrote later:</para> - - <blockquote> - <para><emphasis>We did not call our software "free software", - because that term did not yet exist; but that is what it was. - Whenever people from another university or a company wanted to - port and use a program, we gladly let them. If you saw someone - using an unfamiliar and interesting program, you could always - ask to see the source code, so that you could read it, change - it, or cannibalize parts of it to make a new program. - </emphasis></para> - - <para>(from <emphasis role="bold"><ulink - url="http://www.gnu.org/gnu/thegnuproject.html"/></emphasis>)</para> - </blockquote> - - -<para>This Edenic community collapsed around Stallman shortly after -1980, when the changes that had been happening in the rest of the -industry finally caught up with the AI Lab. A startup company hired -away many of the Lab's programmers to work on an operating system -similar to what they had been working on at the Lab, only now under an -exclusive license. At the same time, the AI Lab acquired new -equipment that came with a proprietary operating system.</para> - -<para>Stallman saw the larger pattern in what was happening: +Kesilapan yang berkaitan adalah persembahan dan pembungkusan, membayangkan yang perkara ini boleh dilakukan kemudian, tatkala projek sedang lancar. +Persembahan dan pembungkusan melibatkan tugasan yang luas, semuanya bersekitar tema mengurangkan halangan hinggalah kemasukan. +(Making the project inviting to the uninitiated means +writing user and developer documentation) +Membuat projek bermakna menulis dokumentasi pengguna dan pembangun dengan cara yang tidak biasa, +menyediakan laman web projek yang bermaklumat kepada pendatang baru, +mengautomasi sebanyak mungkin kompilasi dan instalasi perisian, dan sebagainya. +Malangnya kebanyakan pengaturcara melayan tugas ini kurang penting berbanding kod itu sendiri. +Terdapat beberapa penyebabnya. Pertama, ia dirasai seperti kerja yang sibuk, kerana manafaatnya lebih kepada mereka yang tidak biasa dengan projek tersebut, +dan begitulah sebaliknya. Lagipun, mereka yang membangunkan kod tidak memerlukan sangat pembungkusan. +Mereka sudah tahu bagaimana untuk menginstal, mentadbir, dan menggunakan perisian tersebut, kerana mereka yang menulisnya. +Kedua, kemahiran yang diperlukan untuk membuat persembahan dan pembungkusan yang baik sangat berbeza dengan mereka yang perlu menulis kod. +Manusia lebih memfokus kepada apa yang mereka tahu, walaupun mungkin projek yang lebih baik dapat dihasilkan dengan meluangkan sedikit masa untuk sesuatu +yang kurang sesuai dengan mereka. +<xref +linkend="getting-started"/> membincangkan persembahan dan pembungkusan dengan terperinci, dan menjelaskan kenapa ianya perlu diutamakan di peringkat awal projek. +</para> + +<para> +Kemudian muncul pula salah anggap iaitu sedikit atau tiada pengurusan projek diperlukan dalam sumber terbuka, atau sebaliknya, iaitu pengurusan sama yang +diamalkan untuk pembangunan dalaman akan berkesan sama seperti dalam projek sumber terbuka. +Pengurusan dalam projek sumber terbuka tidak selalunya nampak, namun bagi projek yang berjaya, ia biasanya berlaku di belakang tabir dalam bentuk tertentu. +Satu experimentasi pemikiran kecil cukup untuk menunjukkan sebabnya. +Suatu projek sumber terbuka mengandungi koleksi rawak pengaturcara—yang terkenal dengan kategori fikiran-tersendiri—mereka yang hampir tidak +pernah bersua muka, dan mereka yang mungkin memiliki matlamat peribadi yang berbeza dalam menjalankan projek. +Experimentasi pemikiran ini adalah dengan hanya membayangkan apa akan terjadi kepada kumpulan sedemikian <emphasis>tanpa</emphasis> pengurusan. + +Kecuali adanya keajaiban, ia akan hancur atau menjadi renggang dengan cepatnya. Tiada perkara yang boleh terurus sendiri, sebagaimana yang kita harapkan sebaliknya. +Namun pengurusan, walaupun ianya mungkin aktif, biasanya tidak rasmi, tidak ketara, and low-key. Satu perkara yang dapat mengekalkan kumpulan pembangunan bersama adalah +kepercayaang yang dikongsi iaitu mereka boleh melakukan lebih baik secara konsert berbanding individu. +Oleh itu matlamat pengurusan lebih untuk memastikan mereka terus percaya perkara ini, dengan menyediakan standard untuk komunikasi, +dengan memastikan pembangun yang berguna tidak mendapat sedikit akibat daripada keganjilan (idiosyncracies) peribadi +dan secara umumnya dengan menjadikan projek tersebut satu tempat di mana pembangun ingin selalu kembali. +Teknik khusus untuk melakukan perkara ini dibincangkan dalam buku ini. +</para> + +<para> +Akhirnya, terdapat kategori am masalah yang boleh dipanggil "kegagalan pandu-arah budaya." +Sepuluh tahun dahulu, malah lima, adalah terlalu awal untuk mengatakan berkenaan budaya global perisian percuma, namun kini tidak lagi. +Budaya yang boleh dikenalpasti berkembang secara perlahan, dan sedang ia pastinya ia tidak teguh—ianya paling tidak terbuka kepada perselisihan dalaman dan berpuak sebagaimana budaya +yang bersempadan secara geografi—ia tetap mempunyai teras yang konsisten. +Kebanyakan projek sumber terbuka yang berjaya, memaparkan sebahagian atau kesemua ciri-ciri teras ini. +Mereka memberi ganjaran bagi kelakuan yang tertentu, dan menghukum selainnya; +mereka mencipta suasana yang merangsang penyertaan yang tidak dirancang, kadang kala (sometimes at the expense of central coordination); +mereka mempunyai konsep tentang kebiadapan dan kesopanan yang mungkin terlalu berbeza daripada yang biasa diketahui. +Yang penting, penyertaan dalam jangka masa yang lama secara amnya memperdalamkan lagi standard ini, agar mereka berkongsi setuju secara kasarnya berkenaan +kelakuan yang dijangka. + +Projek yang gagal biasanya melencong daripada teras ini dengan cara yang signifikan, +meskipun tidak disengajakan, dan selalu tiada persetujuan berkaitan apa yang sepatutnya bagi kelakuan yang munasabah. +Ini bermakna apabila masalah muncul, suasana tersebut dengan cepatnya boleh bertambah buruk, oleh sebab peserta kekurangan +budaya yang mantap untuk dirujuk bagi menyelesaikan perbezaan itu. +</para> + + +<para> +Buku ini adalah panduan praktikal, bukannya kajian secara antroplogi atau sejarah. +Namun, pengetahuan (working knowledge) bagi asal-usul budaya perisian percuma adalah asas yang penting bagi mana-mana nasihat praktikal. +Seseorang yang memahami sesuatu budaya boleh mengembara jauh dan luas ke dalam dunia sumber terbuka, +bertemu dengan budaya yang banyak variasi tempatan dan dialek,namun masih mampu menyertai dengan selesa dan berkesan di setiap tempat. +Sebaliknya, seseorang yang tidak memahami budaya tersebut akan mendapati proses menganjur dan menyertai satu projek adalah susah dan dipenuhi kejutan +Ini kerana bilangan manusia yang membangunkan perisian percuma masih bertambah pesat, terdapat ramai orang berada dalam kategori yang kedua— +sebahagian besarnya adalah budaya bagi pendatang akhir-akhir ini, dan akan terus begini untuk beberapa ketika. +Jika anda rasa anda adalah salah seorang daripadanya, bahagian selepas ini menyediakan latarbelakang untuk perbincangan yang akan +anda temui kemudian, kedua-duanya dalam buku ini dan atas Internet. +(Sebaliknya, jika anda pernah bekerja dengan sumber terbuka untuk suatu masa, anda mungkin telah mengetahui banyak sejarahnya, +oleh itu langkau sahaja ke bahagian seterusnya.) +</para> +</simplesect> +<!-- ========================== SECTION =========================== --> + +<sect1 id="history"> + +<title>Sejarah</title> + +<para> +Perkongsian perisian telah wujud selama mana perisian itu sendiri wujud. +Pada peringkat awal komputer, pengilang merasakan kelebihan persaingan hanyalah kepada inovasi perkakasan, dan oleh itu tidak +banyak memberi perhatian terhadap perisian sebagai aset bisnes. +Kebanyakan pelanggan mesin yang awal ini adalah saintis atau juruteknik, iaitu mereka yang mampu mengubahsuai dan memperluaskan sendiri +perisian yang dihantar bersama mesin. +Pelanggan ada kalanya mengedarkan pembetulan yang telah mereka lakukan bukan saja kepada pengilang, tetapi juga kepada pemilik +mesin yang setara. +Pengilang selalunya bertoleransi, malah menggalakan hal ini: pada mereka, pembaikan kepada perisian, daripada man jua sumber, +hanya membuatkan mesin berkenaan lebih menarik kepada pelanggan berpotensi yang lain. +</para> + +<para> +Walaupun tempoh awal ini dalam banyak bentuk sama seperi budaya perisian percuma, ianya berbeza dari dua aspek genting. +Pertama, dahulu sangat sedikit piawaian bagi perkakasan— +masa itu adalah perkembangan inovasi dalam rekabentuk komputer, namun kepelbagaian senibina komputer bermakna semua tidak +serasi dengan semua yang lain. Oleh itu, perisian yang ditulis untuk satu mesin biasanya tidak boleh digunakan ke atas mesin lain. +Pengaturcara lebih ke arah memperolehi kepakaran dalam satu senibina yang khusus atau keluarga senibina +(yang mana pada masa ini mereka lebih ke arah memperoleh kemahiran dalam satu bahasa pengaturcaraan atau keluarganya, +yakin yang kepakaran mereka akan boleh beralih kepada mana-mana perkakasan komputeran yang mana mereka bekerja). +Oleh kerana kepakaran seseorang ke arah mengkhusus kepada satu jenis komputer, pengumpulan kepakaran mereka memberi kesan +terhadap pembuatan komputer yang lebih menarik kepada mereka dan rakan-rakannya. +Maka, masa itu adalah minat pengilang untuk menghasilkan kod yang khusus kepada mesin dan menghasilkan pengetahuan untuk +disebarkan secara meluas yang mungkin. +</para> + + +<para> +Kedua, pada masa itu tiada Internet. Tetapi sangat kurang kekangan undang-undang berkaitan perkongsian berbanding sekarang, +yang banyaknya adalah perkara teknikal: +sebagai perbandingan, cara untuk membolehkan data berpindah dari satu tempat ke satu tempat lain tidak mudah dan sukar. +Terdapat rangkaian setempat yang kecil, sesuai untuk berkongsi maklumat antara pekerja dalam satu makmal penyelidikan atau syarikat. +Namun masih terdapat halangan perlu diatasi jika seseorang ingin berkongsi dengan setiap orang lain, dimana jua mereka berada. +Dalam kebanyakan kes, halangan ini <emphasis>berjaya</emphasis> diatasi. +Kadang kala kumpulan berbeza menghubungi satu sama lain secara bebas, menghantar disket, pita melalui mel biasa, dan kadang kala +pengilang sendiri menjadi pusat setempat untuk pembetulan tersebut. +Jua elemen yag membantu adalah kebanyakan pembangun komputer pada masa itu bekerja di universiti, yang mana penerbitan pengetahuan adalah dijangka. +Namun hakikat fizikal bagi transmisi data bermakna sentiasa ada galangan untuk dikongsi, galangan berkadar dengan jarak (merujuk yang nyata atau struktur organisasi) +yang perisian tersebut perlu bergerak. Perkongsian meluas, tanpa bergesek, seperti yang kita tahu pada hari ini, adalah mustahil. +</para> + +<!-- ========================== subsection ========================== --> +<sect2 id="propertization"> +<title> +Kebangkitan Perisian Hak Milik dan Perisian Percuma +</title> +<para> +Tatkala industri menjadi matang, beberapa perubahan yang saling berkait berlaku secara serentak. +Kepelbagaian rekabentuk perkakasan beransur-ansur memberi laluan kepada sejumlah kecil pemenang yang jelas— +pemenang melalui teknologi unggul, pemasaran hebat, atau gabungan keduanya. +Pada masa yang sama, dan bukanlah keseluruhannya kebetulan, pembangunan apa yang dipanggil bahasa pengaturcaraan "paras tinggi" +bermakna yang seseorang boleh menulis satu aturcara sekali, dan secara automatik diterjemah ("kompil") untuk dilarikan atas komputer yang berbeza jenis. +Implikasi perkara ini tidak merugikan pengilang perkakasan: pelanggan sekarang boleh menjalankan usaha kejuruteraan perisian yang utama tanpa +perlu menumpu kepada satu senibina komputer tertentu. +Apabila ini digabungkan dengan perbezaan prestasi antara pelbagai komputer yang semakin mengurang, dengan rekabentuk yang tidak cekap menjadi terbuang, +pengilang yang menganggap perkakasan sebagai satu-satunya aset mereka, boleh melihat ke arah penurunan marjin untung pada masa hadapan. +Kuasa komputeran data mentah semakin menjadi (Raw computing power was becoming a fungible good), +sedangkan perisian menjadi pembeza (while software was becoming the differentiator). +Menjual perisian, atau paling kurang menganggapnya sebagai satu bahagian daripada jualan perkakasan, mula nampak seperti strategi yang bagus. +</para> + +<para> +Ini bermakna pengilang perlu memulakan penguatkuasaan hakcipta kod mereka dengan lebih tegas. +Jika pengguna dengan mudahnya terus berkongsi dan mengubahsuai kod secara bebas antara mereka, mereka mungkin mengimplemen semula sebahagian +penambahbaikan yang mana pada masa ini dijual sebagai "nilai tambah" oleh pembekal. +Lebih teruk lagi, kod yang dikongsi jatuh ke tangan pesaing mereka. +Ironinya adalah semua ini berlaku sewaktu Internet mula berkembang. +Hanya apabila perkongsian perisian yang benar-benar tidak dihalang menjadi satu kemungkinan secara teknikal, perubahan dalam bisnes komputer +membuatnya secara ekonomi tidak diingini (ecomonically undesirable), sekurang-kurangnya dari kacamata sebarang syarikat tunggal. +Pembekal mengetatkan kawalan, sama ada menghalang capaian pengguna ke atas kod yang dilarikan pada mesin mereka, atau menegaskan perjanjian ketakdedahan +yang tak memungkinkan perkongsian berkesan. +</para> + +<sect3 id="history-conscious-resistance"> + +<title> +Tentangan Dalam Sedar +</title> +<para> +Dengan dunia pertukaran kod tanpa sekatan semakin melenyap, satu tindakan balas terbuku di dalam minda sekurang-kurangnya seorang pengaturcara. +Richard Stallman bekerja dalam Makmal Artificial Intelligence di Massachusetts Institute of Technology pada tahun 1970-an dan pada awal 80-an, +semasa apa yang kini dipanggil zaman emas dan lokasi emas untuk perkongsian kod. +Makmal AI mempunyai "etika penggodam" yang kukuh, +<footnote> +<para> +Stallman menggunakan perkataan "penggodam" dalam maksud "sesiapa yang suka membuat aturcara dan seronok pandai tentangnya," bukannya maksud yang agak baru +"seseorang yang menceroboh komputer." +</para> +</footnote> +dan orang ramai bukan saja digalakkan malah diharap berkongsi apa sahaja pembaikan yang mereka lakukan kepada sistem. +Yang mana Stallman kemudiannya menulis </para> <blockquote> +<para> +<emphasis> +kami tidak menyebut perisian kami "perisian percuma", +kerana istilah tersebut belum wujud lagi; tapi itulah ianya. +apabila sesiapa daripada universiti lain atau syarikat lain mahu meletakkan atau mahu menggunakan suatu aturcara, kami berbesar hati membenarkannya. +Jika anda melihat seseorang menggunakan aturcara yang tidak dikenali dan menarik, anda boleh sentiasa bertanya untuk mlihat kod sumbernya, +agar anda boleh membacanya, mengubahnya, atau cannibalize sebahagian daripadanya bagi menghasilkan aturcara yang baru. +</emphasis> +</para> +<para>(from <emphasis role="bold"><ulink + url="http://www.gnu.org/gnu/thegnuproject.html"/></emphasis>) +</para> +</blockquote> +<para> +Komuniti Edenic ini runtuh sekitar Stallman, sebaik saja selepas 1980, apabila perubahan yang berlaku dalam industri yang lain akhirnya menyaingi +Makmal AI Lab. +Satu syarikat yang baru bermula mengupah ramai pengaturcara Makmal tersebut untuk membangunkan sistem pengoperasian yang setara +dengan apa yan telah mereka hasilkan dalam Lab itu, cumanya sekarang di bawah lesen yang esklusif. +Pada masa yang sama, Makmal AI memerlukan kelengkapan baru yang datang bersama sistem pengoperasian yang mempunyai hak milik. +</para> -<para><emphasis>The modern computers of the era, such as the VAX - or the 68020, had their own operating systems, but none of them - were free software: you had to sign a nondisclosure agreement - even to get an executable copy.</emphasis> </para> - - <para><emphasis>This meant that the first step in using a - computer was to promise not to help your neighbor. A cooperating - community was forbidden. The rule made by the owners of - proprietary software was, "If you share with your neighbor, you - are a pirate. If you want any changes, beg us to make them." - </emphasis> </para> - - </blockquote> - -<para>By some quirk of personality, he decided to resist the trend. -Instead of continuing to work at the now-decimated AI Lab, or taking a -job writing code at one of the new companies, where the results of his -work would be kept locked in a box, he resigned from the Lab and -started the GNU Project and the Free Software Foundation (FSF). The -goal of GNU<footnote><para>It stands for "GNU's Not Unix", and the -"GNU" in that expansion stands for...the same -thing.</para></footnote> was to develop a completely free and open -computer operating system and body of application software, in which -users would never be prevented from hacking or from sharing their -modifications. He was, in essence, setting out to recreate what had -been destroyed at the AI Lab, but on a world-wide scale and without -the vulnerabilities that had made the AI Lab's culture susceptible to -disintegration.</para> - -<para>In addition to working on the new operating system, Stallman -devised a copyright license whose terms guaranteed that his code would -be perpetually free. The GNU General Public License (GPL) is a clever -piece of legal judo: it says that the code may be copied and modified -without restriction, and that both copies and derivative works (i.e., -modified versions) must be distributed under the same license as the -original, with no additional restrictions. In effect, it uses -copyright law to achieve an effect opposite to that of traditional -copyright: instead of limiting the software's distribution, it -prevents <emphasis>anyone</emphasis>, even the author, from limiting -it. For Stallman, this was better than simply putting his code into -the public domain. If it were in the public domain, any particular -copy of it could be incorporated into a proprietary program (as has -also been known to happen to code under permissive copyright -licenses). While such incorporation wouldn't in any way diminish the +<para> +Stallman melihat pola yang lebih besar dalam apa yang telah berlaku: +</para> + +<blockquote> +<para> +<emphasis> +Komputer moden pada era tersebut seperti VAX atau 68020, mempunyai sistem pengoperasian mereka sendiri, namun tiada antara sistem itu yang percuma: +anda perlu menandatangani perjanjian sulit walaupun untuk mendapatkan salinan yang bolehlaksana. +</emphasis> +</para> + +<para> +<emphasis> +Ini bermakna yang langkah pertama untuk menggunakan komputer adalah dengan berjanji untuk tidak membantu jiran anda. Masyarakat yang bekerjasama adalah +dilarang. +Peraturan yang dibuat oleh pemilik perisian adalah, "Jika anda berkongsi dengan jiran anda, anda adalah lanun. Jika anda mahu sebarang perubahan +merayulah pada kami untuk melakukannya." +</emphasis> +</para> +</blockquote> + +<para>Dengan personaliti yang aneh, beliau menolak aliran tersebut. +Daripada terus bekerja di the now-decimated AI Lab, atau bekerja menulis kod dalam salah satu syarikat baru yang mana hasil kerjanya akan dikunci +di dalam kotak, beliau berhenti kerja daripada makmal dan memulakan Projek GNU dan Free Software Foundation (FSF). +Matlamat GNU adalah + +<footnote><para> +Ianya bermaksud "GNU's Not Unix", dan "GNU" dalam makna panjangnya adalah...perkara yang sama juga. +</para> +</footnote> +untuk membangunkan sistem pengoperasian yang sepenuhnya percuma dan terbuka dan badan bagi perisian aplikasi, yang mana pengguna tidak akan dilarang +daripada menceroboh atau berkongsi pengubahsuaian yang telah mereka lakukan. +Secara intipatinya, beliau membina semula apa yang telah musnah dalam makmal AI, namun kali ini dengan skala seluruh dunia dan tanpa +terdedah kepada budaya makmal AI yang percaya kepada disintegrasi. +</para> + + +<para> +Tambahan kepada tugasan ke atas sistem pengoperasian yang baru, Stallman mereka lesen hakcipta yang mana termanya menjamin yang kod beliau +would be perpetually free. +GNU General Public License (GPL) adalah satu helaian undang-undang yang bijak: ia mangatakan yang kod berkaitan boleh disalin dan diubahsuai +tanpa halangan, dan kedua-dua salinan dan kerja yang terbit daripadanya (i.e., versi yang diubah) mesti diagihkan dengan lesen yang sama seperti +asal, tanpa ada sebarang kekangan tambahan. +Kesannya, ia menggunakan undang-undang hakcipta untuk mencapai kesan bertentangan dengan hakcipta tradisi: Daripada menghadkan edaran perisian, +ianya menghalang <emphasis>seseorang</emphasis>, walau penulis itu sendiri, daripada menghadkannya. +Bagi Stallman, ini lebih baik daripada hanya meletakkan kod dalam domain awam. Jika ia berada dalam domain awam, mana-mana salinannya yang tertentu +mungkin akan digabungkan dalam aturcara berhakmilik (sebagaimana yang diketahui terjadi kepada kod di bawah lesen hakcipta permisif). + + +While such incorporation wouldn't in any way diminish the original code's continued availability, it would have meant that Stallman's efforts could benefit the enemy—proprietary software. The GPL can be thought of as a form of protectionism for free @@ -447,7 +417,10 @@ gain a competitive advantage over the other members. X Windows<footnote><para>They prefer it to be called the "X Window System", but in practice, people usually call it "X Windows", because -three words is just too cumbersome.</para></footnote> itself was free +three words is just too cumbersome. +</para> +</footnote> +itself was free software, but mainly as a way to level the playing field between competing business interests, not out of some desire to end the dominance of proprietary software. Yet another example, predating the @@ -462,11 +435,12 @@ system in order to complete his <emphasis>real</emphasis> goal—a book on computer programming—and saw no reason not to release his system to the -world when done.</para> - -</sect3> - -<para>Without listing every project and every license, it's safe to +world when done. +</para> +</sect3> + +<para> +Without listing every project and every license, it's safe to say that by the late 1980's, there was a lot of free software available under a wide variety of licenses. The diversity of licenses reflected a corresponding diversity of motivations. Even some of the @@ -587,15 +561,21 @@ of paid work) <emphasis>should</emphasis> have the right to control the terms of distribution, and that no moral judgement need be attached to the -choice of particular terms.</para> - -<para>For a long time, these differences did not need to be carefully +choice of particular terms. +</para> + +<para> +For a long time, these differences did not need to be carefully examined or articulated, but free software's burgeoning success in the business world made the issue unavoidable. In 1998, the term <firstterm>open source</firstterm> was created as an alternative to "free", by a coalition of programmers who eventually became The Open Source Initiative (OSI).<footnote><para>OSI's web home is <ulink -url="http://www.opensource.org/"/>.</para></footnote> The OSI felt +url="http://www.opensource.org/"/>. +</para> +</footnote> + +The OSI felt not only that "free software" was potentially confusing, but that the word "free" was just one symptom of a general problem: that the movement needed a marketing program to pitch it to the corporate @@ -697,8 +677,10 @@ <!-- ========================== SECTION =========================== --> <sect1 id="today"> -<title>The Situation Today</title> - + + +<title>The Situation Today</title> + <para>When running a free software project, you won't need to talk about such weighty philosophical matters on a daily basis. Programmers will not insist that everyone else in the project agree @@ -731,10 +713,11 @@ facing a new project. What will persuade all these people to stick together long enough to produce something useful? The answer to that question is complex enough to occupy the rest of this book, but if it -had to be expressed in one sentence, it would be this:</para> - - <blockquote> - <para><emphasis>People should feel that their connection to a +had to be expressed in one sentence, it would be this: +</para> + +<blockquote> +<para><emphasis>People should feel that their connection to a project, and influence over it, is directly proportional to their contributions.</emphasis></para> </blockquote> @@ -750,13 +733,12 @@ choose, what license, what development process, precisely what kind of infrastructure to set up, how to publicize the project's inception effectively, and much more. Starting a project out on the right foot -is the topic of <link linkend="getting-started">the next -chapter</link>.</para> - -</sect1> - -</chapter> - +is the topic of +<link linkend="getting-started">the next +chapter</link>. +</para> +</sect1> +</chapter> <!-- local variables: sgml-parent-document: ("book.xml" "chapter") _______________________________________________ Producingoss-translators mailing list Producingoss-translators@red-bean.com http://www.red-bean.com/mailman/listinfo/producingoss-translators
