3 ms·

> Monetization via Paid Premium Version / Open Core This point is interesting, because it assumes the only way to do premium is with a closed-source version, l

> Monetization via Paid Premium Version / Open Core This point is interesting, because it assumes the only way to do premium is with a closed-source version, losing the open-source benefits. Personally I've had good success (i.e. comfortably enough income as a solo bootstrapped project that I can work on open source full time) doing a freemium approach that's 100% open-source for http://httptoolkit.tech http://httptoolkit.tech Yes, anybody can fork the project and remove the payment checks (here: https://github.com/httptoolkit/httptoolkit-ui/blob/5cf0b10c6f8bb902ee5261414e8a21a45904690d/src/model/account/account-store.ts#L108 https://github.com/httptoolkit/httptoolkit-ui/blob/5cf0b10c6...) but it's a non-trivial hassle to fork everything and hook it all up, and means ongoing maintenance work to manage a fork forever, so at the price it's not really worth any serious professional's time (and I give out free licenses for everybody who contributes to the code anyway). Works well, lets you stay 100% open source, which is good for everybody and encourages contributions, and you can still make enough money to fund development (never going to make anybody a billionaire, but that's not the point).

paydevs 4y ago
Interesting, can you elaborate how a "premium user" pays if he wants to host the system by himself? Does he contact you directly or is there a payment system where he gets a code?
- pimterry 4y ago
  To access the paid bits, you log in with your email (passwordless: it emails you a code to login) either online (https://httptoolkit.tech/get-pro/ https://httptoolkit.tech/get-pro/) or in the app itself, and you complete an online checkout (managed by Paddle.com) to subscribe for X duration. As long as you're logged into the app itself, it makes a check on startup with your auth token to see if your current subscription is still active. If it's active, all the paid features turn on. No passwords, no license keys, auth & subscription data storage managed by Auth0, and one tiny accounts server that glues the checkout & auth0 together (which is also open source: https://github.com/httptoolkit/accounts/ https://github.com/httptoolkit/accounts/). That's the normal flow, but assuming you don't change the code it works the same whether you use the hosted deployment or you fully self-host the core app.
josevalerio 4y ago
I really like this approach. Typically, we're building some sort of tool that does some undifferentiated heavy lifting that is not core to our customer's business. The last thing they want is to dedicate their most expensive resource (dev time) to maintain a tool that they themselves didn't even build from scratch. Nice :)
- pimterry 4y ago
  Exactly. You do probably lose income from a small percentage of dedicated hobbyists who're determined to use it for free and self-host, but those are probably not your core target market anyway. And I think many of those people are the kind of people likely to add their own features and contribute them back, and making it easier makes to fork & self host makes that far more likely.
netizen-936824 4y ago
I agree with the required effort needed, but doesn't it only take one person to fork it? Once that fork is out there and maintained, the obvious choice for most people would be to use the free fork
- pimterry 4y ago
  Could happen! There's a bunch of reasons why I'm not super worried about this though: - It is a fair bit of work for the person forking, including ongoing work to keep up to date indefinitely into the future as new features come out and the code changes, for no clear personal benefit to distributing it more widely. - Doing this properly is not free. Distributing desktop apps means paying for code signing certificates, which cost you a few hundred dollars every year. Without this, both Apple & Windows will loudly complain and show many scary warnings to very firmly discourage all users from using your software. - For the same effort (and zero cost) anybody doing this could instead contribute a feature, or bug fix, or docs improvement to the app, and I'd give them a free Pro account anyway. Seems like a strictly better deal. - Even if/when somebody does do this, the marketing moat is pretty strong. Making a significant number of users aware of such a fork would be a huge amount of work on its own, for no real benefit. - From a funding perspective, the most relevant users are well-paid software professionals, where the product is usually being bought by their boss and they just want something that works ASAP. Even if a free fork existed, they don't want to spend an hour digging around to find one that's trustworthy & up to date. - Most of the features are free anyway. The Pro features are literally targetted at professionals: people working in teams, setting up mocks for entire APIs, dealing with enterprise proxies & certs, etc. Not people trying to do some quick reverse engineering & testing. That means the people who want Pro are almost exactly the people for whom doing the work to fork & maintain the project isn't worthwhile. - There's a meaningful percentage of users who pay in part because they explicitly want to fund ongoing development on the software they're using, because they like the project. Those users don't even want to switch to a free fork. - Empirically, I've done this for a few years now, and AFAIK not one person has ever forked it for anything but their own personal use :-)
  - afarviral 4y ago

paydevs 4y ago

Interesting, can you elaborate how a "premium user" pays if he wants to host the system by himself? Does he contact you directly or is there a payment system where he gets a code?

pimterry 4y ago
To access the paid bits, you log in with your email (passwordless: it emails you a code to login) either online (https://httptoolkit.tech/get-pro/ https://httptoolkit.tech/get-pro/) or in the app itself, and you complete an online checkout (managed by Paddle.com) to subscribe for X duration. As long as you're logged into the app itself, it makes a check on startup with your auth token to see if your current subscription is still active. If it's active, all the paid features turn on. No passwords, no license keys, auth & subscription data storage managed by Auth0, and one tiny accounts server that glues the checkout & auth0 together (which is also open source: https://github.com/httptoolkit/accounts/ https://github.com/httptoolkit/accounts/). That's the normal flow, but assuming you don't change the code it works the same whether you use the hosted deployment or you fully self-host the core app.

josevalerio 4y ago

I really like this approach. Typically, we're building some sort of tool that does some undifferentiated heavy lifting that is not core to our customer's business. The last thing they want is to dedicate their most expensive resource (dev time) to maintain a tool that they themselves didn't even build from scratch. Nice :)

pimterry 4y ago
Exactly. You do probably lose income from a small percentage of dedicated hobbyists who're determined to use it for free and self-host, but those are probably not your core target market anyway. And I think many of those people are the kind of people likely to add their own features and contribute them back, and making it easier makes to fork & self host makes that far more likely.

netizen-936824 4y ago

I agree with the required effort needed, but doesn't it only take one person to fork it? Once that fork is out there and maintained, the obvious choice for most people would be to use the free fork

pimterry 4y ago
Could happen! There's a bunch of reasons why I'm not super worried about this though: - It is a fair bit of work for the person forking, including ongoing work to keep up to date indefinitely into the future as new features come out and the code changes, for no clear personal benefit to distributing it more widely. - Doing this properly is not free. Distributing desktop apps means paying for code signing certificates, which cost you a few hundred dollars every year. Without this, both Apple & Windows will loudly complain and show many scary warnings to very firmly discourage all users from using your software. - For the same effort (and zero cost) anybody doing this could instead contribute a feature, or bug fix, or docs improvement to the app, and I'd give them a free Pro account anyway. Seems like a strictly better deal. - Even if/when somebody does do this, the marketing moat is pretty strong. Making a significant number of users aware of such a fork would be a huge amount of work on its own, for no real benefit. - From a funding perspective, the most relevant users are well-paid software professionals, where the product is usually being bought by their boss and they just want something that works ASAP. Even if a free fork existed, they don't want to spend an hour digging around to find one that's trustworthy & up to date. - Most of the features are free anyway. The Pro features are literally targetted at professionals: people working in teams, setting up mocks for entire APIs, dealing with enterprise proxies & certs, etc. Not people trying to do some quick reverse engineering & testing. That means the people who want Pro are almost exactly the people for whom doing the work to fork & maintain the project isn't worthwhile. - There's a meaningful percentage of users who pay in part because they explicitly want to fund ongoing development on the software they're using, because they like the project. Those users don't even want to switch to a free fork. - Empirically, I've done this for a few years now, and AFAIK not one person has ever forked it for anything but their own personal use :-)
- afarviral 4y ago