# Open Source Education Path: a course repo for contributors and for maintainers

> The OpenSource-Communities/intro repository is a Docusaurus site that hosts two written courses, one on contributing to open source projects and one on becoming a maintainer, with community maintained translations. It is documentation rather than software, so the interesting question is what an organisation can reuse from it, not whether to depend on it.

**OpenSource-Communities/intro** — Empowering Your Open Source Journey: From First Contribution to Project Leadership

- Repository: https://github.com/OpenSource-Communities/intro
- Website: https://learn.osscommunities.com/
- Stars: 713 · Forks: 171
- Language: JavaScript
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/opensource-communities-intro

## Two courses aimed at two different stages of an open source life

The repository is described as hosting comprehensive educational content for two audiences: people who want to learn to contribute to open source projects, and people who want to become project maintainers. The content is split accordingly into an Intro to Open Source Course and a Becoming A Maintainer Course, each with its own README under the docs directory, and the README links to both as the starting points.

That split is the design decision worth noticing. A single course that tried to cover both would have to choose between explaining how to open a good issue and explaining how to triage a queue of issues from someone else. Splitting them means the first course can stay at the level of a first pull request and the second can assume that the reader has already been around a project once. The trade off is that a reader who arrives with no context has to work out on their own which of the two documents to open first, since the README presents them as parallel links rather than as a sequence.

The repository also carries the usual community scaffolding: a Code of Conduct that all contributors must abide by, a contributing guidelines file, and a separate document for helping with translations. Questions are directed to a community discussions page linked from the README. None of this is unusual for a community project, but the emphasis is on participation, and on teaching people to take part in projects rather than to use a specific piece of software.

## The course site is a Docusaurus build that lives in the same repository

The layout is the giveaway that this is a site, not a collection of loose Markdown files. Alongside the docs directory there is a docusaurus.config.js, a sidebars.js, a src directory, a static directory and a netlify.toml, which is the conventional shape of a Docusaurus project with content in docs and components under src.

The package manifest names the project @OpenSource-Communities/open-source-education-path, marks it as private, and pins Docusaurus 3.9.2 through @docusaurus/core, @docusaurus/plugin-content-docs and @docusaurus/preset-classic, with React 18.3.1 and react-dom 18.3.1. The private flag is a small but important detail: this package is not published to a registry, so there is no versioned artefact to install and no upgrade path through npm. The version field reads 1.0.0 and is not tied to any release, and the repository has no GitHub releases at all.

Two more files sit at the root and say something about how the site is worked on. There is an .nvmrc, which pins a Node version for contributors who use a version manager, and there is an Intro.code-workspace file, a Visual Studio Code workspace definition for the course documents. A browserslist section in the manifest sets a production target of browsers above half a percent usage that are not dead and not Opera Mini, with a looser development target covering recent Chrome, Firefox and Safari. The presence of a netlify.toml points at Netlify as the hosting platform, and that file is where the build command and publish directory would be configured.

## Local development means a Node 20 install and the scripts the manifest declares

There is no published package to fetch, so the way to work with the content is to clone the repository, install the dependencies with npm install, and then use the npm scripts that the manifest declares. The engine requirement is stated explicitly.

```json
    "engines": {
        "node": ">=20.0.0"
    }
```

The script block is the interesting part, because each entry maps an npm script name to a Docusaurus command.

```json
    "scripts": {
        "docusaurus": "docusaurus",
        "start": "docusaurus start",
        "build": "docusaurus build",
        "swizzle": "docusaurus swizzle",
        "deploy": "docusaurus deploy",
        "clear": "docusaurus clear",
        "serve": "docusaurus serve",
        "write-translations": "docusaurus write-translations",
        "write-heading-ids": "docusaurus write-heading-ids"
    },
```

So npm start runs the development server with hot reloading, which means edits to a course document appear in the browser without a rebuild. For a check that mirrors what a deployment would produce, run npm run build to generate the static site and then npm run serve to serve that output locally. If a build is stuck on stale content, npm run clear resets the Docusaurus cache, and npm run swizzle generates theme component overrides for customising the look.

The important caveat is that all of this only gets you a local copy of a site that already exists elsewhere. The README points readers to an online learning path hosted under the opensauced.pizza domain, and the project homepage field points at learn.osscommunities.com, so the canonical way to consume the content is to read it online. Running the site locally matters if you intend to change it, and the deployment path for that is the deploy script in the same block, which expects the hosting credentials and site configuration to be set up on the Netlify side.

## Translations are a maintained document set, not a build flag

The repository treats translation as a first class contribution activity rather than an afterthought. A separate file, referenced from the README as the community translations page, collects the translations maintained by the community, and a second file covers the i18n guidelines for anyone who wants to help translate the courses.

The Docusaurus scripts support that workflow, and the last two entries in the script block are the ones that exist for it.

```json
        "write-translations": "docusaurus write-translations",
        "write-heading-ids": "docusaurus write-heading-ids"
```

The first extracts the translatable strings from the content into locale files, the second generates stable heading identifiers. Both are needed because translated documents need stable anchors, and because translation files have to be regenerated whenever the source text changes. That is a maintenance obligation the project accepts rather than hides, and it is the part of the workflow that a forking organisation inherits along with the text.

What the repository does not spell out is the size of the translated corpus. The README says translations are maintained by the community and points at two guideline files, but no list of supported locales, no coverage table and no statement of which languages are current is published anywhere in the repository files. For a team that intends to deliver the course in a language other than English, that gap is the first thing to investigate, because a translation file that has drifted from the source is worse than no translation at all. The i18n guidelines file is the place where that process is presumably described in full.

## What you get is prose, so the reuse question is about attribution and staleness

There is no code in this repository to adopt, no API to call and no configuration to merge. The deliverable is teaching content, and that changes what adoption means. An organisation that wants to onboard new contributors has three realistic options: point people at the hosted site, fork the site and host its own copy, or copy the course documents into an internal documentation system. The last option loses the navigation, the translations and the site styling, and it also loses the ability to pull in upstream corrections.

The staleness question is specific to this repository. The last push was on 2026-05-31, the repository is not archived, and there are no GitHub releases, so there is no tag to pin to and no changelog to diff. A fork is therefore on the hook for merging upstream by hand, and the updates arrive as ordinary commits to the main branch rather than as versioned releases. For text that changes slowly this is tolerable. For a curriculum that names specific tools, workflows or community processes, a fork left alone for a year quietly becomes advice for a different landscape.

The project is honest about who it serves. The stated audience is people learning to contribute and people learning to maintain, and the surrounding community channels, code of conduct and community translation effort all point the same way. A company looking for a certification programme for engineers will not find one here. A maintainer looking for a script to triage issues will not find one here either. The realistic value is a well organised starting syllabus that a team can shorten, reorder and point at its own examples.

## The licence is a Creative Commons badge over a custom LICENSE.txt

The README displays a Creative Commons Attribution 4.0 badge pointing at the Creative Commons licence page, while GitHub classifies the licence as a custom one that it cannot categorise, with a LICENSE.txt file at the root. Both facts are visible and they are not the same claim, so anyone planning to redistribute the course text should read LICENSE.txt rather than rely on the badge.

Attribution carries an obligation that matters for this kind of content. A Creative Commons Attribution licence requires that reuse names the author and indicates whether changes were made, so a fork that renames the courses, rewrites the text or translates it will need to carry that attribution. This is a factual reading of the licence identifier on display and not legal advice, but it is exactly the kind of detail that gets lost when a team copies a document into a slide deck and nobody records where it came from.

The other structural fact is about distribution channels. The README offers three ways in: the two course documents in the repository itself, the online learning path under the opensauced.pizza domain, and the homepage listed in the repository metadata, learn.osscommunities.com. They are related but not identical, and a reader who wants to check whether a particular update has reached the hosted site has to compare the documents by hand. For a self hosted alternative, the same content can be run through any Docusaurus instance you control, and the netlify.toml in this repository is a working reference for how the build and the hosting fit together.

## Conclusion

Use this repository when you need a structured, reusable curriculum for teaching new contributors or for training the people who will take over a project, and be ready to fork the site rather than to depend on the hosted one. Do not reach for it as a tooling answer, because there is no code to install and no release to pin to. Before reusing it, check the two things this repository leaves to you: the licence, which the README presents as Creative Commons Attribution 4.0 while GitHub classifies the repository as carrying a custom licence in LICENSE.txt, and the translation workflow, where the i18n guidelines and the community translations file describe a process rather than a published locale matrix.

## FAQ

### What is included in the OpenSource-Communities/intro repository?

Two written courses under the docs directory, an Intro to Open Source Course and a Becoming A Maintainer Course, along with community maintained translations, a contributing guidelines file and separate i18n guidelines. The content is documentation for learning to contribute and to maintain, not a software tool.

### How do I run the Open Source Education Path site locally?

Clone the repository, install the dependencies with npm install and run npm start, which maps to the docusaurus start script. The manifest requires Node 20.0.0 or newer, and the root .nvmrc pins the matching version.

### How do translations of the courses work?

Translations are maintained by the community and collected in a community translations file, with a separate i18n guidelines document explaining how to help. The write-translations script extracts translatable strings and write-heading-ids generates heading identifiers for translated documents. The repository does not publish a list of supported languages or their current coverage.

### What licence covers the course content?

The README shows a Creative Commons Attribution 4.0 badge, while GitHub classifies the repository as carrying a custom licence that it cannot categorise, and a LICENSE.txt file sits at the root. Read LICENSE.txt before redistributing the text, and keep the attribution that a Creative Commons Attribution licence requires.

### Is there a released version of the Open Source Education Path courses?

No. The repository has no GitHub releases and the package manifest is marked private, so there is nothing to install from a registry and no tag to pin to. The content is read online, through the learning path linked in the README and the homepage listed for the repository.

## Sources

- [Issues](https://github.com/OpenSource-Communities/intro/issues)
- [OpenSource-Communities/intro on GitHub](https://github.com/OpenSource-Communities/intro)
- [Project website](https://learn.osscommunities.com/)
- [README](https://github.com/OpenSource-Communities/intro/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/opensource-communities-intro