Published Sep 16, 2025 ⦁ Updated Oct 11, 2026 ⦁ 16 min read
OSS Programming: A Developer's Guide to Getting Started

OSS Programming: A Developer's Guide to Getting Started

OSS stands for open source software: software whose source code is published under a license that lets anyone use, study, change and redistribute it. OSS programming means writing code for such projects, either contributing to existing ones like Linux, PostgreSQL or VS Code's open source core, or publishing your own. To start, you need Git, a GitHub (or GitLab) account, a basic understanding of licenses, and one small issue in a project you already use.

This guide covers what counts as open source, the licenses you'll meet, how to set up and make a first contribution step by step, and the honest trade-offs, as of October 2026.

What is OSS in software?

"Open source" has a precise meaning. The Open Source Initiative's Open Source Definition sets ten criteria a license must meet, including free redistribution, access to source code, permission to create derived works, and no discrimination against people, groups or fields of use. A project is open source when it is released under a license that meets them, usually one on the OSI-approved list.

Some things that look open are not:

  • Public code without a license is "all rights reserved" by default. You can read it on GitHub, but you have no right to reuse it. GitHub's docs on licensing a repository say the same.
  • Source-available licenses such as the Business Source License (BSL) or the Server Side Public License (SSPL) publish the code but restrict some uses, so they are not OSI-approved. HashiCorp's 2023 switch of Terraform to the BSL is why the community fork OpenTofu exists.
  • "Free" apps that you can download at no cost but whose code is closed are freeware, not open source.

Open source software examples

Area Examples
Operating systems Linux, FreeBSD, Android's AOSP
Languages and runtimes Python, Go, Rust, Node.js, OpenJDK
Databases PostgreSQL, MySQL, SQLite, Valkey
Web and infrastructure Kubernetes, nginx, Docker Engine, OpenTofu
Developer tools Git, VS Code's Code - OSS core, Neovim
Frameworks React, Django, Ruby on Rails, Spring

DevHunt's open source tools category lists newer open source developer tools, and free alternatives maps paid products to open and free replacements.

Open source licenses you need to understand

You don't need to be a lawyer, but you need to recognize the main families. choosealicense.com, maintained by GitHub, compares them side by side.

License Type What it requires Common in
MIT Permissive Keep the copyright and license notice JavaScript libraries, small tools
Apache-2.0 Permissive Keep notices, state changes; includes an explicit patent grant Cloud and enterprise projects
BSD-3-Clause Permissive Keep notices; no use of the authors' names to endorse Older systems software
MPL-2.0 Weak copyleft Share changes to MPL-licensed files; the rest of your app can be any license Firefox, Penpot
GPL-3.0 Strong copyleft Distribute the whole derived work's source under the GPL Linux userland tools, many desktop apps
AGPL-3.0 Network copyleft Like GPL, and also applies when users use the software over a network Self-hosted server software

Rules of thumb:

  • Using OSS inside your company's app: permissive licenses are almost never a problem. GPL code linked into software you distribute means your code must be GPL too. AGPL extends that to software you offer as a service.
  • Publishing your own project: MIT or Apache-2.0 if you want maximum adoption, GPL or AGPL if you want improvements to stay open.
  • Contributing: your contribution is usually licensed under the project's license. Some projects also require a Developer Certificate of Origin sign-off (git commit -s) or a Contributor License Agreement (CLA).

Setting up your OSS development environment

  1. Install Git from git-scm.com and set your identity:

    git config --global user.name "Ana Developer"
    git config --global user.email "ana@example.com"
    

    Use the email linked to your GitHub account so commits are attributed to you. GitHub can give you a private noreply address if you don't want yours public.

  2. Create a GitHub account and set up SSH keys or the GitHub CLI (gh auth login) so you can push without typing passwords.

  3. Pick an editor you are productive in: VS Code, a JetBrains IDE, Zed or Neovim all work. See IDE tools on DevHunt for more options.

  4. Install the project's toolchain exactly as its README or CONTRIBUTING.md describes. Many projects ship a dev container or a Makefile target that sets everything up.

New to Git itself? Read the beginner's guide to open source version control first.

Finding a project to contribute to

The best first project is one you already use, because you understand the problems and will notice good fixes. Then:

  • Look for labeled issues. Many projects tag beginner-friendly work with good first issue or help wanted, as GitHub's guide to finding contributions describes. Search across GitHub with is:issue is:open label:"good first issue" language:python.
  • Browse topics and Explore. github.com/topics/<topic> lists projects by subject, and github.com/explore gives recommendations based on your activity.
  • Check project health before investing time: recent commits, maintainers replying to issues and PRs within a few weeks, a CONTRIBUTING.md, and a code of conduct.

Making your first contribution, step by step

This is the standard fork-and-pull-request flow on GitHub.

  1. Comment on the issue to say you're working on it, and ask questions if the expected fix is unclear. This avoids two people doing the same work.

  2. Fork and clone the repository. With the GitHub CLI, one command does both and sets up remotes:

    gh repo fork owner/project --clone
    cd project
    

    Per the gh repo fork manual, your fork becomes origin and the original repository becomes upstream.

  3. Create a branch for the change:

    git switch -c fix-date-parsing
    
  4. Make the change, with a test. Follow the project's code style and run its test suite and linters locally before pushing.

  5. Commit with a clear message that says what changed and why, and references the issue:

    git commit -am "Fix date parsing for ISO week dates (#1234)"
    

    Add -s if the project requires a DCO sign-off.

  6. Sync with upstream so your branch is current, then push:

    git fetch upstream
    git rebase upstream/main
    git push -u origin fix-date-parsing
    
  7. Open the pull request with gh pr create or the GitHub web UI. Fill in the PR template, link the issue (Fixes #1234), and describe how you tested it.

  8. Respond to review. Push follow-up commits to the same branch; the PR updates automatically. Expect requested changes. That is normal, not rejection.

Contributing without writing code

Code is one way in. Projects also need:

  • Documentation: fixing unclear setup steps is often the most valuable first PR.
  • Bug reports with minimal reproductions.
  • Triage: reproducing reported issues and confirming which are duplicates.
  • Design and UX, translations, and answering questions in discussions or forums.

Working with maintainers and the community

  • Read the code of conduct and follow it. Most projects use the Contributor Covenant.
  • Be patient. Maintainers are often volunteers. A polite ping after two weeks of silence is fine; daily pings are not.
  • Keep PRs small and focused. One fix per PR gets reviewed far faster than a large refactor.
  • Don't take review personally. Style feedback is about the codebase's consistency, not your skill.
  • Disclose AI-generated code if the project asks, and check its policy first. Several projects now restrict or reject AI-written contributions.

Advantages and disadvantages of open source software

Advantages Disadvantages
Free to use, with source you can inspect and audit Support depends on the community unless you pay a vendor
No lock-in: you can fork or self-host Projects can be abandoned or change license
Large ecosystems and shared fixes Uneven documentation and UX
Contributing builds a public portfolio Your contributions are public, including mistakes

For a deeper comparison when choosing tools for a team, see open source vs proprietary developer tools.

FAQ

What does OSS mean in programming?

OSS means open source software: code released under a license that lets anyone use, study, modify and share it. OSS programming is writing or contributing code to such projects.

Is open source software free?

Free to use, yes, and the license guarantees your rights to the code. Many companies still charge for hosting, support or extra features around an open source core, so "open source" doesn't mean a vendor's whole product is free.

How do I start contributing to open source as a beginner?

Pick a project you use, find an issue labeled good first issue, read CONTRIBUTING.md, then fork, branch, fix, test and open a pull request. Documentation fixes are a good first contribution.

Which open source license should I choose for my project?

MIT or Apache-2.0 if you want anyone, including companies, to adopt it with minimal conditions. GPL-3.0 or AGPL-3.0 if you want modified versions to stay open. Use choosealicense.com to compare.

Is code on GitHub automatically open source?

No. Without a license file, public code is all rights reserved. A repository is open source only when it includes an open source license.