Aurum
Download

Open Source Maintenance

A healthy repository with clear licence, docs and policies, weekly triage and review rhythms, predictable releases, safer supply chains and the boundaries that keep a maintainer going for years.

Free · Mac (Apple silicon) and Windows · v1.0.0 · Other platforms

Then open the Marketplace in the app, search for Open Source Maintenance, and click Install. It goes into your own files, and works offline from then on.

What it installs.

1

Pillar

1

Area

50

Projects

200

Starter tasks

⚙️ Software Engineering

Open Source Maintenance

Maintaining an open source project, triaging issues, reviewing contributions, cutting releases and avoiding burnout as a maintainer.

  1. Repository health audit for maintainers
  2. Maintainer time budget and boundaries
  3. Licence choice recorded in the repository
  4. Project scope and non-goals statement
  5. README that answers a newcomer's first questions
  6. Contributing guide with a working local setup
  7. Code of conduct with a named enforcement contact
  8. Issue and pull request templates
  9. Issue label scheme for triage
  10. Security policy and private reporting channel
  11. Weekly issue triage hour
  12. Pull request review queue rhythm
  13. Stale issue and pull request policy
  14. Predictable release cadence and checklist
  15. Changelog built from merged pull requests
  16. Support questions routed to the discussion board
  17. Contributor CI matrix upkeep
  18. Quarterly roadmap and milestone grooming
  19. Monthly maintainer energy check-in
  20. Testing against major downstream dependents
  21. Reviewing first-time contributions kindly and firmly
  22. Declining feature requests with a clear reason
  23. Semantic versioning and deprecation practice
  24. Asking for minimal reproductions
  25. Licence compatibility basics for incoming code
  26. Writing release notes users actually read
  27. Mentoring a regular contributor toward commit rights
  28. Good first issue pipeline
  29. Documentation site and versioned docs choice
  30. Funding model for the project
  31. Written governance model
  32. DCO or contributor licence agreement decision
  33. Second maintainer with release rights
  34. Automated release publishing with trusted publishing
  35. Moving the repository to an organisation account
  36. First stable 1.0 release
  37. Major version migration guide and release
  38. Contribution month preparation
  39. Conference talk or workshop about the project
  40. Annual maintainer report and contributor thanks
  41. Releasing research code alongside a paper
  42. Research software sustainability past the grant
  43. Maintaining open source alongside a day job
  44. Company-sponsored project with outside contributors
  45. Adopting an abandoned or unmaintained project
  46. Handing over or archiving a project responsibly
  47. Coordinated vulnerability disclosure and advisory
  48. Supply chain hardening of the release process
  49. Usage signals from downloads and dependents
  50. Maintainer team roles and decision rights

Where it starts.

Each project arrives with its purpose, milestones and first tasks written out. Here is how the first three read.

Repository health audit for maintainers

Before adding rules or rituals, look at the repository the way a stranger arriving from a search result would. Counting open issues by age, unanswered pull requests, missing community files and the date of the last release tells you which of the projects below matter first, and gives a baseline to compare against in six months.

First tasks

  • Open the repository's community profile page and note what is missing
  • Count open issues and pull requests older than six months
  • Record the date of the last release and last outside contribution
  • Write the three worst gaps into a maintainer notes file

Maintainer time budget and boundaries

Unpaid maintainers rarely burn out from one huge task; they burn out from answering every notification within the hour. Deciding how many hours a week the project gets, when you are off, and how quickly users can expect a reply turns an open-ended obligation into a job with edges.

First tasks

  • Decide how many hours a week the project gets and write it down
  • Turn off forge email notifications except mentions and review requests
  • Add an expected response time sentence to the contributing guide
  • Log the hours you spent on the project this week @recurring(weekly:sun)

Licence choice recorded in the repository

Code without a licence is, in most countries, not legally reusable, so serious users and companies quietly walk away. Choosing a recognised open source licence, putting the full text in a LICENSE file and stating it in the package metadata makes the terms clear to people and to the scanners their employers run.

First tasks

  • List what you want users and companies to be allowed to do with the code
  • Compare two permissive and one copyleft licence against that list
  • Commit the chosen licence text as LICENSE at the repository root
  • Set the SPDX identifier in the package manifest

Make it yours.

Install Open Source Maintenance, then tell Aurum the date you're aiming for. It checks whether the plan fits the weeks you actually have.

Free · Mac (Apple silicon) and Windows · v1.0.0 · Other platforms

Blueprints are general information to help you organise your own work. They are not medical, financial, legal or other professional advice. See the Terms.