I made the recipe-filter extension you mentioned, which has the source available on GitHub at the link you gave and thus is trivial for others to fork, modify, install locally, and so on. All extensions wind up as an archive with JS that one could modify, but I've made this one especially transparent.
With your ExtensionPay, I could add a check to see if someone has a subscription for some new features I'm working on, but it feels like something's missing checking in that code into a public repo with no server necessary for the processing the extension requires. The trust is handled in the JS running on the users' browsers.
> As Mozilla recommends, it's better to focus on making a good product for the majority of users that won't hack your extension.
It's fairly popular (a bit over 58K active users) and someone already forked+modified the extension for another browser. It seems like if I charge some amount for the new features, it would be trivial for someone to fork it, remove the subscription check, and distribute it as a new extension. Similarly, they could add their own payment system and charge for the clone by changing just a few lines.
As it stands, giving it away for free means there's nothing at stake. Adding a payment check in plain JS feels like it would generally work but incentivizes other putting in the time to crack it or clone it for profit and there's no great way back from that point.
Well, your extension has 50k+ users. What percentage do you think would try to get around the payment system? I'm guessing most of your users aren't that technical, they just hate those recipe card things :) And how many users does the next most popular fork of your extension have?
Notion Boost is also an open-source extension on Github with 20k+ users and has made a bunch of money from users paying for pro features. So there's at least one data point in your favor.
I'd also like to point out that you're speculating! You don't know what will happen :) One reason I made ExtensionPay was so that developers (including me!) can just try monetizing their extensions with no costs and very little time commitment and see what happens empirically — get the data.
How were you thinking about monetizing your extension anyway? Subscriptions? One-time? Freemium?
I made the recipe-filter extension you mentioned, which has the source available on GitHub at the link you gave and thus is trivial for others to fork, modify, install locally, and so on. All extensions wind up as an archive with JS that one could modify, but I've made this one especially transparent.
With your ExtensionPay, I could add a check to see if someone has a subscription for some new features I'm working on, but it feels like something's missing checking in that code into a public repo with no server necessary for the processing the extension requires. The trust is handled in the JS running on the users' browsers.
> As Mozilla recommends, it's better to focus on making a good product for the majority of users that won't hack your extension.
It's fairly popular (a bit over 58K active users) and someone already forked+modified the extension for another browser. It seems like if I charge some amount for the new features, it would be trivial for someone to fork it, remove the subscription check, and distribute it as a new extension. Similarly, they could add their own payment system and charge for the clone by changing just a few lines.
As it stands, giving it away for free means there's nothing at stake. Adding a payment check in plain JS feels like it would generally work but incentivizes other putting in the time to crack it or clone it for profit and there's no great way back from that point.