From Beginner to Builder: Your First Code Contribution

By Ejiro Oghenekome, Sal Kimmich

Maybe you’ve used open source before and wondered how it all works, or you’re early in your career and heard that open source contributions can boost your growth. Maybe you’ve witnessed software supply chain attacks and felt an urge to make a difference. Maybe you just started learning about OpenSSF in our last blog: “Understanding OpenSSF Community and Working Groups.” 

Well, you are in the right place!

Contributing to open source is rewarding, but stepping into a security-focused project raises the bar. There are stricter tooling, more guarded spaces, and heavier reputational weight. That’s not to intimidate you. It’s there to help you grow. That’s why this guide is not only about how to contribute but also how to become a trusted, thoughtful collaborator.

Contributing to Security Projects Is Different

Security projects, especially those under OpenSSF, come with elevated discipline:

• CI & Security Controls: Projects like OpenSSF Scorecard and Allstar integrate automated checks to validate code quality and security.
• Protected Branches: Nothing bypasses pull request review.
• Vulnerability Disclosure Policies: Flaws must go through private channels before being made public.
• Provenance and Authentication: SLSA compliance, commit signing, and mandatory two-factor authentication (2FA) are common safeguards.

These aren’t just hurdles—they’re learning opportunities. Working with these tools and policies helps you understand how secure software is built, vetted, and released. It’s like training within the most responsible and accountable environments.

Why You Shouldn’t Use AI for Your First Contribution

Tempted to lean on AI for that first PR? Pause.

Using ChatGPT, Copilot, or Cursor for your first contribution does more harm than good.

• Context is Key: OpenSSF codebases have architecture and rationale that only you can learn by exploring the repo, reading the logic, and understanding the project’s voice. AI-generated code may be semantically correct, but it often misses the point or style.
• Maintainers feel when you are not invested: A PR that reads like AI-crafted boilerplate shows that you didn’t do the deep read-through. That leads maintainers to doubt your attention and breaks the trust that you can do real work.
• You lose the learning opportunity: Each step, from reading code, diagnosing a problem, writing tests, to interacting with CI, is where your confidence is built. Those aren’t things AI can teach you.

Tip: Use AI to ask questions, not to generate PRs. Ask: “What does this error mean in CI logs?” or “How would I squash my commits?” These questions are great for AI, but are a waste of maintainer attention: keep project-specific questions for maintainer communication to help you learn and grow. While you’re still learning, let your PRs be fully your own work. You personally must understand and be able to defend the work you’ve done. 

Step 1: Understand What Open Source Really Is

Open source software is your launchpad, not just a codebase, but a culture built on shared trust, open collaboration, and mutual respect. Contributing to OpenSSF tools means you’re part of an effort that affects the security of an entire ecosystem. That means your work carries real weight.

Step 1 Considerations 

• I understand open source is about public collaboration, not just free code.
  Open source projects thrive on public critique and discussion. Your changes will be visible to everyone, from maintainers to users, making transparency integral. Understanding this teaches you how to craft contributions that align with community expectations and norms. Open and public communication is in open source. Rather than using DMs to individual maintainers or participants to ask questions or discuss a problem, having a discussion out in the open often leads to faster and more thorough feedback, and just helps coordinating work among multiple people. Maintainers love it when people engage with the mindshare of the community to solve problems, and it can bring together a whole team to help you with your goals. 
• I’ve browsed projects hosted by OpenSSF: www.openssf.org/projects
  Exploring live projects helps you get a sense of scope, style, and activity. It lets you choose one where your skills match the project needs, and where issues are regularly addressed, helping you avoid stale or dormant efforts.
• I understand open source licenses define how my contributions can be used.
  Projects choose licenses to clarify usage rights and responsibilities. When you contribute, you agree to those terms, knowing this protects both you and the project from future legal or compliance issues.

Step 2: Learn the Culture (Without Rookie Mistakes)

Open source thrives on relationships built through shared values. If you engage thoughtfully, you’ll be welcomed. If you ignore conventions, you risk isolating yourself early on.

Step 2 Consideration 

• • I’ve read the README and CONTRIBUTING.md of an OpenSSF project.
    These files are the starting line; they show you how to build the project, where to ask questions, and what the maintainers expect. Skipping them is like getting dropped into a new city without GPS.

• I’ve read the Issues How GitHub issues are managed says a lot about a project, so another recommendation at this stage could be to read through the open issues to familiarize yourself with the sorts of open problems the project is prioritizing and who participates in the discussions.

• I’ve joined the Slack: www.openssf.org/getinvolved
  Real-time chat gives context, camaraderie, and mentorship. It’s also where informal technical discussions happen; joining signals your interest and makes future asks easier. Attend community meetings at this stage, and review their past recordings (these are all available on the OpenSSF Meetings Calendar. 
• I know PR feedback targets the code, not me.
  Reviews may feel critical, but they’re focused on quality, not you. Adopting a growth mindset helps you see feedback as guidance, not judgment.
• I’ve reviewed the project’s Code of Conduct.
  This document clarifies communication standards and outlines how to report issues. Familiarizing yourself with it shows respect for that community’s culture and expectations.

Step 3: Build Your Open Source Toolkit

You don’t need fancy tools—just the right ones, and the confidence to use them.

Step 3 Consideration 

• Git is installed, and I can fork + clone on GitHub.
  These steps move the code to your environment, where real learning begins. Practicing a merge or resolving a conflict now makes real contributions feel intuitive later.
• My GitHub account has 2FA enabled: www.github.com/settings/security
  Many OpenSSF projects require 2 Factor Authentication as a non-negotiable security step. Enabling it shows you’re serious and that your account is secure enough to be trusted. You’ll see this on every security project, and it’s in place on many non-security projects as well. It’s a best practice, so get used to using it. 
• I’ve reviewed at least one CI log from the project GitHub Actions.
  Seeing how CI reports errors (syntax, security, style) prepares you to interpret your own test failures later. This gives you a leg up in diagnosing and fixing issues.
• I’ve tried out a tool like OpenSSF Scorecard or Allstar.
  Hands-on experience helps you understand the problem domain and the project’s approach to solving it. It also gives you context you can reference in your contributions.

Step 4: Find Your First Contribution

“Good first issue” means the project is intentionally welcoming and ready to guide newcomers. Use this as your entry path—then deepen from there.

Step 4 Consideration

• I’ve found a “good first issue” without an assignee.
  This is your green light: the issue is scoped for beginners, and there’s space for you to step in. These labels often signal that maintainers are ready to support you.
• I commented to claim the issue.
  For example, it can be as simple as this: “Hi @maintainer, I’d like to work on this. Does that sound okay?” This stage is informal, and is just to ensure this is work the project still needs from the community. Claiming it publicly ensures no one else starts working on the same thing and opens a line of communication where you can ask for context or start a collaborative thread. Once you commit yourself, complete the work. If you get blocked, bring that blocker into the conversation and get some help. If you decide not to complete a contribution, at least provide a record of the research and context that got you as far as you did, so others can follow, and let them know that PR is open for them to contribute to and complete! 
• I forked the repo and created a local branch.
  This structure gives you freedom to experiment without affecting the project’s main line. Good branch hygiene also makes your work easier to review later.
• I read the setup instructions and ran the tool locally.
  Running it yourself helps detect mismatched versions, undocumented dependencies, or overlooked setup steps. It also gives you background knowledge you may need during development.

Step 5: Make Your Contribution

This is where intention meets output: you’ve prepared, and now you’re creating. Keep your changes clean, communicative, and guided by feedback.

Step 5 Consideration

• I created a new branch for my change.
  Branches keep your work organised, easy to test, and roll back if needed. They also help future collaborators understand your changes in isolation.
• I ran tests locally.
  A green test suite shows you’ve done more than write code, you’ve respected the project’s quality standards. It prevents trivial failures in CI.
• I opened a PR that references the issue (e.g., “Closes #42”).
  Linking the issue makes reviewing easier and manages project tracking automatically. It adds transparency and shows that your PR has been planned, not accidental.
• I responded to feedback quickly and professionally.
  It only takes a few minutes to acknowledge a reviewer and push a change. That responsiveness keeps momentum going and shows respect for your reviewers’ time.
• All CI checks passed before merging.
  A green CI pipeline signals readiness for merging. It shows that you’ve met the project’s automated standards and are giving maintainers a clean package to review.

Step 6: Celebrate and Grow

A merged PR is more than code. It’s trust earned. Now it’s time to build on that trust by engaging your new community.

Step 6 Consideration 

• I thanked reviewers and maintainers.
  A simple thank-you goes a long way in open source. It shows appreciation and strengthens relationships without extra effort. There is always a human on the other side of an open issue or PR. Treat them with the same respect you would give to a person if a screen weren’t between you. If you make it to a technical conference, they’ll be excited to meet you, and it’s worth showing up with mutual respect from both sides. 
• I shared my first contribution publicly.
  Posting about your PR on Slack, social media, or update channels, boosts morale and shows you’re taking ownership. It also inspires others to follow and add to the work, and can help to provide feedback on documentation at this stage. 
• I looked for a second issue or asked, “What’s next?”
  Beginners don’t stop at one contribution. Asking what to tackle next signals commitment and helps maintainers see you as someone who’s eager to stick around. Individual contributors are often the key to project success, and employers look for contributors who show commitment to projects over time. 
• I reviewed or helped another contributor.
  Reviewing is learning. By reading someone else’s code and offering feedback, you deepen your understanding and add value beyond your own PRs. You can do this once you become more familiar with the way a project works and have a better understanding of its technical roadmap. This is extremely useful to maintainers and might mean you are on a pathway to eventually become a maintainer of that project yourself. 

Full Contributor Roadmap

A quick-glance version of your journey. Keep it handy as both your checklist and celebration meter.

Before You Contribute

•  Understand open source culture and OpenSSF values
•  Browse projects and find what interests you
•  Join Slack, read the Code of Conduct, set up Git + 2FA

Prepare Your First Contribution

•  Read the docs and example PRs/issues
•  Pick a good first issue
•  Fork the repo and run it locally
•  Comment to claim the issue

Submit Your PR

•  Create a focused branch
•  Apply the change and run tests
•  Open PR with context and gratitude
•  Respond to feedback, pass CI

After Your First PR

•  Merge = achieved. Thank the team. 
•  Share your story publicly
•  Tackle a new issue or triage
•  Join a working group or meeting

Final Word

Contributing to OpenSSF projects takes courage and care but the rewards are real. Each step builds your skills, confidence, and reputation. You’ll make mistakes, and that’s part of the journey. But the community is looking for people who show up. Your first contribution doesn’t have to be perfect. It just has to be yours. Now go find a “good first issue,” claim it, and do open source in a way that only you can! 

About the Authors

Ejiro Oghenekome is an emerging cybersecurity professional who’s turning curiosity into impact. With roots in UI/UX design and a growing body of work in software security, she brings an instinct for user-centred thinking to every technical challenge. Whether she’s breaking down secure coding practices for beginners or contributing to community documentation and tooling at OpenSSF, Ejiro makes security feel approachable. A consistent contributor across several open source projects, she’s part of a new wave of practitioners bridging design, education, and security across the African tech ecosystem and to the global community. Now focused on growing her career in cybersecurity, Ejiro is seeking roles where she can deepen her technical skills, contribute to real-world defences, and keep making security more accessible for everyone.

Sal Kimmich is a developer advocate and security engineer working at the intersection of open source governance, software supply chain security, and privacy-enhancing technologies. They serve as a contributor to the Open Source Security Foundation’s Education SIG, BEAR WG, and co-chair of the CHAOSS data science WG. Sal helps build inclusive pathways as an international open source community leader, known for mentoring first-time contributors and shaping policy around secure development practices across Europe, the UK, and North America. By day, you’ll find Sal filling in the gaps of the latest threat models for agentic AI systems; in their free time, they mentor the next generation of exceptional engineering talent and help them find their voice in open source security.