Many useful Open Source projects begin with a simple question: “What should this tool help someone do?” A second question should come soon after: “What data does this tool really need?”
Data choices are scope choices. If your project collects names, locations, student records, disability information, security logs, or account details, you are not just adding fields to a database. You are adding design work, documentation work, security work, support work, and long-term responsibility.
Planning data boundaries early helps you build software that is smaller, safer, and easier to sustain. That matters for public benefit software, where the people using the tool may have limited resources, limited technical support, or real reasons to be careful about what they share.
Why This Stage Matters
Planning and scoping is where you turn a good idea into something you can actually build. Data boundaries are part of that plan.
A data boundary explains what your project will collect, store, process, display, export, and avoid. It keeps you from accidentally building a larger system than you can maintain.
For example, imagine an Open Source reading practice app for adult learners. You may want to track progress so learners can see improvement over time. But do you need full names? Email addresses? Birth dates? Location? Teacher notes? Audio recordings? Each “yes” changes the size and responsibility of the project.
A clear boundary might be: the app stores practice history on the user’s own device and does not require an account for the first version. That one decision changes the scope. You may not need login, password reset, user administration, or a hosted database at the beginning.
Step 1: Name the Decisions Your Software Must Make
Start with decisions, not database fields. Ask what the software must decide in order to help the user.
Write down questions like:
- Does the tool need to know who the user is?
- Does it need to remember progress between sessions?
- Does it need to share information with another person?
- Does it need to sort, recommend, alert, or restrict access?
- Does it need to prove that an action happened?
If the software does not need a piece of data to make a useful decision, question whether it belongs in your first scope.
For the reading practice app, the software may need to know which lessons were completed and which words were difficult. It may not need the learner’s legal name, address, or employer.
Step 2: Sort Data Into Three Buckets
Once you have a rough list, sort each data item into one of three buckets: required, helpful, or risky.
- Required: The project cannot deliver the core value without it.
- Helpful: The project works without it, but the experience may improve with it.
- Risky: The data could create harm, maintenance burden, or trust concerns if collected poorly.
This sorting process makes scope visible. It also helps you avoid treating every idea as equally important.
In an accessibility project, a user’s preferred text size may be required. A saved profile photo is probably helpful at best. Medical history, diagnosis details, or personal identification documents may be risky and outside the first version unless the project truly depends on them.
For public benefit software, collecting less can be a strength. A smaller data surface can make the project easier to explain, easier to host, easier to audit, and easier for communities to trust.
Step 3: Decide What You Will Not Store
A good plan says no clearly. Write a short list of data your project will not store in the first version.
This list is not a failure of ambition. It is a way to protect the project from becoming too large too soon.
Your “will not store” list might include:
- Real names unless users choose to enter them
- Precise location data
- Payment information
- Private messages
- Uploaded documents
- Raw security logs older than a short planned window
- Any data not needed for the core workflow
This is especially useful for Open Source contributors. When someone suggests a feature that requires new sensitive data, you can point to the boundary and have a concrete scope discussion instead of a vague argument.
Step 4: Turn Data Choices Into Feature Limits
Data planning should change what you build. If it does not affect scope, it is just paperwork.
For each data decision, ask what features become simpler, delayed, or unnecessary.
- If you do not store accounts, you may not need password reset yet.
- If progress stays on the device, you may not need a server dashboard yet.
- If users export files manually, you may not need integrations yet.
- If reports are anonymous, you may not need identity management yet.
- If settings are local, you may not need a hosted profile system yet.
These are planning wins. They reduce the amount you must design, code, document, test, and maintain.
They also make it easier for a small Open Source project to serve people sooner. Software for Progress Foundation supports developers who want to create sustainable tools that benefit all people. Sustainability is not only about funding or attention. It is also about choosing a shape you can responsibly build.
Step 5: Write a Data Boundary Note
Before development begins, write a short note that future you and future contributors can understand.
Keep it plain. You do not need a long policy document at this stage. You need a planning artifact that guides scope.
Use this structure:
- Purpose: What the project helps users do.
- Required data: The minimum data needed for the core workflow.
- Optional data: Data users may provide, but the project can work without it.
- Not collected: Data intentionally outside the first version.
- Storage location: Local device, user-provided storage, project server, or another planned location.
- Retention plan: Whether data is temporary, user-controlled, or kept for a defined reason.
- Scope impact: Features you are delaying or avoiding because of these choices.
Example:
Purpose: Help adult learners practice reading and see their own progress.
Required data: Lesson completion, practice dates, and words marked difficult.
Optional data: Display name chosen by the learner.
Not collected: Legal name, address, birth date, school records, audio recordings, and precise location.
Storage location: Local device for the first version.
Retention plan: User can clear progress data from settings.
Scope impact: No accounts, teacher dashboard, cloud sync, or multi-device progress in the first version.
A Simple Planning Checklist
Use this checklist before you start building:
- Have you listed the decisions your software must make?
- Have you separated required, helpful, and risky data?
- Have you named data you will not collect in the first version?
- Have you changed the feature scope based on those choices?
- Can a new contributor understand the boundary in five minutes?
- Can a user understand why the project asks for each piece of data?
- Does the data plan match your current capacity to maintain the project?
If the answer is no, reduce the scope before adding more features.
TL;DR
Data boundaries are planning tools. They help you decide what your Open Source project needs, what it can avoid, and what responsibilities you are ready to take on.
Before you build, name the software’s required decisions, sort data into required, helpful, and risky buckets, write down what you will not store, and turn those choices into feature limits.
A smaller data plan can make your project more buildable, more trustworthy, and easier to sustain for the people it is meant to serve.