Prompt and context
This product interview question tests whether you treat open source as a product decision rather than a one-time marketing activity. An internal tool may contain proprietary workflows, dependencies, data formats, and security boundaries; publishing code does not automatically create a sustainable community. A strong answer covers target users, differentiation, license and compliance review, maintenance capacity, release stages, community operations, and exit criteria.
What the interviewer is evaluating
- Whether you validate an external user problem instead of treating internal adoption as market proof.
- Whether you weigh strategic value, product experience, intellectual property, security risk, and long-term maintenance cost together.
- Whether you can design a staged path from documentation and an experimental repository to a stable release.
- Whether you define observable measures for contribution quality, adoption, retention, maintenance load, and risk events.
Clarifying questions to ask first
First confirm the core job, target external users, and available alternatives. How many internal teams use it, how often, with what task success rate, and which company systems or unpublished components does it depend on? Does the company want ecosystem influence, recruiting, external adoption, commercial leads, or lower maintenance cost? Have the code, dependencies, examples, brand, and documentation gone through intellectual-property, security, privacy, and export-control review? How long can the team support maintenance, responses, and compatibility?
A 30-second answer framework
I would not open-source it solely because internal teams use it. I would validate the external problem and the product boundary, then compare keeping it internal, releasing a reusable core, offering an open client with a hosted service, and fully open-sourcing it. Next I would complete license, dependency, data, and security review and run a small, reversible public pilot with documentation, contribution rules, and an accountable maintainer. I would expand only when external task success, meaningful adoption, contribution quality, and maintenance cost meet agreed thresholds with controlled risk. If repeated cycles miss the thresholds, I would freeze new features or archive the project while preserving a migration path.
Step-by-step deep dive
1. Turn internal success into external problem hypotheses
Interview internal users about their jobs, time saved, alternatives, and dependencies that cannot be exposed. Gather comparable evidence from developers, maintainers, and integration partners in the target market. Separate value created by the tool from value created by the company's internal process. Write falsifiable hypotheses, such as an external team completing installation, configuration, and a real task within a defined time.
2. Compare product boundaries and release models
Compare keeping the tool internal, open-sourcing a general-purpose core, opening a client while offering a hosted service, and fully open-sourcing the product. Estimate external value, differentiation, revenue or ecosystem benefit, support volume, infrastructure cost, and substitution risk for each. Separate proprietary adapters, credential handling, data collection, and reusable capabilities so the pursuit of a complete release does not expose boundaries that should remain private.
3. Complete license, dependency, and risk review first
A license determines how users may use, modify, and redistribute the work; do not select one from memory without legal confirmation. Inventory third-party dependencies, generated code, trademarks, sample data, vulnerability handling, supply-chain exposure, and export restrictions. Remove credentials, internal addresses, and customer data. Ensure the license file, copyright notices, and contributor terms match the repository, and record decisions and unresolved items in the release checklist.
4. Design the minimum viable public release
Publish an installable core, a clear quick start, a compatibility matrix, examples, and issue templates. Invite a small group of target users to complete installation, a first task, and an upgrade; record time, failure points, and support requests. Mark unstable interfaces with their version status so external users do not mistake an internal deployment promise for a public support promise.
5. Establish community and maintenance operations
Name maintainers, response targets, release cadence, a security disclosure channel, a code of conduct, and a transparent decision process. Contribution guidance should explain how to submit issues, tests, documentation, and code; reviewers should apply the same standard to external contributions. Distinguish downloads from a healthy community by tracking useful discussions, mergeable contributions, issue close time, and maintainer load.
6. Use staged metrics to expand or stop
During the pilot, measure installation-to-first-successful-task completion, four-week retention, active external organizations, contribution merge rate, response time for critical issues, and monthly maintenance hours. A security or compliance event, unacceptable support backlog, or no new meaningful adoption across repeated cycles should trigger a pause review. Metrics are decision guardrails, not universal promises about open-source value; set thresholds with the tool's complexity and target users.
Model high-quality answer
I would first validate whether external users have the same job as internal teams and which dependencies must be rewritten or hidden. Then I would compare keeping it internal, open-sourcing a general-purpose core, opening a client with a hosted service, and fully open-sourcing it. I would inventory licenses, third-party dependencies, trademarks, sample data, credentials, vulnerability disclosure, and supply-chain risk, with legal and security review. After approval, I would release only an installable core with a quick start, compatibility matrix, contribution guide, code of conduct, and named maintainer, then invite a small set of target users to complete real tasks. I would monitor first-task completion, four-week retention, active organizations, contribution quality, response time, and maintenance hours. A security event or repeated failure to meet thresholds would pause expansion, freeze features, or archive the project with migration guidance. Only after meeting the thresholds would I add integrations and stronger support commitments.
Common mistakes
- Treating the number of internal teams as external market validation.
- Discussing brand exposure and recruiting without license, dependency, data, or security boundaries.
- Publishing internal deployment scripts, credential handling, or customer examples and creating avoidable exposure.
- Publishing code before documentation, contribution rules, and a maintainer are ready.
- Using download volume as a proxy for meaningful adoption, task success, and community health.
- Omitting support-load, risk-event, pause, and archive criteria and assuming the project will maintain itself.
Follow-up questions and responses
Is it worth open-sourcing if only one internal team uses it?
With insufficient evidence, validate the external problem and build a small prototype instead of using internal scale as the decision rule. If external users cannot install it independently or its value depends on company workflows, keep it internal or expose only an abstracted component.
Which license should we choose?
List the intended use, modification, redistribution, and commercial scenarios, then have legal counsel select and confirm a license against dependencies and company policy. The product manager should explain trade-offs and user impact, not present a license name as an unreviewed legal conclusion.
Does a lack of contributors mean the project failed?
Not necessarily. The tool may create value through stable adoption, issue feedback, or ecosystem integrations. Evaluate contributor count alongside task success, retention, active organizations, maintenance cost, and strategic goals, using the pre-agreed review cycle to expand, adjust, or archive.
When should public maintenance stop?
Start an archive review when maintenance cost persistently exceeds value, an unacceptable security or compliance risk appears, or repeated fixes still fail to create target-user value. Publish migration, version-freeze, and security-notice plans in advance, preserve necessary source and documentation, and reduce the chance of abruptly cutting off existing users.