Many Open Source ideas start with a useful question: “What can I build?” For public benefit software, an even better discovery question is: “Who is currently left out, and why?”
An access gap is the distance between a person and a tool that could help them. The gap might be cost, language, disability, device limits, confusing setup, privacy risk, lack of internet, or a workflow that was designed for someone else.
Software for Progress Foundation exists to help Open Source developers create software that benefits all people. That starts before code. In ideation and discovery, your job is not to prove your idea is exciting. Your job is to find a real gap where free, open, well-designed software could make life easier for people who are not being served well today.
Look for Exclusion, Not Just Inconvenience
Not every annoyance is an access gap. A developer wanting a nicer dashboard is different from a public school teacher being unable to use a learning tool because it requires expensive licenses. Both may be valid problems, but one points more clearly toward public benefit.
When exploring an idea, ask what kind of exclusion is happening:
- Cost exclusion: people cannot afford the existing tool or subscription.
- Language exclusion: the tool is not usable in the languages people actually speak.
- Ability exclusion: the tool does not work well with screen readers, keyboard navigation, captions, or other accessibility needs.
- Device exclusion: the tool assumes fast laptops, new phones, or constant broadband.
- Trust exclusion: people cannot use the tool safely because of privacy, surveillance, or unclear data practices.
- Knowledge exclusion: setup or maintenance requires expertise the intended users do not have.
This helps you move from “I want to build a tool” to “I want to reduce a barrier.” That difference matters.
Describe the Gap in Plain Language
Before choosing features, write a simple access gap statement. Keep it short enough that a non-developer could understand it.
Use this format:
People in [situation] cannot easily [important task] because [barrier], and that leads to [harm or missed opportunity].
Here are a few examples:
- Education: Adult learners with older phones cannot easily practice digital literacy skills because most training tools require large downloads, and that leads to fewer chances to build confidence online.
- Accessibility: Community event organizers cannot easily check whether their pages meet basic accessibility needs because existing tools are too technical, and that leads to events being harder to attend for disabled people.
- Security: Small nonprofit teams cannot easily manage basic account security because enterprise tools are too expensive or complex, and that leads to preventable risk.
If your statement is vague, your project idea will probably be vague too. A clear access gap gives you a sharper reason to build.
Separate the Barrier From the Solution
Discovery gets weaker when you attach to a solution too early. “We need an app” is not an access gap. It is one possible response.
Try listing barriers before listing features. For example, suppose you care about helping local mutual aid groups share supply needs. The first idea might be “build a coordination platform.” But the access gaps may be more specific:
- Some volunteers only have phones and limited data.
- Some groups already use spreadsheets but struggle with duplicate entries.
- Some organizers need multilingual updates.
- Some information should not be public because it could put people at risk.
- Some groups do not have technical admins to maintain a server.
Those details may lead to a very different project than a full platform. Maybe the useful Open Source contribution is a lightweight form-to-spreadsheet tool, an offline-friendly template, a privacy checklist, or a small translation workflow. The right idea becomes clearer when you understand the barrier.
Check Who Benefits First
In public benefit Open Source, “users” are not always the same as “people who benefit.” A teacher may use a tool, but students benefit. A clinic administrator may use a scheduling system, but patients benefit. A security volunteer may use an audit script, but the protected community benefits.
During ideation, name both groups:
- Direct users: Who will install, open, run, configure, or maintain the tool?
- Beneficiaries: Who is better off if the tool works?
- Excluded people: Who might still be left out even if the tool succeeds?
- Potentially harmed people: Who could be put at risk by bad defaults, public data, or misuse?
This is especially important in security, accessibility, education, and civic technology. A tool can be free and Open Source but still fail people if it assumes the wrong environment or ignores risk.
A Concrete Example: Simple Security for Small Nonprofits
Imagine a developer wants to build an Open Source security checklist app for small nonprofits. That sounds helpful, but discovery should go deeper.
The access gap statement might become:
Small nonprofit staff without dedicated IT support cannot easily know which basic account security steps matter most because existing guidance is scattered and technical, and that leads to avoidable account takeovers and data exposure.
Now the developer can explore the idea without jumping straight to code. They might learn that staff do not need another long guide. They need a short, plain-language assessment that works in a browser, does not require login, explains each recommendation, and can be printed for board review.
That discovery changes the project. Instead of building a complex security management product, the developer may start with an Open Source self-assessment tool and a set of editable organization policies. The idea is smaller, clearer, and more likely to help the intended users.
Use an Access Gap Checklist
Before you commit to an idea, review it against this checklist:
- Can you name the specific group that faces the barrier?
- Can you explain the barrier without mentioning your proposed feature?
- Can you describe what becomes easier, safer, or more possible if the gap is reduced?
- Have you considered cost, language, disability, device limits, privacy, and maintenance?
- Do you know who will use the tool and who will benefit from it?
- Can the idea work for people with fewer resources than you have?
- Is Open Source important to solving the gap, not just your preferred way to publish code?
If you cannot answer these yet, that is not failure. It means you are still in discovery. Stay there a little longer.
TL;DR
Good Open Source ideas for public benefit often begin with an access gap: a real barrier that keeps people from using, trusting, affording, or benefiting from existing tools.
Before you decide what to build, describe who is left out, what they cannot do, why the barrier exists, and what changes if the barrier is reduced. This keeps your project grounded in need instead of assumption.
When developers start with access, they are more likely to create sustainable Open Source software that serves real communities. That is the kind of software that can move us toward a future where technology works for everyone.