Many Open Source ideas start with a tool: an app, a dashboard, a browser extension, a library, a chatbot. That is natural for developers. We like to imagine the thing we could build.
But in the Ideation & Discovery phase, the most useful question is not “What should the tool do?” It is “What problem are we trying to understand well enough to serve?”
Good problem framing helps you avoid building software that is technically impressive but disconnected from real needs. It also supports the mission of public benefit Open Source: creating software that people can access, trust, adapt, and sustain over time.
The Goal Is Not a Perfect Idea
At this stage, you are not trying to produce a full project plan. You are trying to create a clear, testable understanding of the problem.
A good problem frame helps you answer:
- Who is affected? Be specific about the people, groups, or organizations experiencing the problem.
- What is hard for them right now? Describe the friction in plain language.
- Why does it matter? Connect the problem to access, safety, learning, independence, cost, time, or dignity.
- What makes the problem difficult to solve? Name constraints before jumping to features.
- What would be better if the problem were reduced? Describe the improvement without assuming a particular implementation.
This is discovery work. You are building understanding before you build software.
Start With a Problem Sentence
Write one sentence that describes the problem without naming your product idea.
Use this simple structure:
For [specific people], [specific task or situation] is difficult because [reason], which leads to [impact].
For example:
For adult learners using shared public library computers, practicing typing and digital forms is difficult because many learning tools require accounts or paid subscriptions, which leads to less confidence applying for jobs or services online.
This sentence does not say “build a typing app.” It leaves room to discover whether the best contribution is a web tool, printable practice sheets, a curriculum companion, a browser-based form simulator, or documentation for libraries using existing tools.
That flexibility is important. If you name the solution too early, you may stop listening.
Separate Symptoms From Root Causes
Discovery often begins with a visible symptom: people are not using a tool, a class is hard to complete, a security practice is ignored, or an accessibility feature is missing.
Symptoms are useful clues, but they are not always the real problem.
Ask a few “why” questions:
- Why is this task hard today?
- Why have existing tools not solved it for this group?
- Why would someone avoid the current option?
- Why might a free tool still be inaccessible?
- Why would maintainers, teachers, caregivers, or community workers struggle to adopt it?
For public benefit software, root causes often include more than code. They may include language, connectivity, device access, trust, privacy concerns, disability access, institutional rules, or lack of time.
If you only address the symptom, your project may look useful but fail in practice.
Map Who Is Affected and Who Has Influence
Many social impact projects have more than one group involved. The person who feels the problem may not be the person who chooses the tool, installs it, explains it, funds it, or maintains it.
Before choosing a direction, make a simple stakeholder list:
- Primary users: the people directly experiencing the problem.
- Helpers: teachers, librarians, caregivers, volunteers, advocates, or support staff.
- Decision makers: people who approve tools, policies, budgets, or technical environments.
- Maintainers: people who would keep the software useful after launch.
- People at risk of harm: anyone who could be excluded, exposed, misled, or burdened by the project.
This does not need to be formal. Even a short list can change your thinking. It may reveal that your project needs to work on old devices, avoid collecting personal data, support multiple languages, or be usable by someone with limited technical support.
Look for Constraints Before Features
Developers often brainstorm features first. In discovery, constraints are more valuable.
Constraints tell you what reality the project must fit into. They help you avoid building something that only works in ideal conditions.
Look for constraints such as:
- Low bandwidth or offline use
- Shared devices or public computers
- Screen reader and keyboard navigation needs
- Limited time for training or onboarding
- Strict privacy expectations
- Institutional rules about installing software
- Users who are not comfortable creating accounts
- Maintainers who can only give a few hours per month
These constraints should not discourage you. They make the project more grounded. Sustainable Open Source software is not just code that can be published. It is software that can keep serving people under real conditions.
A Concrete Example
Imagine you want to build an Open Source tool to help small community organizations improve website security.
A weak frame would be:
We should build a security scanner for nonprofits.
That may be useful, but it assumes the solution. A stronger discovery frame would be:
For small community organizations without dedicated technical staff, keeping websites secure is difficult because security guidance is scattered, technical, and hard to prioritize, which can lead to outdated software, exposed data, or loss of public trust.
This frame opens better questions:
- Do these organizations know what software their sites use?
- Who receives security alerts, if anyone?
- Are they afraid of breaking the site if they update it?
- Would a scanner help, or would it create confusing warnings?
- Would plain-language checklists, hosted reminders, or safer defaults be more useful?
- What information should the tool avoid collecting?
You may still build a scanner. But now it would come from a clearer understanding of the problem, not just the developer’s first instinct.
Test Your Frame Before You Commit
Once you have a problem frame, share it with a few people close to the issue. You are not asking them to approve your idea. You are asking whether the problem description sounds true.
Ask:
- Does this describe a real problem?
- Who is missing from this description?
- What part sounds wrong or too broad?
- What would make this problem worse?
- What have people already tried?
If people correct your framing, that is a good outcome. Discovery is supposed to change your mind. A revised problem statement is progress.
A Small Checklist for Better Problem Framing
- Describe the problem without naming your preferred tool.
- Name the specific people affected.
- Include the real-world impact of the problem.
- List constraints that may shape any useful solution.
- Identify who else influences adoption or maintenance.
- Check whether existing tools fail because of access, trust, cost, usability, or fit.
- Share the frame with people closer to the problem and revise it.
TL;DR
Before naming your Open Source project or choosing features, frame the problem clearly. A strong problem frame explains who is affected, what is difficult, why it matters, and what constraints shape the work.
This helps you build software with public benefit in mind. The goal is not to start with the most exciting idea. The goal is to understand a real need well enough that your future project can be useful, accessible, and sustainable.