Hilary Carter | 01 October 2026
Stepping into Ciudad Cultural Konex in Buenos Aires for Nerdearla was an unforgettable experience. The venue was unique. It was as colourful with a giant orange staircase in the heart of the complex, had a mix of indoor and outdoor stages and spaces, and reflected the signature innovative and creative expression of Argentina. For me, it was a rare opportunity to engage with technology enthusiasts from across Latin America in a conference hosted at one of the region’s most prominent cities. A standout for me was participating in a panel discussion moderated by Leandro Colombo Viña on the topic of getting started in open source development, the subject of a new LF Research report. The discussion, held in the complex auditorium before a packed house, featured practitioner insights from Stormy Peters of AWS, Megan Knight of ARM, Roberto Luna Rojas from the Valkey project, and Michael “Monty” Widenius, creator of MySQL and MariaDB.
Top: Backstage with the Sysarmy production team. Missing Monty Widenius. Photo courtesy of Roberto Luna Rojas.
Bottom: From left to right, Leandro Colombo Viña, Stormy Peters, Hilary Carter, Roberto Luna Rojas, Megan Knight, Monty Widenius. Photo courtesy of Nerdearla.
The energy at Nerdearla reinforced a truth we see across the tech landscape: While there is an optimism around technology, and developer interest in contributing to open source projects is high, knowing where to start remains a challenge. This is why we’re so pleased to share our new report, Getting Started with Open Source Development: A Practical Guide for New Contributors, to help clear pathways to greater open source participation. Authored by Dr. Ibrahim Haddad with a foreword by Linux Fellow Shuah Khan, this report offers practical guidance for anyone moving from using open source to helping build it. The report also reflects insights from open source enthusiast Doug Byers, whose valuable peer review captured additional considerations for would-be contributors.
Understanding project mechanics before writing code
Building a clear mental model before touching code is critical for success in open source development. Unlike traditional corporate environments where tasks are assigned directly by engineering leads, open source relies on a voluntary, asynchronous model where maintainers oversee upstream repositories and evaluate proposed changes.
Before submitting a change, new contributors must navigate project licensing, developer agreements, and behavioral guidelines. Understanding whether a repository uses a permissive or copyleft license determines how the contribution can be used.
In addition, adhering to legal attestations like the Developer Certificate of Origin (DCO) via simple commit sign-offs or executing a Contributor License Agreement (CLA) ensures that pull requests move forward smoothly without administrative delays.
Navigating workflows and overcoming contribution barriers
Choosing where to start can feel overwhelming given the sheer volume of active projects. The report reveals that starting from an existing technical context—such as software, frameworks, or tools you already use daily—greatly reduces the learning curve. Evaluating health signals like recent commit activity, issue response times, and welcoming maintainer messaging allows newcomers to identify healthy, supportive communities.
Adjusting to different tooling environments is another requirement for success. While GitHub and GitLab rely on standard pull or merge request workflows, other foundational open source projects use mailing lists or Gerrit change-based reviews. The visual below outlines the basics of what first-time contributors should do before writing any code:
Another topic for discussion on the panel that is also reflected in the report was the idea of Imposter syndrome. It’s real, and it affects people of all skill sets, frequently holding back potential talent. Drawing on findings from our previously published Mentorship in Open Source report, nearly two-thirds of mentees entered structured programs lacking confidence in their ability to contribute, regardless of their background skill level. Programs such as LFX Mentorship address this gap directly by pairing newcomers with experienced maintainers, helping 90 percent of participants build strong confidence by the time they complete their mentorship.
Making your first contribution and building standing
When developers are ready to submit work, starting small is essential. The report highlights that maintainers welcome a variety of contributions—including documentation updates, bug triage, test coverage, and localized translations—just as eagerly as they welcome new code.
Maintaining good commit hygiene, keeping pull requests tightly focused on a single issue, and accepting review feedback constructively demonstrates respect for maintainer time and builds immediate trust. Here is a look at the step by step process:
Repeating these actions, and being courteous in the process, is the key to success. Trust in open source is built over time through repeated, reliable participation. As developers consistently deliver value and help maintain community spaces, their role within a project naturally evolves.
Making the business case for workplace contribution
For engineers seeking approval to contribute to open source projects during work hours, framing the request around business value is effective. Building on findings from our ROI for Open Source Software Contribution report, organizations engaging in open source contribution see a 2x to 5x return on investment. And companies that maintain internal private forks lose time and capital—averaging $670,000 annually in maintenance workarounds—due to roadmaps diverging from upstream repositories.
Getting started also often involves getting buy-in from your employer. By proposing a narrow, time-boxed contribution on a production dependency, developers can demonstrate how upstream fixes reduce tech debt, enhance security, and speed up internal development, creating business value. Here are a few points to consider when bridging the discussion with your boss:
- Propose contributions focused on critical production dependencies to reduce internal maintenance burdens.
- Frame contribution hours around measurable outcomes, such as landed bug fixes or triaged issues.
- Highlight research showing that active upstream engagement accelerates product development cycles by 10 percent on average.
The journey into open source begins with a single step, supported by structured guidance and community collaboration. We encourage first-time contributors to reach out with a single step, start small, build networks one connection or conversation at a time, and above all, not to give up. There is room for everyone with different skill sets in open source - the key is to making small, recurring contributions over time, and above all, not giving up.
To everyone who came to the Nerdearla panel, or who will download, read, or share the report, with a newcomer, your actions are an important part of what makes open source a great space to spend time in. We encourage you to stay engaged.
To smooth your journey to increasing open source contribution or engagement, we invite developers, maintainers, and engineering leaders to explore our full research report collection by visiting Linux Foundation Research. The reports and the datasets behind them are readily accessible - and we hope you’ll take advantage of this resource.