Open5e is a community-driven project focused on making D&D accessible, open, and fun. We welcome any and all contributions!
The best way to get involved is to join our discord
You can also check out our current roadmap, which has our high-level goals laid out.
Here is an ongoing list of content we'd love to add to the site. Feel free to offer additional ideas.
All contributors are welcome, but you'll find it easiest to contribute if you're familiar with one of the following areas:
- Python/Django. This is the framework for our API (docs & readme).
- VueJS. This is the framework for our website (docs & readme). React or Angular experience will also serve you well here!
- JSON. Our data is stored as a set of JSON files. You don't need to be an expert, but currently you need some comfort with JSON to contribute data.
- Blender, Photoshop, or or art skills. Creating artwork to support our data is a major ongoing project.
- Writing. There's a lot of non-SRD content we could backfill, but we're not all writers.
Take a look around at issues in areas you're comfortable with, hop on the discord! Many issues are tagged with help-wanted
and good first issue
. You'll find these particularly approachable or interesting.
When you're ready to submit an issue, we do all PRs against staging
branches, which auto-deploy to test environments. We make regular cuts over to production once we're comfortable with what's there.
Open5e is Open. Everything we create should be available for others to use as they see fit. To that end, we should only include content that can be licensed for commercial use, or that we own. Our licenses should be similarly open, pulling from copyleft and open source movements.
Open5e is accessible. There should be as few hurdles to accessing the content and site as possible. No paywalls, no pop-ups, no ads eating up all your bandwidth. Someday someone will force us to add API tokens, but we've even avoided that up until now!
We are against intrusive advertising. This is not a business. It is a project for the community. The goal is not to make money, beyond covering costs. Anything we do promote on the site should be something we genuinely think people using it will appreciate, and they shouldn't see those recommendations unless they seek them out.
We are a library, not a publisher. Especially on the API side, we avoid making changes to the content or adding our own new rules. But we don't let this get in the way of being useful. Where there is something important that we don't have access to, we may choose to create an equivalent in the same spirit as the original. This is especially acceptable for non-rule content like flavor text, art, and descriptions.
People depend on us. We can't break existing functionality, even if the new functionality would be cooler, easier, or better. If we do, we need to warn people so they can maintain their own projects. As a general rule, adding new stuff is safe. Structural changes or removal of existing stuff is risky.