[ADD] oca_monetize

[hbrunn]

here a sketch of what I meant during @thomaspaulb's talk concerning oca_monetize.

I think this is a good way to start, because

• it keeps everything open
• it's opt-in for authors, so contributors who don't like the whole concept just don't depend on this in their modules
• we need very little infrastructure changes (just need to define the product and add some code to generate the key, write some text about why this is a good idea)
• it's quite similar to what wikipedia and libreoffice do successfully
• we appeal to the best in people, not the worst

In my opinion we should then hand out such keys to all companies who have people in PSCs or module maintainers (so that we reward being active in the community), everyone else should buy it.

I kept the "key" and verification of it very basic, because anyone who wants to bypass this does so anyways, so it doesn't make sense to do anything fancy here imho.

To generate your own "key", say:

import base64
import json
version = '1.0'
start_date = '2024-01-01'
end_date = '2024-12-31'
partner_name = 'Hunki Enterprises BV'
subscription = dict(version=version, start_date=start_date, end_date=end_date, partner_name=partner_name)
print(base64.b64encode((json.dumps(subscription)).encode('utf8')).decode('utf8'))

[JordiBForgeFlow]

@hbrunn if a contributor does not like this concept cannot use the modules where it has been applied? Has to inherit the method to deactivate it in another module?

[hbrunn]

well that's possible, but I'm not sure an author should. If I developed some great widget module and decided I want this to be monetized for OCA, I'd expect authors depending on it to respect that.

[thomaspaulb]

I think a warning appearing for all users, perpetually, is perhaps too much nag for people to live with on a daily basis. CEO's will complain that their users get confused by it, it takes space on the screen, etc.

I think the message should be:

• Directed at the higher end users, so maybe the ones who have Administrator rights only - these should normally be the ones deciding what to pay for
• Temporary - eg like Wikipedia has these temporary funding runs, in order not to affect usability so much
• Friendly - we're asking / trying to convince, not requiring

What I thought really sympathetic and what made me pay is how the creator of KeePass for Android pops up a message after each Oktoberfest has passed, asking to buy him a beer at the Octoberfest if you like the app. If you don't like the app enough, by all means don't do it.

This serves to not annoy people, eg you can easily click the message away, but even a yearly reminder serves already the purpose of making people aware that there is a team of volunteers behind this that created a specific value for you, and explains you how you can contribute. That's already a win compared to the current situation of most people being completely unaware.

[thomaspaulb]

... and if that's the approach, I'd rather call this oca_information - inform people about what OCA is and in what ways they are able to pay

[thomaspaulb]

Perhaps this could be a text that a scheduled action regularly refreshes from an online source, in order to keep it up to date.

[OSevangelist]

If i remember right the "call to action" from Wikipedia (and others) usually also contains different options for support that try to resemble the grade of utility to the user. That leads from small amounts (one time) to regular contributions. I don't know how something like that would be perceived among contributors / OCA members, but i would prefer a system that is able to differentiate the link to the "subscription product" according to the overall share of the OCA code base use in the concrete installation (and dependent on oca_monetize) as well as the number of users on the DB. As both maybe conceived as sensitive data and and GDPR issue after all, we might want to let the end user control what he is actually sending to the OCA to have his fair subscription package link generated.

[thomaspaulb]

If I developed some great widget module and decided I want this to be monetized for OCA, I'd expect authors depending on it to respect that.

I'm not sure if I feel comfortable with the idea of original authors deciding on this stuff. It could also cause a rift in visions, throwing up a barrier for others contributing to a module that is "in the other camp".

[sbidoul]

The whole idea is very interesting (which is not to say I'm 100% convinced we should dot it yet). Thanks for proposing it in a concrete PR, Holger!

it's opt-in for authors, so contributors who don't like the whole concept just don't depend on this in their modules

I'm hesitant about that. Since the collected funds would go to OCA for the benefit of the community, and not the author directly, why would an author contributing to OCA object to that? By opting out, would it also mean a maintainer also opts out of being funded in the context of a possible future maintenance programme?

I'd rather call this oca_information - inform people about what OCA is and in what ways they are able to pay

This makes sense to me. A few years ago there was also an idea of an oca_base module which would send anonymous statistics about installed OCA modules, so we get a feeling of which are used most and inform prioritization of efforts.

[hbrunn]

I'm summarizing the input I got here and elsewhere:

• rename to oca_information (but then if we emuleate wikipedia's call to action, why not oca_call_to_action?)
• don't try to enforce anything, just add a badge asking for a financial contribution
• don't show this to everyone, only admins
• don't show it always, only sporadically (what invervals? do we want to keep showing this to orgs that already contributed?)

In my opinion, this absolutely should not phone home, so any kind of after install updates is out I think.

Is @OCA/board on board with the whole idea? We'll need your collaboration to set up some page(s) for this.

[thomaspaulb]

I'd say that if this goes through, it should be an all or nothing affair, not something that individual contributors can choose to depend on or not - which automatically means this needs to part of the bigger discussion of how and why to monetize. Since everyone has gone wild again with ideas, I'm not sure if the board is ready to reopen the whole discussion and fit in this and other ideas, or they would rather want to stick with the existing plan that has been presented at the OCA days, and try that first before pivoting. But maybe they can comment on that :-)

[vdewulf]

Hello,
Thanks a lot for the concrete proposition and all the feedback. We have a Board Meeting this Wednesday, we will discuss this idea together with all ideas received in the shared pad, and we'll see how we can proceed.
I'll come back here with the conclusion.

[OSevangelist]

@hbrunn / @sbidoul

would you also strongly oppose a "phoning home" on module usage statics if the admin opts in to sent anonymized usage statistics ? I am asking, because i think there is lots of value in collecting this information to better steer focus, priorities and funds of the OCA (after we collected them) and having two modules for "calling to action" with regards to the OCA is probably overhead.

[sbidoul]

To clarify, the kind of phoning home I have in mind is sending a hash of the database id + the list of OCA modules¹ installed, so nothing sensitive or permitting to identify the user/company would be stored in our database. And this could be opt-out (my preference) or opt-in.

Footnotes

1. How to identify an OCA module is TBD: could be based on the URL (https://github/oca...) or the author field containing Odoo Community Association. ↩

[hbrunn]

@vdewulf any news on this? By now I'd be of a mind to make this just a gentle reminder as outlined in #57 (comment), with some text linking to the sponsorships in the webshop and the random Donation products.

I think depending on this absolutely must be the choice of the author/maintainers of a module, trying to shove that down anyone's throat will not work and would be wrong in my opinion as there are different legitimate points of view on this.

If however an author of some widely depended on module decides do add a dependency on this, well, then tough luck for anyone further up in the dependency tree who dislikes it.

Phoning home: I still find this a very delicate issue, and another discussion anyways for how I envision this module by now.