open-source-with-pradumna: a Docusaurus guide to Git and GitHub for beginners

A reading resource, not a piece of tooling

The repository bills itself as 'Building the repo you need to get started with Open Source', and it is worth being precise about what that means. There is no library to install, no command to run and no API to call. What ships is a static documentation site, together with the Markdown files it is built from, and the entire value of the project is in the prose, screenshots and video links those pages contain.

The intended reader is a beginner. The topic list names Open Source, Git and GitHub, and the sections are written for someone who has heard of pull requests but has never opened one. That framing is unusual for an open source repository that is itself on GitHub, and it gives the project a specific role: it is the 'first pull request' ramp that many community programmes point new contributors at.

The site is published at os.pradumnasaraf.dev, and the repository also carries the usual governance files, CODE_OF_CONDUCT.md, CONTRIBUTING.md and SECURITY.md, alongside a .gitpod.yml for browser-based development. Those extras sit oddly beside a tutorial site, but they signal that the repository is maintained with the same care as a code project rather than as a folder of exported posts.

What the six documentation sections contain

The README indexes the content as six areas, each with its own page under docs/. The first is a 15-Day Bootcamp described as containing 15 days of Twitter threads and blogs that the author posted during the bootcamp. That is a dated archive of a specific teaching run rather than a generic curriculum, which is both its charm and its limit.

The second, the How to section, is the most practical piece: a step-by-step guide with written instructions, screenshots and video covering how to create an issue, clone or fork a repository, and create a pull request. The third is a Learning Resources page collecting other videos, blogs and images on Open Source, Git and GitHub, which makes the project partly a curation layer over material it did not write.

The remaining three pages round out the funnel. Beginner Friendly Projects holds repository links where newcomers can practice their first contributions. Regular Content gathers informational posts written by the author and by other community members. The FAQ collects commonly asked questions on the same three subjects. Read as a whole, the structure is a path: learn the concepts, watch someone do it, find a project to practise on, then resolve the specific questions that came up.

How the site is assembled with Docusaurus and React 19

The build is Docusaurus 3, with @docusaurus/core and @docusaurus/preset-classic both pinned to ^3.10.2 and React 19 on the front end, including react-dom 19.3.0. MDX support comes from @mdx-js/react, and the site uses clsx for conditional class names alongside prism-react-renderer for syntax highlighting.

The repository layout follows the standard Docusaurus shape: docusaurus.config.js holds the site configuration, sidebars.js defines the navigation, and babel.config.js is present for the Babel pipeline. Content is split between the docs/ directory and src/, with static/ holding images and other assets. The Markdown pages listed in the README, bootcamp.md, resources.md, beginners.md, regular.md, faq.md and the how-to/create-repo.md file, are ordinary Markdown with embedded images, which is why they can be read directly on GitHub without running the site at all.

The npm scripts expose the standard Docusaurus commands:

"start": "docusaurus start",
"build": "docusaurus build",
"serve": "docusaurus serve",

Running the build script produces a static site that can be hosted anywhere, which is the point of a Docusaurus site in a tutorial repository: the same content works as a browsable site and as plain Markdown for anyone who prefers to read it on GitHub or clone it.

Running the site locally and serving it from a container

The container setup is the most useful piece of engineering in the repository, because it lets anyone run the whole site without configuring Node on their machine. The Dockerfile is a two-stage idea in practice: it copies the manifests first so that dependency installation is cached separately from the source copy.

WORKDIR /usr/src/app

COPY package*.json ./
RUN npm ci

EXPOSE 3000

CMD ["npm", "start", "--", "--host", "0.0.0.0"]

The compose file keeps it to a single service named server, with the port mapping and a fixed container name:

services:
  server:
    build:
      context: .
    ports:
      - 3000:3000
    container_name: server

With that in place, docker compose up builds the image and serves the Docusaurus development server on port 3000. The npm start command is passed the host and port flags so the server listens on all interfaces rather than only on loopback, which is required for the port mapping to actually reach it from the host.

The .gitpod.yml at the repository root is the third option, giving a browser-based workspace that opens the project in a hosted development environment. Together the three routes, local npm, Docker and Gitpod, cover contributors on different platforms and make it straightforward to contribute a page without installing a .NET or JVM toolchain.

A Node version mismatch between package.json and the Dockerfile

The package.json engines field requires Node 22 or newer, stating the requirement as node >=22.0, and the browserslist targets for development are similarly current. The Dockerfile disagrees. Its build argument defaults to Node 20, and the base image is built from that argument rather than from the version the package.json declares.

The image therefore runs npm ci and npm start on Node 20 while the project declares that Node 22 is the minimum. Nothing in the repository explains the discrepancy, and it is the kind of thing that surfaces only when someone builds the image and then hits an engine warning or a dependency that refuses to run on the older runtime.

Fixing it means changing the build argument default from 20 to 22 and rebuilding, or passing the argument at build time. Until then, the Docker path is a slightly different environment from the local one, which defeats part of the purpose of shipping a container for a documentation site in the first place. It is a small defect, but it is exactly the kind of drift that a pinned Node version in CI would have caught.

Release tags and the version in package.json

The last push to the repository was on 2026-10-17, so the source is being worked on. The published releases tell a different story about content. The newest tag is v2.3.0, released on 2025-01-04, before that v2.2.3 on 2024-10-29 and v2.2.2 on 2024-09-19. Meanwhile package.json carries the version 2.3.1, a build that has no corresponding release tag.

For a static site the practical effect is small, since the content lives in Markdown and the deployment comes from whatever commit you build. But for anyone who wants to run a known-good copy, the gap between the current source and the last tagged release means a deploy from the main branch is not the same as a deploy of v2.3.0. The security fix pinning serialize-javascript to 7.0.3 in the overrides block also lives in the current source rather than in the tag, so a checkout of the last release runs an older dependency tree.

The licence is GPL-3.0, which is an unusual choice for a documentation site and worth understanding before you fork it or reuse the prose. The GPL's copyleft obligations attach to derivative works of the licensed material, so a fork that ships modified versions of the guide pages falls inside them. This is a description of the licence terms and not legal advice, and the LICENSE file in the repository is the text that governs.

Where this project does not fit

For a developer who already has a working knowledge of Git and GitHub, the repository offers little. The content is introductory by design: the How to page covers creating an issue and opening a pull request, which is a sensible first contribution but a solved problem for anyone who has shipped code before.

The bigger limitation is durability of the sources. A large part of the archive consists of Twitter threads and blog posts written during a specific bootcamp period, which were posted to platforms that change, and where individual posts can be edited or removed. The repository's value is that it keeps copies of that material under version control, but it cannot guarantee that every external video it links to stays available.

It is also a single-author resource. The Regular Content page gathers posts from community members, and the Learning Resources page points outward, but the structure and the teaching voice are one person's. There is no versioning of the guide content by date, no localisation, and no exercise or self-check that would let a learner verify that they understood a procedure. For a structured curriculum with assessments, look elsewhere; for a friendly walkthrough that a new contributor can read in one sitting before making a first pull request, this is exactly the right size.

Editorial conclusion

Use this repository if you are teaching Git and GitHub to people who have never forked a repository, or you want a self-hostable copy of one author's beginner material you can point new contributors at. It is the wrong tool for an engineer who already knows the workflow, and it is not a substitute for the official Git and GitHub documentation it links to. Before deploying your own copy, fix the Node version mismatch between the package.json engines field and the Dockerfile, and check that the version you deploy carries the docs content your learners need, since the newest published release is v2.3.0 from 2025-01-04.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Pradumnasaraf/open-source-with-pradumna on GitHub
3. Project website
4. README
5. Releases