Introduce Free2Wait monetization

[PatchRanger]

Please refer to https://github.com/Free2Wait/composer-free2wait .

In short: this PR proposes a way to monetize open-source development of your project. The idea is similar to how free-to-play works in gamedev industry: "You are free to wait for the package download - but in case if time is money for you, please consider buying non-waiting access to the package - every cent goes to the package developer to incentive the open-source development."

According to packagist statistics of your package https://packagist.org/packages/aidantwoods/secureheaders , in theory it could have brought to you about 4034 (installs) 0.03 (conversion installs-to-sale) 5 (price of each non-waiting access per month) = $605.1 .

Please give me your feedback about the idea: what do you think? Are you interested? Do you have any suggestions? Concerns?

Would be glad to receive any feeedback. Thank you for attention.

[aidantwoods]

Hello, thank you for the pull-request. I have decided not to merge it for a few reasons:

• The proposed package isn't finished: e.g. there's a hard-coded IP address with an @todo above it. Regardless of what they are, I'd like to be able to test changes before I'd incorporate them into the library.
• The proposed package isn't licensed. This means I wouldn't be able to use legally use the code.

I'm not opposed to the idea of generating revenue from an open-source project, however I don't personally like this model for a few reasons: (Quoting your README here)

Every time when Composer installs or updates any package, it checks:

• Whether the package, being installed/updated, has a special setting, corresponding to the plugin: it means it doesn't interrupt or disturb the way it works for packages that didn't voluntary accept its behavior.
• Whether the IP, where Composer is run, have not already bought non-waiting access for month to download this concrete package.

If all packages did this, using composer would be a nightmare. A large package which has a few dependencies itself, may end up resolving to many dependencies – for sake of argument lets say 30 dependencies are resolved. If every package added a 10 second wait this would lengthen the install time by 5 minutes.

• If I wanted to avoid this wait I'd have to pay $150/month. I personally can't afford to pay this for the sake of not waiting, especially for each project I would potentially be working on.
• Having this occur on each update too would severely discourage users fetching updates. Getting in the way of (security) updates is dangerous.

I think a good measure of whether something like this would work is to consider what composer would look like if every package used it. To me it doesn't look like something I'd personally want to use.

[PatchRanger]

@aidantwoods Thank you for your feedback! It is highly appreciated!

have decided not to merge it

You're not supposed to merge it as is: I just wanted to get your potentional or conditional consent to merge it in the future.

The proposed package isn't finished

Totally correct. As I've mentioned in README.md it's a proof-of-concept - and the goal of the current stage is to gather feedback about value for developers.

Regardless of what they are, I'd like to be able to test changes before I'd incorporate them into the library.

That's just a stub-IP, it is going to be replaced to the IP of the host, where Composer is being called.

The proposed package isn't licensed. This means I wouldn't be able to use legally use the code.

Thanks for the point, I missed it, am going to append license file soon (after corresponding research which license suits better, almost sure GNU GPL v2 is good enough). I've created the corresponding issue https://github.com/Free2Wait/composer-free2wait/issues/1 .

If all packages did this, using composer would be a nightmare.

Nice catch! Thank you for detailed argument. I was thinking about it - but would prefer to postpone the solution for this issue to later stages. But as you raised it, I feel obligated to clarify the point: 10 seconds and $5 are default values to make things started - in the future I think we should be gathering analytics to be able to replace the values accordingly.

In my view the best way to do it is to perform A/B-testing all the time by several values of price and delay in order to maximize the revenue (which is price multiplied by conversion). It means that the algorithm should select the values of price and delay, which make users willing to pay more. If the price or delay set too high (turning it into "nightmare"), the conversion will decrease - and the algorithm should understand that it's time to low values.

The idea is for sure not to make users crying - the idea is to discover sustainable way of open-source development monetization.

TL;DR With increasing number of packages adopting this way of monetization, the price and delay should be decreased - to the values, which make users happy again. Ideally, there should be an automatic algorithm, performing A/B-testing all the time.

I think a good measure of whether something like this would work is to consider what composer would look like if every package used it.

Totally agreed: if it's not going to work globally, it is not worth to work locally.

To me it doesn't look like something I'd personally want to use.

I hope I responded to your concerns, please let me know.

[aidantwoods]

I think I still fundamentally dislike the idea of degrading user-experience for the sake of profit – even with slightly adjusted specifics on how much the experience is degraded, or how much undoing that is going to cost. This is mostly because updates are really important and making them more cumbersome sets everyone backward, literally. Getting people running the latest version is hard enough without making updates actively difficult or obtuse. It is simply too great a cost.

I think that making it easier to support the developers from whom work is used is a worthwhile pursuit, I just don't think this particular model is the way to do it.

I'd suggest looking into the model that Brave uses for awarding websites with funds from those that wish to contribute. But an important thing to note IMO, is that the user-experience is indistinguishable regardless of whether or not you decide to contribute. Open-source should not have tiers.