ابزارهای تست

ابزار تست متن‌باز یا تجاری؛ از License تا TCO و Exit

انتشار در تاریخ توسط محمد عسکری

سه گزینه فرضی برای یک پلتفرم تست داشتیم: Arvand متن‌باز با License صفر، Baran تجاری با ۱۴۴ هزار واحد هزینه License سه‌ساله و Caspian Open-core با Core رایگان. انتخاب بر اساس قیمت License، Arvand و Caspian را برنده می‌کرد؛ اما Caspian در دسترسی تجاری یک Hard gate را رد کرد و الزام پاسخ Sev‑۱، TCO Arvand را از Baran بالاتر برد. وقتی ظرفیت پشتیبانی داخلی را واقعاً موجود فرض کردیم، برنده دوباره Arvand شد.

ابزار تست متن‌باز یا تجاری یک دوگانهٔ «رایگان و منعطف» در برابر «گران و آسان» نیست. باید License و حق استفاده را از قیمت، Source availability را از Forkability، Community را از Support capacity، Transparency را از Security assurance و SLA را از Outcome واقعی جدا کرد.

این راهنما مشاوره حقوقی نیست و محصولی را رتبه‌بندی نمی‌کند. License، Terms، Export control، Plan، قیمت، مالکیت پروژه و دسترسی تجاری تغییر می‌کنند. Legal/Procurement/Security باید نسخه دقیق Artifact، License expression، Contract و شرایط روز را بررسی کنند.

پاسخ کوتاه: متن‌باز بهتر است یا تجاری؟

هیچ‌کدام ذاتاً بهتر نیست. متن‌باز زمانی قوی است که License با Use شما سازگار باشد، پروژه قابل ساخت و نگهداشت باشد، تیم ظرفیت عملیاتی/امنیتی داشته باشد و Fork/Exit واقعی ارزش ایجاد کند. تجاری زمانی قوی است که Supplier قابل‌اعتماد، SLA/Support آزموده، TCO پذیرفتنی، Contract و Exit روشن و دسترسی پایدار داشته باشد.

Open-core، Dual-license، Managed OSS و Commercial support مرز را ترکیبی می‌کنند. Decision را روی «Offering دقیق» بگیرید، نه Brand یا Repository اصلی.

Open Source فقط دیدن Source code نیست

تعریف Open Source در OSI فقط دسترسی به کد را کافی نمی‌داند و معیارهایی مانند Free redistribution، Source code، Derived works و Technology neutrality دارد. بنابراین این برچسب‌ها را جدا کنید:

مدل آنچه می‌گیرید پرسش کلیدی
OSS Source تحت License متن‌باز Obligation و Maintainer capacity چیست؟
Source-available Source قابل مشاهده با محدودیت استفاده/توزیع آیا برای Use ما مجاز است؟
Open-core Core باز، قابلیت‌های خاص تجاری Feature بحرانی در کدام Tier است؟
Dual-license یک Codebase با Licenseهای جایگزین کدام License برای Distribution/SaaS مناسب است؟
Managed OSS OSS به‌صورت Service Data/Region/SLA/Exit چه می‌شود؟
Commercial proprietary حق استفاده قراردادی بدون Source عمومی Control، Evidence و Exit کافی است؟

«رایگان»، «Community edition»، «Freemium» و «Open API» مترادف Open Source نیستند. نام License و متن نسخه همان Release را بخواهید.

مرز این مقاله با راهنماهای دیگر

راهنمای خرید ابزار مدیریت تست مالک Problem brief، Hard gate، PoC، TCO، Contract و Exit عمومی است. انتخاب فریم‌ورک اتوماسیون Architecture و Build-versus-adopt را پوشش می‌دهد. مقاله حاضر فقط مالک ریسک و ارزش مدل مالکیت/License/Support است.

برای Qualification تخصصی، از انتخاب ابزار اتوماسیون تست، راهنمای ابزارهای تست امنیت، ارزیابی Codeless Test Automation یا انتخاب ابزار تست عملکرد استفاده کنید. مدل تجاری نباید Protocol/Oracle/CI نامناسب را جبران کند.

Offering Map را قبل از مقایسه بسازید

برای هر Candidate دقیقاً ثبت کنید:

  • Repository/package/image و Version؛
  • License هر Component/Plugin/SDK/Agent؛
  • Community، Enterprise و Cloud feature boundary؛
  • Support source: Community، Vendor، Partner یا تیم داخلی؛
  • Hosting: Self-managed، Vendor SaaS یا Partner؛
  • Data/control plane و Telemetry destination؛
  • Upgrade/security release channel؛
  • Export/API/backup و Fork path؛
  • Commercial entity و Contract party؛
  • Region/payment/support/download availability.

یک Brand ممکن است هم OSS library، هم Enterprise server و هم Cloud service داشته باشد. نسبت‌دادن License Core به کل Offering یک خطای جدی است.

Hard Gateها را قبل از امتیازدهی تعیین کنید

  • License/Terms برای Use، Modification، Distribution و Deployment پذیرفتنی؛
  • قابلیت‌های بحرانی در Edition قابل‌دسترس؛
  • Commercial/legal/technical access پایدار برای سازمان؛
  • Patch/vulnerability response متناسب Risk؛
  • Artifact provenance/signature/hash قابل Verify؛
  • Runtime/OS/Browser/Protocol compatibility؛
  • Backup/restore و machine-readable export؛
  • Build/upgrade/operate capacity داخل یا قراردادی؛
  • Data/Privacy/Region/Secret controls؛
  • TCO و Deadline زیر سقف؛
  • Fork/escrow/exit متناسب Criticality؛
  • Contract/SLA/indemnity یا Risk acceptance لازم.

License را با نام و Expression دقیق ثبت کنید

فهرست Licenseهای SPDX شناسه استاندارد، متن و URL canonical ارائه می‌کند و Expressionهایی مانند AND، OR و WITH را پشتیبانی می‌کند. در Inventory به‌جای «GPL-ish» یا «free» بنویسید: Package/version، SPDX expression، source، copyright notice و approved use.

سؤال‌های Legal review

  • Internal use، SaaS، Distribution یا ارائه Appliance؟
  • کد را Modify و به مشتری تحویل می‌دهیم؟
  • Link/plugin/IPC boundaries چه هستند؟
  • Notice، attribution یا Source-offer لازم است؟
  • Copyleft و Network copyleft در این معماری چه اثری دارد؟
  • Patent grant/termination، trademark و data/model license چیست؟
  • Dependency، font، icon، docs و test dataset License جدا دارند؟
  • Commercial exception یا Dual-license دقیقاً چه حقی می‌دهد؟

این پرسش‌ها پاسخ عمومی ندارند؛ Counsel باید متن License و معماری استفاده را با هم ببیند. OpenChain ISO/IEC 5230 یک چارچوب فرایندی برای برنامه Compliance متن‌باز ارائه می‌کند؛ داشتن Spreadsheet بدون Owner/Policy/Training/Review کافی نیست.

Source availability را با Forkability اشتباه نگیرید

Fork واقعی به این‌ها نیاز دارد:

  • Source کامل همان Artifact؛
  • Build instructions و Dependencyهای در دسترس؛
  • Test suite و reproducible-enough build؛
  • CI/CD، signing key transition و release process؛
  • Schema migration و backward compatibility؛
  • Plugin/connector ecosystem؛
  • Trademark/name/domain boundary؛
  • Maintainer skill و بودجه؛
  • Security advisory/patch process؛
  • Community/Contributor انتقال‌پذیر.

اگر فقط Source را Clone می‌کنید اما Build نمی‌شود، Test ندارد یا تیم نمی‌تواند Release امن بسازد، Fork یک Option کاغذی است. در PoC یک Version pin‌شده را از Source بسازید و Patch کوچک را تا Artifact امضاشده ببرید.

سلامت پروژه OSS را چندبعدی بسنجید

بعد Evidence ریسک
Governance Maintainer/decision/release policy کنترل فردی و succession نامعلوم
Maintenance Release cadence، issue/PR response، roadmap انباشت و abandonment
Security SECURITY.md، disclosure، advisory، patch time Known vuln بدون مسیر پاسخ
Build integrity signed artifact، provenance، protected release Artifact با Source نامعلوم
Quality tests، CI، compatibility matrix، regression Upgrade غیرقابل پیش‌بینی
Ecosystem plugin/dependency health و official boundary Supply-chain tier پنهان
Sustainability maintainer diversity، funding، sponsor/employer mix Bus/funding factor
Usability docs، migration، support forum، examples هزینه داخلی بالا

Star، Download، Contributor count و آخرین Commit فقط Signal هستند. Project بالغ ممکن است کم‌Commit باشد؛ Repository پرCommit ممکن است یک Maintainer و Release ناامن داشته باشد. Trend و Context را با Criticality خودتان بخوانید.

Score امنیتی Verdict نهایی نیست

OpenSSF Scorecard Checkهای خودکار برای Practiceهای پرریسک Repository ارائه می‌کند. نتیجه را در سطح Check ببینید، نه فقط Aggregate score؛ False positive، Hosting limitation، Context پروژه و تاریخ Scan را ثبت کنید.

OpenSSF Best Practices Badge نیز Self-certification مبتنی بر معیارهاست. Badge یا Score نبودن لزوماً Reject نیست و وجودش تضمین نبود Vulnerability نیست؛ این‌ها Evidence ورودی‌اند که باید با Review، PoC و Risk acceptance ترکیب شوند.

Supplier تجاری را هم مانند Dependency ارزیابی کنید

Source بسته، مسئولیت Due diligence را حذف نمی‌کند. NIST SP 1326 برای ارزیابی Supplier روی Provenance، Resilience، cyber practices، ownership/control و supply-chain tiers تأکید دارد. سؤال‌ها:

  • چه Entity قرارداد/SLA را پاسخ می‌دهد؟
  • Secure development و vulnerability disclosure چگونه است؟
  • Component/SBOM و patch notice ارائه می‌شود؟
  • Artifact/signature/provenance چگونه Verify می‌شود؟
  • Support escalation و Sev-۱ response در Practice چگونه است؟
  • BCP/DR، data backup و RTO/RPO چیست؟
  • Subprocessor/Cloud/Marketplace tierها کدام‌اند؟
  • Acquisition/EOL/price change چه Protectionی دارد؟
  • API/export/deprecation و exit assistance چیست؟
  • Audit evidence تحت NDA یا Tenant test قابل دریافت است؟

SBOM باید Artifact دقیق را توصیف کند

Repository اصلی فقط بخشی از Supply chain است. Binary/container ممکن است Dependency، Agent، Plugin و Library بیشتری داشته باشد. حداقل عناصر SBOM در CISA برای شفافیت Component یک Baseline رسمی می‌دهد؛ در PoC این موارد را Verify کنید:

  • Supplier/component/version و unique identifier؛
  • Dependency relationship؛
  • Author/timestamp SBOM؛
  • فرمت machine-readable و update cadence؛
  • تطابق با Artifact digest؛
  • پوشش transitive/plugin/container/agent؛
  • License field و unknown component؛
  • قابلیت diff میان Releaseها.

SBOM بدون Version/digest یا SBOM قدیمی برای Release دیگر، حس شفافیت کاذب می‌دهد. Completeness و Freshness را Sample کنید.

Source و Binary را با Provenance وصل کنید

Hash نشان می‌دهد Artifact تغییر نکرده، اما نمی‌گوید از Source موردانتظار و Build مورداعتماد آمده است. SLSA Provenance اطلاعات قابل‌راستی‌آزمایی درباره اینکه Artifact کجا، چه زمان و چگونه ساخته شده تعریف می‌کند.

تمرین Artifact verification

  1. Release را از Channel رسمی دریافت کنید.
  2. Digest/signature و identity را Verify کنید.
  3. Provenance subject digest را با Artifact Match کنید.
  4. Source revision و build parameters را با Policy بسنجید.
  5. SBOM را به همان Digest پیوند دهید.
  6. نتیجه Verification را در Admission/CI ثبت کنید.

برای محصول تجاری ممکن است جزئیات متفاوت یا تحت NDA باشد؛ Requirement را Risk-based در Contract بنویسید. برای OSS نیز Release از Mirror ناشناس را فقط به‌خاطر عمومی‌بودن Source معتبر ندانید.

امنیت را به تعداد CVE تقلیل ندهید

NIST SSDF Practiceها را در Prepare، Protect، Produce و Respond گروه‌بندی می‌کند. در Tool selection، مهم است پروژه/فروشنده چگونه جلوگیری، کشف، انتشار Advisory، Patch، Backport و اطلاع‌رسانی می‌کند.

OSV API Query آسیب‌پذیری بر اساس Package/version یا Commit را ممکن می‌کند. Scanner فقط Known vulnerability و Data source موجود را می‌بیند؛ این‌ها را هم بسنجید:

  • Exploitability و Reachability در Deployment شما؛
  • Fix availability و compatibility؛
  • Time-to-triage و Time-to-patch؛
  • Unsupported/EOL version؛
  • Plugin/transitive dependency؛
  • Compensating control و expiry؛
  • Advisory completeness و withdrawn/corrected record؛
  • Residual risk owner.

شفافیت Source به Review کمک می‌کند، نه اینکه Review خودکار انجام شده باشد. فروشنده تجاری نیز به‌خاطر Contract خودکار امن نیست.

Support را با Ticket واقعی تست کنید

SLA روی کاغذ با Resolution متفاوت است. در Trial/PoC، سه Case بفرستید:

  1. سؤال Documentation/Setup؛
  2. Bug قابل‌بازتولید با Severity متوسط؛
  3. سناریوی فرضی Sev-۱ و Escalation path.

Time-to-ack، کیفیت Triage، درخواست Evidence، handoff، timezone/language، workaround، Root-cause/report و Closure را ثبت کنید. Community را نیز با Issue/Discussion واقعی بسنجید، اما Maintainer داوطلب را با SLA خریداری‌شده مقایسه اخلاقی نکنید؛ اگر SLA لازم است، Support partner یا ظرفیت داخلی را بودجه دهید.

Capacity داخلی را با نام افراد اثبات کنید

«تیم ما نگه می‌دارد» باید به Capacity plan تبدیل شود:

  • Owner و Backup؛
  • ساعت ماهانه Admin/Upgrade/Security؛
  • Language/runtime/build skill؛
  • On-call و Severity response؛
  • Release/patch signing authority؛
  • Test environment و compatibility lab؛
  • Funding horizon و succession؛
  • Contribute upstream policy.

Capacity مشترک Platform team را دوبار به چند پروژه تخصیص ندهید. Opportunity cost ساعات مهندس صفر نیست، حتی اگر Invoice License ندارید.

TCO سه‌ساله را با Assumptionهای قابل‌تغییر بسازید

TCO = license + required add-ons + paid support
    + infrastructure/cloud/network/storage
    + administration and on-call
    + upgrade/security remediation
    + training/hiring
    + integration/customization
    + compliance/evidence
    + downtime/risk reserve
    + migration and exit

هزینه License فقط یک Term است. از سوی دیگر، برای گران نشان‌دادن OSS ساعت‌های فرضی نامحدود نسازید. Baseline را از Pilot و Timesheet سبک بگیرید و Range خوش‌بینانه/محتمل/بدبینانه گزارش کنید.

آزمایش اجرایی تصمیم OSS/Commercial/Open-core

یک مدل قطعی Node.js ۲۴.۱۸.۰ با سه گزینه کاملاً فرضی ساختیم. Rate نیروی فنی ۳۵ واحد/ساعت و افق سه سال است. Arvand OSS برای Gate پاسخ Sev-۱، Support سالانه ۲۰,۰۰۰ می‌خرد؛ Baran Commercial License سالانه ۴۸,۰۰۰ دارد؛ Caspian Open-core برای Parallel runner به Add-on سالانه ۳۰,۰۰۰ نیاز دارد اما دسترسی تجاری آن Verify نشده است.

function tco(o, internalSupport = false) {
  return 3 * (o.licenseAnnual + o.requiredAddonAnnual)
    + 3 * (internalSupport && o.model === "OSS" ? 0 : o.supportAnnual)
    + 3 * o.infraAnnual
    + 36 * o.adminHoursMonth * 35
    + 3 * o.upgradeEventsYear * o.upgradeHoursEvent * 35
    + 3 * o.securityHoursYear * 35
    + o.training + o.integration + o.exit
}

const eligible = options
  .filter(o => Object.values(o.gates).every(Boolean))
  .sort((a, b) => tco(a) - tco(b))

خروجی واقعی

Arvand model=OSS core_license_3y=0 required_addon_3y=0 gate=pass tco=265050
Baran model=Commercial core_license_3y=144000 required_addon_3y=0 gate=pass tco=212270
Caspian model=OpenCore core_license_3y=0 required_addon_3y=90000 gate=fail(commercial_access) tco=213300
naive_zero_core_license=Arvand|Caspian
eligible_rank=Baran>Arvand
decision=Baran
sensitivity_internal_oss_support=Arvand:205050>Baran:212270

تفسیر و محدودیت

در Base case، Baran با وجود License بالا TCO کمتری دارد. اما اگر ظرفیت Support داخلی واقعاً تأمین‌شده باشد، هزینه Arvand به ۲۰۵,۰۵۰ می‌رسد و برنده عوض می‌شود. Caspian با Core رایگان به‌دلیل Add-on ضروری و Gate دسترسی، نه رایگان است و نه Eligible.

این عددها Quote بازار، Prediction یا توصیه محصول نیستند؛ Salary، Support، Risk و Integration فرضی‌اند. ارزش آزمایش در نشان‌دادن Gate→TCO→Sensitivity است. Assumptionها را با Evidence خودتان جایگزین کنید.

PoC را روی Upgrade و Failure اجرا کنید، نه فقط Install

  1. Version/Offering/License/SBOM را Freeze کنید.
  2. Use caseهای بحرانی را با Data و CI واقعی اجرا کنید.
  3. Artifact/signature/provenance را Verify کنید.
  4. Source build یا Vendor installation را از صفر تکرار کنید.
  5. یک Minor و یک Major upgrade را Rehearse کنید.
  6. Plugin/dependency ناسازگار را Triage کنید.
  7. یک Known-vulnerability drill و Patch/rollback انجام دهید.
  8. Community/Partner/Vendor ticket واقعی بفرستید.
  9. Backup/restore و disaster node replacement را اجرا کنید.
  10. Maintainer/Vendor unavailable scenario را Tabletop کنید.
  11. Fork/build یا Escrow/exit path را Sample کنید.
  12. Full data/config/history export را Reconcile کنید.
  13. Admin/support hours و cloud usage را اندازه بگیرید.
  14. Score، Confidence، Sensitivity و Residual risk را ثبت کنید.

رویکرد Hybrid را Architecture کنید، نه اینکه ابزار جمع کنید

Hybrid می‌تواند OSS runner + Commercial dashboard، OSS core + Paid support، Proprietary authoring + Open export یا چند ابزار تخصصی باشد. برای هر Boundary مشخص کنید:

  • System of Record و Owner؛
  • API/schema/version؛
  • Identity/Secret/Data flow؛
  • Support handoff؛
  • Failure/Retry/idempotency؛
  • License/Contract هر Connector؛
  • Upgrade order و compatibility؛
  • Exit dependency.

«بهترین هر دو جهان» بدون Integration ownership می‌تواند بدترین هر دو هزینه را بسازد.

برای ایران، OSS مصونیت خودکار از محدودیت نیست

Repository عمومی ممکن است در دسترس باشد، اما Package registry، Container image، Release CDN، Cloud API، Plugin marketplace، Update server، telemetry endpoint یا Sponsor support ممکن است محدود یا ناپایدار باشد. Mirror داخلی، checksum/signature verification، Dependency cache و Reproducible build را با مجوز و Policy طراحی کنید.

برای Commercial/Open-core، Terms، Export control، Account country، payment/invoice، activation، renewal، support، region، data transfer و exit را Legal/Procurement روزآمد Verify کنند. راهنمای ابزارهای جایگزین برای محدودیت دسترسی برای Shortlist عملی مفید است؛ دورزدن Terms یا Control را Architecture پایدار فرض نکنید.

مالکیت فکری را از License compliance جدا نکنید

کد سفارشی، Test script، Plugin، Model، Screenshot، Dataset و Contribution ممکن است Owner/License متفاوت داشته باشند. CLA/DCO، Employee/contractor IP، trademark و حق انتشار Test artifact را بررسی کنید. برای جزئیات بیشتر به راهنمای مالکیت فکری ابزارهای تست متن‌باز رجوع کنید.

Contribution upstream می‌تواند هزینه Fork را کم کند، اما نیازمند Review امنیتی، عدم افشای اطلاعات، IP approval و Maintainer interaction است. Patch خصوصی بلندمدت Upgrade burden می‌سازد.

Scorecard تصمیم مالکیت ابزار

پس از Hard gate، Weightها را پیش از دیدن نتیجه Freeze کنید:

محور وزن Evidence
Technical/Use-case fit ۱۵ PoC و failure path
License/Legal fit ۱۲ Versioned review و obligations
Security/Supply chain ۱۵ SBOM، provenance، practice، patch drill
Maintenance/Upgrade ۱۰ Rehearsal، release policy، capacity
Support/Resilience ۱۰ Ticket، escalation، unavailable scenario
Integration/Ecosystem ۸ API/plugin/CI compatibility
Iran access/operations ۸ Account/download/update/network verification
TCO ۱۰ سه‌سال Base/range/sensitivity
Fork/Exit/Portability ۷ Build/export/restore/replay
Usability/Adoption ۵ Buyer-operated author/reviewer/admin exercise

Rubric صفر تا پنج

  • ۰: Gate شکست‌خورده یا حق/قابلیت ناموجود؛
  • ۱: ادعا، badge، marketing یا امید بدون Evidence؛
  • ۲: Happy path محدود و ریسک زیاد؛
  • ۳: Use case نماینده با limitation پذیرفته؛
  • ۴: Upgrade/security/support/exit تمرین‌شده؛
  • ۵: تکرارپذیر، Governed، resilient و Evidence-linked.

Aggregate score جای Gate یا قضاوت نیست. Confidence، تاریخ، Version و Evidence ID کنار هر Score بیاید. Sensitivity را با سه Persona اجرا کنید: Cost-first، Control-first و Support-first.

مثال یک تیم فین‌تک ایرانی

تیم فرضی برای Web automation، Performance generator، SAST/SCA و Test management ابزار می‌خواهد. یک پاسخ واحد برای همه نقش‌ها منطقی نیست:

  • Runner وب OSS با Protocol و CI مناسب و ظرفیت داخلی؛
  • Support قراردادی برای Component بحرانی یا Partner داخلی؛
  • Performance stack Self-managed با Generator/Telemetry جدا؛
  • SCA دارای SBOM/OSV feed و Policy داخلی؛
  • TMS تجاری فقط اگر access/data/export/contract Gateها را پاس کند؛
  • Mirror داخلی و Artifact verification برای Dependencyها؛
  • عدم ارسال PAN/Token/Production evidence به Cloud نامجاز؛
  • Plan خروج برای هر Data/Script/Plugin.

Decision Record نمونه

decision_id: qa-tooling-ownership-2026-08
scope: web automation runner
offering: OSS core + paid Sev-1 support
version/license: pinned artifact + SPDX expression
gates: legal/pass, access/pass, sbom/pass, build/pass, export/pass
capacity: platform owner 0.5 FTE + backup 0.2 FTE
tco: base + optimistic + pessimistic
evidence: build, upgrade, patch drill, ticket, restore, fork sample
residual_risks: two upstream maintainers; private plugin patch
triggers: 90-day release gap, Sev-1 SLA miss, license change
review_date: quarterly

این انتخاب Hybrid است، نه ایدئولوژیک. اگر Capacity از دست برود یا upstream health افت کند، Trigger باید Re-evaluation را فعال کند.

Contractهای تجاری را با Failure scenario ببندید

  • Offering/Edition/Feature/Usage metric دقیق؛
  • Term، renewal، price cap و true-up؛
  • Support severity/response/escalation/timezone؛
  • Availability/RTO/RPO و service credit limitations؛
  • Security notice، vulnerability/CVE و patch timeline؛
  • SBOM/provenance/audit evidence access؛
  • Data ownership، region، retention، deletion و subprocessors؛
  • API/version/deprecation و rate limit؛
  • Full export format/frequency/cost؛
  • Termination assistance و read-only grace period؛
  • EOL/acquisition/insolvency و escrow در صورت نیاز؛
  • Liability/indemnity/insurance متناسب Counsel.

Service credit لزوماً خسارت Business را جبران نمی‌کند. معماری Recovery و Exit را مستقل نگه دارید.

Governance ابزار OSS را مستند کنید

  • Approved version و update channel؛
  • Owner/backup و support model؛
  • License/SBOM/vulnerability inventory؛
  • Artifact source/signature/provenance policy؛
  • Upgrade cadence و compatibility lane؛
  • Patch/exception SLA و expiry؛
  • Plugin/contribution/fork policy؛
  • Data/secret/network boundary؛
  • Backup/restore/build instructions؛
  • Health trigger و quarterly review.

OSS بدون Governance به «کسی یک‌بار نصب کرد» تبدیل می‌شود؛ Commercial بدون Governance هم به Shelfware، License sprawl و Shadow admin.

Triggerهای ارزیابی مجدد

  • License/Terms/ownership change؛
  • Open-core feature انتقال به Tier پولی؛
  • Release یا security patch از SLO دیرتر؛
  • Maintainer departure یا governance conflict؛
  • Vendor acquisition/EOL/price shock؛
  • Critical CVE یا supply-chain incident؛
  • Runtime/OS/Browser/API compatibility break؛
  • Support SLA miss؛
  • Iran access/payment/download disruption؛
  • Internal owner/capacity loss؛
  • Exit rehearsal failure؛
  • TCO deviation بالاتر از Threshold.

متریک‌های سالم

  • License inventory completeness و unknown expression؛
  • SBOM coverage/freshness و artifact match؛
  • Artifact verification success؛
  • Known vulnerability Time-to-triage/patch و exception age؛
  • Release/upgrade lead time و rollback success؛
  • Support Time-to-ack/mitigate/resolve و reopen؛
  • Admin/security hours در برابر TCO assumption؛
  • Custom patch count/age و upstream rate؛
  • Maintainer/funder concentration trend؛
  • CI/compatibility failure after upgrade؛
  • Export/build/restore success؛
  • License/contract/access trigger count.

Star، Download و Ticket count را بدون Context KPI نکنید. Metric باید Decision یا Trigger داشته باشد.

برنامه ۳۰ روزه تصمیم

روز ۱ تا ۵: Inventory و Gate

Problem، Offering map، Version، License expression، Use، Criticality، access و Hard gate را Freeze کنید. Legal/Security/Procurement/Engineering Ownerها را مشخص کنید.

روز ۶ تا ۱۲: Due diligence

Governance، maintenance، security, SBOM، provenance، vulnerabilities، supplier، support و ecosystem را با Evidence تاریخ‌دار بررسی کنید. Score/Badge را Signal نگه دارید.

روز ۱۳ تا ۲۰: PoC و Failure

Use case، Source build/installation، upgrade، patch drill، plugin break، ticket، backup/restore و artifact verification را Buyer-operated اجرا کنید. ساعت و هزینه را ثبت کنید.

روز ۲۱ تا ۲۶: TCO و Exit

Base/optimistic/pessimistic TCO، internal capacity، commercial terms، full export، fork/escrow و unavailable scenario را تمرین کنید.

روز ۲۷ تا ۳۰: Decision

Gate، Score، Confidence، Sensitivity و Residual risk را مرور کنید. Adopt OSS، Commercial، Open-core، Hybrid، Extend یا Reject همگی نتیجه معتبرند.

۱۵ ضدالگوی انتخاب OSS یا Commercial

  1. «Source روی GitHub است، پس Open Source است»؛
  2. «License صفر، پس TCO صفر»؛
  3. «تجاری است، پس امن و پشتیبانی‌شده است»؛
  4. مقایسه Brand به‌جای Offering/Edition؛
  5. ثبت License بدون Version/Expression؛
  6. نادیده‌گرفتن Plugin/data/docs License؛
  7. Star count به‌عنوان health verdict؛
  8. Aggregate Scorecard به‌عنوان Approval؛
  9. SBOM بدون تطبیق Artifact؛
  10. Source بدون build/fork rehearsal؛
  11. Community به‌عنوان SLA رایگان؛
  12. ظرفیت داخلی بدون Owner/ساعت؛
  13. Open-core بدون Feature boundary؛
  14. Commercial access بدون Account/Contract verification؛
  15. Exit plan فقط هنگام Termination.

چک‌لیست نهایی

  • □ Offering/Edition/Version دقیق ثبت است.
  • □ OSS/Source-available/Open-core/Dual/Commercial درست طبقه‌بندی شده‌اند.
  • □ License expression و Use توسط Legal بررسی شده‌اند.
  • □ Hard gateها پیش از Score تصویب شده‌اند.
  • □ Feature بحرانی در Tier قابل‌دسترس است.
  • □ Iran access/payment/download/support Verify شده‌اند.
  • □ Project/Supplier due diligence Evidence دارد.
  • □ SBOM با Artifact/Version Match است.
  • □ Signature/provenance verification اجرا شده است.
  • □ Vulnerability/patch drill انجام شده است.
  • □ Support ticket/escalation آزموده شده است.
  • □ Internal capacity با Owner/Backup/Hours واقعی است.
  • □ Upgrade/rollback/restore تمرین شده‌اند.
  • □ سه‌سال TCO با Range/Sensitivity محاسبه شده است.
  • □ Full export و Fork/escrow/exit Rehearse شده‌اند.
  • □ Contract failure scenarios را پوشش می‌دهد.
  • □ Score/Confidence/Residual risk ثبت‌اند.
  • □ Re-evaluation trigger و review date وجود دارد.

سؤالات متداول ابزار تست متن‌باز و تجاری

آیا ابزار متن‌باز واقعاً رایگان است؟

ممکن است License fee صفر باشد، اما Infrastructure، Admin، Upgrade، Security، Training، Integration، On-call و Exit هزینه دارند. گاهی OSS هنوز کم‌هزینه‌تر است؛ گاهی Support/Capacity آن را گران‌تر می‌کند. TCO را با Evidence Pilot بسازید.

آیا نرم‌افزار متن‌باز امن‌تر از تجاری است؟

Source visibility امکان Review می‌دهد، اما امنیت به Practice، Maintainer، Build، Release، Dependency، vulnerability response و Deployment بستگی دارد. Commercial نیز با Contract خودکار امن نیست؛ هر دو به Evidence و کنترل مصرف‌کننده نیاز دارند.

Open-core با Open Source چه تفاوتی دارد؟

در Open-core بخشی از محصول OSS و قابلیت‌هایی تجاری‌اند. باید Offering map بسازید و ببینید SSO، Audit، Scale، CI، Export یا Support موردنیاز در کدام Tier و تحت چه Termsی است. License Core را به کل Service تعمیم ندهید.

چه زمانی Paid support برای OSS منطقی است؟

وقتی Severity response، Patch/backport، compatibility یا Accountability لازم است و تیم داخلی Capacity کافی ندارد. Support partner را با Ticket، Skill، upstream relationship، timezone، SLA و Exit ارزیابی کنید؛ خرید Support ضعف فنی Tool را جبران نمی‌کند.

اگر Vendor یا Maintainer ناپدید شود چه کنیم؟

قبل از انتخاب، unavailable scenario را تمرین کنید: Source/build/fork و Community/Partner برای OSS؛ export/read-only grace/escrow/termination assistance برای Commercial. Owner، زمان، هزینه و Capability gap را ثبت و Trigger خروج تعریف کنید.

جمع‌بندی

مدل مالکیت ابزار یک Proxy ناقص است. OSS می‌تواند کنترل و Exit عالی یا Maintenance شکننده بدهد؛ Commercial می‌تواند Support و سرعت یا Lock-in و دسترسی ناپایدار بسازد؛ Open-core می‌تواند تعادل یا Feature trap باشد.

آزمایش فرضی نشان داد License صفر هم می‌تواند TCO بالاتر داشته باشد و با یک Assumption واقعی درباره ظرفیت داخلی، نتیجه دوباره برگردد. Offering و Version را دقیق کنید، Gate قانونی/امنیتی/دسترسی را اول بگذارید، Source-to-artifact و Support را آزمایش کنید، TCO را حساسیت‌سنجی و Exit را پیش از ورود تمرین کنید؛ سپس بر اساس Evidence انتخاب کنید، نه ایدئولوژی.

محمد عسکری

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

دیدگاهتان را بنویسید