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

(2268 مجموع کلمات موجود در متن)
(4958 بار مطالعه شده است)  

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

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

و بدین گونه من نرم افزار 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 ) هستند، نیست (و یـا حداقل، هنوز نشده است). بلکـه، لیــنوس در نگاه من یــک مـهـندس نابغه است؛ با حس ششمی برای اجتناب از خطا؛ و برنامه نویسی حرفه ای با مهارتی مثــال زدنی بــرای یافتن بهترین و کوتاهترین مسیرها. در واقع، ساختار کلی لینوکس بر اساس این ویژگی ها پایه ریزی شده و بازتاب ذات هوشیار لینوس و روش ساده سازی طراحی اش است.

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

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

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

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

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

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

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

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

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

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

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

عملا، ضعف نظری عملکــردی بعــلت دوباره کاریهائــی که در عیب یابی نرم افزار ممکن است رخ دهد، تقریبا هیچ گاه در دنیای لینوکس، در کارائی تاثیر منفی نخواهد داشت. یکی از نتایج "سیاست زود و و به تناوب منتشر کردن برنامه"، کمینه کردن چنین دوباره کاریهائی است که بوسیله انتشار مشکلات حل شده به سرعت قابل حل است.

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

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

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

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

نیما ابوطالبی nima717a@yahoo.com