ورود/ایجاد حساب کاربری
   منوی اصلی
· خانه
· لیست کاربران
· جستجو
· آمار مشاهدات
· آرشیو مقالات


- شرح
· راهنمای نویسندگان
· درباره ما

   همکاری با نشریه
در صورتی که مایل به همکاری با نشریه هستید، می‌توانید در لیست پستی نشریه عضو شده و در جریان امور قرار گیرید. برای اطلاعات بیشتر، اینجا کلیک کنید.

   کاربران
سردبیر
هیچ مدیر کمکی حاضر
همکاران
هیچ مدیر کمکی حاضر
اعضا:
جدیدترین:جدید امروز:0
جدیدترین:جدید دیروز:0
جدیدترین:مجموع:2471
جدیدترین:جدیدترین:
ufumenarayu
اعضا:حاضر
اعضا:اعضا:0
مهمان‌ها:مهمان‌ها:1
مجموع:مجموع:1
کاربران حاضر
هیچ کاربر حاضری وجود ندارد

   ورود کاربران




 


 برای ورود مشکل دارید؟
 ثبت نام کاربران جدید

کلیسای جامع و بازار (قسمت اول)

(1701 مجموع کلمات موجود در متن)
(5962 بار مطالعه شده است)  نسخه چاپی

کلیسای جامع و بازار، بخش اول


سیستم عامل لینوکس، ویرانگر است. حتی پنج سال پیش، چـــه کســی میــتوانـست تصـورش را بکند که یک سیستم عامل جهانی بتواند همچون یک معجزه از ابتکارهای پاره وقتی چندین هزار تن از برنامه نویسان که در سرتا سر جهان پراکنده اند و بوسیله اینترنت با هم در ارتباطند، شکل یابد؟

حقیقتا، مــن چنین تصوری نمیکردم. اوائل سـال ۱۹۹۳، زمانی که لینوکس به دایره ذهن من راه یافت، ده ســال میـشد کــه مـن درگیر یونیکس و جنبش باز-متن بودم. من یکی از اولین شرکت کنندگان پروژه 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

تمامی مطالب و مقالات این سایت تحت مجوز GNU FDL قرار دارند. بنابراین کپی و ایجاد تغییر در آنها مطابق شرایط این مجوز آزاد می‌باشد.