Proprietary vs Open-Source Component Decision Prompt Template

Use this prompt when you are evaluating a third-party software component—a database, a message broker, an API gateway, an authentication library—that will become a long-lived dependency in your production stack. The decision between a proprietary offering and an open-source alternative is rarely about features alone. It is about support guarantees when your on-call engineer is paged at 3 a.m., the speed at which a critical CVE is patched, the true cost of customizing a black-box component to fit your architecture, and the legal exposure hidden in a license file. This prompt forces a structured comparison across those dimensions, producing a decision memo that a principal engineer or CTO can review, challenge, and archive as an audit artifact.

Do not use this prompt for a feature matrix comparison. If you only need to know whether the proprietary tool supports SAML or whether the open-source library has a React wrapper, a simpler feature checklist is faster and cheaper. This prompt is for the moment after the feature check, when the shortlist is down to two viable options and the remaining differentiators are operational, legal, and strategic. It is also not a prompt for evaluating an in-house build. If you are deciding whether to build the component yourself, use the Build vs Buy Decision Memo Prompt Template instead. This prompt assumes you are buying or adopting—the question is from whom and under what terms.

The ideal user is an architect, tech lead, or engineering manager who owns the technical evaluation and will be accountable for the dependency's behavior in production. You should bring concrete evidence: support SLAs, community contribution graphs, CVE response histories, license texts, and integration spike notes. The prompt is designed to work with that evidence. If you feed it vague impressions, it will produce a vague memo. Before running this prompt, gather the artifacts you would want to see if you were the executive approving the decision. The output is a decision memo with explicit risk ratings, not a recommendation. It is your job to make the final call, document the rationale, and own the outcome.

This is the core prompt for the Proprietary vs Open-Source Component Decision workflow. It instructs the model to act as a principal architect and produce a structured trade-off analysis. The prompt is designed to be parameterized with specific component details, context about your system, and your organization's risk profile. Do not use this prompt for simple library comparisons; it is built for architectural decisions with long-term operational and financial consequences.

textCopy
You are a principal software architect evaluating a critical third-party component for a production system. Your task is to produce a structured trade-off analysis comparing a proprietary component against an open-source alternative. Your analysis must be evidence-based, grounded in the provided context, and must not advocate for a preferred option. Explicitly state assumptions and unknowns.

## Decision Context
- **System Purpose:** [SYSTEM_PURPOSE]
- **Component Function:** [COMPONENT_FUNCTION]
- **Proprietary Option:** [PROPRIETARY_OPTION_NAME]
- **Open-Source Option:** [OPEN_SOURCE_OPTION_NAME]
- **Key Non-Functional Requirements:** [NFR_LIST]
- **Team Profile:** [TEAM_SKILLS_AND_CAPACITY]
- **Organizational Risk Tolerance:** [RISK_TOLERANCE_LEVEL]

## Analysis Dimensions
For each dimension below, provide a comparative assessment of both options. Use the following rating scale: Strong Advantage, Slight Advantage, Neutral, Slight Disadvantage, Strong Disadvantage. Justify each rating with specific evidence from the provided context or clearly state that the rating is an assumption.

1.  **Functional Fit:** How well does each option meet the core functional requirements and edge cases?
2.  **Total Cost of Ownership (TCO):** Compare license fees, support contracts, infrastructure costs, and the fully-loaded engineering cost of integration, operation, and customization over 3 years.
3.  **Operational Overhead:** Compare the effort required for deployment, monitoring, upgrades, patching, and incident response.
4.  **Security & Compliance:** Evaluate vulnerability disclosure history, patch responsiveness, security posture, and ability to meet our compliance requirements ([COMPLIANCE_FRAMEWORKS]).
5.  **Community & Vendor Health:** For the proprietary option, assess vendor lock-in, roadmap influence, and financial stability. For the open-source option, assess community activity, maintainer responsiveness, contribution velocity, and the bus-factor risk.
6.  **Customization & Control:** Evaluate the ability to modify behavior, fix bugs, or add features to meet our specific needs without upstream dependency.
7.  **Team Capability Fit:** Assess the learning curve and long-term ownership burden for our team, given their current skills in [TEAM_SKILLS_AND_CAPACITY].
8.  **License & Legal Risk:** Identify any license restrictions, copy-left risks, or legal review requirements that could block our use case or distribution model.

## Output Format
Respond with a JSON object conforming to this schema:
{
  "decision_summary": {
    "recommended_option": "Proprietary | Open-Source | Conditional",
    "confidence": "High | Medium | Low",
    "primary_driver": "string (the single most influential dimension)",
    "deal_breakers": ["string (list of any dimensions that are show-stoppers)"]
  },
  "comparative_analysis": [
    {
      "dimension": "string",
      "proprietary_rating": "string",
      "open_source_rating": "string",
      "evidence_and_rationale": "string (justification for both ratings)"
    }
  ],
  "risk_register": [
    {
      "risk_description": "string",
      "related_option": "Proprietary | Open-Source | Both",
      "severity": "High | Medium | Low",
      "mitigation_strategy": "string"
    }
  ],
  "assumptions_and_unknowns": ["string (list of key assumptions that could change the recommendation)"],
  "suggested_next_steps": ["string (concrete actions like 'conduct a PoC for X', 'request a legal review of Y', 'reach out to Z community')"]
}

## Constraints
- Do not invent evidence. If information is missing, state it as an assumption.
- If [RISK_TOLERANCE_LEVEL] is "Low", the risk register must be especially thorough and the confidence level should reflect that.
- The "recommended_option" can be "Conditional" if the decision depends on resolving a key unknown.

To adapt this template, replace every square-bracket placeholder with concrete values. The [NFR_LIST] should include specific latency, throughput, availability, and data residency requirements. The [TEAM_SKILLS_AND_CAPACITY] placeholder is critical for a realistic assessment; be honest about your team's ability to debug and patch an open-source codebase. The [RISK_TOLERANCE_LEVEL] (High, Medium, Low) will directly influence the model's confidence and the depth of the risk register. After generating the analysis, always review the assumptions_and_unknowns list—these are the points that require human validation before a final decision is made.

This prompt is designed to be invoked as part of a structured Architecture Decision Record (ADR) workflow, not as a one-off chat. The ideal harness wraps the prompt in a function that accepts a [COMPONENT_NAME], [CONTEXT], and [CONSTRAINTS] payload, calls the LLM, and validates the output against a strict JSON schema before the result enters any decision log. Treat the prompt output as a draft analysis that requires human review and evidence attachment, not as a final ruling.

Validation and retry logic: Parse the model response as JSON immediately. Validate that all required top-level keys are present: decision_summary, comparison_matrix, risk_assessment, recommendation, and evidence_gaps. Each option in comparison_matrix must include numeric scores (1-5) for every dimension listed in [CONSTRAINTS]. If validation fails, retry once with the original prompt plus the raw invalid response and a repair instruction: The previous output failed schema validation. Return ONLY a valid JSON object matching the required structure. After two failures, log the raw response, flag the decision for manual completion, and notify the architecture review channel. For high-risk components (authentication, cryptography, data storage), always require a human reviewer to attach source links or vendor documentation to the evidence_gaps section before the decision is accepted.

Model choice and grounding: Use a model with strong JSON mode or structured output support (GPT-4o with response_format, Claude 3.5 Sonnet with tool use, or equivalent). Do not use a base model without instruction tuning for this task. If your organization maintains a database of prior ADRs, retrieve the 2-3 most similar past decisions and inject them as [EXAMPLES] in the prompt template. This grounds the analysis in your team's actual decision history and reduces generic advice. For the community_health and security_responsiveness dimensions, consider augmenting the prompt with real-time data from GitHub API or vulnerability databases via a tool call before the final analysis, rather than relying on the model's training cutoff.

Workflow integration: Store the validated output alongside the ADR metadata (author, date, status, related components) in a versioned decision log. If the recommendation is open_source with a risk_assessment score above 3 for abandonment_risk, trigger a follow-up task to create a fork-and-maintain contingency plan. If the recommendation is proprietary with vendor_lock_in risk above 3, trigger a vendor due diligence checklist. Never auto-approve a decision from this prompt. Route every output to a human reviewer with a 72-hour SLA for high-risk components and a one-week SLA for standard components. Log every invocation, validation result, retry, and human decision for auditability.