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

مقاله کلیسای جامع و بازار از اریک ریموند یکی از مقاله‌های مشهور در زمینه نرم‌افزار آزاد و متن‌باز هست و اگر یه جستجوی ساده انجام بدید، می‌بینید که چقدر تاثیر گذار بوده!

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

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

حقیقتاً، من چنین تصوری نمی‌کردم. اوائل سال ۱۹۹۳، زمانی که لینوکس به دایره ذهن من راه یافت، ده سال می‌شد که من درگیر یونیکس و جنبش باز-متن بودم. من یکی از اولین شرکت‌کنندگان پروژه 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 یونیکس را به عنوان پایه برای سیستم‌عامل‌اش برگزید؛ صرف نظر از شروط مهمی که در ارتباط با سیستم‌عامل وجود دارد) دنیای لینوکس این سنت را تا حد زیادی در کنار تکنولوژی‌اش نگه داشته است؛ تعداد زیادی از پروژه‌های بازمتن، هم اکنون در دسترس هستند. لذا، صرف کردن زمان برای یافتن برنامه‌های خوب در دنیای لینوکس، نتیجه بهتری را نسبت به هر جای دیگری برای شما به ارمغان خواهد داشت.

و چنین اتفاقی برای من نیز رخ داد. با مواردی که قبلا پیدا کرده بودم، جستجوی دوم من ۹ نتیجه را در بر داشت – popmail، pop-perl، pimp، gwpop، getmail، PopTart، fetchpop و 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 علاقه‌ای ندارد. کد برنامه‌ با مشکلات کوچکی که داشت، کمی قدیمی نیز شده بود. من تغییرات بسیاری را در برنامه‌ به وجود آوردم و سرانجام به این نتیجه رسیدیم که تصمیم منطقی این است که مسئولیت برنامه‌ را به دست بگیرم.

واقعیت این بود که بدون اینکه متوجه باشم، پروژه به سرعت در حال پیشرفت بود. زمان زیادی می‌شد که دیگر بسته‌های نرم‌افزاری کوچک را برای نرم‌افزار نمی‌نوشتم و به نگهداری و مدیریت کل برنامه‌ می‌پرداختم؛ و همان زمان بود که این ایده به ذهنم خطور کرد که از این به بعد احتمالاً می‌توانم به تغییرات اساسی بپردازم.

در فرهنگ نرم‌افزاری که اشتراک کد را تبلیغ می‌کند، این یک روش طبیعی برای نمو یک پروژه است. با این منطق کار می‌کردم:
۴) اگر گرایش درستی داشته باشی، به مسائل جالبی برخورد می‌کنی.

اما عقیده کارل هریس حتی ارزشمند‌تر بود. او به این نتیجه رسیده بود که:
۵) اگر علاقه‌ات را نسبت به کار بر روی برنامه‌ای از دست دادی، در این صورت آخرین وظیفه‌ات این است که آن را به فرد شایسته‌ای بدهی.

بدون اینکه هرگز خواسته باشیم در این باره حرفی بزنیم، من و کارل میدانستیم که هدفی مشترک در کسب بهترین راه‌حل برای نرم‌افزار داریم. تنها سوال باقیمانده برای هر دوی ما این بود که آیا من میتوانم از عهدی کار بر بیایم . زمانی که به این باور رسیدم، پاسخ او با بزرگواری همراه بود و نرم‌افزار را به من واگذار کرد. امیدوارم که در وظیفه خود به خوبی او عمل کرده باشم.

اهمیت وجود تعدادی کاربر

و بدین گونه من نرم‌افزار popclient را به دست گرفتم و در نتیجه، کاربران این نرم‌افزار را نیز به دست آوردم. وجود کاربران برای نرم‌افزار بسیار ارزشمند است، نه فقط به این خاطر که نشان‌دهنده این مطلب هستند که نیازی را برآورده می‌کنید، بلکه به این دلیل که آن‌ها بیانگر عمل درست شما هستند. اگر درست رفتار کنید، آن‌ها هم می‌توانند برنامه‌نویس شوند.

سنت قدرتمند دیگر یونیکس که لینوکس آن را به اوج رسانده است، این است که اکثر کاربران این سیستم‌ها، یک هکر نیز هستند. از آن‌جا که کد منبع برنامه‌ در دسترس است، این امکان برای آن‌ها وجود دارد که هکرهای ماهرتری شوند. این مسئله می‌تواند در کاهش زمان عیب‌یابی نرم‌افزار بسیار مؤثر باشد. تنها با ایجاد کمی انگیزه و دلگرمی، کاربران شما می‌توانند مشکلات موجود در نرم‌افزار را تشخیص داده، راه‌حل‌هایی را برای حل این مشکل پیشنهاد دهند و به بهبود برنامه‌نویسی خیلی سریع‌تر از حالتی که شما تنهایی به این کار می‌پرداختید، کمک کنند.

همکار پنداشتن کاربران، راحت‌ترین روش برای تسریع پیشرفت برنامه‌نویسی و کاراترین روش برای عیب‌یابی نرم‌افزار است.

قدرت کارایی این نکته، به سادگی مورد کم توجهی قرار می‌گیرد. در حقیقت، تقریباً تمامی ما که در دنیای بازمتن به فعالیت می‌پردازیم، این نکته را که کاربران تا چه حد می‌توانند در رساندن برنامه‌ به سطح بالاتری از برنامه‌نویسی نقش داشته باشند و با پیچیدگی سیستم مقابله کنند را دست کم می‌گیریم؛ تا زمانی که لینوس توروالدز این تفاوت را به ما نشان داد.

در حقیقت، من فکر می‌کنم بزرگ‌ترین و زیرکانه‌ترین ابتکار لینوس تنها ساخت هسته سیستم‌عامل لینوکس نبود، بلکه بیشتر خلق مدل برنامه‌نویسی لینوکسی بوده است. زمانی که این عقیده را در حضور او مطرح کردم، او خندید و سریعاً آن چیزی که همیشه می‌گفت را تکرار کرد:

“من اصولا آدم تنبلی هستم که می‌خواهد از کارهایی که حقیقتاً دیگران انجام می‌دهند، استفاده‌ای ببرم”.

تنبل همچون روباه، یا همانطور که رابرت هینلین گاهی می‌گفت، آنقدر تنبل که ممکن است ببازی.

با نگاهی به گذشته، یک نمونه برای روش‌ها و موفقیت لینوکس را می‌توان در توسعه کتاب‌خانه GNU Emacs Lisp و آرشیو کد‌های Lisp مشاهده کرد. در قیاس با روش ساخت کلیسایی هسته Emacs C و بسیاری از ابزارهای دیگر بنیاد نرم‌افزار آزاد، تکامل کد‌های Lisp بسیار روان‌تر و کاربر محورانه‌تر بود. ایده‌ها و پیش الگوها اغلب سه یا چهار بار قبل از رسیدن به حالت پایدار نهایی بازنویسی می‌شد و همکاری‌های دورادوری که به وسیله‌ی اینترنت انجام می‌گرفت، معمول بود.

در واقع، تنها هک موفقیت‌آمیز من قبل از fetchmail، احتمالاً VC Mode Emacs بود؛ یک همکاری لینوکس مانند که به وسیله‌ی ارسال email با سه نفر دیگر انجام گرفت. تنها یکی از آن‌ها (ریچارد استالمن، پـدید آورنده Emacs و موسس بنیاد نرم‌افزار آزاد یا FSF) را تا به امروز ملاقات کرده‌ام. آن برنامه‌ مقدمه‌ای برای SCCS ، RCS و بعدها CVS از Emacs بود که ورژن عملیات کنترلی “one-touch” را ارائه می‌داد. برنامه‌ مذکور از مدل کوچک و خامی به وجود آمد که فرد دیگری آن را نوشته بود. توسعه VC موفقیت‌آمیز بود؛ چرا که، برخلاف خود Emacs، این امکان برای کد Emacs Lisp وجود داشت که مراحل انتشار/تست/بهبودی را خیلی سریع طی کند.

یکی از اثرات جانبی پیش‌بینی نشده خط مشی FSF در تلاش برای قانونی همراه کردن کد برنامه‌ با GPL این است که بدین روش استفاده از مدل بازار برای FSF مشکل‌تر می‌شود؛ چرا که باید مجوزهای کپی‌رایت را برای هر همکاری در برنامه‌ که بیش از بیست خـط صورت گرفته، اجرا کنند تا برنامه‌ تحت لیسانس GPL از رویارویی با قوانین کپی‌رایت مصون بماند. کسانی که از قانون کپی‌رایت تحت لیسانس‌های کنسرسیوم MIT X و BSD استفاده می‌کنند، چنین مشکلی نخواهند داشت؛ چرا که آن‌ها تلاشی برای حفظ ارزش‌هایی که ممکن است افرادی را به مقابله تحریک کند، انجام نمی‌دهند.

زود منتشر کن، مرتب منتشر کن

زود منتشر کردن برنامه‌ و انتشار متناوب نسخه‌های بعدی آن، یک بخش مهم از مدل برنامه‌نویسی لینوکسی است. اکثر برنامه‌نویسان (از جمله خود من) معمولا فکر می‌کنند که این روش، یک سیاست نادرست برای پروژه‌های بزرگ است؛ تنها به این دلیل که ورژن‌های ابتدایی، نسخه‌های پر اشکالی هستند و شما نمی‌خواهید که صبر کاربرانتان به پایان برسد.

این طرز فکر، افراد را به سبک کلیسایی برنامه‌نویسی هدایت خواهد کرد. اگر هدف اصلی این باشد که کاربران کمترین خطای ممکن را مشاهده کنند، آن وقت چرا شما تنها نسخه‌های برنامه‌تان را هر شش ماه یک بار (یا حتی کمتر) انتشار می‌دهید و شدیداً برای رفع خطاها در زمان بین انتشار نسخه‌های برنامه‌تان کار می‌کنید؟ هسته Emacs C بدین روش ساخته شد. کتاب‌خانه Lisp، عملاً اینطور نبود – به این خاطر که آرشیو‌های فعالی از Lisp در خارج از کنترل FSF وجود داشت، که شما می‌توانستید نسخه‌های جدید و بهتری از برنامه‌ را که مستقل از چرخه انتشار Emacs بود، پیدا کنید.

مهم‌ترین‌شان، آرشیو Ohio State elisp بود که در بسیاری جهات از آرشیو‌های بزرگ امروز ِ لینوکسی پیشی گرفته بود. اما تنها تعداد کمی از ما واقعا درباره آنچه که انجام می‌دهیم، درست اندیشیده‌ایم؛ و یا درباره ماهیت واقعی چنان آرشیوی با درنظر گرفتن مشکلات مدل برنامه‌نویسی کلیسایی FSF، تعمق کرده‌ایم. حدوداًً سال ۱۹۹۲ بود که تلاشی جدی را در ارتباط با ادغام بسیاری از کد‌های Ohio در کتاب‌خانه رسمی Emacs Lisp، انجام دادم؛ که به مشکلات اساسی برخورد کردم و کاملاً شکست خوردم.

اما یک سال بعد، همانطور که لینوکس به طور گسترده ظاهر شد، به خوبی مشخص بود که چیزی متفاوت و البته بهتر در حال اتفاق افتادن است. سیاست توسعه نرم‌افزار باز لینوس کاملاً با ساختار کلیسایی در تضاد بود. آرشـیوهای sunsite و tsx-11 شــروع به رشد کردند، توزیع‌های زیادی به وجود آمدند؛ و همه این‌ها به وسیله‌ی انتشارهای متناوب و غیر معمول هسته سیستمی، به وجود آمد.

لینوس با کاربرانش تا بیشترین حد ممکن، همانند همکارانش برخورد می‌کرد:

برنامه‌ات را زود و به تناوب منتشر کن و به مشتریانت گوش بده

نوآوری لینوس در این زمینه زیاد نبود (مسائلی از این دست در دنیای یونیکس، به سنتی قدیمی تبدیل شده بود)؛ اما در ارتقاء این سنت تا حدی که بر پیچیدگی کاری که او در حال انجام آن بود، غلبه کند و با آن سازگار شود، بسیار ارزشمند بود. در روزهای نخستین (حدود سال ۱۹۹۱)، انتشار هسته‌ای جدید بیــش از یک بار در هر روز، برای او عجیب نبود. چرا که او همکاران برنامه‌نویس خود را بیش از هر فرد دیگری از طریق اینترنت به همکاری تشویق می‌کرد.

اما چطور این کار انجام شد؟ آیا می‌توانستم از آن الگو برداری کنم، و آیا این مسئله به نبوغ منحصر به فرد توروالدز بستگی داشت؟

فکر نمی‌کنم. مسلماً لینوس یک هکر خیلی ماهر است (چند نفر از ما می‌تواند یک پروژه به بزرگی و جامعیت هسته سیستم‌عامل را انجام دهد؟). اما لینوس جهش نابغه وار عظیمی از خود نشان نداد. لینوس یک نــابـغه خــلاق در طراحی، به نوعی که برای مثال ریچارد استالمن یا جیمز گوسلینگ (از NeWS و Java)، نیست (و یا حداقل، هنوز نشده است). بلکه، لینوس در نگاه من یک مهندس نابغه است؛ با حس ششمی برای اجتناب از خطا؛ و برنامه‌نویسی حرفه‌ای با مهارتی مثال زدنی برای یافتن بهترین و کوتاه‌ترین مسیرها. در واقع، ساختار کلی لینوکس بر اساس این ویژگی‌ها پایه‌ریزی شده و بازتاب ذات هوشیار لینوس و روش ساده‌سازی طراحی‌اش است.

خوب، اگر انتشارهای پی در پی و استفاده ابزاری از رسانه اینترنت تصادفی نبوده باشد، بلکه بخش‌هایی از زیرکی و نبوغ مهندسی لینوس در کوتاه کردن مسیر به سوی هدفش باشد، در این صورت او به دنبال چه بود و چه چیزی را از این سیستم طلب می‌کرد؟

با این فرض، پاسخ در خود سوال نهفته است. لینوس هکرها/کاربران خود را همواره ترغیب و از آن‌ها قدردانی می‌کرد ترغیب به وسیله‌ی نمایش دورنمایی از کاری که خودشان در آن سهیم‌اند و احساس رضایت‌مندی درونی حاصل، و قدردانی با نمایاندن (حتی روزانه) پیشرفتی که در کارشان حاصل می‌شود.

لینوس، دقیقا قصد بیشینه کردن تعداد افراد و ساعاتی را داشت که صرف برنامه‌نویسی و عیب‌یابی می‌شدند؛ حتی اگر این امر به قیمت بی‌ثباتی در برنامه‌ و خستگی ناشی از سختی حل مشکلی دشوار در برنامه‌، می‌شد. لینوس طوری رفتار می‌کرد که گویا به چنین درکی رسیده باشد:

با داشتن همکاران برنامه‌نویس و تست‌کننده‌های بتای زیاد، تقریباً هر مشکلی سریعاً پیدا شده و به وسیله‌ی فردی از افراد کاملاً برطرف می‌شوند.

یا خودمانی تر:

“با وجود چندین نگاه جستجوگر، تمامی خطاها برطرف می‌شوند”.

چیزی که من آن را “قانون لینوکس” نامیده‌ام.

شعار اصلی من هم در این زمینه این بود که هر مشکلی “به وسیله‌ی فردی پیدا می‌شود”. لینوس تردید داشت کسی که مشکلات را درک کرده و آن‌ها را برطرف می‌کند، لزوماً و یا حتی معمولا همان کسی باشد که آن را پیدا کرده است. او می‌گفت: “فردی مشکلات را پیدا می‌کند و فرد دیگری آن را حل می‌کند و من می‌گویم که پیدا کردن مشکل سخت‌تر است.” اما نکته در اینجاست که هر دوی این‌ها سریعاً اتفاق می‌افتد.

فکر می‌کنم هسته اصلی تفاوت بین سبک بازار و سبک کلیسایی در اینجا نهفته است. از دیدگاه برنامه‌نویسی کلیسایی، اشکالات برنامه‌ و مشکلات برنامه‌نویسی، موذی و دردسر ساز هستند. ماه‌ها بررسی تعداد کمی از افراد که وقت خود را به این کار اختصاص داده‌اند، لازم است تا اطمینان حاصل کنید که تمامی خطاها را برطرف کرده‌اید. نتیجه این روش، وقفه‌های زمانی طولانی بین انتشار نسخه‌های مختلف نرم‌افزار، و یأسی اجتناب‌ناپذیر در حالتی که که نسخه‌های دیر منتشر شده برنامه‌ شما کارایی مورد نظر را ندارند، خواهد بود.

از طرف دیگر، در دیدگاه بازار، شما فرض می‌کنید که اشکالات برنامه‌ ذاتاً اتفاقاتی سطحی هستند و یا حداقل، هنگامی که در معرض هزاران برنامه‌نویس مشتاق که منتظر دریافت نسخه‌ای جدید از برنامه‌ هستند، قرار می‌گیرند، سطحی و ضعیف خواهند شد. بنابراین، شما برنامه‌ خود را به تناوب منتشر می‌کنید تا برنامه‌تان بیشتر تصحیح شود و یکی از نتایج جانبی سودمند آن این است که اگر سهواً اشتباهی مرتکب شدید، چیز کمتری برای از دست دادن خواهید داشت.

و نکته در همین بود. همین و بس. اگر “قانون لینوکس” اشتباه می‌بود، آن وقت هر سیستمی به پیچیدگی هسته لینوکس، که به وسیله‌ی افراد بسیاری توسعه یافته بود، می‌بایست زیر فشار عدم هماهنگی‌ها و اشکالات اساسی کشف نشده، با شکست مواجه می‌شد. از سوی دیگر، اگر این قانون دست باشد، تنها کافیست که به شرح دلایل کم خطا بودن لینوکس بپردازیم.

البته شاید دلیلی برای شگفتی هم وجود نداشته باشد، چرا که جامعه‌شناسان سال‌ها قبل کشف کرده‌اند که میانگین نظر گروهی از افراد متخصص (و یا نادان)، قابل اعتمادتر از تک تک آن‌هاست. آن‌ها چنین اصلی را “اثر دلفی” نام‌گذاری کرده‌اند. پیداست که آنچه که لینوس نشان داده است این است که این مطلب حتی در عیب‌یابی نرم‌افزاری چون سیستم‌عامل نیز قابل تعمیم است – اینکه اثر دلفی می‌تواند در آسان کردن پیچیدگی برنامه‌نویسی، حتی در حد و اندازه پیچیدگی هسته یک سیستم‌عامل نیز، مؤثر باشد.

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

عملاً، ضعف نظری عملکردی به علت دوباره کاری‌هایی که در عیب‌یابی نرم‌افزار ممکن است رخ دهد، تقریباً هیچ‌گاه در دنیای لینوکس، در کارایی تأثیر منفی نخواهد داشت. یکی از نتایج “سیاست زود و به تناوب منتشر کردن برنامه‌”، کمینه کردن چنین دوباره کاری‌هایی است که به وسیله‌ی انتشار مشکلات حل شده به سرعت قابل حل است.

بروکس، حتی چنین عقیده تخمینی را با توجه به نظر جف داشت: “هزینه کلی نگهداری برنامه‌ای که به طور گسترده مورد استفاده قرار می‌گیرد، حدود چهل درصد و یا بیشتر از هزینه ایجاد آن است. جالب اینجاست که این هزینه شدیداً تحت تأثیر تعداد کاربران آن نرم‌افزار قـرار دارد. کاربران بیشتر، اشکالات بیشتری را نیز پیدا می‌کنند.” (چیزی که همواره بر آن تاکید دارم).

کاربران بیشتر، اشکالات بیشتری را نیز پیدا می‌کنند، چرا که افزایش یافتن تعداد کاربران، به افزایش روش‌های مختلفی برای آزمایش نرم‌افزار خواهد انجامید. این نکته زمانی تقویت می‌شود که کاربران نرم‌افزار، برنامه‌نویسان کمکی برنامه‌ مذکور نیز باشند. هر کدام ره‌یافتی جدید برای شناسایی مشکلات را با بینشی متفاوت و تحیلی گوناگون ارائه می‌دهند، که نمایانگر زاویه‌ای جدید از مشکل خواهد بود. این تفاوت‌ها کاملاً بیانگر کارایی “اثر دلفی” هستند. در حالت خاصی از عیب‌یابی، این تنوع و گوناگونی به کاهش دوباره کاری‌ها نیز خواهد انجامید.

بنابراین، افزودن تعداد تست‌کننده‌های حالت بتای نرم‌افزار، به کاهش پیچیدگی مشکلات موجود از دیدگاه برنامه‌نویس نخواهد انجامید، بلکه موجب افزایش این احتمال خواهد شد که ره‌یافت شخصی ممکن است در حل مشکل توسط فرد مذکور، به کار آید.

لینوس زرنگی هم کرد. هر وقت که مشکلات جدی در برنامه‌ وجود داشت، ورژن هسته لینوکس به نحوی شماره گذاری شده بود تا این امکان برای کاربران وجود داشته باشد که بتوانند آخرین نسخه “پایدار” برنامه‌ را انــتخاب کنند و یا اینکه ریسک کنند و با ترجیح ویژگی‌ها و امکانات نسخه جدید بر مشکلاتش، از نسخه جدید برنامه‌ استفاده کنند. این تاکتیک، هنوز به طور رسمی توسط بسیاری از هکر‌های لینوکسی استفاده نشده است، اما به نظرم باید این کار صورت گیرد؛ این حقیقت که حق انتخابی در این بین وجود دارد، هر دو را جذاب‌تر خواهد کرد.

زمانی که برنامه‌ دیگر آن برنامه‌ قبلی نبود

با درک نحوه عملکرد لینوس و خلق یک فرضیه درباره دلایل موفقیت آن، تصمیمی هوشیارانه برای تست این تئوری در پروژه جدیدم گرفتم (که در قیاس با لینوکس، مسلماً بسیار ساده‌تر و کوچک‌تر بود).

اما اولین کاری که انجام دادم، سازماندهی دوباره و ساده‌سازی نرم‌افزار popclient بود. پیاده‌سازی کارل هریس (Carl Harris) خیلی دقیق بود، اما نوعی پیچیدگی اضافی در قیاس با خیلی از برنامه‌نویسان C در برنامه‌اش به چشم می‌خورد. او با کد برنامه‌ به عنوان بخش اصلی و ساختمان داده‌ها به عنوان پشتیبان کد برخورد می‌کرد. در نتیجه، برنامه‌ بسیار زیبا سازماندهی شده بود، اما نوع طرح‌ریزی ساختمان داده برنامه‌، روشی معمول نبود و تقریباً زشت سازماندهی شده بود (حداقل در قیاس با استاندار‌های سطح بالای این هکر قدیمی LISP).

جدای این مسائل، دلیل دیگری برای بازنویسی برنامه‌ در کنار بهبود طرح برنامه‌ و ساختار ساختمان داده آن داشتم. در واقع، می‌خواستم برنامه‌ را کاملاً درک کنم. زیاد جالب نیست که مسئول درست‌کردن برنامه‌ای باشی که آن را درک نکرده‌ای!

حدوداً در ماه اول، به پیروی از ساختار پایه‌ای طرح کارل پرداختم. اولین تغییر اساسی که در برنامه‌ انجام دادم، اضافه کردن پشتیبانی از پروتکل IMAP به برنامه‌ بود. این کار را به وسیله‌ی سازماندهی مجدد پروتکل‌ها در یک درایور عمومی و سه جدول متد (برای POP2، POP3 و IMAP) انجام دادم. این تغییر و تغییرات قبلی نمایانگر یک اصل کلی هستند که خوب است برنامه‌نویسان آن را به خاطر بسپارند، به خصوص در زبان‌های برنامه‌نویسی از قبیل C که به طور پیش فرض با انواع پویا کار نمی‌کنند:

ساختمان داده‌ی خوب و برنامه‌ ضعیف بسیار بهتر از برنامه‌ خوب و ساختمان داده بی ارزش کار می‌کند.

فصل نهم از کتاب بروکس:

“اگر می‌خواهی مرا گیج کنی، برنامه‌ات را به من نشان بده ولی ساختمان داده برنامه‌ات را پنهان کن. اما اگر ساختمان داده برنامه‌ات را به من نشان دهی، اغلب دیگر نیازی به دیدن کد برنامه‌ات ندارم؛ همه چیز واضح و مشخص است.”

البته منظور او “فلوچارت‌ها” و “جداول” بود. البته با درنظر گرفتن حرکت سی ساله علمی و فنی/فرهنـگی، این دو تقریباً یکی هستند.

در این زمان (اوائل سپتامبر سال 1996، حدوداً شش هفتــه پس از شروع کار)، به این فکر افتادم که بهتر است که نام نرم‌افزار را تغییر دهم. پس از همه این تغییرات، برنامه‌ مذکور تنها یک POP client ساده نبود. اما دچار تردید شدم، چرا که تا آن زمان هیچ کار کاملاً جدیدی در ساختار برنامه‌ انجام نداده بودم. نسخه popclient من، هنوز هویت قبلی خود را داشت.

این تغییر بنیادی زمانی به وجود آمد که برنامه‌ fetchmail قادر به ارسال کردن نامه‌های دریافت شده به پورت SMTP شد. درباره‌اش خواهم گفت؛ اما قبل از آن: قبلاً گفتم که تصمیم داشتم که این پروژه را برای تست تئوری‌ام درباره آنچه که لینوس توروالدز انجام داده بود، به کار بگیرم. ممکن است بپرسید چطور این کار را کردم؟ به روش‌های زیر:

۱. برنامه‌ام را زود و به تناوب منتشر می‌کردم (تکرارش تقریباً کمتر از هر ده روز یک بار نمی‌شد، اما در طی دوران اوج برنامه‌نویسی، هر روز این کار انجام می‌شد)

۲. هر کس را که با من به نحوی درباره fetchmail درتماس بود را به لیست بتای خودم اضافه می‌کردم. هر زمانی که نسخه جدیدی را انتشار می‌دادم، آگهی‌های زیادی را به لیست بتای خودم ارسال می‌کردم تا آن‌ها را به مشارکت در پروژه تشویق کنم.

۳. به تست‌کننده‌های نسخه بتای نرم‌افزارم گوش می‌کردم، نظر آن‌ها را درباره تصمیماتم جویا می‌شدم و هر زمان که آن‌ها بسته‌های نرم‌افزاری و یا نظراتشان را برایم ارسال می‌کردند، از آن‌ها تشکر می‌کردم.

نتیجه نهایی این کمک‌های کوچک، بسیار سریع اثر خود را نشان داد. از آغاز پروژه، با گزارش‌های با ارزشی در ارتباط با خطاهای برنامه‌ مواجه شدم که برنامه‌نویسان حاضرند به خاطرش جان بدهند! که اغلب با راه‌حل‌های خوبی نیز همراه بود. من متفکرانه مورد نقد قرار گرفتم، نامه‌های بسیاری به دستم رسید و نظرات هوشمندانه‌ای نیز دریافت کردم. که همگی مرا به این نکته هدایت کرد:

اگر شما با تست‌کننده‌های نسخه بتای برنامه‌تان، چنان که آن‌ها با ارزش‌ترین منبع شما هستند، برخورد کنید، آن‌ها به عنوان با ارزش‌ترین منبع شما به شما پاسخ خواهند داد.

یک نکته ارزشمند از موفقیت fetchmail، تعداد اعضای لیست نسخه بتای پروژه، یعنی دوستان fetchmail-friends است. در زمان نوشتن این مقاله، لیست مذکور ۲۴۹ عضو داشت که هر دو یا سه هفته یکبار به تعداد اعضای آن اضافه می‌شود.

عملاً، با اصلاح نرم‌افزار در اواخر ماه مه سال 1997، لیست مذکور از آن تعداد زیاد اعضایش که به سیصد نفر می‌رسید، به دلیل جالبی تعدادی از اعضایش را از دست داد. خیلی از افراد از من می‌خواستند تا آن‌ها را از لیست خارج کنم، چرا که برنامه‌ fetchmail به حدی خوب عمل می‌کرد، که دیگر نیازی به بودن در لیست احساس نمی‌کردند! شاید این یک بخش از چرخه حیات پروژه کاملی باشد که در سبک بازار نوشته شده است.

نرم‌افزار popclient به fetchmail تبدیل می‌شود

تحول اصلی در پروژه زمانی صورت گرفت که هری هاچیسر (Harry Hochheiser) کد برنامه‌اش را در ارتباط با ارسال نامه به پورت SMTP ماشین سرویس‌گیرنده برایم فرستاد. من سریعاً به این نتیجه رسیدم که یک پیاده‌سازی درست از این ساختار تمامی روش‌های دیگر را به کنار خواهد زد.

هفته‌های زیادی را به سرو کله زدن با fetchmail پرداختم، تا طرح واسط برنامه‌ که قابل استفاده اما بی قواره بود، را بهبود بخشم – برنامه‌ ظاهری ناهنجار داشت، با گزینه‌های زیادی که به طور نامنظم در سراسر آن پراکنده بودند. مخصوصاً گزینه‌هایی که برای کپی‌برداری نامه دریافت شده به یک فـایل در صندوق‌پستی و یا یک دستگاه خروجی استاندارد تعبیه شده بودند، خاطرم را می آزردند، اما دلیلش را نمی‌توانستم درک کنم.

آنچه که در حین فکر درباره قابلیت ارسال SMTP به ذهنم خطور کرد، این بود که نرم‌افزار popclient سعی داشت تا کارهای زیادی را با هم انجام دهــد. این برنامه‌ به نـحوی طراحی شده بود تا هم یک عامل انتقال پست الکترونیکی (MTA) و هم یک عامل تحویل موضعی (MDA) باشد. با قابلیت ارسال SMTP ، می‌توانست از حــوزه کــــاری MDA خارج شده و یک MTA محض باشد که به سادگی sendmail، نامه را به برنامه‌های دیگر برای تحویل موضعی تحویل می‌دهد.

چرا تمامی پیچیدگی‌های پیکــربندی یک MDA یا عملیات قفل و الحاق (Lock and Append) بر روی یک صندوق‌پستی در هم آمیخته شوند، در حالیکه پورت ۲۵ تقریباً در تمامی پـلتفرم‌هایی که از TCP/IP پشتیبانی می‌کنند، به این کار اختصاص داده شده است؟ بخصوص زمانی که این مسئله به معنی شباهت ساختاری نامه دریافتی با نامه معمولی یک فرستنده SMTP باشد؛ که درواقع همان چیزی است که ما می‌خواهیم.

درس‌های زیادی در این نکته وجود دارد. در ابتدا، ایده ارسال SMTP بزرگ‌ترین نتیجه‌ای بود که من از تلاش هوشیارانه‌ام برای شبیه‌سازی روش لینوس گرفتم. یکی از کاربران، این ایده فوق العاده را به من داد – تنها کاری که بایــد انجام می‌دادم این بود که مفاهیم را درک کنم.

روش کارای بعدی برای داشتن ایده‌های خوب، کسب ایده‌های خوب از کاربرانتان است. بعضی وقتها این روش دوم بهتر است.

با کمی دقت، بسرعت خواهید فهمید که اگر کاملاً با خودتان درباره آنچه که به دیگران بدهکارید صادق باشید، دنـیا با تمام بزرگی‌اش همانطور با شما رفتار کرده است که شما با هر تکه از نوآوریتان که خلقش کرده‌اید؛ و این تنها شایسته بخشی از نبوغ درونی شماست. همه ما دیدیم که این مطلب چقدر برای لینوس مؤثر افتاد.

(وقتی که این مقاله را در کنفرانس Perl در ماه اوت سال ۱۹۹۷ ارائه دادم، لری وال در ردیف اول نشسته بود. وقتی که به آخرین خط پاراگراف فوق رسیدم، او همچون مبلغ‌های مذهبی فریاد زد : “بگو، بگو براد!”. تمامی حضار خندیدند، چرا که می‌دانستند که چنین چیزی برای سازنده perl نیز اتفاق افتاده بود.)

بعد از گذشت تنها چند هفته از اجرای پروژه در آن حال و هوا، تعریف و تمجیدهای مشابهی را نه از کاربرانم، بلکه از سایر افرادی که سخنانم به گوش آن‌ها رسیده بود، دریافت کردم. من هنوز تعدادی از آن نامه‌ها را دارم. هر وقت حس می‌کنم که زندگیم بی ارزش بوده، یک نگاهی به آن‌ها می اندازم 🙂

اما دو درس پایه‌ای دیگر وجود دارد که برای هر نوع طراحی نرم‌افزار، مناسب است.

در اغلب اوقات، اکثر راه حل‌های ابداعی و برجسته از درک این نکته ناشی می‌شود که تحلیل شما از مسئله اشتباه بوده است.

زمانی من تلاش می‌کردم تا با ادامه توسعه نرم‌افزار popclient به عنوان یک MTA/MDA ترکیب شده، برنامه‌ام تمامی انواع تحویل محلی را انجام دهد؛ در واقع می‌خواستم مسئله اشتباهی را حل کنم. ساختار برنامه‌ fetchmail می‌بایست مجدداً مورد بررسی و تحلیل قرار می‌گرفت تا به یک MTA محض تبدیل شود.

زمانی که به یک بن بست در برنامه‌نویسی می‌رسید، زمانی که فکر کردن به مرحله بعدی برایتان سخت می‌شود، آن وقت به دنبال جواب درست نباشید، بلکه به فکر یافتن سوال درست باشید. احتمالاً صورت مسئله نیازمند این است که از نو بیان شود.

با این وجود، مشکلم را از نو مورد بررسی قرار دادم. به وضـوح مشخص بود که کار درست این است که:

۱. قابلیت ارسال SMTP را در قالب یک درایور عمومی بگنجانم.

۲. آن را حالت پیش‌فرض قرار دهم.

۳. سرانجام تمامی حالات دیگر تحویل را نادیده بگیرم، به خصوص گزینه‌های ارسال به فایل و ارسال به خروجی استاندارد.

بعضی اوقات در مورد اجرای بند ۳ به تردید می افتادم، و از این می‌ترسیدم که کاربران قدیمی popclient که به مکانیزم‌های تحویل دیگر عادت کرده‌اند، از این کار ناراحت شوند. در تئوری، این امکان برایشان وجود داشت که با روش‌های مشابه بتوانند مشکلشان را برطرف کنند. اما در عمل، این تحول می‌توانست برایشان سخت و دشوار باشد.

اما زمانی که این کار را انجام دادم، بهبودی زیادی در روند کار ایجاد شد. مشکلاتی که در کد درایور وجود داشت به صفر رسید. پیکربندی برنامه‌ بسیار ساده‌تر شد – دیگر برنامه‌ بیهوده درگیــر MDA و صندوق‌پستی کاربر نمی‌شد؛ همچنین دیگر نگرانی در ارتباط با پشتیبانی از سیستم‌عامل مورد استفاده در ارتباط با قفل کردن فایل وجود نداشت.

همچنین، این راه تنها روش برای جلوگیری از از دست دادن نامه‌ها نیز بود. اگر شما فایلی را به عنوان محل تحویل نامه هایتان در نظر می‌گرفتید و دیسک پر می‌شد، آن وقت شما نامه‌تان را از دست می‌دادید. این مسئله هیچگاه با ارسال به وسیله‌ی SMTP اتفاق نخواهد افتاد، چرا که شنونده SMTP شما تا زمانی که نامه شما تحویل داده نشود یا حداقل برای تحویل در زمانی دیگر اسپول (Spool) نشود، پیغام OK را برنمی‌گرداند.

کارایی نرم‌افزار نیز افزایش یافت (البته انتظار نداشته باشید که با یک بار اجرای نرم‌افزار به این نکته پی ببرید). فایده مهم دیگری که نمی‌توان از آن به سادگی گذشت، کاهش محسوس تعداد صفحات راهنما بود.

بعداً، مجبور شدم تا قابلیت تحویل از طریق یک MDA محلی تعیین شده توسط کاربر را برای ایجاد امکان مدیریت بعضی از حالات نادری که در ارتباط با SLIP پویا به وجود می آمد، مجدداً به برنامه‌ اضافه کنم. اما راه بسیار ساده‌تری را برای انجام آن پیدا کردم.

چطور؟ در کنار گذاشتن ویژگی‌های کهنه در حالی که می‌توانید بدون آن‌ها، همچنان با همان کارایی کار کنید، تردید نکنید. به گفته آنتونی سنت-اگزیوپری (زمانی که خلبان و طراح هواپیما بود و هنوز نویسنده کتاب‌های کلاسیک کودکان نشده بود):

رسیدن به حد کمال در حالی که که چیز دیگری برای اضافه کردن وجود ندارد، به دست نمی آید، بلکه این مهم زمانی حاصل می‌شود که نتوان چیزی را از طرح مورد نظر کم کرد.

زمانی که برنامه‌ شما هم بهتر و هم ساده‌تر می‌شود، بدانید که درست عمل کرده‌اید. و در پروسه انجام کار، طرح برنامه‌ fetchmail هویت خاص خود را پیدا کرد، که کاملاً با نسخه قدیمی popclient متفاوت بود.

زمان تغییر نام برنامه‌ فرا رسیده بود. طرح جدید بیشتر از آن برنامه‌ popclient قدیمی به برنامه‌ ارسال نامه الکترونیکی می‌خورد؛ هر دو به نوعی MTA بودند، اما برنامه‌ popclient جدید متفاوت عمل می‌کرد. در نهایت و پس از دو ماه، نام برنامه‌ را به fetchmail تغییر دادم.

برنامه‌ fetchmail رشد می‌کند

حال، من طرح برنامه‌ای ابداعی و منظم را در اختیار داشتم و به خوبی می‌دانستم که در کارم موفق بوده‌ام چرا که هر روز از آن استفاده می‌کردم، و لیست بتایی که صحت این ادعا را تأیید می‌کرد. به تدریج حس می‌کردم که ابتکارهای کوچکی که ممکن است برای افراد کمی سودمند باشد، دیگر مرا ارضاء نمی‌کند. من در نوشتن برنامه‌ای دست داشتم که برای هر هکری که از یک نسخه یونیکس و یک کانکشن میل SLIP/PPP استفاده می‌کند، حقیقتاً مفید بود.

با قابلیت ارسال SMTP، برنامه‌ به شدت از سایر رقیبان خود پیشی گرفته بود و به چنان برنامه‌ قدرتمندی تبدیل شده بود که نه تنها سایر رقیبان خود را از راه بدر کرده بود، بلکه آن‌ها را به بوته فراموشی سپرده بود.

حدس می‌زنم که حتی نتوانید چنین نتیجه‌ای را متصور شوید. تنها زمانی می‌توانید، به این درک برسید که چنان قدرت تحلیلی در طراحی نرم‌افزار داشته باشید که نتیجه کار برایتان محرز و طبیعی جلوه کند. تنها روش برای حصــول چـنـین افکاری، با داشتن ایده‌های زیادی در ذهنتان حاصل می‌شود – و یا به وسیله‌ی یک نوع تیز بینی منهدسی وار، تا ایده‌های خوب دیگر افراد را در ماورای نحوه نگرش آن‌ها به چنگ آورید.

اندرو تننبام ایده اصلی ساخت یک سیستم‌عامل کوچک محلی شبیه یونیکس را برای ماشـین‌های 386 داشت تا از آن به عنوان ابــزاری برای تدریس استفاده کند. لینوس توروالدز ایـده Minix را به حدی ارتقاء داد که تصورش برای اندرو بعید بود و آن را به چیزی ارزشمند و شگفت انگیز تبدیل کرد. به همین روش (هر چند در مقیاس کوچک‌تری)، من ایدهایی را از کارل هریس و هری هاچیسر دریافت کردم و آن‌ها را به سطح بالاتری ارتقاء دادم. ما مبتکرانی چنانکه مردم در تصورشان آن را به نابغه تعبیر می‌کنند، نبودیم. از سوی دیگر، اکثر پیشرفت‌های علوم مختلف و رشته‌های فنی مهندسی و نرم‌افزار نیز به وسیله‌ی مبتکرانی نابغه صورت نگرفته است؛ البته جدای برخی از اساطیر برنامه‌نویس.

نتایج حاصل مست کننده بود. در حقیقت، نوعی از موفقیت که هر هکری برای آن و به امید آن زندگی می‌کند! و همه این‌ها به این معنی بود که من می‌توانستم سطح استانداردهایم را حتی فراتر از این نیز ببرم. برای آن که fetchmail را به آن خوبی که در خورش بود تبدیل کنم، می‌بایست علاوه بر برآورده کردن نیازهای شخصی‌ام در نوشتن برنامه‌، جنبه‌های مورد نیاز دیگر افراد را هر چند که خارج از حوزه نیازهای من باشد، لحاظ می‌کردم. و البته همه این کارهـا را به گونه‌ای انجام دهم که برنامه‌ همچنان ساده اما قدرتمند باقی بماند.

اولین و مهم‌ترین ویژگی که من بعد از درک این نکته به برنامه‌ام اضافه کردم، قابلیت پیشتیبانی از multidrop در برنامه‌ام بود. امکان دریافت نامه از میل باکس‌هایی که تمامی نامه‌ها را برای یک گروه از کاربران نگهداری می‌کنند، و سپس هر نامه را به گیرنده مخصوص خود ارسال می‌کنند.

تصمیم اضافه کردن این قابلیت به برنامه‌، کمی به دلیل اصرار‌های پیاپی بعضی از کاربران، و بیشتر به این خاطر بود که فکر می‌کردم که اجبار حاصل در کار با آدرس‌های این‌چنینی می‌تواند خطاهای برنامه‌ قبلی را کـاهـش دهــد؛ و همـینطور نیز شد. بررسی RFC 822 زمان زیادی برد، نه به این دلیل که هیچ بخشی از آن سخت بوده باشد، بلکه به این خاطر که حاوی توده‌ای از اطلاعات به هم مرتبط و جزئی بود.

اما نحوه آدرس دهی multidrop، نتیجه تصمیم یک طرح عالی را به خوبی نشان داد. اینجا بود که فهمیدم:

هر ابزاری در جای خود، مفید و سودمند است، اما یک ابزار واقعاً سودمند آنچنان در استفاده منعطف است که حتی تصوش را هم نمی‌کنید.

کاربرد غیر منتظره قابلیت multidrop در برنامه‌ fetchmail، در کـار با فهرست‌های پستی با نگـهداشتن لیست، و نیز امکان بسـط نام‌های مستعار، در سـمـت سرویس‌گیرنده یک کانکشن SLIP/PPP بود. این امر به این معنی بود که شخصی که در پشـت یه ماشین شخصی نشسته و از یک اکانت ISP استفاده می‌کند، قادر به مدیریت فهرست پستی خواهد بود، بدون اینکه نیازی به رجوع به فایل‌های نام‌های مستعار ISP داشته باشد.

تغییر مهم دیگری که تست‌کننده‌های بتای نرم‌افزار خواستار آن شده بودند، پیشیبانی از عملیات 8-بیتی MIME بود. انجام این کار بسیار سـاده بود، چرا که حـواسـم به کد‌های 8-بیتی بود؛ نه به خاطر این که من احتمال درخواست این ویژگی را از قبل پیش‌بینی می‌کردم، بلکه به دلیل پیروی از اصلی دیگر:

وقتی که نرم‌افزار دروازه‌ای، از هر نوعی می‌خواهد باشد، می‌نویسید، تلاش بسیاری کنید تا جریان داده شـما تا حد امکان کوچک شود و *هیچگاه* اطلاعات را دور نریزید، مگر اینکه گیرنده شما را مجبور به این کار کند.

اگر از این اصل پیروی نمی‌کردم، آن وقت پشتیبانی از MIME هشت بیتی، سخت و مشکل ساز می‌شد. در آن صـورت، مجبور بودم تا تمامی RFC 1652 را بخوانم تا چند بیت به ساختار تولید سرایند اضافه کنم.

برخی از کاربران اروپایی، مصرانه خواستار گنجاندن گزینه‌ای برای مــحدود ساختن تعداد پیغام‌هایی که در هر جلسه بازیابی می‌شود، شدنـد (که در این صورت، آن‌ها می‌توانستند هزینه‌های گران شبکه‌های تلفنشان را کنترل کنند). من مدت زمان زیادی بر این موضوع پافشاری و با درخواستشان مخالفت می‌کردم، و هنوز هم واقعاً از آن تغییر دل خوشی ندارم. اما زمانی که شما برای کاربران جهان برنامه‌ می‌نویسید، باید به نظرات مشتریانتان گوش کنید. این مسئله حتی در زمانی که آن‌ها پولی به شما نمی‌دهند، هم صادق است.

درس‌های دیگری از پروژه Fetchmail

قبل از اینکه به بررسی نتایج کلی مهندسی نرم‌افزار در این ارتباط بپردازیم، نکات مهم دیگری در ارتباط با پروژه fetchmail وجود دارد که شایسته بررسی و تحلیل است.

در سینتکس فایل‌های rc بعضا کلمات کلیدی بی‌ارزش یافت می‌شود، که تماماً توسط تجزیه‌گر برنامه‌ نادیده گرفته می‌شود. سینتکس انگلیسی-مانند بسیار خواناتر از کلمات کلیدی مختصر و مرسومی است که عموماً استفاده می‌شود.

این نکته زمانی به ذهنم خطور کرد که دریافتم که چقدر تعاریف فایل‌های rc، می‌توانند در تشبیه یک زبان کوچک نقش داشته باشند (به همین دلیل بود که کلمه کلیدی server را در برنامه‌ popclient به poll تغییر دادم).

حس کردم که هرچه واژه‌های اصلی برنامه‌ به انگلیسی محاوره‌ای نزدیک‌تر باشد، کاربرد برنامه‌ نیز ساده‌تر خواهد شد. هم‌اکنون، هر چند من از حامیان اصلی مکتب “از آن زبان بساز” در طراحی نرم‌افزار هستم که نمونه‌های آن را می‌توان در Emacs و HTML و خیلی از موتورهای دیتابیس یافت، معمولاً علاقه زیادی به استفاده از سینتکس انگلیسی-وار ندارم.

برنامه‌نویسان قدیمی به استفاده از واژه‌هایی کاملاً دقیق، مختصر و بدون هیچ گونه زیاده گویی گرایش دارند. این سبک، میراثی فرهنگی از زمانی است که منابع کامپیوتری گران بوند و لذا مراحل عمل تجریه می‌بایست تا حد امکان ارزان و ساده می‌بود. در این صورت طبیعی بود که زبان انگلیسی با افزونگی در حدود ۵۰٪، یک مدل نامناسب بوده باشد.

این موضوع، دلیل من برای اجتناب عادت گونه‌ام از واژه‌های محاوره‌ای انگلیسی نبود؛ به آن اشاره کردم تا اشتباه بودنش را گوش‌زد کنم. با هسته و سیکل‌هایی که ارزان تمام شوند، ایجاز حاصل به خودی خود یک فرجام نیست. این روزها مهم‌تر این است که زبان برنامه‌نویسی برای انسان راحت‌تر باشد تا اینکه برای ماشین ارزان‌تر تمام شود.

هرچند، دلایل بسیاری برای محتاط بودن وجود دارد. یکی، هزینه پیچیدگی در مرحله تجزیه است – شما قطعاً نمی‌خواهید به جایی برسید که مجموعه کاملی از اشکالات و عوامل مختلف پریشانی کاربر، برنامه‌تان را فرا بگیرد. دیگری این است که تلاش برای تبدیل سینتکس زبان به حالتی محاوره‌ای و انگلیسی مانند، اغلب نیازمند این است که انگلیسی مورد استفاده تا حد زیادی برای همسو شدن با هدف مورد نظر از قالب اصلی خود خارج شود؛ آنقدر که این تشابه ظاهری به زبان طبیعی مورد نظر، به اندازه همان سینتکس سنتی گیج کننده خواهد بود (این مطلب را در بسیاری از به اصطلاح “نسل چهارمی”‌ها و زبان‌های پرس و جوی دیتابیس‌های تجاری می‌بینید)

می‌توان گفت که سینتکس مدیریتی برنامه‌ fetchmail از این مشکلات به دور بود، چرا که دامنه ادبیاتی آن محدود و اندک بود و با ساختار یک زبان همه منظوره فاصله داشت. مطالبی که به کاربر می‌رساند، ساده بود و حداقل خیلی پیچیده نبود، لذا پتانسیل کمی برای پریشانی و گمراهی کاربر در تقابل ذهنی بین مجموعه‌ای کلمات روزمره انگلیسی و زبان مدیریتی واقعی نرم‌افزار، داشت. فکر می‌کنم درس بزرگی در این نکته نهفته است:
وقتی فاصله بین ادبیات مورد استفاده برنامه‌ شما و ادبیات محاوره‌ای زیاد است، اصطلاحات خودمانی می‌توانند مفید واقع شوند.

نکته دیگر تأمین امنیت واهی است! بعضی از کاربران fetchmail از من می‌خواستند تا نرم‌افزار را به گونه‌ای تغییر دهم تا پسورد‌ها را به شیوه رمزگذاری شده در فایل‌های rc به نحوی ذخیره کند که از دسترسی دیگر افراد مصون بماند.

من چنین کاری را انجام ندادم، چرا که عملاً این کار امنیت را افزایش نمی‌داد. هر کسی که مجوز‌های خواندن فایل‌های rc شما را داشته باشد، توانایی اجرای برنامه‌ شما را نیز همانند شما خواهد داشت – و اگر به دنبال پسورد شما باشند، با استفاده از رمزگشاهای خاصی قادر به یافتن پسورد شما خواهند بود.

نتیجه رمز گذاری پسورد در برنامه‌، تنها به ایجاد حس اعتمادی واهی در افرادی که این کاره نیستند، می‌انجامید. قانون کلی این است که :

کل امنیت یک سیستم به اسرار آن است. از کم کاری در بحث امنیت حذر کنید.

پیشنیازهای لازم برای سبک بازار

منتقدان و شنوندگان اولیه این مقاله، همگی سوالاتی را درباره پیش‌نیاز‌های لازم برای یک پیاده‌سازی موفق از سبک بازار در توسعه نرم‌افزار مطرح می‌کردند، که مباحثی نظیر صلاحیت‌های سرپرست پروژه و سبک برنامه‌نویسی در حالتی که فردی سعی بر ایجاد انجمنی از کمک-برنامه‌نویسان دارد را شامل می‌شد.

کاملاً مشخص است که کسی نمی‌تواند در سبک بازار، برنامه‌نویسی را از ابتدا شروع کند. هر فرد، قادر به تست برنامه‌، اشکال‌زدایی و بهبود نرم‌افزار است، اما انجام یک پروژه از ابتدا و کار انفرادی بر روی آن در مدل بازار بسیار سخت خواهد بود. لینوس این کار را امتحان نکرد، من هم چنین کاری نکردم. جامعه برنامه‌نویسان ِ پا گرفته شما نیازمند پروژه‌ای قابل اجرا و تست است تا با آن سرگرم شود.

زمانی که شما شروع به ایجاد انجمنی این چینی می‌کنید، آنچه که برای ارائه نیازمند آن هستید، قولی است که دیگران آن را باور داشته باشند. ممکن است که برنامه‌تان چنان که باید درست کار نکند؛ ممکن است منطقتان خام، کدتان پراشکال، برنامه‌تان ناقص، و مستند سازیتان ضعیف باشد. چیزی که نباید در آن کوتاهی کنید متقاعد کردن درونی ِ همکاران برنامه‌نویستان است که می‌تواند برنامه‌تان را در آینده‌ای نزدیک به برنامه‌ای کارا و خوب تبدیل کند.

لینوکس و fetchmail، هر دو با طرحهای پایه‌ای قدرتمند و جذاب، پا به جامعه گذاشتند. افراد بسیاری که پس از ارائه این مقاله به مدل بازار می اندیشند، یه این نکته مهم پی برده‌اند؛ سپس از کل مطالب به این نتیجه می‌رسند که سطح بالای بینش طراحی نرم‌افزار و هوشمندی در سرپرستی پروژه، از هم تفکیک ناپذیرند.

اما لینوس، طرح برنامه‌ خود را از یونیکس گرفت. من طرح خودم را از نسخه‌های اولیه popclient گرفتم (هر چند تغییرات زیادی کرد، ودر قیاس با لینوکس، خیلی بیشتر در ارتباط با آن گفته شد). در این صورت، آیا سرپرست/هماهنگ‌کننده یک پروژه در سبک بازار واقعا نیازمند داشتن استعداد استثنایی طراحی نرم‌افزار است، یا اینکه او می‌تواند از قدرت استعداد طراحی دیگران بهره ببرد؟

فکر می‌کنم، زیاد مهم نیست که هماهنگ‌کننده توانایی خلق طرح‌هایی با نبوغ استثنایی را داشته باشد، بلکه آنچه که مهم است این است که هماهنگ‌کننده پروژه قادر باشد تا ایده‌های خوب را از دیگر ایده‌ها تشخیص بدهد.

هر دو پروژه لینوکس و fetchmail گواهی بر این ادعا هستند. لینوس، نه در مقام یک طراح مبتکر برجسته (همانطور که پیشتر بحث شد)، ابتکار فوق العاده‌ای را از خود برای تشخیص طرح‌های خوب و یکپارچه کردنشان با هسته لینوکس نشان داد. و من نیز پیش از این، به شرح چگونگی شکل گیری یک ایده قدرتمند طراحی در برنامه‌ fetchmail (ارسال SMTP) که متعلق به فرد دیگری بود، پرداختم.

اولین شنوندگان این مقاله، از من با اشاره به این که ابتکار طراحی را در پروژه‌های تحت بازار راحت جلوه داده‌ام، تعریف و تمجید کردند؛ به این دلیل که خیلی از آن‌ها را خودم دارا هستم و در نتیجه این مسائل برایم سهل و آسان است. شاید تا حدی حق با آن‌ها باشد؛ فاز طراحی (در قیاس با برنامه‌نویسی و یا عیب‌یابی) مطمئنا قوی‌ترین مهارت من است.

اما مشکل زیرک و مبتکر بودن در طراحی نرم‌افزار این است که این خصوصیت بعد از چندی به یک عادت تبدیل می‌شود – شما خودتان همه کارها را می‌کنید و زمانی که مجبور می‌شوید که آن‌ها را به فرمی ساده و قدرتمند در آورید، گیج می‌شوید. پروژه‌هایی را به یاد می‌آورم که در آن‌ها به مشکل برخوردم، چرا که مرتکب این اشتباه شدم؛ اما حواسم بود که این اشتباه را در fetchmail مرتکب نشوم.

بنابراین، به این باور رسیدم که پروژه fetchmail تاحدی موفقیت‌آمیز بود، چرا که زیرکی‌ام را کنترل کردم؛ این استدلال (حداقل) در تضاد با ابتکار در طراحی، برای پروژه‌هایی که سبک بازار اجرا می‌شوند، لازم و ضروری است. و لینوکس را در نظر بگیرید. فرض کنید لینوس توروالدز سعی می‌کرد نوآوری‌های بنیادین در طرح سیستم‌عامل را در طی توسعه پروژه‌اش را خودش انجام دهد؛ در این صورت آیا این احتمال وجود داشت که هسته حاصل از این کار، به همان پایداری و موفقیتی باشد که اکنون در دست ماست؟

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

مهارت دیگری وجود دارد که به طور مستقیم با توسعه نرم‌افزاری در ارتباط نیست؛ فکر می‌کنم اهمیتش به اندازه زیرکی در طراحی پروژه‌های سبک بازار باشد – و ممکن است مهم‌تر باشد. هماهنگ‌کننده و یا مدیر یک پروژه در سبک بازار می‌بایست از مهارت‌های ارتباطی خوب در برخورد با افراد، برخوردار باشد.

این مسئله بدیهی است. برای ساخت یک انجمن توسعه نرم‌افزار، آنچه که نیاز دارید این است که افراد را جذب کنید؛ آن‌ها را به کاری که می‌خواهید انجام دهید، علاقمند سازید؛ و از بابت کاری که انجام می‌دهند، از آن‌ها تشکر کنید؛ سرو صداها و تبلیغات فنی پروژه، روشی قدیمی برای انجام این کار است؛ اما این جدا از موضوع بحث است. خصوصیات خود شما نیز در پروژه نقش اساسی دارد.

این تصادفی نیست که لینوس یک مرد نازنین و دوست داشتنی است که سبب می‌شود تا دیگران هم مانند خود او شوند و بخواهند که به او کمک کنند. این یک اتفاق نیست که من یک فرد برون‌گرای فعال هستم که از کار کردن با دیگران لذت میبرم و مهارت زیادی در طنز دارم. برای اینکه مدل بازار پا بر جا بماند، اندک توانایی شما در مجذوب ساختن افراد می‌تواند بسیار مؤثر واقع شود.

زمینه اجتماعی نرم‌افزار بازمتن

حقیقت دارد که: بهترین هک‌ها از راه‌حل‌های شخصی برای مشکلات هر روزه مبتکرِ آن شروع می‌شود؛ و سپس به طور گسترده مورد استفاده قرار می‌گیرد، چرا که مشکل فوق، می‌تواند مشکل گروه گسترده‌ای از کاربران باشد. این ما را به دلیل قانون ۱ باز می‌گرداند، که اگر بخواهیم آن را به شیوه‌ای بهتر بیان کنیم، می‌توانیم بگوییم:
برای حل یک مسئله جالب، از یافتن مسئله‌ای شروع کنید که برایتان جالب باشد.

برای من، کارل هریس و ورژن‌های اولیه popclient جرقه‌های اولیه شروع بود، که نتیجه‌اش برنامه‌ fetchmail شد. اما درک این نکته نیازمند گذشت زمان نسبتاً زیادی است. نکته جالب توجه، این است که به نظر می‌رسد انتخاب سیر حرکت لینوکس و fetchmail برای بررسی، ما را به مرحله بعدی هدایت می‌کند – سیر تکاملی نرم‌افزار در بین انجمن‌های زیاد و فعالی از کاربران و برنامه‌نویسان.

فرد بروکس در کتابش ، نشان داد که زمان برنامه‌نویس قابل تعویض نیست، و اضافه کردن برنامه‌نویس جهت تسریع در پروژه‌ای که به تأخیر افتاده است، موجب بیشتر به تأخیر افتادن آن نیز خواهد شد. او به بحث در این مورد پرداخت که پیچیدگی و هزینه‌های ارتباطی ِ یک پروژه با تعداد برنامه‌نویسان آن، هنگامی که نمودار پیشرفت پروژه خطی است، نسبت مستقیم دارد. این ادعا “قانون بروکس” نام گرفت و به عنوان قانونی بدیهی پذیرفته شد. اما اگر قانون بروکس همه ماجرا بود، در این صورت شکل‌گیری لینوکس غیر ممکن می‌شد.

تنها چند سال بعد، جرالد وینبرگ در کتاب روانشناسی ِ برنامه‌نویسی کامپیوتر ، بیان کرد که قانون بروکس باید به طور اساسی تصحیح شود. در بحث “برنامه‌نویسی با دیگران” (egoless programming)، وینبرگ نشان داد که در حالاتی که برنامه‌نویسان خودشان تمامی کارها را بر روی کدشان انجام نمی‌دهند، و دیگر افراد را به پیدا کردن مشکلات برنامه‌ و بهبودی در نرم‌افزار تشویق می‌کنند، چنان پیشرفتی در برنامه‌ ایجاد می‌شود که نمونه‌اش را نمی‌توان در هیچ مدل دیگری یافت.

می‌توان گفت که واژه‌های انتخابی وینبرگ، تحلیلش را از پذیرشی که شایسته و سزاوار آن بود، بر حذر داشت – مثلا به کار بردن واژه “egoless” برای هکرهای اینترنتی، برای برخی خنده‌دار بود. اما من فکر می‌کنم که استدلال او، امروزه بیش از زمان دیگری به واقعیت نزدیک است.

تاریخچه یونیکس باید قاعدتاً افکار ما را برای آنچه که باید از لینوکس یاد بگیریم، آماده کرده باشد (و تجربه‌ای که من در قالب کوچک‌تری با الگو برداری تعمدی از روش لینوس، شرح دادم). یعنی، زمانی که برنامه‌نویسی را به عنوان فعالیتی اساسی به طور مجزا درنظر بگیریم، ابتکار‌های بسیار بزرگی از هدایت پروژه به توجه و قدرت خلاق جوامع برنامه‌نویسی حاصل می‌شود. برنامه‌نویسی که تنها از قدرت فکر خود در یک پروژه بسته استفاده می‌کند، در قیاس با برنامه‌نویسی که به خوبی می‌داند که چطور زمینه یک پروژه باز و تکاملی را که عیب‌یابی و پیشرفت آن به کمک صدها برنامه‌نویس دیگر انجام می‌شود، فراهم کند، شکست خورده است.

اما دنیای سنتی یونیکس، بنا به دلایل متعددی مانع از به کمال رسیدن این خط مشی شد. از جمله این دلایل می‌توان به محدودیت‌های مجوز‌های گوناگون، اسرار تجاری، و سودهای تجاری اشاره کرد. دیگری این بود که اینترنت آن زمان به وسعت امروز نبود.

پیش از اینکه اینترنت ارزان شود، تنها چند انجمن محدود با سبک برنامه‌نویسی “egoless” وارِ وینبرگ به فعالیت می‌پرداختند، و یک برنامه‌نویس به راحتی می‌توانست نظر بسیاری از افراد حرفه‌ای و برنامه‌نویسان دیگر را جلب کند. آزمایشگاه Bell ،MIT AI و UC Berkeley، به مهد نو آوری‌های افسانه‌ای و بزرگ تبدیل شده بودند.

لینوکس اولین پروژه‌ای بود که تلاشی هوشیارانه و موفق را در استفاده از تمام جهان به عنوان منبع نوآورش‌اش انجام داد. فکر نمی‌کنم که همزمانی و همگامی دوران رشد لینوکس و WWW تصادفی بوده باشد، و اینکه لینوکس دوران کودکی خود را در حدود سال‌های ۱۹۹۳-۱۹۹۴ همزمان با گسترش صنعت سرویس‌دهنگان اینترنت و انفجار تقاضا برای اینترنت سپری کرد. لینوس اولین کسی بود که چگونگی استفاده از اصول جدیدی را آموخت که فراگیر شدن اینترنت آن‌ها را ممکن ساخته بود.

با این حال که اینترنت ارزان قیمت نیازی ضروری برای رشد مدل لینوکس بود، اما فکر می‌کنم که این امر به خودی خود کافی نبود. عامل حیاتی دیگر، پیشرفت سبک رهبری پروژه و مجموعه روش‌های همکاری بود که این امکان را به برنامه‌نویسان می‌داد تا نظر برنامه‌نویسان دیگر را جلب کنند و از این رسانه بیش‌ترین استفاده را ببرند.

اما این سبک رهبری و روش‌های همکاری چیستند؟ این دو را نمی‌توان نتیجه قدرت ارتباطات دانست – و حتی اگر بتوان چنین تصور کرد، رهبری با اجبار، چنین نتیجه‌ای که امروز شاهدش هستیم، در بر نخواهد داشت. وینبرگ از کتاب زندگینامه پایتر الکسیویچ کروپتکین، آنارشیست قرن نوزدهم روسیه، با عنوان “خاطرات یک انقلابی”، مطالبی را در تأیید این موضوع نقل قول کرده است:

“پس از گذراندن دوران کودکی در خانواده‌ای فقیر، مثل هر مرد جوان دیگری در آن دوران، وارد زندگی واقعی شدم؛ با باور ِ لزوم حرف شنوی، فرمان‌پذیری، تحمل سرزنش، تنبیه و… . اما طولی نکشید که تصمیم گرفتم تا این وضعیت را عوض کنم و با اربابان مقابله کنم؛ و در شرایطی که کوچک‌ترین اشتباهی، عواقب وخیمی برای مرتکب شونده آن به همراه داشت، تصمیم گرفتم تا تفاوت بین پیروی از قانون حرف شنوی با پیروی اصولی که دیگر مردم با آن موافق بودند، را حس کنم. اولی، بیشتر مناسب رژه‌های نظامی بود که هیچ تقارنی ساختار زندگی نداشت؛ و رسیدن به این هدف تنها با تلاشی سخت در همسو شدن اراده عمومی ممکن بود.”

عبارت “تلاشی سخت در همسو شدن اراده عمومی” کاملاً گویاست که پروژه‌ای همانند لینوکس به چه چیزی نیاز دارد – و “قانون حرف شنوی” را به هیچ وجه نمی‌توان در میان داوطلبانی که در بهشت آنارشیست‌ها!! که ما آن را اینترنت می‌نامیم، به سر می‌برند، به کار برد. برای اینکه خوب به کار و رقابت بپردازید، هکرهایی که می‌خواهند پروژه‌های گروهی را رهبری کنند، باید چگونگی جذب افراد و تزریق انرژی و شوق به کار را در انجمن‌های علاقمند را در حالی که به طور سربسته توسط “اصل توافق” ِ کروپتکین به آن اشاره شد، یاد بگیرند. باید این مسائل را یاد بگیرند تا بتوانند از قانون لینوس استفاده کنند.

پیش‌تر، از “اثر دلفی” به عنوان تفسیری قابل قبول برای قانون لینوکس، یاد کردم. اما قیاس‌های قدرتمند دیگری نسبت به سیستم‌های تطبیقی در زیست شناسی و اقتصاد یافت می‌شود که به این موضوع اشاره دارند. دنیای لینوکس در بسیاری از جهات همانند یک بازار آزاد یا یک اکولوژی عمل می‌کند؛ یک مجموعه از عوامل خودخواه در تلاش برای هر چه بیشتر کردن سودی هستند که در فرایند انجام کار، نهایتاً به یک آرایش خود به خود اصلاح شده‌ای خواهد انجامید که بسیار کاراتر و حرفه‌ای‌تر از هر پروژه متمرکزی است. اینجاست که باید به دنبال نتایج “اصل توافق” بگردیم.

منظور از تلاش برای “عملکرد بر اساس منفعت” در هکرهای لینوکسی، تنها به معنی کلاسیک ِ اقتصادی آن نیست، بلکه به معنی حس معنوی حاصل از رضایتمندی درونی آن‌ها و شهرتی است که در میان هکرهای دیگر به دست می‌آورند. (ممکن است این انگیزه، نوع‌دوستانه عنوان شود، اما نمی‌توان انکار کرد که نوع‌دوستی نیز به خودی خود، نوعی از رضایتمندی درونی است که به فرد نوع‌دوست دست می‌دهد). فرهنگ‌های اختیارگرا که از این روش استفاده می‌کنند، کم نیستند. یکی از آن‌ها که من مدت زیادی است در آن مشارکت دارم، گروه هواداران داستان‌های علمی-تخیلی است، برخلاف آنچه که هکرها آن را صریحاً به “egoboo” (افزایش شهرت کسی در میان دیگر هواداران) می‌شناسد، محرک اصلی فعالیت‌های داوطلبانه آن است.

لینوس، با درست قرار دادن خویش به عنوان دروازه بان پروژه‌ای که توسعه‌اش اکثراً توسط دیگران انجام گرفت، و پرورش علاقمندی در پروژه تا زمانی که پروژه روی پای خود ایستاد، نشان داد که درک زیرکانه‌ای از “اصل توافق عمومی” ِ کروپتکین به دست آورده است. این دیدگاه شبه اقتصادی از دنیای لینوکس، ما را قادر می‌سازد تا ببینیم که چطور این توافق عملی شده است.

می‌توانیم به روش لینوس به عنوان روشی برای خلق بازاری کارا در “egoboo” بنگریم – تا خودپسندی تک تک هکرها را تا آن‌جا که ممکن است بهم متصل سازد، تا با دشواری‌هایی مبارزه کند، که تنها به وسیله‌ی همکاری‌های تنگاتنگ و مداوم، ممکن بود. در پروژه fetchmail (البته در مقیاس کوچک‌تر) نشان دادم که الگوبرداری از روش او به نتایج خوبی خواهد انجامید. شاید حتی من این روش را هوشیارانه‌تر و سیستماتیک‌تر از او هم بکار برده باشم.

افراد زیادی (به خصوص آن‌هایی که اصولا نسبت به بازارهای آزاد بدبین هستند)، انتظار یک فرهنگ خودخواهانه یک طرفه‌ای دارند که از هم گسیخته، شخصی، بی فایده، مرموز و خصومت‌آمیز باشد. اما این انتظار، کاملاً توسط (تنها برای اینکه مثالی ذکر کنم) تنوع گیج‌کننده، کیفیت و عمق مستندات لینوکس مردود است. اگر برنامه‌نویسان از مستندسازی متنفرند، پس چگونه است که هکرهای لینوکسی حجم انبوهی از مستندات را تولید کردند؟ بدیهی است که بازار آزاد لینوکس در egoboo بهتر در تولید محصولات ارزشمند تلاش می‌کند؛ با روشی متفاوت از آنچه دربخش‌های مستندسازی پر هزینه تولیدکننده‌های نرم‌افزار‌های تجاری رخ می‌دهد.

هر دو پروژه هسته سیستم‌عامل لینوکس و fetchmail نشان داد که با تشویق درست خیلی از هکرهای دیگر، یک برنامه‌نویس/هماهنگ کننده قدرتمند می‌تواند به واسطه اینترنت از وجود خیلی از همکاران برنامه‌نویس دیگر سود برد، بدون اینکه پروژه‌اش را به هرج و مرج و بی نظمی بکشاند. بنابراین، با توجه به قانون بروکس، من می‌گویم:

اگر هماهنگ کننده پروژه، از رسانه‌ای همچون اینترنت استفاده کند، و بداند که چگونه بدون استفاده از جبر به رهبری بپردازد، مطمئناً روش رهبری بهتر می‌شد.

فکر می‌کنم که آینده نرم‌افزار‌های بازمتن تا حد زیادی به افرادی تعلق خواهد داشت که می‌دانند چطور تجربه لینوس را تکرار کنند، کسانی که به روش کلیسایی پشت می‌کنند و بازار را در آغوش می‌گیرند. منظورم این نیست که قدرت فردی و نبوغ دیگر اهمیت ندارد، بلکه، فکر می‌کنم که پیشگامان نرم‌افزارهای بازمتن، کسانی خواهند بود که از قدرت فردی و نبوغ شخصی، کار خود را شروع می‌کنند و سپس، آن را به وسیله‌ی ساخت داوطلبانه و مؤثر انجمن‌هایی از علاقمندان، تقویت می‌کنند.

و شاید، این امر تنها منحصر به نرم‌افزار‌های بازمتن نباشد. برنامه‌نویسی با اهداف غیر تجاری، که در دریای استعداد جامعه لینوکس قرار می‌گیرد، می‌تواند بر مشکل خود غلبه کند. به سختی بتوان از عهده کرایه بیش از دویست نفر که در پروژه fetchmail به من کمک کردند، برامد.

احتمالاً، در انتها، جنبش بازمتن پیروز خواهد بود؛ نه به این دلیل که تشریک مساعی از نظر اخلاقی کاری پسندیده است یا به این خاطر که “احتکار نرم‌افزار” اخلاقاً مطرود است (با فرض اینکه نکته آخر را باور دارید، همانطور که من و لینوکس با آن مخالفیم)، بلکه تنها به این خاطر که دنیای تجارت نمی‌تواند در یک مسابقه فنی در حال پیشرفت، در جدال با انجمن‌های باز-متنی که از زمان متخصصان بیشتری برای حل مشکلاتش بهره می‌برد، پیروز شود.

پس‌گفتار :

نت‌اسکیپ به بازار می‌پیوندد

حالت عجیبی به آدم دست می‌دهد زمانی که حس کنی در حال رقم زدن تاریخ هستی…
در ۲۲ ژانویه سال ۱۹۹۸، حدوداً هفت ماه پس از اولین انتشار این مقاله، شرکت نت‌اسکیپ، اعلام کرد که قصد دارد کد منبع برنامه‌ Netscape Communicator را انتشار دهد. من از این ماجرا تا روز انتشار آن خبری نداشتم.

اریک هان، نایب رییس و رییس بخش تکنولوژی در نت‌اسکیپ، بعداً نامه‌ای مختصر به شرح زیر برای من نوشت:

“از طرف تمامی افرادی که در نت اسکیپ کار می‌کنند، می‌خواستم در درجه اول از شما برای کمکی که به ما کردید تشکر کنم. تفکر و مقاله شما الهام اصلی برای تصمیم ما بود.”

در هفته‌های بعد، من مرتباً به دعوت نت‌اسکیپ به Silicon Valley دعوت می‌شدم تا در کنفرانس‌های استراتژیک با برخی از مدیران بلند پایه و مهندسان فنی آن‌ها شرکت کنم. ما به تدوین استراتژی انتتشار کد منبع نت‌اسکیپ و مجوز مربوطه‌اش پرداختیم و در مورد طرح‌های بلند مدت و اثرات آن در جامعه باز-متن نیز گفتگو کردیم. الان که من در حال نوشتن این پس‌گفتار هستم، کمی زود است که بخواهم به شرح آن بپردازم، اما جزئیات آن به زودی اعلام خواهد شد.

نت‌اسکیپ، اکنون زمینه را برای یک آزمایش بزرگ و جهانی از پیاده‌سازی مدل بازار در دنیای تجارت فراهم کرده است. اکنون خطری فرهنگ باز–متن را تهدید می‌کند؛ اگر نت‌اسکیپ در کار خود موفق نشود، تفکرات دنیای بازمتن چنان بی‌اعتبار خواهد شد که دنیای تجارت تا یک دهه بعد به آن نزدیک نخواهد شد.

از سوی دیگر، این یک فرصت استثنایی است. واکنش‌های اولیه از Wall Street و نقاط دیگر کاملاً مثبت بوده است. فرصتی برای پیشرفت برایمان فراهم شده است. اگر نت‌اسکیپ با این حرکت بتواند سهم قابل توجهی از بازار را به دست آورد، زمینه را برای انقلابی بزرگ در صنعت کامپیوتر فراهم کرده است.

سال بعد باید سال جالب و آموزنده‌ای باشد.

---

من دنبال ترجمه‌ی این مقاله می‌گشتم که تونستم اون رو از اینجا پیدا کنم. که احتمالاً ترجمه آقای نیما ابوطالبی باشه… ولی دیدم این سایت از سال ۱۳۸۶ آپدیت نشده، و خب گفتم نکنه یه زمان از دست بره…

منبع زبان اصلی