کلیسای جامع و بازار - قسمت ششم

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

حالت عجیبی به آدم دست میدهد زمانی که حس کنی در حال رقم زدن تاریخ هستی ...

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

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

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

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

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

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

ترجمه: نیما ابوطالبی   nima717a@yahoo.com

منبع:

http://www.catb.org/~esr/writings/cathedral-bazaar/

PDF Version