در سال های اخیر استفاده از نرم افزارهای Open Source در سراسر جهان افزایش چشمگیری داشته است. در این مقاله روند کلی استفاده از این نرم افزار ها را بررسی می کنیم.

مقدمه:

تحلیل گران نرم افزار سال 2005 را به عنوان سال نرم افزار های Open Source اعلام کردند.استفاده ی گسترده از این نرم افزارها ، توجه رسانه ها را به آن ها جلب کرده است. بسیاری از شرکت های مشاوره ی نرم افزاری ، به تازگی حمایت از پروژه های Open Source را شروع کرده اند. از نرم افزار های Open Source  می توان هم به عنوان یک ابزار جانبی می توان استفاده کرد(مثل Eclipse IDE, gcc,.. ) و هم به عنوان یک جز اصلی در پروژه از آن ها بهره برد. (مثلTomcat, Spring Framework, Apache HTTP,… )

 اغلب افراد، بدون توجه به مسائل جانبی  از این نوع نرم افزار ها استفاده می کنند چرا که در نگاه اول نرم افزارهای  Open    Sourceمزایای زیادی دارند، از جمله این که به برنامه نویس ،حق انتخاب بیشتری می دهند، دانش و آگاهی بین برنامه نویسان را افزایش می دهند و همچنین شجاعت برنامه نویسی را در بین افراد جامعه بالا می برند.

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

ارائه ی یک تعریف جامع برای نرم افزار های Open Source

ابتدا یک گام به عقب بر میگردیم و تعریف نرم افزار Open Source را بررسی می کنیم. یک تعریف رایج در بین کاربران به این صورت است: "هر گونه نرم افزاری که به صورت آزادانه و رایگان و با Source Code  قابل ویرایش، در دسترس عموم کاربران  قرار گرفته است،یک نرم افزار Open Sourceمحسوب می شود. "

سازمان OSI یک تعریف رسمی تر و دقیق تر از نرم افزار های Open Source در وب سایت خودش قرار داده است. OSI در این تعریف ، از ده معیار استفاده می کند که تعدادی از آن ها عبارتند از : توانایی توزیع آزادانه ی نرم افزار ، دسترسی به  Source Code های برنامه برای همه و امکان پیاده سازی قابلیت های جدید بر روی نسخه ی قبلی نرم افزار .

همچنین سازمان OSI  مجوز های مربوط به این نوع نرم افزار ها را بررسی و تایید می کند تا صحت مطابقت  این مجوز ها با استاندارد های این سازمان تائید شود.  تا به حال ، 58 مجوز مختلف توسطOSI تایید شدند مثل : (GPL)، مجوز  Apache 2.0 و مجوز موزیلا (MPL 1.1) .

با این حال برخی مجوز ها وجود دارند که از همه معیار های موردنظر OSI پیروی نمی کنند.

ارتباط با کادر مدیریت پروژه

معمولا کادر مدیریت پروژه در مورد استفاده از نرم افزارهای Open Source دو نوع تفکر دارند:

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

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

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

در شرایط دوم ممکن است مفهوم نرم افزار Open Source برای مدیریت مبهم به نظر برسد . در دسترس بودن Source Code  برنامه برای همه افراد ،ممکن است از نظر کادر مدیریت یک ریسک محسوب بشود. همچنین چون نمی شود هزینه ی کلی پروژه را تخمین زد، نگرانی های مالی هم وجود دارد.

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

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

صدور مجوز

برای بررسی این بحث ، فرض می کنیم که یک برنامه نویس در حال توسعه ی یک برنامه ی تجاری است و از تجهیزاتی استفاده می کند که بر اساس مجوز Apache منتشر شده اند و همچنین از چند نرم افزار Open Source هم برای کار خودش کمک می گیرد. در ادامه به سوالاتی که ممکن است در ذهن شما پیش بیایند جواب می دهیم .

-اگر لازم باشد در پروژه ام از نرم افزار Mozilla استفاده کنم، چه مواردی را باید در هنگام انتشار محصولم در نظر بگیرم ؟

-آیا می توانم فقط بخشی از محصولات مجوز Apache را استفاده کنم ؟

- اگر من از محصولات GNU استفاده کنم (که تحت مجوز GNU GPL عرضه شده اند) ، آیا من هم باید نرم افزارم را بر اساس مجوز GPL  منتشر کنم ؟

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

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

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

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

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

همچنین ممکن است با "مجوزدهی دوگانه"   مواجه شوید . یک نمونه از این موضوع ، پایگاه داده  MySQL است که تحت دو مجوز منتشر شده است، که فقط یکی از آنها مطابق با استانداردهای OSIاست.

مدیریت پروژه

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

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

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

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

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

حمایت و پشتیبانی

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

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

باید ها و نباید ها در دنیای نرم افزار های Open Source

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

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

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

نتیجه گیری پایانی

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

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