-
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make the case to restate ubiquity #236
Comments
So are we essentially trying to find the ratio of inactive to active installs from 24.1.0+ to try and estimate the amount of active installs we have in the versions 20.0 to 23.12.0, where we don't have that data? |
Yes, with the addition that we also have active vs. inactive in versions prior to 20.*, yes? What would be interesting is to see the ratio of active vs. inactive over time for all versions where we can get both numbers. |
Yep, we do have the info for active vs inactive in the older versions too. Good call |
Keep in mind that there are companies ahem that run self-hosted behind isolated networks. |
Hehe. ;-) Yes, we've always known that reported instances is a lower bound, that's still very much true. It's quite eye-opening to me to realize that our self-hosted community is much larger and alive than we previously could see easily. Worth investing in! :-) |
Lost momentum on this, gonna close it out for hygiene. |
Self-hosted is a component of Sentry's ubiquity metric (the "90k orgs" stat we put on all of our job descriptions, for example). With getsentry/sentry#62441 we now have quite a different picture🔒 for self-hosted.
We are already using this new understanding in OSPO (e.g., #232). This ticket is to track working with Sentry's Biz Ops team to update our overall company understanding for reporting. The task is to:
The text was updated successfully, but these errors were encountered: