Community
Breeze is an open-core project, and most of what moves it forward comes from people who run it. This page is the honest list of what actually helps, ordered by how much time each one takes, not by how much it helps us. Pick a rung that fits the time you have. Every rung puts your name somewhere real: a row in the compatibility matrix, a credit in the release notes, a byline on a script.
Install self-hosted Breeze on whatever you have. Weird hardware is especially useful: an old Synology, Proxmox on a consumer board, an ARM SBC, the server in the closet. Then file a 5-field environment report: hardware, OS, endpoint count, what worked, what did not.
What happens next
Your setup gets a named row in the public compatibility matrix, so the next person on the same hardware knows it runs before they start.
Reproduce it first, then file with the issue template: version, environment, steps, expected versus actual, logs. A report we can reproduce gets fixed; a vague one gets a round of questions.
What happens next
Every report gets a human response within 2 business days. We do not promise fix timelines. When a community-reported bug ships fixed, the release note credits the reporter.
If you run Breeze in production, write a review when the listings are live. Say what is broken too. A 4-star review with specifics does more for us, and for the next MSP evaluating us, than a vague 5-star.
The honest state: Breeze has no G2 or Capterra listing yet. We are claiming both now.
What happens next
Tell us on Discord that you would write one and we will ping you the day the listing is live. The review is the byline.
Fix what confused you during your own deployment, while it is still fresh. Typos and broken commands count. Deployment guides for unusual setups are the highest-value target: if you got Breeze running somewhere the docs do not cover, write down what you did.
Docs PRs go through the same one-click CLA as code. Rung 6 explains why.
What happens next
Merged docs changes ship with your contributor credit on the page.
Monitoring checks, remediation scripts, automations you already run on your own fleet: package one up and share it. The community scripts library repo is being stood up now. It will be MIT licensed with no CLA, and every submission gets maintainer review before it is listed. Reviewed, not certified. Read anything before you run it on a client fleet.
Until the library repo is live, Discord is where to share. Post the script and what it does, and we will move it into the library when it opens.
What happens next
Every accepted script keeps your byline.
If you want to build the product itself, start with a good first issue. The label is maintained on purpose so there is always a scoped first step.
Breeze is an open-core project; contributions need a CLA so the project can survive. It is one click on your first PR. Contributors who show up consistently have become paid contractors on the project.
What happens next
A maintainer reviews your PR, and merged work is credited in the release notes.
No time? This rung takes money instead
Breeze is crowdfunding a white-box penetration test: an outside firm, full scope, every dollar of the campaign public, and the company matches what the community puts in. The full report gets published after remediation. Nobody in RMM publishes audits. Sponsors are funding the thing they would want to read before trusting any vendor, ours included.
The honest state: the campaign has not launched yet. GitHub Sponsors is live now, and campaign details are coming on the blog.
What happens next
Sponsors are named on the audit page and in the published report post.
Questions? Ask in the Discord or open a GitHub Discussion. The people who build Breeze read both.
Still evaluating Breeze?
Get your questions answered by the team that builds it. 20 minutes, no deck.
Book a call