Making an open source package - lessons learned

Making an open source package is pretty hard in 2024. Expectations are high, and there’s a lot to take into account. I recently developed an open source package. This talk covers what worked, what didn’t work, what I would do again and what I would do differently.

I developed an open source package called “scores” ( https://github.com/nci/scores , https://scores.readthedocs.io/ ). This is not a presentation about what “scores” does, but instead covers the lessons I learned. Despite being an experienced software developer and having used lots of open source software, there was still a lot to learn (and a lot to figure out) about open source package maintenance.

Every package is different, but this is what I did and these are the lessons I learned.

• Technical Matters:
  • How to lay things out on disk
  • Configuration files
  • Automated testing
  • Type hinting
  • Linting and other static analysis tools
  • Code layout and design
• Documentation:
  • What documentation to produce
  • Picking and using a tech stack
  • Rendering (documentation often renders differently in different locations)
• Ecosystem Integration:
  • How to fit in well with the tools around you
  • Versioning
  • Publishing to PyPI
  • How and what to automate
  • How to do releases
• Community Considerations:
  • Code review standards
  • Clear presentation of information
  • Understanding your user base and audience