Open Source projects often grow in a quiet way. First there are a few users. Then there are bug reports, feature requests, questions, security concerns, pull requests, and people depending on your work in places you may never see.
That is a good sign, especially for projects built for education, accessibility, security, or public benefit. But growth can also become a problem if the project depends on one tired maintainer saying yes to everything.
Sustainability is not only about money. It is also about time, attention, boundaries, and making promises you can actually keep. A maintainer workload budget helps you decide what your project can support without burning you out.
Why This Stage Matters
Software for Progress Foundation supports Open Source developers because useful software should be able to reach the people who need it, not disappear when one maintainer runs out of energy. If your project helps a teacher, a nonprofit, a local government group, a screen reader user, or a small security team, reliability matters.
A workload budget is a simple written plan for how much maintenance your project can handle. It does not need to be fancy. It should answer a few practical questions:
- How many hours can you realistically spend each week or month?
- What kinds of work are most important?
- How quickly can users expect a response?
- What requests will you decline or defer?
- What work can contributors safely help with?
The goal is not to make your project look bigger than it is. The goal is to make it durable.
Step 1: List the Work You Already Do
Before you can budget maintenance, you need to see what maintenance actually includes. Many developers only count coding time, but sustainable Open Source work includes much more.
Make a list of recurring work from the last month or two. Include items like:
- Reviewing issues and pull requests
- Answering setup questions
- Triaging bugs
- Testing releases
- Updating dependencies
- Fixing documentation
- Responding to security reports
- Explaining project direction
- Managing community discussions
- Supporting older versions
Then estimate the time each item takes. You do not need perfect numbers. A rough estimate is enough to show whether your current pace is realistic.
For example, if you can spend five hours a week on the project but issue triage, dependency updates, and user support already take six hours, the project is over budget before you write any new code.
Step 2: Pick Your Maintenance Priorities
Not all maintenance work has the same value. A project with public benefit should protect the parts that keep users safe, included, and able to rely on the tool.
Choose three to five priorities for your current stage. These might be:
- Security: Fix critical vulnerabilities before adding new features.
- Accessibility: Avoid changes that make the tool harder to use with assistive technology.
- Stability: Keep the main workflow working for current users.
- Documentation: Make setup and common tasks clear enough for new users.
- Contributor support: Review beginner-friendly contributions on a predictable schedule.
Priorities help you say no without guilt. If a feature request is interesting but would take time away from security fixes or accessibility improvements, you can defer it. That is not neglect. That is stewardship.
Step 3: Define Support Levels
One reason maintainers burn out is that users assume support is unlimited. You can prevent confusion by writing down what support your project provides.
Your support levels can be simple:
- Critical security issue: Acknowledge as soon as possible and prioritize a fix.
- Bug that breaks the main use case: Review during the next maintenance session.
- Documentation issue: Accept reports and welcome pull requests.
- Feature request: Consider only if it fits the project scope and maintainer capacity.
- General help request: Answer when possible, but do not guarantee one-on-one support.
Put this in your README, contributing guide, or issue templates. Clear support levels are not unfriendly. They help users understand what to expect, and they help contributors know where help is most useful.
Step 4: Set a Weekly or Monthly Capacity Limit
Now choose a capacity limit. This is the amount of time you can give the project without harming your job, school, family, health, or other responsibilities.
Be honest. A sustainable budget might be:
- Two hours every Saturday morning
- One maintenance evening each week
- Four hours per month for dependency and security updates
- One release window every six weeks
Once you set the limit, use it to plan the work. If you have four hours this month, do not schedule ten hours of fixes. Move lower-priority work to a backlog, mark it as help wanted, or close it with a clear explanation.
This is especially important when your software serves people with limited alternatives. A small project that is maintained consistently is often more useful than a big project that collapses under unrealistic promises.
Step 5: Create a Contributor-Safe Backlog
Scaling does not always mean adding more maintainers right away. Sometimes it means making small pieces of work safe for others to pick up.
Look at your backlog and separate tasks into groups:
- Good first contributions: Small documentation fixes, examples, tests, or labels.
- Experienced contributor tasks: Isolated bugs with clear expected behavior.
- Maintainer-only tasks: Security fixes, architecture decisions, releases, and sensitive reports.
For each contributor-safe task, add enough context for someone to begin without a long private conversation. Include the expected outcome, relevant files, and how to test the change.
This protects your time and gives contributors a better experience. It also makes the project less dependent on one person over time.
A Concrete Example
Imagine an Open Source captioning tool used by small community education programs to make recorded lessons more accessible. The maintainer has six hours a month available.
Without a workload budget, every request feels urgent: a new export format, a UI redesign, a dependency warning, a teacher asking for setup help, and a bug affecting captions in one browser.
With a workload budget, the maintainer can decide:
- First priority: bugs that block caption creation or playback.
- Second priority: accessibility issues affecting keyboard or screen reader use.
- Third priority: documentation that helps educators install the tool.
- Feature requests are reviewed quarterly, not immediately.
- General support questions are answered through public issues only when time allows.
That plan does not solve everything, but it keeps the project useful. It also tells users and contributors how to help in ways that match the project’s real capacity.
Step 6: Review the Budget Regularly
Your workload budget should change as the project changes. Review it every few months or after a major release.
Ask:
- Am I spending more time than I planned?
- Which requests are creating the most pressure?
- Are users confused about what support is available?
- Can any recurring task be automated or documented?
- Is it time to recruit another maintainer or reduce scope?
If the project is growing, this review helps you scale carefully. If the project is staying small, it helps you keep it healthy. Both outcomes are valid.
TL;DR
A sustainable Open Source project needs more than good code. It needs realistic boundaries around maintainer time.
- List the maintenance work you already do.
- Choose the priorities that protect users and public benefit.
- Define support levels so people know what to expect.
- Set a weekly or monthly capacity limit.
- Make safe tasks available for contributors.
- Review the budget as the project grows or changes.
Sustainability is not about doing everything. It is about keeping useful software alive in a way that is honest, humane, and dependable for the communities it serves.