A quick overview of takeaways from our first year of offering paid support for Mongoose, and why Tidelift is often better than just paying projects directly for support.
- Subscribers are all SMBs. We often get bug reports from larger cos - Cisco, Atlassian, etc. but they don’t subscribe. Likely because Mongoose isn’t as prominent in their eyes, and the devs that work on Mongoose-related projects don’t have budgets.
- No deluge of support requests! Most subscribers only have a few requests per year.
- Most subscribers prefer to interact via Slack rather than via GitHub. GitHub issues have friction, especially with issue templates. Slack provides a less formal environment where subscribers can ask quick questions.
- Subscribers tend to subscribe more as a way to support the project, say thank you, and occasionally get a quick bit of help. They aren’t striving for high ROI.
- Mongoose is better suited for this approach as a framework than, say, a polyfill for JavaScript’s String startsWith() function. Mongoose has a fairly broad surface area, and it is entirely possible for an entire SMB to use Mongoose for all operational database calls.
Where Tidelift makes this better:
- Tidelift is better at selling to enterprises! Executives at big companies need to look at the big picture because most BigCos have numerous projects all using numerous different frameworks, programming languages, etc.
- Most companies don’t need that much support from one particular project, and even then the support requests are typically not urgent. Tidelift makes paying for OSS more compelling by aggregating, and can help make maintainers’ lives easier by helping answer requests are not code related, like copyright or license questions.
- Works for all projects, even tiny polyfills.
A quick overview of takeaways from our first year of offering paid support for Mongoose, and why Tidelift is often better than just paying projects directly for support.
- Subscribers are all SMBs. We...