DEV Community: Kylee Morgan

Expanding Software Engineering Teams for Social Impact Projects

Kylee Morgan — Sun, 13 Sep 2026 21:47:31 +0000

The Problem: Engineering Capacity Is a Bottleneck

Hiring full-time engineers is expensive and competitive, especially on a nonprofit, mission-driven budget. Meanwhile, there's a large population of developers who want to contribute to meaningful projects without signing on for a full-time role. Open source is the mechanism that connects those two realities.

This is how I doubled the engineering capacity for social impact tech organizations on GitHub by leveraging open-source to find quality contributors.

Why Open Source Can Expand Your Engineering Team

More contributors without proportional hiring. An active open source project extends the engineering team with a contributor network. Internal engineers focus on high-priority work (architecture, product-direction, major features / migrations, security); external contributors take on dependnecy upgrades, maintenance, bugs, documentation, tests, and other well-scoped tasks.
Attract mission-aligned engineers. Open source makes your technical work visible before without ever posting a job listing. That builds a pipeline of people already invested in the mission, and increases speed of hiring.
Build technology others can reuse. Social impact organizations frequently solve problems other organizations face too. Open sourcing those solutions lets the work benefit an entire ecosystem instead of staying locked inside one org.
Enhance code quality. Open-source improves code quality through continuous peer review, radical transparency, and diverse global collaboration.

Make Repository Discoverable

None of this works if contributors can't find you. Contributors interested in social impact work tend to search in a few predictable places, so it's worth showing up in them deliberately:

Topic tags: Tag your repository with social-good, social-impact, opensourceforgood, sustainable-development-goals or sdg, digital-public-goods or dpg, and non-profit. These are the exact terms contributors use to search GitHub.
The Digital Public Goods Registry: If your project meets the Digital Public Good Standard — open-source codebase, transparent ownership, data privacy compliance, alignment with the UN's Sustainable Development Goals — registering puts you in front of an audience actively looking for projects exactly like yours.
GitHub collections: Get listed in relevant GitHub collections, which group repositories by shared theme for easy browsing.
Good first issue lists: Submit approachable issues to programs like GitHub's Social Impact "Good First Issue" list, which exists specifically to route new contributors to projects like yours.
Anchor to an SDG: Framing your project against a specific Sustainable Development Goal gives potential contributors an immediate answer to "why does this matter" before they read a line of code.

Make Repository Contributor-Friendly

Start by making the project contributor-friendly. A public repository alone doesn't create a community. Make it easy for someone with zero context on your organization to get oriented:

README: What does this project do, why does it matter, and do you set up it up locally?
CONTRIBUTING.md: What is the standardization framework for assigning, reviewing, and accepting contributions?
Issue + Pull Request templates: What needs to be done before opening an issue or pull request?
Code of Conduct: What kind of community are you building?

Check GitHub's Community Insights in your repository settings to verify all requirements (including those listed above).

Open Issues

Turn your backlog into contribution opportunities. Not every engineering task needs to be handled internally. Use GitHub Issues to identify externally contributable work:

Documentation improvements
Bug fixes
Tests
Accessibility improvements
Small features
Developer tooling
Dependency updates

Label issues clearly: good first issue, help wanted, documentation, plus desired tech stacks or skills, so contributors can self-select into appropriate work instead of guessing. Issue labels should be standardized, such Sane GitHub Labels by David Lunny methodology.

Track progress and activity metrics with GitHub's built-in tools:

GitHub Milestones and GitHub Project Boards to track issue completion.
GitHub Contributor Insights to track contributor activity.

Your Open Source Collaboration Framework

Finally, treat contributors like part of the team. Open source contribution shouldn't feel like throwing code over a wall. There should be a lightweight system of reviewing pull requests, answering questions, giving feedback, recognizing contributions, and communicating project priorities.

!important Security

While GitHub provides many built-in tools like dependabot, internal engineers must have a system for ensuring public contributions are safe. I wrote blog post about this here. In general, reviewers should not run untrusted code without thorough review and precautions, security scans, and following best practices. Additionally, if participating in events like Hacktoberfest, maintainers need to a system prepared for handling mass, low-effort contributions.

Closing: Start Small

You don't need hundreds of contributors or to waste engineer's time with outreach and reviews to see the benefit. Open source enables engineers to do more meaningful work, connect, use their skills for issues they care about, and leads to higher code quality.

Securely Merging Pull Requests from Public Contributors

Kylee Morgan — Sun, 13 Sep 2026 21:44:56 +0000

Intro: Maintainers Caught at a Fork 🍴

How can maintainers safely test forked PRs without exposing sensitive data to potentially untrusted code? This article explores how on forked pull requests authored by public code contributors, with no elevated permissions from repository / organization roles, can be securely merged.

Context

Terminology:

Event Trigger: Event that initiates a workflow in GitHub Actions (like push, pull_request, and workflow_run).
Context (in GitHub Actions): The environment of where the workflow run, determined by the event trigger, repository, and branch.
actions/checkout: A GitHub Action that checks out a repository at a specific commit or ref so a workflow can access the code in the workflow's context.
pull_request: An event trigger that runs your workflow when activity on a pull request in the workflow's repository occurs.
Head (source): refers to the branch / repository containing the proposed code changes.
Base (target): refers to the branch / repository where proposed code changes are being merged into.

Workflow Permissions - Internal vs. Forked Pull Requests:

When a workflow includes the actions/checkout action, it uses the GITHUB_TOKEN to authenticate and fetch the repository at a specific commit or ref, placing the files into the $GITHUB_WORKSPACE directory, the workflow's context, so subsequent steps can access them. By default, workflows triggered by pull_request run actions/checkout in the context of the pull request’s head commit. But for forked pull requests, the GITHUB_TOKEN is read-only and secrets are unavailable. GitHub intentionally configures this as a security measure.

This design ensures untrusted code does not access repository secrets, meaning secret-dependent workflows fail on forks.

Safety:

Risks of Granting Secrets Access on Untrusted Code:

While security mitigations minimize risk, there is no foolproof way to securely allow secrets access on untrusted forked PRs. From injecting malicious code to exploiting race conditions, I invite readers to view this repository for a list of all the things that can go wrong. Ultimately, all public code contributions need to be treated as untrusted code:

“Any automated processing of PRs from an external fork is potentially dangerous and such PRs should be treated like untrusted input.” - Jaroslav Lobačevski, GitHub, writes in Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests

So here are 3 solutions, ranging from least to most secure, for running secret-dependent workflows, such as tests, on untrusted forks.

Solutions:

Solution 1 - Dangerous Use of pull_request_target:

Introduced in 2021, GitHub provides the pull_request_target event to elevate the GITHUB_TOKEN permissions to read/write on forked pull requests. By default, this sets the context as the base repository, rather than the fork, allowing metadata-only (no secrets) workflows to run, such as automated labels, comments, project board updates, etc. within a trusted context.

Unlike pull_request, secrets-dependent workflows run successfully on forks, but not in the context of the proposed code changes; misleading unaware developers with false test results. To run secrets-dependent workflows on proposed code changes in untrusted forks, the fork’s PR head SHA must be explicitly set with actions/checkout:

name: Checkout PR branch
uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.ref }}

But this is dangerous on it's own. The primary use case for pull_request_target is non-invasive, maintainer tasks on forks, not running or building untrusted code. Any developer using pull_request_target for any reason should carefully read the warnings and precautions here: GitHub Docs: pull_request_target.

Solution 2 - The workflow_run Prescan:

Also introduced in 2021, the workflow_run event enables chained workflows and elevates permissions:

“The workflow started by the workflow_run event is able to access secrets and write tokens, even if the previous workflow was not.” - GitHub Official Documentation

The trick is to create 2 workflows; first for static analysis of the untrusted code, the second for granting secrets access. This helps minimize the risk of exposing secrets to untrusted code by isolating read and write permission jobs.

The prescan is triggered by pull_request, setting the untrusted code in it's context and no secrets access. Upon successful completion of the prescan, the second workflow is triggered by workflow_run, granting secrets access to perform secret-dependent workflow runs on proposed code changes in forks, such as tests.

The prescan workflow should fail if:

Author is verified as untrusted with if comparisons. For example, if the head (source) respository's full name (owner-name/repo-name and always unique) matches trusted authors or by author permissions.
Changes made to sensitive files like .github/workflows/*, .gitignore, scripts.
Fail on static analysis via CodeQL.

Solution 3 - Use Isolated, Disposable Environments:

In my opinion, this is the best solution is simply running tests locally by cloning into an isolated, disposable environment after successful completion of a prescan workflow.

Best Practices:

Require contributors to obtain their own test secrets (if accessible), run tests locally, and share screenshot of results in the PR template. Clearly document in README and CONTRIBUTING file. This does not negate the need to run your own tests.
Always require maintainer approval before workflow runs on forks.
Never expose secrets directly in a pull_request_target workflow checking out PR code. Use dummy secrets with limited permissions and monitor them regularly.
Never use variable untrusted data in prescan workflow logic, such as github.event.pull_request.title which users can alter during workflow runs.
Prevent script injection in run steps and prefer GitHub Actions over inline scripts.
Pin marketplace Actions versions with commit SHAs.
Stay updated on security hardening for GitHub Actions.

Increasing Global Developer Coverage for Open-Source Organizations: with Docker and PostgreSQL

Kylee Morgan — Mon, 20 Jan 2025 18:07:38 +0000

Open-source projects thrive on community contributions, but one of the biggest barriers for new contributors is setting up a local development environment. With varying tech stacks, computer usage limits, and dependency overhead, how can open-source projects provide a one-size-fits-all setup?

Recently, I addressed these challenges for a free, open-source, privacy-first therapy application called Bloom. After containerizing the application with Docker, contributors were still required to host PostgreSQL data locally. While this approach was practical for backend development, it posed challenges for frontend contributors, as PostgreSQL hosting was necessary to run integration tests. To attract talented contributors, it became essential to minimize dependency overhead and align development requirements with the needs of developers. Additionally, offering flexible solutions to accommodate diverse computing capabilities was prioritized to help expand global developer accessibility.

Here’s how it worked, and the impact it made 👇

The Challenge: Lowering the Barrier to Entry

For developers interested in contributing to Bloom, getting the app running locally was often the first hurdle. Depending on their environment, contributors had to grapple with:

Installing and configuring PostgreSQL.
Manually populated their database with test data.
Managing dependencies that conflicted with their existing stack.
Adapting to Docker’s or PostgreSQL’s learning curve if they weren’t already familiar.

These issues would deter new contributors, especially those with limited system resources or time.

The Solution: Offering Flexible Setup Options 🌐
To make contributing more accessible, I configured three distinct, cross-compatible setup paths with clear documentation for seamlessly implementing each:

1. Manual Hosting with PostgreSQL:
For developers who prefer working directly with PostgreSQL on their local machine, this option allows them to host the database manually. Additionally, this lowered computer resource usage, as Docker has a high overhead.

2. Connecting a Locally Hosted PostgreSQL Database to Docker:
Some contributors might already have PostgreSQL installed and want to keep it separate from Docker. This option lets them connect their locally hosted database to the Dockerized application, bridging the gap between containerized and non-containerized setups. This also provided a compromise for computer usage and dependency overhead.

3. Running the App Entirely in Docker (with Persistent Data):
For devs who prefer a fully containerized development environment, they can now the backend and database in Docker (my personal favorite method). This approach minimizes dependency conflicts and leverages Docker-specific PostgreSQL tools. To ensure persistent data storage, similar to a locally hosted PostgreSQL database, I configured Docker volumes. With Docker volumes, this enabled both staff developers and contributors to fully containerize the application without needing to re-populate the database with each new container. Additionally, this streamlined my pull request workflow as a maintainer, as I no longer needed to manually populate the database from a forked branch when reviewing complex pull requests locally. Of course, there are caveats to this method, forked pull request tests run on my machine using Docker volumes can alter my local database, but I quickly realized I could navigate this using tmux multiplexers or docker-compose.override.yml files (that is for a future blog post).

Why These Options Matter?

This flexible setup benefits staff and community developers alike by:

Catering to diverse preferences: Whether a developer prefers Docker or manual PostgreSQL configurations, they can choose the setup that works best for them. ✔️
Accommodating resource limitations: Developers with lower-powered machines or network limitations can manually use PostgreSQL, while those with more resources can opt for containerization. ✔️
Reducing dependency conflicts: Each option minimizes the risk of version mismatches or conflicts with pre-installed tools. ✔️
Implements consistency: Regardless of the set-up developers opt for, the code remains consistent, and data is persistent. ✔️

The Results: A More Inclusive Developer Community

By lowering the barrier to entry, these setup options helped attract more contributors to Bloom and streamlined the workflow for maintainers. As an open-source tech organization focused on advocating for positive social impact, utilizing the most of limited resources is paramount for this project. With this new set-up, developers can start working on the app faster and with less frustration, fostering a more inclusive and engaged developer community. So far, contributor troubleshooting inquiries have been reduced, but this is only the beginning! Ultimately, this was an excellent learning opportunity for me as a developer advocate, and for contributors exploring Docker and PostgreSQL configurations.

Takeaways for Other Open-Source Projects

If you’re looking to improve community outreach for your open-source project, consider implementing flexible setup options like these. Providing contributors with choices tailored to their preferences and constraints, while maintaining consistency for staff developers, can make a significant difference in empowering contributors to engage.

When evaluating the onboarding flow for open-source applications, here are questions I like to ask myself:

Is this set-up causing contributors to drop of, and if so, where?
Can the gaps in the onboarding flow be resolved?
How can we provide flexible dev environment set-up options to enhance developer reach?

Thank you for reading this far! 🏆

If this post interested you, let's connect! I am always looking to collaborate with passionate technologists. Schedule a chat with me today: https://calendly.com/communaltech/coffee-chat-15-30min

Stay tuned for more, if you enjoyed this post, I invite you to follow my work on GitHub: https://github.com/kyleecodes