يك داستان اپنسورس؛ تولد داتنت نیوک
شرح اين قصه اپنسورسی را چندی پيش در كتاب DotNetNuke ASP.NET Portals به قلم شاون واكر، مبتكر و مدير اصلی پروژه خواندم و آن را بسيار آموزنده و جالب يافتم. خواننده كتاب با مطالعه اين قصه با چالشهای واقعی يک پروژه اپنسورسی و مزايا و معايب آن آشنا میشود. در اين كتاب ارزشمند، مبتكر داتنت نیوک يک فصل كامل پانزده صفحهای را به شرح اين داستان اختصاص داده است. در اينجا بخش نخست خلاصهای از اين داستان از نظرتان خواهد گذشت. مطالعه اين ماجرا را به همه كسانی كه قصد شروع و هدايت يك پروژه اپنسورس دارند، پيشنهاد میكنم.
قصهای برای چالشگران
آيا قصد شروع يک پروژه اپن سورس را داريد؟ آيا در ميانه راه مديريت يک پروژه منبع باز هستيد؟ آيا چالشهای عملی دنبالكردن پروژههايی از اين دست را میدانيد؟ آيا درباره مشكلات كار تيمی چيزی شنيدهايد؟ چگونه میتوان در اجرای يک پروژه اپن سورس به موفقيت دست يافت؟
بعد از خواندن اين داستان واقعی، احتمالاً پاسخ بسياری از اين پرسشها را خواهيد يافت. البته اين داستان مربوط به يک پروژه بزرگ نيست، اما ماهيت پروژههايی از اين دست به گونهای است كه میتوان بسياری از درسهای آن را به فعاليتهای بزرگتر نيز تعميم داد. گذر از فراز و نشيبهای مديريت يک پروژهِ اپن سورس، تجربه گرانبهايی است كه جز با عمل به دست نمیآيد.
در اين داستان با اغلب چالشهای عملی يک پروژه اپنسورسی، از جمله مسئله انتخاب يک مدل مجوزدهی (Licensing Model) برای توسعه آتی نرمافزار آشنا خواهيد شد.
تولد يك پورتال
چنانكه میدانيد، نرمافزار پورتالسازی داتنت نيوک، يكي از پيشرفتهترين و موفقترين سيستمهای ساخت پورتال و انجمن آنلاين بر اساس فناوری ASP.NET مايكروسافت است. تاكنون هزاران نفر از سراسر دنيا اين نرمافزار را به رايگان دانلود كردهاند و به كمك آن برای سازمان، گروه يا شركت خود و ديگران پورتال ساختهاند.
شاون واكر (Shaun Walker)، مبتكر پروژه DotNetNuke چنانكه در مقدمه كتاب DotNetNuke ASP.NET Portals تعريف نموده، در ابتدا اصلاً قصد ورود به يك پروژه اپن سورسی را نداشته است، اما نياز او را وادار كرد كه به اين سمت برود.
او زماني به فكر توليد يك نرمافزار پورتالسازی افتاد، كه وضعيت شركت نرمافزاری كه در آن مشغول به كار بود، به دليل رقابت سنگين صنعت IT چين و هند با ايالات متحده دچار بحران میشود و ناگزير دست به تجديد ساختار میزند و در اين حين، زيربنای برخی محصولات و توليدات خود را از فناوری مايكروسافت به فناوری جاوا تغيير میدهد.
همزمان زرنگی شركتهای چينی و هندی در بهرهبرداری از رهيافت برونسپاری (Outsourcing)، موجب میشود به تدريج تعداد قابل ملاحظهای از مشتريان و سازمانهای آمريكايی هنگام تصميمگيری براي خريد يک نرمافزار يا راهكار، گزينههای چينی را به دليل ارزانتر بودن نسبت به محصولات و خدمات شركتهای بومی خود، ترجيح دهند.
لذا تعدادی از كاركنان شركت به منظور كاستن از هزينهها بركنار میشوند و سمت شاون واكر از برنامهنويس به مدير پروژه تغيير میيابد؛ زيرا دانش او در زمينه برنامهنويسی روی پلتفرم مايكروسافت ديگر كاربردی نمیيابد. اين اتفاقات درست مصادف میشود با معرفی و عرضه فناوری داتنت از سوی مايكروسافت و واكر كه طی آن سالها شاهد برتری فناوری جاوا بر پلتفرم مايكروسافت – به دليل بهرهگيری از معماری شیء گرا و عدم وابستگی به سيستمعامل- بوده است، از معرفی يک فناوری كاملاً شیءگرا توسط مايكروسافت بسيار خوشحال میشود و تصميم میگيرد آن را بياموزد.
واكر خيلي زود متوجه میشود كه مايكروسافت براي تبليغ اين فناوري جديد، سورس چند پروژه نرمافزاری كامل و جالب، از جمله مديريت محتوای سايت (CMS) با استفاده از ASP.NET را به رايگان در اختيار عموم قرارداده است و كنجكاو میشود.
براي واكر خيلی جالب بود كه مايكروسافت در مجوز بهرهبرداری از سورسها براي كاربر نهايی EULA يا End-User License Agreement به برنامهنويسان اجازه میدهد به طور نامحدود از آنها استفاده كنند.
پروژهای كه در اين ميان برای واكر جالب مینمايد، IBuySpy است كه بعداً واكر بر اساس آن، DotNetNuke را میسازد.
او با خود فكر میكند كه شايد بتواند تغييراتی در اين سورس بدهد، آن را بهتر كند و به عنوان محصول خودش به فروش برساند (چون مجوز مذكور، چنين اجازهای به او میداد).
با اين حال سير حوادث او را به سمتی میبرد كه متوجه میشود هيچ راهی براي نجات پروژه DotNetNuke جز اپنسورس كردن آن وجود ندارد و تنها آن زمان است كه واكر متوجه میشود كه اصولاً يكي از دلايلی كه بعضی از برنامهنويسان را به سمت اپن سورس میكشاند، عدم امكان تحقق آرمانهايشان از طرق ديگر است.
بنابراين به زعم او خيلي از پروژههای اپن سورس ابتدا با هدف كسب سود و توليد نرمافزار تجاری شروع شدهاند، اما در ميانه راه متوجه میشوند كه هدف و كارايی واقعی نرمافزار آنها شناخته نخواهد شد؛ مگر اينكه راه اپنسورس را در پيش بگيرند.
حامی از راه میرسد
آيا راهحل ديگری هم وجود داشت؟ بله! راه ديگري هم وجود داشت. پروژههای اپنسورس به حامی مالی نياز دارند. پروژه IBSW نيز به يك اسپانسر نياز داشت و اين اسپانسر چه كسی غير از مايكروسافت میتوانست باشد؟ جنجال كوتاهی كه شان واكر آفريد و خود به آن خاتمه داد، سبب شد توجه مسئولان عالیرتبه در شركت مايكروسافت به اين پروژه جلب شود.
معلوم شد كه در تمام مدتي كه IBSW در حال تغيير و تحول بود، زير ذرهبين مايكروسافت بوده است. اما تا پيش از اين جنجال، شركت آسوده خيال در گوشهای نشسته بود و به طور غيرمستقيم از پيشرفت پروژه و تبليغی كه به واسطه آن برای فناوری ASP.NET میشد، بهره میبرد. گويی اين جنجال مايكروسافت را به خود آورده بود. تعامل و ارتباطی كه بين اسكات گوتريه و شاون واكر بر سر اين جنجال برقرار شد، IBSW را در كانون توجه دپارتمان ASP.NET در مايكروسافت قرار داده بود.
آنها از IBSW و تلاشهای واكر خوششان آمده بود و مايل نبودند پروژه به دليل مشكلات مالی و فشار كاری واكر به شكست بينجامد. البته گوتريه و تيم ASP.NET مايكروسافت در اين مقطع هيچ قولی به واكر نمیدهند. اما اين حادثه پايهای میشود براي تحولات بعدی كه در نهايت مايكروسافت را به اسپانسر پروژه تبديل میكند.
ديالوگ گوتريه و واكر ادامه میيابد تا سرانجام روز موعود فرا میرسد. مايكروسافت رسماً واكر را براي مذاكره دعوت میيكند. هيجان و استرس واكر را فرا میگيرد. او كه تا چندی پيش يک برنامهنويس معمولیي بود، اكنون از سوی بزرگترين شركت نرمافزاری جهان دعوت شده بود. مايكروسافت ميخواست از او و IBSW حمايت كند.
واكر روزی را به خاطر میآورد كه به سوی ردموند، شهری كه ساختمانهای مركزی مايكروسافت در آن قرار دارند، رانندگی میكرد و در طول سه ساعت رانندگی، تمام گزينههای ممكن را مرور میكرد تا برای هر وضعيتی آماده باشد. سعی میكرد در ذهنش برای هر پرسش و چالشی آماده باشد. سرانجام به آنجا رسيد و وارد ساختمان زيبای ردموند شد.
در آنجا گوتريه منتظرش بود و او را به دفتر شيک خود برد. در طول اين مذاكره هيجانانگيز و غيرقابل پيشبينی، ناگهان ترس واكر فرو میريزد و برخورد نماينده مايكروسافت را بسيار صميمانه میيابد. طوفان ايدهها و فكرهای جالبی كه ميان آن دو رد و بدل میشود، فضای اتاق را پر میكند. اين طوفانمغزی سه ساعت به طول میانجامد.
واكر مینويسد: «من آنجا فهميدم كه چرا گوتريه را پدر ASP.NET مینامند و با خودم فكر میكردم كه چه سعادتی پيدا كردم كه سه ساعت از وقتش را به من اختصاص داد تا قابليتهای نرمافزارم را به او نشان دهم. تصوری كه از دژ عظيم مايكروسافت داشتم، يكباره تغيير يافت».
واكر ابتدا دمويی از آخرين نسخه IBSW و قابليتهای آن را نمايش میدهد. سپس گوتريه به تشريح قابليتها و ويژگیهای ASP.NET2.0 که در آن زمان در مقطع تست آلفا بود، ميپردازد. شرط اصلی مايكروسافت برای همكاری چه بود؟ مايكروسافت میخواست مطمئن باشد كه IBSW با چشمانداز و معماری آتی ASP.NET هماهنگ میشود.
در واقع اين شركت علاقمند بود اين پروژهِ اپن سورسی طوری متحول شود كه همواره مُبلغ قابليتهای اصلی جديدترين نسخه ASP.NET باشد. واكر تا آن زمان هيچ چيز درباره ASP.NET2.0 نمیدانست. براي او تزريق معماری ASP.NET2.0 به درون IBSW هم جالب و هم چالشبرانگيز بود.
مذاكره آن دو اهميت فوقالعادهای برای واكر داشت. اما تنها يک شروع برای حمايت راهبردی مايكروسافت در ميان مدت بود. هنوز مشكل كوتاه مدت واكر حل نشده بود و صرف نظر از تفاهم كلی ميان آنها، هنوز دنيای واقعی براي واكر مشابه شرايط پيش از جنجال سرويس اشتراک بود.
پس او همچنان محتاج يک راهحل كوتاه مدت بود. در جستوجو برای يافتن يك راه برونرفت از شرايط موجود، او به فكر ايده ميزبانی وب افتاد. به هرحال همه كساني كه از IBSW استفاده میكردند، به يک ميزبان وب نياز داشتند تا پورتال خود را روی آن بنا كنند.
بنابراين واكر تصميم گرفت شريكي پيدا كند تا براي او يک سرويس ميزبانی وب راه بيندازد. سرانجام كسی از ميان كاربران فعال محفل IBSW در سايت asp.net پيدا شد كه خيلی در زمينه ميزبانی وب مهارت و علاقه داشت. آنها توانستند اين ايده را عملی كنند.
در ابتدا وضعيت خوب بود. اما به تدريج هزينههای همين كار، يعنی ميزبانی پورتالهای مشتريان و پشتيباني از آنان، خود به دردسر جديدی تبديل شد كه تقريباً اكثر درآمد حاصل از ميزبانی را میبلعيد. اين وضعيت «كجدار و مريز» تا آنجا ادامه يافت كه سود و هزينه كار برابر شد و ايده واكر ديگر كارايی خود را از دست داد.
در اين مقطع او تصميم میگيرد به اين ائتلاف تاكتيكی پايان بدهد، ولي اين اقدام كار دردناک و ناخوشايندی بود. وقتی واكر تصميم خود را به شريكش اعلام كرد، با ناراحتی شديد او روبهرو شد. مشكل اين بود كه هيچ سندی هم برای اين همكاری وجود نداشت. اين ائتلاف به صورت شفاهی صورت گرفته بود، و هيچ قراردادی ميان آنها امضا نشده بود و حالا كه او تصميم گرفته بود به اين همكاری پايان دهد، با عذاب وجدان روبهرو شده بود.
واكر مینويسد: «يكی از درسهای مهمی كه من از اين كار گرفتم اين بود كه گرچه پروژه اپنسورس بود، هيچ همكاری و تفاهمی كه موجب پيوند و ارتباطی ميان عناصر پروژه و موجوديتهای بيرون از آن میشود، نبايد بدون مستندسازی باشد».
برند و هويت DotNetNuke
يكی از مسائلی كه در مذاكره واكر و گوتريه مطرح شده بود، لزوم انتخاب يک هويت و نام (Brand) جديد برای IBSW بود. كلمه IBSW كه مخفف IBuySpy Workshop بود هنوز نام و هويت پروژه IBuySpy مايكروسافت را يدک میكشيد. در حالی كه تغييرات سورس كد پروژه نسبت به نسخه اوليه به اندازهای بود كه ديگر نمیشد آن را نسخه جديدی از IBuySpy تلقی كرد.
بنابراين واكر شروع به جستوجو برای يافتن يك نام جديد كرد و در اين ميان به شعار Nuke برخورد. اين كلمه را فرانسيسكو بورزی، مبتكر PHP-Nuke و پيشتاز نرمافزارهای پورتالسازی تحت وب سر زبانها انداخت. از نظر لغوي Nuke يک واژه جديد است كه از كلمه Nuclear به معنی هستهای (اتمی) الهام گرفته است.1
واكر تصادفاً عبارت DotNetNuke را به عنوان يک دامين در اينترنت جستوجو میكند و در كمال تعجب متوجه میشود كه هنوز دات كام، دات نت و دات اورگ آن ثبت نشده است. بنابراين تصميم میگيرد dotnetnuke.com ،dotnetnuke.net و dotnetnuke.org را ثبت كند.
اما به دليل وضع مالی خرابش در آن لحظه، فقط به اندازه ثبت يک دامين داخل كارت اعتباريش پول داشته است و به ناچار فقط دات كام آن را ثبت میكند. چندی بعد به فاصله كوتاهی از ثبت اين دامين، كسی يا كسانی داتنت و دات اورگ آن را به نام خودشان ثبت میكنند.2
سپس واكر به سراغ سمبل انرژی اتمی میرود كه البته متعلق به شركت يا سازمان خاصی نيست و در يک سايت اينترنتی به تصوير يك چرخدنده كه روی آن اين علامت درج شده بود، برمیخورد. از سمبل چرخ دنده در صنعت و كسب و كار فراوان استفاده میشود و به نهاد خاصی تعلق ندارد، ولی واكر برای محكم كاری از بابت عدم نقض قانون كپی رايت با مسئول آن سايت تماس میگيرد و از او اجازه میخواهد از اين تصوير در لوگويی كه برای DotNetNuke در ذهن خود ترسيم كرده بود، استفاده كند. به اين ترتيب پروژه داتنت نیوک با نام و سايت جديدش اعلام وجود میكند. نسخه اول DNN همان نسخه 5/0/1 نرمافزار IBSW بود.3
انتخاب مدل مجوز دهی اپن سورس
چالش مهم ديگری كه شاون واكر بايد به آن میپرداخت، مسئله مدل مجوزدهی (Licensing Model) بود. مجوز EULA مايكروسافت برای اين نرمافزار خاص، يعني IBuySpy بسيار آزاديخواهانه تنظيم شده بود؛ زيرا هدف مايكروسافت ترويج فناوری ASP.NET بود.
بنابراين اگر كسانی مانند واكر میخواستند از اين سورس مجانی برای توليد يک نرمافزار تجاری استفاده كنند، مانعی وجود نداشت. اما شاون واكر چه به لحاظ مالی و چه از نظر قدرت كسب وكار در حدی نبود (و نيست) كه بشود او را با مايكروسافت مقايسه كرد.
بنابراين او نمیتوانست همانقدر آزادی به كاربران و مصرفكنندگان IBSW و اينک (DotNetNuke) بدهد. از طرفی، نرمافزار IBSW نسبت به IBuySpy خيلی تفاوت كرده بود و منطقی نبود كه همان مجوز مايكروسافت ضميمه آن شود. به همين دليل، واكر متن EULA مايكروسافت را از فايلهای پروژه IBSW حذف كرده بود و آن را بدون هيچگونه مجوزی روانه اينترنت كرده بود.
چنين وضعيتي صحيح نبود. پس او به يک مدل مجوزدهی مناسب احتياج داشت. البته همانطور كه خود واكر توضيح میدهد، او نمیتوانست يک مدل «من درآوردی» بسازد و ضميمه پروژه اپنسورسی خود كنند؛ زيرا چنين كاری در صنعت اپن سورس زياد پذيرفته نبود.
از طرفی، با وجود چندين مدل مجوزدهی معتبر كه هر يک طرفداران و حاميان پروپاقرصی در صنعت دارند و در بوته عمل محک خوردهاند، ديگر چه نيازی به ابداع يک مدل غير استاندارد و ناشناخته وجود داشت؟ بنابراين مهمترين كاری كه بايد واكر انجام میداد، تحقيق در اين زمينه و انتخاب يک مدل مناسب بود.
وقتی واكر كمی در اين زمينه مطالعه میكند، خيلی زود متوجه میشود كه برخلاف تصور اوليهاش نه يک مدل، بلكه چندين و چند مدل مجوزدهی وجود دارد كه تازه واردان به عرصه اپنسورس را از بابت تنوعشان شگفت زده میكند. نكته اينجاست كه همه اين مدلها با استاندارد پايهای اپن سورس يعنی Open Source Definition كه مجموعهای از خط مشیهای كليدی تعريف شده توسط OSI يا www.open-source.org است، همخوانی دارد.
اين اصول كليدی به كاربران مصرفكننده حق توزيع آزادانه نرمافزار، توليد و توزيع نرمافزارهای مشتق شده از نرمافزار اصلی، حق دسترسی به سورس كد و استفاده از آن، و حق تركيب كردن اين سورس با نرمافزارهاي ديگر را میدهد.
اما تنوعی كه در زمينه مدلهای مجوزدهی اپن سورس وجود دارد، ناشی از حقوق و محدوديتهای بيشتری است كه هر يک از اين مدلها به اصول كلی تبيين شده از سوی OSI میافزايند و هر يک از اين حقوق و محدوديتهای اضافی با هدف تطابق خطوط كلی اپنسورس با شرايط خاص يک كسبوكار، معماری نرمافزار و نيازهای مصرفكنندگان آن افزوده شدهاند.
در ميان همه اين مدلها، دو مدل مجوزدهی معروفتر نظر واكر را جلب میكند: يكی GPL يا GNU Public License كه در سال 1989 توسط ريچارد استالمن، مؤسس بنياد نرمافزار آزاد پيشنهاد و توسعه داده شده بود و ديگری BSD يا Berkeley Software Distribution كه توسط دانشگاه بركلی كاليفرنيا ابداع شده بود. مجوز GPL كه گاهی با نام كپی لفت (Copyleft) شناخته میشود، متكی بر يک آرمان جنجالی است.
هدف GPL آن است كه اطمينان حاصل شود نه فقط خود نرمافزار، بلكه هر نرمافزار مشتق شده ديگر از روی آن نيز تحت مجوزGPL قرار بگيرد. اگرچه اين آرمان براي اهداف بشردوستانه خيلي عالی به نظر میرسد، در محيطهای تجاری مشكلآفرين میشود.
اگر بنا به فرض مايكروسافت IBuySpy را تحت GPL منتشر كرده بود، شاون واكر حق نداشت مدل مجوزدهی را تغيير دهد و فكر بهرهبرداری تجاری از آن را به خود راه بدهد. بنابراين واكر به اين نتيجه رسيد كه GPL چندان براي مقاصد او مناسب نيست.
مدل BSD اساساً يک مجوز كپیرايت است و گرچه تضمين میكند كه توزيع و استفاده از نرمافزار آزادانه باشد، دو خصوصيت مهم دارد: نخست اينكه نرمافزارهای مشتق شده مجبور نيستند همچنان به مدل مجوزدهی نرمافزار اوليه متعهد بمانند.
دوم اينكه، مدل BSD از سازندگان نرمافزارهای مشتق شده میخواهد كپیرايت يا حق مالكيت معنوی نرمافزار اوليه را در مشتقات خود ذكر كنند. به زبان ساده، میتوانيد از يک نرمافزار اپن سورس تحت مجوز BSD هم آزادانه استفاده كنيد، هم آزادانه آن را كپی كنيد و ميان ساير علاقمندان توزيع كنيد و هم از روی آن نرمافزارهای ديگری مشتق كنيد.
اما به لحاظ معنوی حق نداريد آن را نرمافزار خودتان بناميد و هميشه بايد در مستندات نرمافزار اين نكته ذكر شود كه مالكيت معنوی اصل و اساس اين محصول متعلق به كيست. به همين دليل، اين مدل در محافل دانشگاهي كه مالكيت معنوی براي پژوهشگران بسيار مهم است، طرفدار زيادی دارد. پس از بررسیهای فراوان، مدل BSD به مذاق شاون واكر خوش میآيد و آن را برای داتنت نیوک انتخاب میكند.
چالش وفاداری
همچنان كه شاون واكر و پروژه داتنت نیوک پيش میرفت، مشكلات و چالشهای جديد و عجيب و غريبی پيش میآمد كه او تا پيش از اين هرگز فكرش را نكرده بود. بزرگترين چالش هنگامی رخ مینمايد كه واكر رقيب پيدا میكند؛ آن هم چه رقيبی! كاربرانی از محفل خودش! اينان برنامهنويسان خوش قريحه و باهوشی بودند كه علیالاصول مجاز بودند به سورس كد داتنت نیوک دسترسی داشته باشند و آن را توسعه دهند.
مشكل اينجا بود كه شاون واكر به قول خودش از 110 درصد اوقات فراغتش برای توسعه دات نت نوک، پشتيبانی از كاربران و مديريت محفل اپنسورسی خود استفاده میكرد و باز هم وقت كم میآورد. به همين دليل و با توجه به حجم كارهای مديريتی در پروژه، وقت كمی برای افزودن قابليتهای جديد به نرمافزار پيدا میكرد و نمیتوانست همچون روزهای نخست برای اين كار وقت بگذارد.
بنابراين كاربران باهوشی كه در محفل آنلاين دات نت نیوک رفت و آمد میكردند، با سرعت بيشتری نسبت به او، قابليتها و امكانات جديد براي داتنت نیوک میآفريدند و از او جلو میزدند. شاون واكر با يک مشكل وجدانی فوقالعاده بغرنج مواجه شده بود. از يك سو اگر به اين برنامهنويسان چالشگر فرصت عرض اندام میداد، موقعيت خودش به خطر میافتاد. از آن مهمتر، موقعيت نسخه رسمی داتنت نیوک بهعنوان محصول اصلی اين محفل آنلاين به خطر میافتاد.
از سوی ديگر، اگر مانع كار آنها میشد، اين برخلاف اصول اپنسورس بود و يادش میافتاد كه خودش هم روزی جزء همين دسته كاربران چابک و فعال بوده است. آيا اگر مايكروسافت در روزهای نخستين IBuySpy نگران به خطر افتادن اقتدار خود در پروژه IBuySpy میشد و در مسير فعاليت شاون واكر سنگ اندازی میكرد، او خشمگين نمیشد؟ آيا در اين صورت هيچوقت IBSW مجالی برای توسعه پيدا میكرد؟ آيا در صورت اين مانع تراشی، خود مايكروسافت پشيمان نمیشد؟
برای درک شرايطی كه برای واكر پيش آمده بود، كافی است خودتان را جای او بگذاريد و فكر كنيد بعد از اين همه خون دل خوردن كسانی بيايند و به همين راحتی دسترنج شما را به اسم اپنسورس از شما بربايند. چون وقت بيشتری برای توسعه آن دارند يا باهوشترند.
در اين مقطع واكر به نكته مهمی پی برد. به قول خودش «بزرگترين درسی كه از پروژههای اپنسورسی موفق میتوان گرفت، اين است كه هيچ پروژه منبع بازی كامياب نخواهد بود؛ مگر اينكه گروه برنامهنويسان اصلی آن به تيم خود وفادار باشند».
وفاداری كه در كسب و كارهای تجاری فوقالعاده مهم و كليدي است، در پروژههای اپن سورس حتی سرنوشتسازتر است. چه راهحلی براي مقابله با اين چالش در يك فضای آزاد، دموكراتيک و اپنسورسی وجود داشت؟ گاهی وقتی انسان تحت فشار قرار میگيرد، خلاقيت بيشتری از خود نشان میدهد و واكر تنها در همين مقطع بود كه فهميد برای حفظ محصول خود در برابر رقبای بالقوه، نيازمند يک تيم وفادار است.
در هر كسب و كار پويايی مقاطع سرنوشتساز و حساسی وجود دارد كه به تعبير اندروگرو، مديرعامل سابق شركت اينتل، «نقطه چرخش راهبری» هستند. در چنين مقاطعی، مدير و راهبر اصلی يک مجموعه، ناگزير از اتخاذ يک تصميمگيری شجاعانه است؛ زيرا آلترناتيو ديگر همانا نابودی است. خيلی وقتها اين چالش سخت چيزی جز واگذاری امور كليدی به گروهی از همكاران معتمد نيست.
بهعنوان يک مدير و بنيانگذار يک حركت تا كی میخواهيد متكلم وحده باشيد؟ تا كی میتوانيد به تنهايی از پس چالشهای مديريت يک مجموعه رو به رشد برآييد؟ چند نفر را میتوانيد مديريت كنيد؟ ده نفر؟ صد نفر؟ هزار نفر؟ مگر چندتا دست و مغز و چشم داريد؟ بالأخره زمانی فرامیرسد كه لازم میبينيد افراد معتمدی در مجموعه خود داشته باشيد تا اختيارات كليدی و حساس خود را به آنان تفويض كنيد تا بتوانيد يک گام ديگر در مسير رشد و پويايی سازمان خود برداريد.
پس شاون واكر مجبور بود از توان و لياقت برنامهنويسان باهوش و قابل اعتمادی كه اتفاقاً تعدادشان كم هم نبود استفاده كند، مديريت تک نفره را كنار بگذارد و تيمی از مديران تشكيل دهد. از آن دشوارتر اينكه، در يک پروژه اپنسورس بايد روحيه دموكراتيكی داشته باشید و بتوانيد با نظرات موافق و مخالف همتيمیهای خود كنار بياييد. چون به آنان وابستهايد. وگرنه، پيشرفت نخواهيد كرد و دوباره به همان وضعيت شكنندهای برمیگرديد كه هر رقيب سمجی میتواند كارتان را به راحتی به چالش بكشد.
اما تشكيل يك تيم مديريت برای مقابله با چالشهای بالقوهای كه از سوی برنامهنويسان باهوش و ستيزهجو پيش میآمد، كافی نبود. ضمن اينكه واكر به يک مدل برای كنترل سورس (Source Control Model) نياز داشت كه جزء لاينفک هر پروژه برنامهنويسی تيمی است.
شاون واكر برای اين منظور يک مانيفست تهيه كرد كه در آن اصول كار تيمی در پروژه داتنت نیوک تشريح شده بود. او همچنين يک مدل كنترل سورس انتخاب كرد و برای محدود كردن چالشگران ستيزهجو قوانينی در محفل داتنت نیوک وضع كرد تا راه برای مانور برنامهنويسان وفادار باز و عرصه بر برنامهنويسان بیوفا تنگ شود. اين قوانين چه بودند؟ واكر چه مدلی را برای كنترل سورس برگزيد؟ مانيفست داتنت نوک چه بود؟ پاسخ اين پرسشها را در مطالب بعدی که صحبتهای شان واکر را ارائه دادهایم، بخوانيد.
پینوشت:
1- اين واژه هنوز در فرهنگ لغات انگليسی معنی دقيقی ندارد و معانی گوناگونی برای آن آمده است. اما در ميان همه اين معانی، بار تشبيهی و استعارهای آن در ارتباط با انرژی هستهای بيشتر است و به همين دليل، مثلاً بعضی وقتها نفوذهای شديد كامپيوتری و عملياتی مانند هک كردن سايتها از طريق ترفند Denial Of Service با اين واژه توصيف میشود. بنابراين «نوک» يا «نيوک» يک استعاره است كه به قدرت اثرگذاری اشاره دارد.
2- واكر از اين اتفاق با تلخی ياد میكند و از كسانی كه اين كار را كردند، انتقاد میكند. در اين مورد من با او كاملاً همدل و هم نظر هستم. اصولاً آدمهای بيكاری در اينترنت وجود دارند كه مترصد اين هستند كه ببينند كه چه اسامی بالقوهای ممكن است بهعنوان دامين ثبت شوند و زودتر میروند آنها را به نام خود ثبت میكنند تا بعداً به كسانی كه واقعاً مايلند (به دليل نام محصول يا سازمان و شركت خود) آن را داشته باشند، به قيمتهای نجومی بفروشند.
بازار بزرگ و مسخرهای هم برای دلالی و دست به دست كردن اين دامينهای جذاب پديد آمده است. هرچند در مواردی واقعاً اين ترفند براي پول درآوردن مؤثر واقع شده است، اما بيشتر داستانهايی كه در مورد موفقيت اين آدمهای فرصتطلب میشنويد، افسانهای بيش نيست. من خودم چند نفر از كسانی كه عاشق دلالی دامين هستند را میشناسم. اغلب آنها وضع مالی بدی دارند و در آرزوی روزی هستند كه از راه فروختن يک دامين جذاب، ميليونر شوند. ولی بخت اغلب با آنها يار نيست. چنانكه واكر نيز از خير آن دو دامين ديگر گذشت.
3- لوگوی امروزی داتنت نیوک متفاوت از لوگويی است كه در اين داستان شرح آن آمده است.