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

● زیر ساخت مورد نیاز برای پروژه های متن باز
به منظور انجام (توسعه) یک نرم افزار متن باز نیاز به ابزارها و زیرساختهایی است که امکانات لازم برای انجام یک پروژه متن باز را فراهم کنند. در این بخش این زیر ساختها را مورد بررسی قرار می دهیم.
▪ این زیرساختها عبارتند از:
۱) public code Archive
Project Documentation (۲
Bugs database (۳
Open Mailing Lists or Newsgroup (۴
Website (۵
● بایگانی عمومی کدPublic Code Archive)
▪ <br)>دلایل استفاده از PCA
۱) یک نیاز اولیه در پروژه های متن باز، امکان دسترسی عمومی به کد منبع (source code) است.
۲) هر توسعه دهنده چه در داخل و چه در خارج شرکت باید بتواند در هر زمان به آخرین نسخه از کدهای پروژه، دسترسی داشته باشد.
۳) هر توسعه دهنده باید بتواند مستقیما در کد منبع مربوط به پیمانه(module) ای که مسئولیتش را برعهده دارد، تغییرات اعمال کند.
۴) فعالیتها و رفع اشکالات(BUG) انجام شده توسط توسعه دهندگانی که هنوز به آنها اجازه دسترسی مستقیم و نوشتن در کد منبع، داده نشده است، باید ثبت شود و در درون کد منبع ذخیره و نگهداری شود.
۵) کد منبع ها باید مرتبا ایجاد شده (در صورت امکان هر روز) و برای download توسط توسعه دهندگان و کاربران در اختیار آنها قرار گیرد. معمولا آخرین نسخه ای که به خوبی پایدار (stable) شده است برای download در اختیار دیگران قرار داده می شود. همچنین باید همیشه این امکان برای کاربران فراهم باشد که بتوانند یک نسخه کاربردی از کد را download کنند.
این ساختار کاملا متفاوت از ساختار توسعه معمول است، که در آن توسعه دهندگان داخلی رونوشتهایی اختصاصی از کدهای منبع را در اختیار دارند و مرتبا آنها را برای توسعه دهندگان بیرونی منتشر می کنند. با به اشتراک گذاشتن یک بایگانی مرجع یکسان برای همه، در صورتی که هر یک از توسعه دهندگان تغییراتی را اعمال کنند یا اشکالی(bug) را اصلاح نمایند تغییرات به سرعت در اختیار سایر توسعه دهندگان قرار می گیرد.
توسعهدهندگان داخلی دسترسی های خاصی نخواهند داشت بنابراین همکاران دیگر (توسعهدهندگان خارجی) از اینکه برای انجام تغییرات و اصلاح اشکالات وقت صرف کنند، دلسرد نمی شوند، زیرا آنها نیز کلیه دسترسی هایی که به توسعه دهندگان داخلی داده شده است را دارا می باشند. در اکثر پروژه های متن باز از Concurrent version system،به طور اختصار CVS ، به عنوان انبار کدهای به اشتراک گذاشته شده استفاده می کنند. CVS این امکان را فراهم می کند که همزمان چندین توسعه دهنده بتوانند کد منبع را ویرایش کنند، بدون اینکه وابسته به تغییرات اعمال شده توسط سایرین باشند. CVS امکان تعریف چندین شاخه (با استفاده از ایجاد چندین نسخه از کد)، امکان بازگشت به آخرین نسخه و امکان استفاده همزمان چندین کاربر از یک کد منبع را فراهم می کند. CVS یک پروژه متن باز است که به صورت مجانی در دسترس است.
اینکه سیستم مدیریت کنترل منبعی (SCM=source control management) که شما در پروژه تان از آن استفاده می کنید به صورت آزادانه در اختیار توسعه دهندگان پروژه شما باشد، مسئله مهمی است، زیرا کسانی که به صورت پاره وقت بر روی پروژه شما کار می کنند تمایلی ندارند که برای تهیه (SCM) هزینه ای پرداخت کنند. ممکن است که اعضای تیم توسعه دهنده پروژه شما، عقیده داشته باشند که با توجه به اینکه سیستم SCM شرکت شما از CVS بهتر است، به کاربردن CVS موجب می شود که بسیاری از خصوصیات مفید SCM شرکت شما کنار گذاشته شود. آنها باید درک کنند که استفاده همه توسعه دهندگان از یک SCM مشابه مسئله مهمی است و خصوصیات مفیدی که در صورت استفاده کردن از CVS از دست می روند، به خاطر همکاری توسعه دهندگان خارجی، از راه های دیگر جبران می شوند. همچنین امید است که خصوصیات مفیدی که در SCM شرکت وجود دارد اما در CVS موجود نیست در نسخه های بعدی CVS به آن اضافه شوند.
پروژه ای با نام subversion درحال انجام است که در زمینه سیستم کنترل نسخه بتواند در مجامع متن باز، جایگزین CVS شود.
Bonsai ابزاری است که توسط پروژه Mozilla مورد استفاده قرار گرفت و به توسعه دهندگان این اجازه را می دهد که بتوانند با استفاده از ارسال درخواست برای بایگانی CVS، آخرین تغییرات اعمال شده را مشاهده کنند یا حتی متوجه شوند که چه شخصی در یک خط خاص تغییراتی را اعمال کرده است. اولین کاری که باید برای اعضای تیم انجام شود راه اندازی و نگهداری یک سرویس دهنده کد CVS است و دومین کار، کنترل روزانه و اطمینان از این مسئله است که سرویس دهنده، درست کار می کند و در صورتی که مشکلی درآن وجود داشته باشد باید این مشکل پیدا شده و حل شود، سومین کار این است که اشکالات اصلاح شده و سایر کارهای انجام شده توسط همکاران (توسعه دهندگان خارجی) باید در بایگانی کد منبع، ثبت و نگهداری شوند.
● مستندات پروژه (Project Documentation)
علاوه بر مستندات مورد نیاز برای یک کاربر نهایی (که به صورت معمول در پروژه های نرم افزاری وجود دارد)، یک پروژه متن باز نیاز دارد که مستندات داخلی خوبی هم برای توسعه دهندگان داشته باشد. شما باید این مستندات را تا حد ممکن ساده تهیه کنید تا توسعه دهندگان جدید بتوانند به راحتی ساختار کد منبع را درک کنند. این کار موجب می شود که توسعه دهندگان جدید به راحتی کارشان را شروع کنند و توسعه دهندگان بیشتری برای همکاری، ترغیب می شوند. عدم وجود یا ضعیف بودن مستندات داخلی موجب می شود که توسعه دهندگان تمایل به قطع کردن همکاری پیدا کنند.
برای توسعه دهندگانی که کار بر روی پروژه را به عنوان بخشی از کار معمول روزانه شان انجام می دهند، اختصاص دادن زمان کافی جهت درک ساختار و نحوه کارکرد کد پروژه امری طبیعی و قابل قبول است. برای این اشخاص ضعیف بودن مستندات امری عادی است، اما برای افرادی که فقط بخش کمی از زمان آزادشان را به توسعه پروژه، اختصاص می دهند و می خواهند خطایی را اصلاح کنند یا تغییر خیلی کمی اعمال کنند، کیفیت مستندات می توانند نقش خیلی مهمی در موفقیت یا شکست آنها داشته باشد. توسعه دهندگان جدید نیاز دارند که بتوانند رابطه های موجود در کد منبع را درک کنند و به اندازه کافی در مورد نحوه کار کد پروژه اطلاعات کسب کنند، تا بتوانند تغییرات مورد نظرشان را درآن اعمال کنند. اگر آنها در ابتدا بتوانند با موفقیت تغییرات مورد نظرشان را اعمال کنند به انجام کارهای بیشتر بر روی کد علاقمند تر خواهند شد. یک ابزار مبتنی بر web که می تواند به توسعه دهندگان جهت جستجو در کد منبع کمک کند، lxr است. این به این معنی است که همه توسعه دهندگانی که در کد منبع همکاری دارند باید مستندات مربوط به کد خودشان را تهیه کنند. اشخاص اغلب نیاز دارند که مستندات مربوط به طراحی را نوشته و ضرورتا آنها را به روز نگه دارند و همچنین توضیحات سطح بالایی در مورد معماری نرم افزار تهیه کنند. این موضوع می تواند یک کار اضافه برای کسانی باشد که در پروژه شما مسئولیت نوشتن مستندات تکنیکی را بر عهده دارند.
Mailing list معمولا یک مکان خوب برای توسعه دهندگان جدید (و قدیمی) است که می خواهند از تصمیمات مختلف طراحی اطلاع داشته باشند.
مستندات مهم دیگری که باید وجود داشته باشد، نقشه مسیر(road map) پروژه است. نقشه مسیر پروژه، برنامه توسعه را برای کل پروژه و برای پیمانه ها به صورت اختصاصی توضیح می دهد. نقشه مسیر تعیین می کند که برنامه توسعه دهندگان هسته (تیم مدیریت پروژه) و مسئولان پیمانه ها، در بحثهای داخل mailing list چیست. نقشه مسیر این امکان را به توسعه دهندگان و کاربران می دهد که بتوانند از تغییراتی که در پروژه انجام خواهد شد و زمان اعمال این تغییرات اطلاع پیدا کنند. بسیاری از توسعه دهندگان با استفاده از نقشه مسیر تصمیم می گیرند که چه کاری را باید انجام بدهند. پس این حیاتی است که نقشه مسیر به روز نگه داشته شود. نقشه مسیر و جلسات مذاکره هستند که مسائلی مانند ویژگی هایی (Features) که باید در پروژه موجود باشند، راهنماهای مورد نیاز برای تمرکز بر روی پروژه و جهت گیری پروژه را تعیین می کنند. شما اغلب نیاز دارید که لیست های دلخواه (wish list) را برای کل پروژه و یا برای هر پیمانه خاص تهیه کنید.
لیست دلخواه مکان مناسبی برای توسعه دهندگان است که می توانند از طریق آن بفهمند که چه موقع آنها می توانند کار مورد علاقه شان را برای کمک به انجام پروژه انجام دهند (به عنوان مثال چه موقع لازم است که پیمانه خاصی که مورد علاقه توسعه دهنده است پیاده سازی شود.) فرآیند ایجاد لیست دلخواه، کاربران را به صحبت کردن و شرکت در طراحی تشویق می کند. مشارکت کاربران به عنوان طراح در موفقیت واقعی پروژه نقش خیلی مهمی دارد.
کاربران نهایی شما هم اغلب نیاز به مستندات دارند. این احتمال وجود دارد که تعدادی از کاربران تمایل داشته باشند که در نوشتن این مستندات کمک کنند. Mailing list عمومی کاربران یک منبع اطلاعاتی عالی است. سازمان دهی اطلاعات در درون یک لیست مرتبط از سوالات پرسیده (FAQ) اولین قدم مناسب است.
اگر شما نویسندگان فنی و حرفه ای دارید که در پروژه شما کار می کنند، آنها می توانند مسئول مستندات پیمانه ها باشند، در این حالت دیگران می توانند پیشنهادات و اطلاعات خود را برای آنها ارسال کنند، اما آنها هستند که تصمیم می گیرند که چه چیزهایی در مستندات قرار گیرد. البته اگر یک کدنویس پیمانه، تعدادی پیشنهاد خوب ارائه دهد، می تواند این حق را پیدا کند که مستقیما مستندات را ویرایش کند. مستندات باید طوری آماده شوند (درقالبی باشند) که اشخاص بتوانند به سادگی آنها را بخوانند، مثلا به صورت text یاHTMailing list باشند و نیازی نباشد که کاربران و توسعه دهندگان برای خواندن مستندات، نرم افزار خاصی را در اختیار داشته باشند (مخصوصا نرم افزارهایی که برای تهیه آنها باید هزینه پرداخت شود).
چند پروژه متن باز برای استاندارد سازی DocBook/xMailing list به عنوان قالب متعارف برای مستندات نرم افزارهای متن باز مطرح شده اند.
● پایگاه داده اشکالات (Bugs database)
اشکالات اتفاق می افتند و در شروع اشکالات بیشتر هستند. ابزارهایی که برای دنبال کردن اشکالات انتخاب می کنید، باید تا حد امکان کارکردن با آن برای توسعه دهندگان، ساده باشد زیرا در غیر این صورت از آن استفاده نخواهند کرد. تعدادی از توسعه دهندگان ترجیح می دهند که از ابزارهایی برای کنترل اشکالات استفاده کنند که از طریق mail کار می کند، این کار موجب می شود که اشکالات گزارش شده از طریق mail برای آنها ارسال شود و آنها بتوانند از طریق mail آنها را پاسخ دهند. سایر توسعه دهندگان استفاده از پایگاه داده اشکالات مبتنی بر web را ترجیح می دهند. به خاطر اینکه کاربران منابع اصلی گزارش اشکالات هستند، باید گزارش کردن اشکالات برای آنها کار ساده ای باشد. پیدا کردن اشکالات زمان زیادی از کاربران، خواهد گرفت. همچنین آنها را با مشکلاتی روبرو خواهد کرد، حال فرض کنید که گزارش کردن این اشکالات هم کاربران را دچار سختی و زحمت کند، این امر کاربران را از فعال کردن در این زمینه دلسرد خواهد کرد. بنابراین ضروری است که ابزارهای مناسبی برای گزارش آسان اشکالات در اختیار کاربران قرار داده شود. برای پروژه ضروری است که یکی از اعضای پروژه کنترل کند که آیا اشکالی گزارش شده است یا نه و در صورت وجود داشتن گزارش آن را به پایگاه داده اشکالات اضافه کند.
تشویق کاربران برای گزارش اشکالات موجب می شود که شما تعداد زیادی تست کننده داشته باشید که اشکالات پروژه را استخراج می کنند. راه حل مناسب دیگر این است که شما یک توسعه دهنده داشته باشید که مسئول بررسی و خواندن mailing list کاربران باشد و بتواند از مشکلات گزارش شده، گزارشهای مربوط به اشکالات را استخراج کند، همچنین شما می توانید mailing list خاص برای گزارش اشکالات داشته باشید. مسئولین پیمانه ها باید اطمینان داشته باشند که ایده های خوبی که در mailing list بیان می شوند، در پایگاه داده اشکالات ثبت خواهند شد. پیشنهادهای ثبت شده در پایگاه داده اشکالات باید مرتبا برای به روز رسانی لیست دلخواه، مورد استفاده قرار گیرند.
یک نمونه از سیستم دنبال کننده اشکالات که توسط پروژه های متن باز مختلف مورد استفاده قرار گرفته است Bugzilla است. این ابزار به صورت خاص برای پروژه Mozilla ایجاد شد و کد آن به صورت مجانی در دسترس دیگران قرار داده شد. پروژه متن باز NetBeans، در حال حاضر از ISSUEZILLA استفاده می کند که بر مبنای Bugzilla می باشد. Scarab پروژه متن بازی است که به عنوان سیستم کنترل اشکالات نرم افزارهای متن باز، هم اکنون در حال توسعه است.
نگهداری و به روزرسانی پایگاه داده اشکالات، یکی دیگر از کارهای بنیادی است که باید در یک پروژه متن باز انجام شود.
● Mailing list یا گروه خبری (Open Mailing Lists or Newsgroup)
اینکه همه بحثهای مربوط به پروژه های متن باز به صورت باز انجام می شود مهم است. کاربران و توسعه دهندگان باید یک Mailing list یا گروه خبری عمومی برای بحثهایشان داشته باشند. بحثها شامل مسائلی مانند خبرها، گزارش اشکالات و خطاها و راه حل آنها، موضوعات مربوط به طراحی و پیشنهادات برای کارهای آینده است. توسعه دهندگان داخلی باید در Mailing listها شرکت کنند و فقط از Mailing listهای داخلی استفاده نکنند. از این به بعد برای راحتی بیان، هر کجا از واژه Mailing list استفاده می شود، منظور گروه خبری میباشد.
● اجازه دهید همه بدانند که چه اتفاق هایی می افتد
حیاتی است که اعضای مجمع در جریان بحثهای توسعه دهندگان داخلی باشند زیرا اگر توسعه دهندگان خارجی احساس کنند که توسعه دهندگان داخلی کارهایشان را در یک اجتماع بسته (در جمع خودشان) انجام می دهند و از emailهای اختصاصی خودشان استفاده می کنند احساس می کنند که به عنوان اعضای سطح پایین تر در نظر گرفته شده اند و باعث می شود که تا حد توان با پروژه همکاری نکنند. منظور این نیست که توسعه دهندگان داخلی باید فقط از Mailing list عمومی استفاده کنند، بلکه به این معنی است که در صورتی که جلسه ای برگزار می شود از توسعه دهندگان خارجی هم برای شرکت در جلسه دعوت شود و از نظرات آنها نیز استفاده شود و یا اینکه این امکان وجود داشته باشد که توسعه دهندگان خارجی نقطه نظرات خود را از طریق mail ارسال کرده و نظرات آنها در جلسه مورد بررسی قرار گیرد.
توجه داشته باشید که بیشتر کارهای طراحی از طریق email انجام می شود، مناسب ترین کار این است که آنها را در بایگانی Mailing list نگه داری کنید زیرا بسیاری از بحثهای مربوط به طراحی در مستندات ثبت نمی شوند و این می تواند در شرایطی مشکل ساز باشد. مثلا اگر دیدگاه های پایه در طراحی تغییر کنند و یا اشخاص جدیدی به پروژه اضافه شوند که برای انجام کاری که به عهده دارند نیاز به درک اصول طراحی پروژه داشته باشند، نبود مستندات مربوط به طراحی و بحثهای آن مشکل ساز خواهد بود.
دلیل دیگری که به خاطر آن باید به همه اجازه دهید که در جریان بررسی های پروژه قرار گیرند این است که در شرایطی مجمع تصمیم به تغییر اساسی در کد پروژه می گیرد. بدترین شرایط در صورتی که دیگران از این تصمیم اطلاع نداشته باشند این است که مسئولین پیمانه ها تغییرات زیادی در پیمانه های خود اعمال کنند، بدون اینکه از تغییرات اساسی در کد پروژه اطلاع داشته باشند، در این شرایط وقتی که سایر توسعه دهندگان از تغییرات اطلاع پیدا می کنند به دلیل اینکه اعمال این تغییرات در کارهای انجام شده آنها وقفه شدیدی ایجاد می کند، یا وقتی آنها برای انجام کار بر روی پیمانه خود، به کد پروژه مراجعه می کنند و مشاهده می کنند که کد پروژه کاملا عوض شده است، برای آنها مسئله خوشایندی نخواهد بود. حتی در بعضی از موارد این امکان وجود ندارد که توسعه دهنده نتواند پیمانه خودش را با تغییرات کلی اعمال شده هماهنگ کند زیرا این تغییرات صرفا در حد یک روش تئوری بوده است و اصولا ممکن است قابل پیاده سازی در پیمانه ها نباشد. در صورتی که تصمیمات مربوط به اعمال تغییرات کلی در کد پروژه زودتر به مسئولین پیمانه ها اطلاع داده شود، شرایط کمی بهتر خواهد بود و آنها می توانند قبل از اعمال تغییرات کلی، شرایط پیمانه هایشان را برای سازگاری با این تغییرات بررسی کرده و در صورت وجود مشکل آن را گزارش کنند. اما بهترین حالت این است که اعلام عمومی انجام شود و زمان بررسی پروژه برای اعمال تغییرات کلی به اطلاع همه رسانده شود، بنابراین همه می توانند در جلسه شرکت کنند یا نظرات خودشان اعلام کنند، سرانجام پس از جلسه تصمیمات اتخاذ شده به اطلاع کلیه اعضا رسانده شود. این کار باعث می شود که توسعه دهندگان خارجی هم احساس کنند که نقش مهمی در پروژه دارند و واقعا هم دارند، به علاوه با بودن نقطه نظرهای مختلف کیفیت طراحی نیز افزایش پیدا می کند.
● آداب و اصول اعلان
نحوه ارسال پیامها و اعلان اخبار باید به گونه ای باشد که افراد درونی یا بیرونی شرکت دچار سوء تفاهم نشوند. هر پیامی که در Mailing list قرار داده می شود باید از نظر گیرندگان آن مورد بررسی قرار گیرد. این کار باعث می شود که امکان به وجود آمدن سوء تفاهم، کاهش یابد.
● انواع و تعداد Mailing listها و گروه های خبری
Mailing listهای مختلف، برای منظورهای متفاوت می توانند مورد استفاده قرار گیرند. به طور کلی بهتر است که تعداد کمتری Mailing list داشته باشند تا اینکه تعداد آنها بخواهند خیلی زیاد شود. باید Mailing list به شکلی باشد که تعداد زیادی از افراد بتوانند در آن با یکدیگر ارتباط برقرار کنند و همچنین در آن احساس راحتی کنند. فقط در صورتی یک Mailing list جدید ایجاد کنید، که واقعا لازم باشد. مسئول Mailing list نقش مهمی ایفا کند و باید بتواند هماهنگی و نظم را در Mailing list برقرار کند. یک پروژه کوچک تنها به یک Mailing list برای کل بحثهای مربوط به پروژه احتیاج دارد. در عوض یک پروژه بزرگ ممکن است نیاز به چندین Mailing list داشته باشد. برای مثال، ممکن است هر پیمانه به یک Mailing list جداگانه نیاز داشته باشد. شما به یک Mailing list برای کاربران نیاز دارید، زیرا در پروژه های متن باز بخش خاصی برای پاسخ گویی به مشکلات کابران وجود ندارد، بنابراین باید یک Mailing list وجود داشته باشد تا کاربران بتوانند مشکلات مربوط به پروژه را از آن طریق گزارش دهند. مسئله دیگر این است که برای هر Mailing list یک بایگانی وجود داشته باشد. این بایگانی می تواند برای توسعه دهندگان و کاربران جدیدی مفید باشد زیرا می توانند مشاهده کنند که آیا یک ایده خاص، قبلا مورد بحث قرار گرفته است یا نه. اطمینان حاصل کنید که جستجو در درون بایگانی کار سادهای باشد. مشکل دیگری که توسط Mailing list و بایگانی آن حل می شود، از بین رفتن بدگمانی های ناشی از دسیسه های داخلی است زیرا در Mailing list، همه چیز به صورت واضح و آشکار در دسترس همه است و هیچ مسئله ای از دید دیگران مخفی نمی ماند.● اهمیت Spam
با ادامه افزایش Mailهای ناخواسته و درخواست نشده در اینترنت شما نیز نیاز به انجام کارهایی دارید که از وارد شدن Spamها به Mailing listهایتان جلوگیری کند. اگر Spamها کم باشد می توان با کمی تلاش به صورت دستی آنها را از Mailing list حذف کرد اما اگر تعداد Spamها زیاد باشند عملا Mailing list غیر قابل استفاده خواهد شد.
برای مبارزه با Spamها چندین روش وجود دارد:
۱) نصب Filtersهای مربوط به Spam
۲) محدود کردن اجاره ارسال mail به Mailing list فقط برای اعضای شرکت
۳) شخصی مسئول کنترل و جداسازی mailهای بی ارتباط، با موضوع Mailing list باشد
● Website پروژه
علاوه بر Mailing list، پروژه نیاز به یک website دارد که کاربران و توسعه دهندگان بتوانند از طریق آن در مورد پروژه اطلاع کسب کنند و اخبار مربوط به پروژه در آن مشاهده کنند website می تواند شامل موارد زیر باشد:
۱) انتظارات مورد نظر از پروژه
۲) راهنمای کاربران
۳) آموزش
۴) بایگانی مربوط به Mailing listها
۵) سایر مستندات پروژه
همچنین باید در website مکانی برای download آخرین نسخه پروژه وجود داشته باشد (هم Source پروژه و هم ساختار آماده استفاده پروژه یعنی فرم binary پروژه).
● چرخه حیات نرمافزار
پس از فراهم کردن زیربنای مورد نیاز برای توسعه نرم افزارهای متن باز، در این قسمت فعالیتهایی که برای پیشرفت پروژه متن باز نیاز است، می پردازیم:
● تصمیم گیری و برنامه ریزی
تصمیم گیری و برنامه ریزیها باید در Mailing list عمومی و یا جلسه عمومی که همه حضور دارند انجام شوند. تصمیم گیری در یک جلسه عمومی، خیلی زمان گیرتر از تصمیم گیری در یک مجمع خصوصی توسعه دهندگان است، اما تنوع و تعداد زیاد نظرات، تصمیم گیری با کیفیت بهتری انجام خواهد شد. معمولا بحث و گفتگوها درمجامع عمومی به بلندا کشیده می شود بدون اینکه طولانی شدن بحث سودی در بهبود آن داشته باشد. بنابراین در این ساختار باید شخصی وجود داشته باشد که در صورتی که بحث به نتایج مطلوبی رسید آنرا خاتمه دهد و مانع از طولانی شدن بی نتیجه بحث شود، و نتایجی که افراد بر روی آن به تفاهم رسیده اند را استخراج کند. یکی از دلایل رایج شکست پروژه های نرم افزاری این است که به ملاقاتهای موردنیاز پروژه اهمیتی داده نمیشود. برای مثال به ندرت اتفاق می افتد که یک کاربر عادی بتواند در زمان تعریف ساختار پروژه به بحث وارد شود، اما به منظور دستیابی به یک موفقیت واقعی در پروژه های متن باز، ضروری است که یک کاربر عادی، بحث را آغاز کند و پس از آنکه نیازمندی های پروژه به صورت کامل تعریف شد، راه حلهایی برای پیاده سازی آنها تعیین شود و اگر چندین راه حل پیشنهاد شده بود، توسعه دهندگان باید بر اساس تجربه و آزمایش، بهترین را انتخاب کنند. به این ساختار، ساختار مبتنی بر کاربر(User – Centered) گویند، که متن باز برای موفقیت پروژه ها، به شدت این روش را پیشنهاد می کند.
تصمیمات مربوط به طراحی و اصولی که تصمیمات بر اساس آنها اتخاذ شده اند، باید در مستندات طراحی پروژه ثبت شوند، همچنین باید شخصی برای به روز نگه داشتن آنها مشخص شود.
تصمیمات زمان بندی پروژه باید در نقشه مسیر (road map) ثبت شوند. همانطور که گفته شد، توسعه دهندگان و کاربران براساس نقشه مسیر، از تغییرات و زمان اعمال آنها بر روی پروژه اطلاع کسب می کنند. زمان بندی، از ابعاد مختلف برای پروژه های متن باز با ارزش است زیرا بسیاری از افراد پروژه به صورت داوطلب با پروژه همکاری می کنند. توسعه دهندگان داخلی می توانند به یک کار خاص در بازه های زمانی مختلف گماشته شوند اما توسعه دهندگان خارجی انتخاب می کنند که چه کاری می توانند انجام دهند و برنامه ریزی خودشان را بر آن اساس تنظیم می کنند. در مورد نحوه release نرم افزار در ادامه توضیح داده می شود اما ۲ روش در مورد release نرم افزارها مورد توجه است:
۱) برای یک شرکت که پروژه ای را آغاز می کند باید خصیصه هایی که می خواهند در release بعدی قرار داده شوند تعریف شده باشند و زمان بندی تعیین شده باشد سپس ویژگی های پیاده سازی شوند. اما برای پروژه های متن باز این ساختار بر عکس است، ابتدا یک ویژگی پیاده سازی میشود، سپس پس از آنکه تعداد این ویژگی ها زیاد شد، تاریخی برای release بعدی مشخص می گردد.
۲) تنظیم زمان برای release بعدی موجب می شود که افراد پیمانه هایشان را تا آن زمان به پایان برسانند. در این ساختار، نرم افزار در تاریخ تعیین شده برای release، منتشر می شود و پیمانه هایی که آماده باشند در آن قرار می گیرند اما در صورتی که کار پیمانه ای به پایان نرسیده باشد باید تا release بعدی صبر کند.
● Integrating Contribution
در یک پروژه متن باز موفق، تولید بسیاری از خصیصه های جدید و اصلاح اشکالات، توسط توسعه دهندگان همکار انجام می شود. با اینکه همه اشخاص می توانند کد منبع را بخوانند اما فقط تعداد کمی از گروه های توسعه دهنده، اجازه نوشتن مستقیم در کد منبع را دارند. در پروژه هایی مانند Mozilla وLinux، هر پیمانه یک یا چند مالک دارد. مالک پیمانه کسی که حق دارد در کد منبع پیمانه بنویسد یا در آن تغییرات اعمال کند، سایر کسانی که تمایل به این کار داشته باشند باید از مالک پیمانه اجازه کسب کنند. در پروژه ای مانند Apache یک هسته مرکزی از توسعه دهندگان بر روی کل پروژه، مدیریت می کردند که به آنها Committers گفته می شد. هر یک از آنها می توانستند بر روی هر یک از پیمانه های پروژه تغییرات اعمال کنند، هرچند اغلب، انجام تغییرات بزرگ به رای گذاشته می شد. در مورد پروژه های کوچک معمولا یک شخص خاص چنین مدیریتی را انجام می دهد و می تواند اجازه اعمال تغییرات در پروژه را به دیگران بدهد. اگر توسعه دهندگان خارجی یک اشکال را حل و آن را اعلام کنند، وظیفه مالک پیمانه است که آن را بررسی کند و در صورت تایید، آن را در کد منبع پیمانه اعمال کند.
● How Decision Get Made Varies Among Open Source Projects
نقشهای تعیین شده در توسعه نرم افزارهای متن باز عبارتند از:
۱) معماران
۲) طراحان
۳) پیاده سازان (کد نویس)
۴) افراد کنترل کننده کیفیت (تسترها)
۵) مدیرهای release
تعدادی از این نقشها باید در زمان مدیریت و اجرای فرآیند توسعه فعالیت داشته باشند (پیاده سازی، مدیریت، releaseها و کنترل کیفیت)، در حالی که سایر نقشها باید به عنوان نقشهای مورد نیاز، در کلیه مراحل تولید و ایجاد محصول نرم افزار، مورد توجه قرار گیرند) معماران و طراحان. (از دیدگاه توسعه نرم افزار به روش سنتی، نیازمندیها، خصیصه ها، معماری و طراحی باید قبل از پیاده سازی محصول مشخص شده باشند، البته در این ساختار هم یک بازبینی چرخشی در مراحل توسعه نرم افزار انجام می شود.
متن باز ساختار طراحی مجدد را دنبال می کند که حتی علاوه بر طراحی، معماری پروژه هم، حالت سیال دارد و می توانند مطابق با خواست توسعه دهنده تغییر کند. مذاکرات و گفتگوهای مربوط به طراحی ها و معماری های بکار رفته در پروژه باید در بایگانی ها و سایر مستندات جانبی نگهداری شوند. همچنین نیازمندی ها و خصیصه ها هم باید به صورت غیر رسمی در بایگانی و توضیحات کد منبع و خود کد منبع ثبت شوند.
● بازبینی کدها(Code reviews)
مالک پیمانه باید حداقل یک بازبینی غیر رسمی بر روی کدها و اشکالات اصلاح توسط همکاران (کسانی که اجازه ویرایش مستقیم کد منبع را ندارند)، داشته باشد و سپس آنها را اعمال کند. اما چه کسی کدهای مالک پیمانه را کنترل می کند؟ معمولا کلیه کدها مرتبا توسط توسعه دهندگان مختلف مورد بازبینی قرار می گیرند بنابراین اگر کدی وجود داشته باشد که بد نوشته شده باشد، بهینه نباشد، نامرتب باشد یا در آن اشکالی وجود داشته باشد، شخصی وجود خواهد داشت که آن را اصلاح کند یا حتی بازنویسی کند. برخی از پروژه های بزرگ، به صورت رسمی فرآیند بازبینی کدها را، در جریان کارهای خود دارند و هر کدی باید حتما در این فرآیند کنترل شده باشد(مانند پروژه Mozilla)
● تولیدات روزانه(Daily Builds)
یک نیاز ضروری در پروژه های متن باز که به موفقیت آنها کمک می کند، این است که توسعه دهندگان قادر باشند که تغییرات مورد نظرشان را در آخرین نسخه کد منبع ایجاد کنند و آنرا کامپایل کنند و خروجی حاصل از این تغییرات را مشاهده کنند زیرا عدم امکان در انجام این کار موجب می شود که انگیزه برای ادامه کار کاهش یابد. پس ضروری است که شخصی این مسئولیت را برعهده داشته باشد که از سالم بودن محصول تولید شده اطمینان حاصل کند (در محصول تولید شده نباید خطاهای مهلک و بد وجود داشته باشد) و در صورت وجود مشکل جدی، این شخص باید خودش مشکل را حل کند یا آن را به تولید کننده آن پیمانه اطلاع دهد، تا توسط مالک پیمانه رفع شود. در پروژه Mozilla ابزاری با نام tinderbox وجود داشت که دارای ساختاری بود، که بر اساس مکانیسم هایی می توانست از روی کد منبع، محصول را برای Platformهای مختلف تولید کند و گزارشی مبتنی بر وضعیت محصول تولید شده ارائه دهد. بنابراین در هر زمان کاربران می توانستند ازمیزان قابل اطمینان بودن محصول تولید شده اطلاع داشته باشند. این که در هر زمان آخرین محصول تولید شده، به منظور download توسط دیگران به ثبات و پایداری (Stable) رسیده باشد، مسئله مهمی است. سریعترین راه حل این است که آخرین نسخه قابل اجرا از محصول برای download دراختیار کنترل کننده ها(testers) قرار گیرد تا به سرعت مشکلات محصول، پیدا شود.
● تست کردن(Testing)
در واقع هر شخصی که از یک محصول متن باز استفاده می کند، قسمتی از کوشش برای تست آن نرم افزار بشمار می آید. تفاوت زیادی بین تست کردن محصول توسط کاربران با تست کردن آن توسط توسعه دهندگان است. زیرا معمولا توسعه دهندگان محصول را در شرایط خاص و ایزوله، تست می کنند، در حالی که کاربران فارغ از دیدگاه های قبلی و فقط جهت رفع نیازهایشان از نرم افزار استفاده می کنند که همین کار موجب تست آن هم می شود. در برخی از پروژه های متن باز تست رسمی وجود ندارد و همه اشکالها از استفاده های کاربران عادی گزارش می شوند، روش دیگر این است که تست کننده ها به عنوان بخشی از فرآیند release استخدام می شوند. یکی دیگر از روشها این است که عده ای داوطلبانه در تست محصول همکاری می کنند. اما به طور کلی کاربران نهایی و توسعه دهندگان خط اول پیدا کردن اشکالها را تشکیل می دهند. برای مثال در پروژه Mozilla ماهانه ۱۰۰۰ اشکال توسط کاربران گزارش می شد.
● Releases
درهر زمان، اشخاصی تغییرات کد منبع را کنترل می کنند، آن یک release جدید است. این همان معنای releaseهای مداوم در پروژه های متن باز است. برای توسعه دهندگان فعال اطمینان از اینکه بر روی آخرین کد کار میکنند مسئله مهمی است زیرا آنها دوست ندارند که برای حل اشکالهایی وقت بگذارند که قبل از آنها کسی آن را حل کرده باشد. اما برای خیلی از افراد releaseهای مداوم اهمیت کمی دارد. کاربران دوست دارند که به برنامه هایی دسترسی داشته باشند که به پایداری و ثبات رسیده و قابل اطمینان باشد، هر چند که میزان پایداری مطلوب از لحاظ کاربران، مختلف است. برای مثال تعدادی از آنها می خواهند که به آخرین خصیصه ها هم دسترسی داشته باشند در حالی که سایرین می خواهند از محصولی استفاده کنند که واقعا قابل اطمینان و بدون اشکال باشد.
فرآیند release برای پروژه های متن باز کاملا مشابه با پروژههای تجاری است. با این تفاوت که این فرآیند در متن باز راحت تر است. برای مثال اگر کد یک پیمانه جدید نسبتا به پایداری رسیده باشد و قابلیت مفیدی باشد، این امکان وجود دارد که این کد به release جدید اضافه شود، حتی اگر مستندات آن ضعیف باشد یاحتی اصلا وجود نداشته باشد.
وظیفه مدیریت release اغلب این است که در مورد اینکه چه چیزهایی به release جدید اضافه شوند تصمیم گیری کند. بخش مهمی از کار مدیر release این است که فقط به پیمانه هایی اجازه اضافه شدن به release جدید را بدهد که پایدار شده باشند. در یک پروژه متن باز فرآیند توسعه کاملا مشابه با تکرار فرآیند release است. توسعه دهندگان اگر بخواهند که بر روی پیمانه ای کار کنند که در release وجود ندارد، پروژه هایی که از CVS استفاده می کنند شاخه جدیدی برای آنها ایجاد می کنند، که از این طریق می توانند بر روی آن پیمانه جدید، جهت قرار گرفتن در releaseهای بعدی کار کنند. وقتی که بسیاری از اشکالها رفع شد و release به پایداری رسید، روش درست این است که یک نسخه بتا از release بیرون داده شود، زیرا اکثر مردم اعتقاد دارند که نسخه بتا به دلیل اینکه تستهای بیشتری بر روی آن انجام شده است قابل اطمینان تر است و می تواند اشکالهای نسخه قبل را پوشش دهد. در نهایت پس از آنکه آخرین اشکالهای عمده هم حل شدند، release به صورت یک بسته نرم افزاری ارائه می شود. این مهم است که کلیه releaseها با اعداد مشخص شوند تا کاربران بتوانند بر اساس این اعداد ترتیب releaseها را تشخیص دهند. برای مثال در بعضی از پروژه ها از اعداد زوج برای releaseهای پایدار استفاده می شود و از اعداد فرد برای releaseهای تست نشده استفاده می شود. مثلا آخرین نسخه پایدار لینوکس در اکتبر سال ۲۰۰۲ نسخه ۲.۴.۱۹ بود در حالی که نسخه توسعه آن ۲.۵.۴۴ بود و نسخه پایدار کرنل بعدی ۲.۴.۲۰ بود. شرکت RedHat نسخه های release لینوکس خود را در اختیار همه قرار می دهد در حالی که نسخه های پایدار شده را تنها در اختیار کسانی می گذارد که هزینه خریداری آنها را پرداخت کنند.
● Support
مجوزهای مختلف متن باز به صورت روشن بیان می کنند که نرم افزارهای متن باز به هیچ وجه پشتیبانی ندارند. این یک بحث کلی است، اما در واقع شرکتهایی مانند RedHat پول خوبی برای این موضوع دریافت میکنند. در حقیقت پروژه های خیلی بزرگ توسط کاربران و توسعه دهندگانی که بر روی آن کار می کنند پشتیبانی می شوند. در پروژه های متن باز موفق، مردم می توانند از طریق Mailing list اصلی مشکلاتشان را سوال کنند و به سرعت جواب دریافت کنند.
● افزودن پیمانه جدید یا زیر پروژه
یکی از روشهایی که توسعه دهندگان می توانند پروژه ها را پیش ببرند، کار کردن بر روی یک پیمانه جدید به صورت توزیع شده است. این کار می تواند به صورت کلی قابلیتهای جدیدی را به نرم افزار اضافه کند اما همه پیشنهادها برای پیمانه های جدید موفق نیستند زیرا برخی فقط برای گروه خاصی کاربرد دارند و برخی قابل پیاده سازی نیستند. اما در مورد اضافه شدن پیمانه های جدید باید فرآیند پذیرش انعطاف پذیری وجود داشته باشد. بعضی از پروژه ها یک محیط آزمایشی دارند که هر کس می تواند به راحتی یک زیر پروژه برای توسعه یک پیمانه جدید ایجاد کنند. این قابلیت به توسعه دهندگان امکان می دهد که ایده های جدید خودشان را تست کنند. به طور کلی توسعه یک پیمانه جدید، شامل همه مراحل release مربوط به یک پروژه رسمی نمی باشد. به طور کلی توسعه دهندگان می توانند یک نسخه آزمایشی برای پیمانه جدید ایجاد کنند که شامل خصوصیات آن پیمانه جدید باشد و برای download و اجرا در اختیار هر کاربری که خواستار آن باشد قرار دهند. وقتی که مجمع، تصمیم به ایجاد یک پیمانه جدید می گیرد مهم است که مسائلی ازقبیل تعیین وظایف افراد، زمان خروج پیمانه از محیط آزمایشی و اضافه شدن آن به عنوان بخشی از پروژه اصلی تعیین شود این کار به مهارتهای زیادی نیاز دارد زیرا ساختار مورد نیاز برای یک محیط آزمایشی کامل، از یک ساختار رسمی متفاوت است. زیرا در محیط آزمایشی هدف تشخیص این مسئله است که این پیمانه، مفید وکاربردی است یا نه.

نویسندگان: سیما زمانی، رامین شکری پور
ویرایش: بهروز عبادی

منبع : آژانس خبری فناوری اطلاعات و ارتباطات ایستنا