Support boundaries help maintainers route bugs, questions, feature requests, and security reports without turning every channel into unpaid support.
Support boundaries explain what help an open source project can provide, where users should ask, what information is required, and which requests maintainers will close or redirect.
Boundaries are not hostility. They protect maintenance work by making support expectations visible before users open issues, send private messages, or ask for help in the wrong channel.
Why boundaries matter
Open source projects can attract bug reports, usage questions, feature requests, security reports, installation help, integration questions, and private consulting requests. If all of that lands in the same place, maintainers lose the ability to distinguish project work from user support.
Without boundaries, users also become frustrated. They may ask in an issue tracker expecting personal help when maintainers only use that tracker for actionable bugs. A clear policy prevents mismatched expectations.
Good boundaries tell users where to go next. They do not simply say "unsupported."
Define supported and unsupported use cases
Start by listing what the project can realistically support. Supported use cases may include current stable versions, documented installation paths, official packages, reproducible bugs, and security reports.
Unsupported use cases may include old versions, unofficial builds, private customizations, unsupported operating systems, third-party integrations, broad consulting, or urgent business support.
Be specific. "We support the current release and the previous minor release" is clearer than "old versions are unsupported." If the project cannot name supported versions, it should at least state how maintainers decide.
Support scope should also cover environments. A project may support upstream source builds but not downstream packages, or official binaries but not modified forks. It may support one database backend, browser, runtime, or operating system version while accepting community fixes for others. These distinctions prevent maintainers from debugging environments they cannot reproduce.
For libraries and developer tools, define whether help covers usage questions, integration design, performance tuning, deployment advice, or only project bugs. A user may reasonably think all of those are support if the project does not say otherwise.
Separate bugs, questions, features, and security reports
Each request type needs a channel:
- Bugs need version, platform, steps, expected behavior, and actual behavior.
- Usage questions may belong in discussions, forums, chat, or community support.
- Feature requests need a user problem, impact, and maintenance tradeoff.
- Security reports need a private or designated security path.
- Paid or urgent support needs a separate commercial path if one exists.
Security reports should not be treated as ordinary support. Even when the project has strict boundaries, security-sensitive reports need a safe route.
Put boundaries where users ask
Support boundaries should appear in the README, issue templates, contributing guide, discussion welcome message, security policy, and project website where relevant.
The closer the boundary is to the request form, the better it works. A support policy hidden in a wiki will not prevent support issues. An issue template that asks "Is this a bug report, feature request, or support question?" can route users before maintainers intervene.
Use links. If questions belong in discussions, link discussions. If security reports belong in a policy, link the policy. If paid support exists, label it clearly.
Issue forms can enforce some boundaries before the maintainer reads the request. A form can ask the user to choose bug, feature request, or support question; require supported version information; and point security reports away from public issues. The form should be helpful, not hostile. If users must lie to get past the template, the boundary is poorly designed.
The README should give the short version. A separate support policy can hold details, but the first visible project page should still tell users where to report bugs, where to ask questions, and what maintainers do not provide.
Write respectful closure language
Closing a support request can be respectful and firm. A good closure names the reason and next path:
"Thanks for the report. This tracker is for reproducible bugs in supported versions. This looks like a usage question, so please use the discussion forum and include your version and configuration."
Avoid sarcasm, blame, or unexplained labels. The user may simply have followed the wrong path.
Respectful closure protects maintainers and teaches future readers how the project works.
Protect maintainer time without blocking contributors
Support boundaries should not prevent useful contribution. A user asking a support question may reveal missing documentation. A feature request may become a good issue after scope is clarified. A bug report may start incomplete but become actionable after one focused request for information.
The boundary should route work, not dismiss it automatically. If a question appears repeatedly, add docs. If users keep filing the same unsupported issue, improve the template or README.
Boundaries work best when they convert repeated support into durable project improvements.
This is where triage judgment matters. Closing every incomplete issue immediately may reduce queue size but lose valid reports. Keeping every vague question open may drown maintainers. A better pattern is one focused request for missing evidence, followed by closure or redirection if the information does not arrive.
If a support question reveals a docs gap, maintainers can close the support thread after opening or linking a documentation task. That keeps the tracker focused while preserving the improvement.
Private support and direct messages
Private support is especially risky for maintainers. It hides answers from the community, creates pressure for immediate response, and can blur volunteer work with consulting.
If maintainers do not offer private support, say so. Direct users to public channels unless the report is security-sensitive or contains private information that should not be public.
If a maintainer or company offers paid support, separate that from the community project. Users should know when they are asking the project and when they are asking for a commercial service.
Unsupported versions and platforms
Unsupported versions create recurring support pressure. Users may report bugs from old releases, abandoned operating systems, unofficial packages, or downstream builds maintainers cannot reproduce.
State how unsupported cases are handled. The project might ask users to reproduce on the current version, redirect downstream package issues, or close reports for unsupported platforms.
Do not imply that unsupported means unimportant. It means the project cannot spend maintainer time on that path unless someone contributes a supported fix.
Unsupported does not always mean "never." A project can say that maintainers do not reproduce issues on an old platform, but a well-scoped community patch may be considered if it does not add maintenance burden. That distinction lets contributors help without making maintainers responsible for every environment.
For security reports, unsupported-version language needs care. If the project only supports current versions, say so. If an old version is known to be affected but will not be patched, users need direct upgrade or mitigation guidance where the project can provide it.
Boundary examples
A small command-line project might say: "Issues are for reproducible bugs and documentation fixes in the latest release. Usage questions belong in discussions. Security concerns should use the security contact."
A library might say: "We support the current major version. Compatibility questions for older versions may be closed unless a maintainer or sponsor supports that branch."
A desktop app might say: "Unofficial builds and downstream packages are outside this tracker unless the issue reproduces with the official source release."
The wording should fit the project. Copying another project's policy can create promises the maintainer cannot keep.
Support-routing table
| Support request | Public channel | Required detail | Maintainer action | Redirect or close condition |
|---|---|---|---|---|
| Reproducible bug | Issue tracker | Version, platform, steps | Triage and label | Missing evidence after request |
| Usage question | Discussion or forum | Goal and configuration | Redirect or answer once | No code/docs change implied |
| Feature request | Feature template | Problem and tradeoffs | Evaluate scope | Out of scope or duplicate |
| Security report | Security policy | Private details | Route to security contact | Never ordinary support |
| Old version | Issue or discussion if allowed | Version and reason | Ask to reproduce current | Unsupported branch |
| Unofficial package | Downstream tracker first | Package source | Redirect if downstream-specific | Not reproducible upstream |
| Paid help | Commercial channel if offered | Scope and urgency | Separate from project queue | No paid path exists |
Revisit boundaries after spikes
Support boundaries should change when reality changes. A major release may create upgrade questions. A popular blog post may send beginners to the tracker. A dependency break may create many similar reports.
After a spike, review which requests arrived, which were misrouted, and which docs were missing. Then update templates, release notes, support pages, or labels.
The goal is not to make every future request disappear. It is to reduce preventable confusion.
Handling repeated boundary violations
If users keep ignoring boundaries, first check whether the boundary is visible and understandable. A rule hidden below a long README may not be enough. A template that says "not support" without pointing to the support channel will frustrate users.
When the rule is clear and a user continues to push private or out-of-scope support, maintainers can close the thread and stop responding. Repeating the same explanation can become the support burden the boundary was meant to prevent.
Abusive behavior is different from ordinary confusion. If a user harasses maintainers, demands private service, or ignores conduct rules, use the project's moderation or code-of-conduct process. Support boundaries and community safety should reinforce each other.
Boundaries for commercial users
Commercial users often depend on open source projects in production, but that dependency does not automatically create a support contract. A company using the software may file bugs, sponsor work, buy support if offered, or contribute fixes; it should not assume maintainers can provide urgent help for free.
Projects can make this explicit without being antagonistic. "We welcome reproducible bug reports from all users. We do not provide private integration support through the public issue tracker" is clear and fair.
If paid support or consulting exists, separate it from community maintainership. Public issue triage should not quietly become a sales queue, and paid customers should not receive hidden control over the public roadmap unless the project explains that relationship.
When boundaries become documentation
Every boundary should be easy to point to. If maintainers frequently type "we do not support old versions," that sentence belongs in the support policy. If they often explain how to ask usage questions, that belongs in the discussion welcome message or issue template.
Boundary docs should be short. Users opening an issue are usually trying to solve a problem, not read governance. Put the practical decision first: what channel to use, what details to include, and what the project will close or redirect.
Review boundary language after tense interactions. If a closure comment sounds irritated, turn the useful part into neutral policy wording. That makes the next redirect easier and less personal.
Support-boundary checklist
Before publishing boundaries:
- Supported versions and platforms are named or explained.
- Bugs, questions, features, and security reports have separate paths.
- Issue templates ask for the right evidence.
- Closure language is firm and respectful.
- Private support expectations are clear.
- Security reports are not treated as ordinary support.
- Repeated support questions become documentation work.
- Boundaries are visible where users ask for help.
Support boundaries work when they are specific, visible, and connected to triage. They let maintainers say no without making users guess what the project can actually support.