Open Source Participation

Why Smarter. Open source is usually taught by pointing students at a huge project, where a newcomer’s pull request can wait months, or at a toy repository that nobody else uses. Smarter is in between: a real platform in production, developed entirely in public, small enough that a contribution is noticed, and run with the same practices as much larger projects:

  • A clear license. The AGPL-3.0, whose network clause makes it a good case study: it applies when a modified version is offered to users as a service, not only when it is distributed.

  • Published rules. A contributing guide, a code of conduct, a security policy for private vulnerability reports, issue forms, a pull request template and a CODEOWNERS file.

  • Automation that teaches the workflow. Every commit message is checked by commitlint, the pre-commit hooks check formatting, spelling, security and secrets, and semantic-release turns conventional commits into versions and changelogs on four release branches. The project has published more than five hundred releases.

  • Many ways in. Issues, discussions and pull requests in the main repository; more than nine hundred pages of documentation; and smaller repositories in the smarter-sh organization, such as the Go CLI, the chat component, the VS Code extension and the Python SDK, where a first contribution is easier.

  • A project whose health students can measure. Twenty-two contributors, one code owner, and a public history of every release, so the bus factor, governance and sustainability are concrete, and a class’s contributions make a visible difference.

A course or a capstone can end with a real contribution to a real project. A merged pull request is a public, verifiable piece of work for a student’s portfolio.

What the course covers. How open source works: motivations, roles, governance and funding; copyright, permissive and copyleft licenses, the AGPL and compatibility; reading a project’s rules; the pull request workflow: forks, branches, conventional commits, hooks, CI and semantic versioning; documentation contributions in reStructuredText; choosing a substantial issue and asking first; code contributions that follow a project’s patterns; giving and receiving code review; coordinated disclosure, CVEs and supply chain security; project health, CHAOSS metrics and the bus factor; and sustaining contribution, from triage to becoming a maintainer.

Look at.

Each course plan lists every file and page that it uses under Smarter in the Source Code.

Read. Contributing, Code of Conduct, Developer Guidelines, Semantic Versioning Guide, Documentation Style Guide & Technical Reference.

Exercises.

  • Choose an issue, discuss the approach with the maintainers in the issue before writing code, and see a pull request through review.

  • Improve the documentation: a clearer explanation, a missing example, or a corrected command. This is the easiest first contribution, and one of the most valued.

  • Read the AGPL-3.0 license, and explain what it allows and requires, and how it differs from the MIT and Apache licenses.

  • Follow one feature from its conventional commit to the release and the changelog entry that semantic-release produced from it.

Note

Contact the maintainers in GitHub Discussions before a large class starts contributing, so that they can label suitable issues as good first issue and plan for the reviews.

Course plans. Three complete, ready-to-teach plans, each with a schedule, graded assignments and rubrics, two capstone projects, recommended texts, further study and technical prerequisites. See Course Formats and Grading for what the formats have in common.

See the Smarter Instructor Guide to install Smarter and set up a class.