کلیسای جامع و بازار (قسمت اول)(1701 مجموع کلمات موجود در متن) (5957 بار مطالعه شده است)  کلیسای
جامع و بازار، بخش اول
سیستم
عامل لینوکس، ویرانگر است.
حتی
پنج سال پیش، چـــه کســی میــتوانـست
تصـورش را بکند که یک سیستم عامل جهانی
بتواند همچون یک معجزه از ابتکارهای پاره
وقتی چندین هزار تن از برنامه نویسان که
در سرتا سر جهان پراکنده اند و بوسیله
اینترنت با هم در ارتباطند، شکل یابد؟
حقیقتا،
مــن چنین تصوری نمیکردم.
اوائل
سـال ۱۹۹۳، زمانی که لینوکس به دایره ذهن
من راه یافت، ده ســال میـشد کــه مـن
درگیر یونیکس و جنبش باز-متن
بودم.
من
یکی از اولین شرکت کنندگان پروژه GNU
در
اواسط دهه ۱۹۸۰ بودم و تعداد زیادی از نرم
افزار های باز متن را بر روش شبکه انتشار
دادم، و در توسعه بــسیاری از نرم افزارهـا
(
نظیر
nethack,
Emacs VC and GUD modes, xlife و
...
) کــه
هنــوز بطــور گستــرده مـورد استفاده
قرار میگیرند، نقش مستقیم یا غیر مستقیم
داشتم.
فکر
میکردم که می‌دانم چه چیزی در حال رخ
دادن است.
لینوکس
ویرانگر تر از آنچیزی بــود کــه من فکر
می‌کـردم.
من
با ابزارهائی ساده در حال وعظ با انجیل
یـونیکس بــودم!
و
سالها به شکلی تکاملی و با ساختار موجود
برنامه نویسی میــکردم.
اما
همچنین بر این باور بودم که یک نوع پیچیدگی
بحرانی خـاصی در روش قبلی وجود دارد که
نیازمند روش ساخته یافته تر و متمرکز تری
است.
من
بر این عقیده بودم که نرم افزارهای پایه‌ای
و مهم (سیستم
عامل و ابزار های بزرگی همچون Emacs)
می‌بـایسـت
بــا مهارتی خاص و بوسیله نوابغی منحصر
بفرد یا گروهی از دانشمندان مــنـزوی،
همانند یک کلیسا ساخته شوند؛ بدون اینکه
نسخه بتائی از آن را قبل از زمان ارائه آن
توزیع کنند.
روش
برنامه نویسی لینوس توروالدز
(انتشار
زود و متناوب برنامه، اجازه کامل به شما
تا هر کاری را که میخواهید بر روی برنامه
انجام دهید، و آزاد بودن در قاعده و
ساختارش)
یک
شگفتی بود.
نه
تنها دیگر خبری از روش کلیسائی نبــود،
بـلکه جامعه لینوکس بیشتر به یک بــازار
شلوغ از روش های گوناگون و متـنـوع شبـاهـت
داشت (کــه
شایستگی آن به خوبی بوسیله آرشیو سایتهای
لینوکسی، کــه تـائید نظرات افراد مختلف
در آن وجود دارد، قابل درک است)؛
کـه در این صورت، یک سیستم اینـچنین پایدار
و منسجم ظاهرا تنها می‌توانست بوسیله یک
توالی از معجزه ها بوجود آید.
این
واقعیت که این سبک بازار مانند کار میکرد،
و البتـه خــوب هــم کار میکرد، یک شوک
محرز بود.
زمانی
که راهم را پیدا کردم، علاوه بر کار سخت
در پروژه‌های مختلف، سعی میکردم تا بفهمم
چرا دنیای لینوکس نه تنها بدلیل اغتشاش
و پریشانی از هم پاشیده نشد، بلکه با قدرت
و سرعتی مثال زدنی از کلیسا سازان!
پیشی
میگیرد.
در
اواسط سال ۱۹۹۶ حس کردم که به نتایجی برای
درک این مطلب رسیده‌ام.
شانس
و اقبال مرا به سمت راه درستی برای تست
تئوری‌ام، راهنــمائی کــرد.
در
قــالب یک پروژه باز متن، عمـدا مــدل
بازار را بــر روی آن پیــاده کــردم و
نتیجه آن موفقیتی پر معنی و مهم شد.
در
ادامه این مقاله، به شرح داستان آن پروژه
خواهم پرداخت و در میان آن، نکات مورد
نیاز برای یــک پروژه باز متن مـوفق را
بیان خواهم کرد.
من
تمامی این تجربیات را در ابتدا از دنــیای
لینوکس یاد نگرفتم، امــا در ادامه
خــواهیـم دید که چطور دنیای لینوکس به
آنها ارزش ویژه‌ای می‌دهد.
اگر
نظر من درست باشد، به شما کمک خواهد کــرد
که تا دقیقا دریابید که چه چیز، جامعه
لینوکس را به چنین منبع ارزشمندی از نرم
افزار های خوب تبدیل کرده است – و همچنین
به شما کمک خواهد کرد که خلاق تر و کارا
تر شوید.
نامه
باید به مقصد برسد
در
سال ۱۹۹۳، من در حــال کار در قسمت فنی
یــک ISP
دسترســی-آزاد
(Free
Access)
کــوچـک
بـه نام CCIL
در
غرب Chester
در
Pennsylvania
بودم.
( مــن
یکی از مــوسسان CCIL
بــودم
و تنــها نرم افزار تابلوی اعلانات
(Bulletin
Board) چندکاربره
مان را نوشتم – شما می‌توانید بوســیله
telnet
به
locke.ccil.org
آن
را آزمــایش کنید که هم اکنون تقریبا سه
هزار کاربر را در ۱۹ خط پشتیبانی می‌کند)
ایــن
کار به من امکان دسترسی ۲۴ ساعته بــه
اینـتـرنت را از طریق خط 56K
میداد.
در
حقیقت، دقیقا منطبق با نیازم بود!
طبیعتا،
با پست الکترونیکی نیز زیاد سر و کار
داشتم.
بنا
به دلایلی، کار کردن بــا پــروتکل SLIP
بین
ماشـین خانــگی‌ام (snark.thyrsus.com)
و
CCIL
خیــلی
سخت بود.
ســرانجـام
زمانی که موفق شدم، انجام تناوبی عمل
telnet
برای
چک کردن نامه هایم را آزاردهنده یافتم.
آنچه
که میخواستم ایــن بود کــه نامه هایم
چنان بر روی سیستم خانگی‌ام دریــافـت
شوند که زمانی که نامه ها میرسند، من متوجه
شوم و بتوانم آنها را بوسیله تمامی ابزارهای
محلی ام مدیریت کنم.
سیستم
ارسال ساده پست الکترونیکی
(Simple
Sendmail Forwarding) جوابــگو
نبــود، چــرا کــه ماشین شخصی من همواره
به شبکه متصل نبود و آدرس IP
ثابتی
نداشــت.
آنـچـه
کـه نـیـاز داشـتم، بـرنـامـه‌ای بـود
کـه به کــانـکشن SLIP
من
دسترسی پیدا کرده تا نامه هایم را در
اختیارم قرار دهد.
میدانستم
که چنین چیزی وجود دارد و اکــثر آنــهـا
از پروتکل ساده‌ای در لایه کـاربرد به
نام POP
استفاده
میکنند.
و
همانطور که مطمئن بودم، یک سرویس دهنده
POP3
با
سیستم عامل BSD/OS
در
آن زمان وجود داشت.
من
نیاز به یک سرویس گیرنده POP3
داشتــم.
بنـابراین،
به شبکه مراجعه کردم و یکی پیدا کردم.
در
واقع، سه یا چهار تا پیدا کردم.
برای
مدتی از pop-perl
استفاده
کردم، اما آن فاقد یک ویژگی بدیهی بود؛
یعنی توانائی برای هک کردن آدرس های
نامه‌های دریافت شده تا پاسخ نامه‌ها
به درستی داده شود.
مشکل
این بود:
فــرض
کنید فردی با نام joe
از
locke
برای
من نامه ای فرستاده باشد.
اگر
من نامه را از snark
دریافت
کرده و بخواهـم بــه آن پاسخ دهم، در ایــن
صورت سیستم نامه رسان من تلاش میکنــد
تـا آن را بـه فردی به نام joe
در
snark
که
وجود خارجی ندارد، برساند.
بــا
دست ویرایش کردن آدرس‌ها تا ccil.org@
به
آن ضمیمه شود، سریعا به کاری عذاب آور
تبدیل شده بود.
حقیقتا،
این کاری بود که کامپیوتر می‌بایست برای
من انجام دهد.
اما
هیچ کدام از سرویس گیرنده‌های POP
نمیدانستند
که چطور باید این کار را انجام دهند و این
به ما درس اول را داد:
۱)
شروع
هر نرم افزار خوب از مشکلات شخصی برنامه
نویسان آن است.
شاید
این مسئله بدیهی به نظر برسد (این
یک ضرب المثل قدیمی است که "نیاز
مادر اختراع است")
امــا
اکـثر تـوسـعه دهندگان نرم افزار زمان
زیادی از عمرشان را بدلایل اقتصــادی،
صرف نـوشتن برنامه هائی میکنند که نه به
آن نیاز دارند و نه علاقه‌ای.
اما
نه در دنیای لینوکس!
- توضیح
خواهم داد که چرا میانگین کیفیت نرم افزار
هائی که از جامعه لینوکس سرچشمه میگیرد،
اینقدر بالا است.
خوب،
آیا من به سرعت و در یک حرکت آتشی به نوشتن
یک سرویس گیرنده POP3
جدید
پرداختم تا با انواع موجود به رقابت
بپردازد؟ خیر!
من
به دقت به ابزارهای POP
که
در اختیار داشتم نگاه کردم، و از خودم
سوال کردم "کدامیک
به آنچه که من میخواهم نزدیکتر است؟".
به
این دلیل که؛
۲)
برنامه
نویسان خـوب، میدانند که چطور برنامه
بنویسند.
اما
برنامه نویسان خــبـره، میدانند کـه
چطور برنامه ها را بازنویسی کنند (و
دوباره به کار بگیرند).
با
اینکه ادعا نمیکنم که یک بـرنـامه نویس
خبره هستم، تلاش کردم تـا ایـن کـار را
تقلید کنم!
یـک
ویـژگی مـهـم از برنامه نویسان خبره،
تنبلی ِ سازنده و مفید آنـهاست.
آنـهـا
بـه خوبی میدانند که شما رتبه A
را
نه بخاطر تلاشتان، که به خاطر نتیجه کارتان
دریافت می‌کنید.
و
همواره آسانتر آن است که از یک بخش خوب از
راه حل شروع به کار کرد تا اینکه از هیج.
برای
مثال، لینوس توروالدز حقیقتا تلاش نکرد
تا سیستم عامل لینوکس را از ابتدا بنویسد.
او
با استفاده مجدد از کدها و ایده هائی که
از MINIX،
یک سیستم عامل کوچک شبیه یونیکس برای
ماشین‌های 386،
گرفته بود کار خود را شروع کرد.
عاقبت،
تمــام کـدهای MINIX،
حــذف شـد و یـا بطور کامل از نو نوشته شد
– ولی در زمانی که وجود داشت، ساختاری را
برای کودکی که سرانجام لینوکس شد، تشکیل
میداد.
با
تفکری مشابه، من به دنبال یک ابزار POP
گشتم
کــه بــه خــوبی نوشته شده باشد، تــا
از آن به عنوان پایه‌ای بــرای برنامه
نویسی‌ام استفاده کنم.
سنت
اشتراک کد در دنیـای یونیکس همواره موافق
استفاده مجدد از کد بوده است.
(به
همین دلیل است که پروژه GNU
یونیکس
را به عنوان پایه برای سیستم عامل اش
برگزید؛ صرف نظر از شروط مهمی که در ارتباط
با سیستم عامل وجود دارد)
دنیای
لینوکس این سنت را تا حد زیادی در کنار
تکنولوژی‌اش نگه داشته است؛ تعداد زیادی
از پروژه‌های باز متن، هم اکنون در دسترس
هستند.
لذا،
صرف کردن زمان برای یافتن برنامه های خوب
در دنیای لینوکس، نتیجه بهتری را نسبت به
هر جای دیگری برای شما به ارمغان خواهد
داشت.
و
چنین اتفاقی برای من نیز رخ داد.
با
مواردی که قبلا پیدا کرده بودم، جستجوی
دوم من نه نتیــجه را در بــر داشــت –
fetchpop,PopTart,get-mail,gwpop,pimp,pop-perl,popmail
و
upop.
در
ابتدا تمرکز خود را بر روی fetchpop
از
سونگ-هانگ
(Sueng-Hong
Oh) قرار
دادم و طرح کلی برنامه ام را بر روی آن
پیاده سازی کردم که حاصلش، پیشرفت‌های
مختلفی در این نرم افزار بود که نویسنده
برنامه در نسخه 1.9
آنها
را ترتیب اثر داد.
چند
هفته بعد، به طور اتفاقی به برنامه
popclient
که
کارل هریس (Carl
Harris) آن
را نوشته بود، برخورد کردم و دریافتم کــه
اشتبــاهی مرتکب شــدم.
هرچند
برنامه fetchpop
حاوی
ایده‌های خوبی بود (برای
مثال حالت daemon)،
ولی تنها قادر به
کار با POP3
بود
و نسبتا ناشیانه نیز نوشته شده بود
(سونگ-هانگ
فرد زیرکــی بود، اما برنامه نویس با
تجربه ای نبود، این دو ویژگی، به خــوبی
در بــرنـامه‌اش قابل مشاهده بود).
کــد
Carl
بهتـر
بود و کاملا حرفه‌ای و قدرتمند نوشته شده
بود، اما برنامه اش فاقد برخی از ویــژگی
های مهم و زیرکانه fetchpop
بود
(که
برخی از آنها را من نوشته بودم).
با
همان برنامه کار میکردم یا برنامه ام را
عوض میکردم؟ اگـــر بـرنـامه‌ام را
عوض میکردم، آنوقت تلاشهایی را که برای
بهتر کردن برنامه قبلی انجام داده بودم
را بی ارزش کرده بودم.
انگیزه
اصلی برای تعویض برنامه‌ام پشتیـبانی
از چنــدین پروتــکل در بــرنامه جـدید
بـود.
POP3 معمولترین
پروتکل در میان پروتکل های سرویس دهنده
post-office
بود،
اما تنها گزینه مــوجــود هــم نبـود.
برنامه
Fetchpop
و
انواع مشابه دیگر از POP2،
RPOP
و
یا APOP
پشتیبانی
نمیکردند، و من همچنین افکاری نه چنــدان
جدی در ارتباط با اضافه کردن احتمالی
پروتکل IMAP
به
برنامه نیز داشتم.
اما
دلیل منطقی تری برای این نظریه که تعویض
برنامه می‌تواند گزینه بهتری باشد،
داشتم.
چیزی
که مدت‌ها پیش از لینوکس یاد گرفتم.
۳)
اگر
بخواهی که چیزی را کنار بگذاری، در هر
صورت سرانجام این کار را میکنی!
یا
به بیانی دیگر، در اکثر موارد واقعا متوجه
مشکلات نخواهی شد تا برای یک بار هم که
شده به دنبال راه حلی بگردی.
در
این صورت دفعه بعد، احتمالا اینقدر میدانی
که چطور کارت را درست انجام دهی.
پس
اگر میخواهی درست عمل کنی، تلاش کن که این
کار را حد اقل یک بار تجربه کنی.
خوب
(به
خودم گفتم)
تغییرات
در برنامه fetchpop
اولین
تلاش من بود.
حالا
برنامه ام را عوض میکنم.
بعد
از اینکه اولین مجموعه از بسته‌های نــرم
افــزاری popclient
را
بــرای کارل هـریـس در تاریخ 25
ژوئن
1996
فرستادم،
فهمیدم که او دیگر اصلا به برنامه popclient
علاقه
ای ندارد.
کد
برنامه با مشکلات کوچکی که داشت، کمی
قدیمی نیز شده بود.
من
تغییرات بسیاری را در برنامه به وجود
آوردم و سرانجام به این نتیجه رسیدیم که
تصمیم منطقی این است که مسئولیت برنامه
را بدست بگیرم.
واقعیت
این بود که بدون اینکه متوجه باشم، پروژه
به سرعت در حال پیشرفت بود.
زمان
زیادی میشد که دیگر بسته های نرم افزاری
کوچک را برای نرم افزار نمی‌نوشتم و به
نگهداری و مدیریت کل برنامه می‌پرداختم؛
و همان زمان بود که این ایده به ذهنم خطور
کرد که از این به بعد احتمالا میتوانم
به تغییرات اساسی بپردازم.
در
فرهنگ نــرم‌افزاری کــه اشتــراک کد
را تبلیغ می‌کند، این یک روش طبیعی برای
نمو یک پروژه است.
با
این منطق کار میکردم:
۴)
اگر
گرایش درستی داشته باشی، به مسائل جالبی
برخورد میکنی.
اما
عقیده کارل هریس حتی ارزشمند تر بود.
او
به این نتیجه رسیده بود که:
۵)
اگر
علاقه ات را نسبت به کار بر روی برنامه ای
از دست دادی، در این صورت آخرین وظیفه ات
این است که آن را به فرد شایسته ای بدهی.
بدون
اینکه هرگز خواسته باشیم در این باره حرفی
بزنیم، من و کارل میدانستیم که هدفی مشترک
در کسب بهترین راه حل برای نرم افزار
داریم.
تنها
سوال باقیمانده برای هر دوی ما این بود
که آیا من میتوانم از عهدی کار بر بیایم
.
زمانی
که به این باور رسیدم، پاسخ او با بزرگواری
همراه بود و نرم افزار را به من واگذار
کرد.
امیدوارم
که در وظیفه خود به خوبی او عمل کرده باشم.
نیما
ابوطالبی nima717a@yahoo.com
منبع:
http://www.catb.org/~esr/writings/cathedral-bazaar/
 PDF Version
| 
منوی اصلی
