معیارهای اساسی در انتخاب انواع oss

معیارهای اساسی در انتخاب  انواع oss

● قابلیت‌های پروژه
درک مشخصه‌های یک پروژه‌ کدباز معمولا ساده است. در اغلب موارد، تیم‌های پروژه آن دسته از مشخصه‌هایی که وجود دارند و آن گروه که موجود نیستند را آشکارا از یکدیگر متمایز می‌سازند. ادعاهای اغراق‌آمیز به سادگی قابل تشخیص هستند و تنها به پرسش‌های پشتیبانی منجر می‌گردند. بنابراین تیم‌های پروژه OSS معمولا در مورد چیزهایی که به درستی کار می‌کنند و مواردی که کار نمی‌کنند در خط مقدم قرار دارند. آنها همچنین خواهان همکاری افراد برای افزودن یا بهبود بخشیدن مشخصه‌هایی که در حال حاضر تحت گسترش قرار دارند، هستند. لیست پستی یا mail list کاربران مکان بسیار خوبی برای یافتن اطلاعات در مورد نحوه‌ی استفاده سایر افراد از نرم‌افزار است. اگر شما در یک تابلوی پیام (message board) یا لیست کاربر به دنبال یک توصیه هستید، حتما در مورد اندازه و حوزه نیازمندی‌هایتان به سایرین توضیح دهید.
در هر صورت، مهم‌تر از مشخصه‌های پروژه، یافتن پروژه‌ای است که سعی در حل نمودن همان مشکل شما دارد. پروژه‌ها در طی زمان رشد می‌نمایند، درست مانند محصولات. شما خواهان انتخاب پروژه‌ای هستید که در جهاتی مشابه با نیازهای فعلی و آینده‌ی شما رشد کند.

 بسیاری از تیم‌های پروژه دارای راهکاری هستند که مشخصه‌هایی را که برای عرضه‌های آینده در نظر گرفته شده‌اند طرح‌ریزی می‌نماید. راهکارها جهت یک پروژه را به خوبی مشخص می‌نمایند، اما در مورد زمان‌بندی آن لزوما این گونه نیست. شما همچنین باید در لیست‌های پستی به دنبال آن نوع از پیشنهاداتی که مورد موافقت قرار گرفته و رد شده‌اند باشید. مباحثات تیم توسعه در مورد بسط‌های پیشنهادی یک روش عالی برای درک سمت و سوی یک پروژه است. اگر مشخصه‌های یک پروژه OSS پاسخگوی نیازهای شما نباشد، میزان تلاش لازم برای پیشرفت یا بسط پروژه به منظور پوشش دادن نیازهای‌تان را مد نظر قرار دهید. اما اطمینان حاصل نمایید که توسعه‌های شما همسو با جهت پروژه باشند. استفاده از نرم‌افزار به شکلی متفاوت از اغلب کاربران دیگر می‌تواند به معنی مشکلات سازگاری در آینده باشد.
● یکپارچگی
شرکت‌های نرم‌افزاری غالبا نرم‌افزارهای واسطی (third-party) که با نرم‌افزارهای خودشان یکپارچه می‌گردند را لیست می‌کنند. همچنین، بسیاری از پروژه‌های OSS به خوبی با سایر نرم‌افزارهای OSS و تجاری یکپارچه می‌گردند. یک شاخص خوب برای تعیین این که چگونه یک پروژه OSS می‌تواند با سایر نرم‌افزارها یکپارچه گردد، یافتن پروژه‌های دیگری است که تا به حال با آن یکپارچه گردیده‌اند. شما همچنین باید به وابستگی‌های پروژه دقت کنید. ممکن است وابستگی‌ها مستند شده باشند یا ممکن است برای یافتن آنها نیازمند تحقیق بر روی اسکریپت‌های ساخت باشید. یک پروژه که سایر پروژه‌ها را به خوبی مورد استفاده قرار می‌دهد احتمالا با در نظر گرفتن استفاده مجدد و یکپارچگی، معماری شده است.
● تعویض‌پذیری
یک مزیت عمده‌ی OSS کاهش محدودیت فروشنده است. همچنان که پروژه‌های OSS را مورد بررسی قرار می‌دهید، میزان محدودیتی را که آنها به وجود می‌آورند مد نظر قرار دهید. به دنبال پروژه‌هایی باشید که استانداردهای صنعتی را همانند نرم‌افزار تجاری پیاده‌سازی می‌کنند. اطمینان یابید که داده‌ها به شیوه‌های دسترس‌پذیر ذخیره و مبادله شوند، و از زبان‌های برنامه‌نویسی منحصر به فرد اجتناب نمایید. اگر شما تعویض‌پذیری را نادیده بگیرید، یکی از مزایای اصلی استفاده از OSS را از دست داده‌اید.
● تیم پروژه
تیم‌های پروژه‌ی OSS می‌توانند محدوده‌ای شامل یک توسعه‌گر واحد تا یک گروه گسترده از اعضای یک تیم توسعه را در بر گیرند. شما باید اندازه، ساختار و انگیزه‌ی گروه توسعه را درک نمایید. چه در مورد نرم‌افزارهای کدباز و چه در مورد نرم‌افزارهای تجاری، قدرت و دید تیم توسعه از اهمیت بسیار بالایی برخوردار است. اما در مورد نر‌م‌افزارهای تجاری، تیم توسعه پنهان است. شما باید به اعتبار شرکت و وعده آنها مبنی بر تداوم یافتن پیشرفت نرم‌افزار تکیه کنید. در مورد کدباز، شما می‌توانید در تیم توسعه نرم‌افزار پیشروی عمیق‌تری نمایید. با بررسی لیست پستی توسعه‌دهندگان پروژه و log های تغییر سورس کد، شما می‌توانید اندازه، وسعت و فرهنگ گروه توسعه را شناسایی نمایید. یک پروژه‌ی قوی نباید بیش از حد به شخص خاصی متکی باشد. اما تیمی که بیش از حد بزرگ یا زودگذر است نمی‌تواند دارای کانون منسجمی باشد.
● فرایند توسعه
نکته دیگری که باید مورد توجه قرار گیرد چگونگی به اجرا در آمدن فرایند توسعه است. به دنبال بهترین شیوه‌ها از قبیل تست یونیت و سبک کدنویسی سازگار باشید. پروژه باید دارای رویه‌های ساخت خوب-مستندسازی‌شده باشد. شما باید اطمینان حاصل نمایید که توانایی ساختن نرم‌افزار و در صورت یافتن یک خطا یا نیاز به یک بسط، توانایی ایجاد تغییر را دارید. بهترین معیار برای ارزیابی یک پروژه مقایسه آن با فرایندهای توسعه در سازمان خودتان است. آیا در سازمان شما کد یک مرحله بازبینی را پشت سر می‌گذارد؟
شما همچنین باید این امر را مد نظر قرار دهید که به چه سادگی می‌توانید همکاری خود با تیم پروژه را عملی نمایید. آیا آنها به سهولت ورودی و patch ها را می‌پذیرند؟ چه مقدار شفافیت در فرایند توسعه وجود دارد؟ شما می‌توانید با این افراد همکاری داشته باشید؟
مدیریت عرضه یک هنر دشوار است. فرایند توسعه‌ا‌ی که به خوبی اجرا شده، شامل شیوه‌های مدیریت عرضه سازگار است.
به تاریخچه عرضه تیم پروژه یا مخزن سورس کد نگاه کنید. آیا عرضه‌ها بیش از حد معمول یا کمتر از حد کافی هستند؟ آیا توضیحات عرضه به میزان کافی مفصل هستند تا به شما در مورد چگونگی و زمان ارتقا یاری رسانند؟ آیا تیم پروژه، سازگاری با موارد قدیمی‌تر را در هنگام ایجاد تغییرات مد نظر قرار داده‌اند؟