devlooped / moq

The most popular and friendly mocking framework for .NET
Other
5.93k stars 801 forks source link

SponsorLink and supporting OSS more broadly #1374

Closed kzu closed 1 year ago

kzu commented 1 year ago

Trying to aggregate the various issues into one to collect feedback.

I invite everyone to read the SponsorLink announcement to understand the intention behind it. No nefarious purpose, I promise! ๐Ÿ™. I also wrote a follow-up post with additional context based on feedback so far.

With that in mind, I'm obviously open to suggestions that help achieve both your goals and mine :)

SponsorLink is now OSS too

An improved and more privacy-preserving implementation could use your feedback

NOTE: 4.20.2 removes SponsorLink since it breaks MacOS/Linux restore. I'll take the opportunity to collect more feedback. The underlying issue still needs addressing, IMHO.

NOTE: SponsorLink won't be coming back until I improve on the suggestions made here. In particular, those mentioned in the announcement on OSS'ing it

alexjamesbrown commented 1 year ago

No nefarious purpose, I promise

Privacy Statement:
Trust me, bro

kzu commented 1 year ago

@jakoss fair point. So org-wide sponsoring should be an option. ๐Ÿ‘

@sgtwilko GUID: chicken-egg. You install the lib, how do I know you're already a sponsor? Generate a local GUID: how to match against a server-side GH app that's completely decoupled from your machine? ๐Ÿค”

kzu commented 1 year ago

@mason-bially "(or you know, you could pay the developer for their work)." ๐Ÿ˜น

BenjaminAbt commented 1 year ago

You install the lib, how do I know you're already a sponsor?

@kzu no matter what you want, you have to obey the law(s). What you do with personal data, SponsorLink and Moq is forbidden - at least in Europe.

DanielCordell commented 1 year ago

@sgtwilko GUID: chicken-egg. You install the lib, how do I know you're already a sponsor? Generate a local GUID: how to match against a server-side GH app that's completely decoupled from your machine? ๐Ÿค”

@kzu Is there really a requirement to be able to check if someone is a sponsor though? If the mechanism for alerting users was as simple as a console message then people wouldn't need to "turn it off". Of course it would be less obtrusive, but that's the trade off to keep users feeling confident in your tools.

Someone said you could have a "private" package if anyone is a verified sponsor, that could be an approach? You could start creating new features that you have to use the "private" package if you want to access.

thaumanovic commented 1 year ago

using the work of unpaid volunteers with no consideration for how they are compensated for their time and labor

I don't think you understand the concept of volunteering if you think compensation is involved. The beauty of OSS is that it's at-will and nobody is forced to do or provide anything. If a maintainer decides to stop supporting a project one day, nobody can reasonably complain about it - they still have the option of forking and maintaining themselves.

While it's nice to have some form of income from your efforts, I don't think it's a necessity. Shoving it down people's throats while violating their rights (GDPR requires users to actively consent, the license disclaimer does not count) then there is a problem. If you want remunerated that badly, then move to a paid product or freemium model.

kzu commented 1 year ago

@DanielCordell I looked at how others (i.e. node) do this "just beg in the console". I haven't seen anyone say it's a success for OSS sustainability. Also, we all build in IDEs nowadays. The only one who will see the console output is the CI server ๐Ÿ˜‚.

More private/enhanced features for sponsors would be great. It would need something from the IDE or GitHub though. It has to be transparent, and it has to be the same package as the "main" one, otherwise, perhaps nobody would even install/learn about them? I'd love it if libraries could just "light up" when you sponsor, for example

sgtwilko commented 1 year ago

@sgtwilko GUID: chicken-egg. You install the lib, how do I know you're already a sponsor? Generate a local GUID: how to match against a server-side GH app that's completely decoupled from your machine? ๐Ÿค”

@kzu Didn't I read that part of the process was signing up using an app linked to Github? That should be able to provide the guid.

DanielCordell commented 1 year ago

While it's nice to have some form of income from your efforts, I don't think it's a necessity

I think this is ignoring a real problem that a lot of projects have become unknowingly taken for granted, I hope nobody believes that people shouldn't be be paid for "work".

he beauty of OSS is that it's at-will and nobody is forced to do or provide anything.

The downside of OSS is that what starts out as volunteering can eventually turn into a job, but one that you didn't apply for and that you have much more of a stronger emotional investment in, making it harder to break away from a project you've worked on for many years. "Just abandon it" is going to be a last resort for anyone with a significant time or emotional investment in what they're making.

kzu commented 1 year ago

The "app" is a GitHub App: basically you give the app permission to read your email, and the app gets a webbhook call after you authorize (simplified). This all happens on the backend. All you have on that end is the user's id/login/email(s).

On the client, someone just installed your lib. The tricky part is mapping the two. And you don't know if GH is even involved (all you "see" is the source, its location, therefore if it's a git repo and that's about it).

DanielCordell commented 1 year ago

More private/enhanced features for sponsors would be great. It would need something from the IDE or GitHub though. It has to be transparent, and it has to be the same package as the "main" one, otherwise, perhaps nobody would even install/learn about them? I'd love it if libraries could just "light up" when you sponsor, for example

@kzu all you need afaik is a private feed and that when you purchase a "licence" for moq premium it gives you instructions/setup necessary to use the premium one.

rouke-broersma commented 1 year ago

@DanielCordell I looked at how others (i.e. node) do this "just beg in the console". I haven't seen anyone say it's a success for OSS sustainability. Also, we all build in IDEs nowadays. The only one who will see the console output is the CI server ๐Ÿ˜‚.

More private/enhanced features for sponsors would be great. It would need something from the IDE or GitHub though. It has to be transparent, and it has to be the same package as the "main" one, otherwise, perhaps nobody would even install/learn about them? I'd love it if libraries could just "light up" when you sponsor, for example

Imo getting paid for open source software is a solved issue and the solution is not sponsorships. They simply do not work, sponsoring is not a sustainable model to get paid for open source work no matter how much you nag them. They will either ignore it, or stop using your package. What does work is paid support contracts + paid licensed features. People will find the correct package because they will contact you to buy it.

kzu commented 1 year ago

@DanielCordell what about CI? Users will have to configure that private feed themselves too?

wdolek commented 1 year ago

@kzu Is there really a requirement to be able to check if someone is a sponsor though? If the mechanism for alerting users was as simple as a console message then people wouldn't need to "turn it off". Of course it would be less obtrusive, but that's the trade off to keep users feeling confident in your tools.

@kzu @DanielCordell There's VSColorOutput64 Visual Studio addon - which does exactly that. It prints additional message to output. When you donate, you can suppress that message by checkbox in settings. (Of course you can check it anyway, but it still make user think)

Why not going this way instead of sending data such sneaky way?

kzu commented 1 year ago

@rouke-broersma I don't think it's as simple as that. Otherwise, GitHub wouldn't have spent time and effort in providing the GH Sponsors feature in the first place.

mason-bially commented 1 year ago

@thaumanovic

Shoving it down people's throats while violating their rights (GDPR requires users to actively consent, the license disclaimer does not count) then there is a problem.

The license does disclaim it. This isn't a website passively running code on your machine. You downloaded and built the software, and somewhere along there you actively accepted the license. Because otherwise you are violating the author's rights. The only legal way you have any right to have a copy of this software in the first place is if you disclaimed all liability of it's use. That's the active acceptance you went through.

I don't think you understand the concept of volunteering if you think compensation is involved.

Plenty of volunteers are paid. Volunteers do necessary community work, giving their time and labor. That doesn't mean they aren't compensated in some way for undertaking tasks others wouldn't for far more money. But if it helps, then I misspoke, I more meant, "for how they survive while giving away their time and labor".

arthrp commented 1 year ago

You're basically sending peoples data to a shady endpoint without asking any kind of permission (I'm not even talking about unsolicited fake warning which is breaking builds). That's illegal in many countries. Also, you've destroyed all trust in your library by sneaking in this change without any consultation with community.

It's not easy to monetize OSS project and sneaking in spyware in your lib is certainly not the way to do it.

kzu commented 1 year ago

@wdolek @arthrp there's no sneaky sending of data. I'm not getting your emails. It's a SHA256 of it. That's unreversible.

abrugsch commented 1 year ago

More private/enhanced features for sponsors would be great. It would need something from the IDE or GitHub though. It has to be transparent, and it has to be the same package as the "main" one, otherwise, perhaps nobody would even install/learn about them? I'd love it if libraries could just "light up" when you sponsor, for example

take a look at the kickstarter-like backer tier list on the graphile maintainer's sponsorship page: https://github.com/sponsors/benjie It's essentially laid out exactly what supporters get. Yes, it's more work on the backend for you (private repos, discord/slack servers, manual verification of supporters on github tickets etc) but that's the case for the "business" side of coding. you need to either be an employee, or you need to act like a business and do business-y things. not just expect people to donate out of free will. you need some stick to go with your carrot. but the stick has to be worth it or you'll just lose all the sponsors you have even now

(In case my carrot/stick reference is too culturally specific, there is an old trope of leading a donkey by riding it holding a stick with a carrot dangling from it just in front of the donkey's face. the donkey walks forward to try and get the carrot but as he does so, the carrot continuously moves out of reach as it is being held by the rider. - if you make the "stick" too much a pain point, the donkey will just give up and not continue walking)

ntovas commented 1 year ago

@kzu The only thing you need is a change in the license, to target large companies. So if a company has a revenue more than a million let's say, they are required to pay a license of your liking in order to use the library. There are no need for anything else, a lot of companies will comply, and that's the end of the story.

Even the hash of the email is PII, if you do that in EU you are in a very big trouble, remove this code ASAP.

kzu commented 1 year ago

@abrugsch "manual verification of supporters on github tickets", that's ONE major thing GitHub could implement for us.

rouke-broersma commented 1 year ago

@rouke-broersma I don't think it's as simple as that. Otherwise, GitHub wouldn't have spent time and effort in providing the GH Sponsors feature in the first place.

You're under the impression GitHub introduced this to help the open source community but GitHub is a corporation, they mostly only do things that are to their benefit. I'm not saying the donation feature is unused, I am saying that it is not a sustainable way to get funding from OSS work. If it worked you wouldn't have this issue in the first place. And nagging people to donate does nothing but cause backlash as you can clearly see.

wdolek commented 1 year ago

@wdolek @arthrp there's no sneaky sending of data. I'm not getting your emails. It's a SHA256 of it. That's unreversible.

can I review code doing that? Is it included as source I can review?

kzu commented 1 year ago

@abrugsch so I take it the stick being an annoying build message (and eventually a build pause) is too much?

abrugsch commented 1 year ago

@abrugsch "manual verification of supporters on github tickets", that's ONE major thing GitHub could implement for us.

how does github verify supporters from patreon, paypal, ko-fi or private donators?

tonyqus commented 1 year ago

I'm also a open source maintainer. I have to admit the method that SponsorLink introduced is really creative although it's a bit aggressive.

Lack of Sponsorship is not a problem only Moq has. It's a common problem for most .NET open source projects. And .NET foundation also doesn't help much on this although it labels itself as foundation of promoting .NET projects and ecosystem.

Compared with Java ecosystem with Apache Foundation support, a few big companies are sponsoring not only talent but also money to different top level projects. While most .NET projects are maintained by individuals.

I do appreciate @kzu is putting efforts on encouraging sponsorship for open source projects.

Sometimes, making troubles for users of open source projects (not on purpose) can definitely help increase the chance of getting sponsorship or extra consulting money from users. I've been maintaining NPOI for almost 14 years. Every time I makes money from NPOI users is because they have troubles (even some are bugs). Too smooth experience of open source projects totally doesn't help on increase sponsorship. This is my experience.

For commercial projects, the company provides post-sale support because users pre-pay money for support service. It's not free. The sustainablity of open source projects I understand should be

However, most open source users doesn't agree on this and they don't wanna pay at all. They wanna everything free.

michalrosenbaum commented 1 year ago

@wdolek @arthrp there's no sneaky sending of data. I'm not getting your emails. It's a SHA256 of it. That's unreversible.

It's not the case. It's just that you can compare it with a list of mails obtained somewhere else e.g. from a leak and this way identitfy someone. That's why hashed mail can be considered as a PII. If I was selling products to dotnet developers I would love to have a list of hashed mails of users of Moq and a huge set of mails obtained somehere else to target my campaign ;).

poke commented 1 year ago

there's no sneaky sending of data

How can adding a closed-source assembly that is obfuscated in any way not be considered sneaky?

And even if you changed it now (making it open source and not obfuscated), your intention there is very clear that you wanted this to be sneaky. Thatโ€™s a heavy trust lost on your part.

I looked at how others (i.e. node) do this "just beg in the console". I haven't seen anyone say it's a success for OSS sustainability.

I think this is a funny statement. With SponsorLink, you have invented a new approach. So letโ€™s find out whether anyone will say in a few months whether that was a success for OSS sustainability. The feedback you are getting doesnโ€™t look great, and I still think itโ€™s very concerning that you donโ€™t understand the underlying issue and continue defending how SponsorLink works.

LarsWesselius commented 1 year ago

@wdolek @arthrp there's no sneaky sending of data. I'm not getting your emails. It's a SHA256 of it. That's unreversible.

I don't get this at all. The discussion about sponsorship is one thing but no one can see what you're doing in your library. Are we just supposed to trust you? How anyone can think this is ok is beyond me. You could be doing anything in your closed source obfuscated SponsorLink code.

kzu commented 1 year ago

@wdolek trivial to verify if you use Fiddler to look at the URL I'm GETing, and grabing the blob-looking segment and SHA256 hashing your git email. It will match.

alexjamesbrown commented 1 year ago

@wdolek @arthrp there's no sneaky sending of data. I'm not getting your emails. It's a SHA256 of it. That's unreversible.

@kzu Hash your email address (from your public gh profile) with SHA265 - https://emn178.github.io/online-tools/sha256.html Now search for the hash on https://gist.github.com See the problem?

kzu commented 1 year ago

@abrugsch they don't. There are NO FEATURES in GitHub that allow you to say "this should only be possible if you're a sponsor" (like opening an Issue).

thaumanovic commented 1 year ago

@abrugsch they don't. There are NO FEATURES in GitHub that allow you to say "this should only be possible if you're a sponsor" (like opening an Issue).

I think that's simply because GitHub is about OSS, and that simply is not in the nature of OSS.

abrugsch commented 1 year ago

@abrugsch so I take it the stick being an annoying build message (and eventually a build pause) is too much?

not the message, but the GDPR breaking dependency and security scan failing process. my company is now scrambling to pin the version in all projects and find alternatives because the next round of nessus scans will fail (let alone the "warnings as errors" flag they require that broke everyone's builds last night)

abrugsch commented 1 year ago

@abrugsch they don't. There are NO FEATURES in GitHub that allow you to say "this should only be possible if you're a sponsor" (like opening an Issue).

no you misunderstood my comment. That was a hypothetical "how WOULD github verify those donators if they implemented sponsor marking for you" sorry I wasn't specific enough

valters-tomsons commented 1 year ago

@abrugsch so I take it the stick being an annoying build message (and eventually a build pause) is too much?

Just imagine what will happen when 20 different packages decide to pause my build to nag for sponsorship. People will start developing extensions to block this and you'll be back where you started.

@wdolek trivial to verify if you use Fiddler to look at the URL I'm GETing, and grabing the blob-looking segment and SHA256 hashing your git email. It will match.

We shouldn't do this, SponsorLink can change at any moment without any warnings and 0 scrutiny, because it's closed source. (and it being obfuscated is another major red flag)

KirovAir commented 1 year ago

@wdolek @arthrp there's no sneaky sending of data. I'm not getting your emails. It's a SHA256 of it. That's unreversible.

This is easily reversible with a rainbow table. Also we can't see what the code is doing! That's the key point here. Also I'd hate for any program to try to scrape any data from my PC.. There are plenty of other good ways to establish some user identity or license. (like asking!)

OSS is hard to monetize, but not impossible. This is just not the correct way. With a name as big as Moq you could even create some unit testing 101 packs for example. Most revenue for OSS is in side businesses and corporate licensing/support unfortunately.

abrugsch commented 1 year ago

OSS is hard to monetize, but not impossible. This is just not the correct way. With a name as big as Moq you could even create some unit testing 101 packs for example. Most revenue for OSS is in side businesses and corporate licensing/support unfortunately.

essentially: if you want business benefits (i.e. getting regularly paid) you have to do more business-y things not just "build it and they will come/pay me"

Minmoose commented 1 year ago

@kzu Maybe I've missed it, but I haven't seen you answer what is in my opinion the biggest problem here, why does this Open Source project inject closed source software that is obfuscated, into the released version?

Why is SponsorLink not open-source? And why is it obfuscated?

This is the blocker for me, before even getting to GDPR issues, you are asking individuals and companies to trust you when you are injecting closed sourced, obfuscated software into an open-source project. I'm confused how you don't understand how this might be a problem.

tonyqus commented 1 year ago

I have an assumption: What if @kzu open source the source code of SponsorLink? Do you guys still have concerns? I think the major problem in the discussion is no trust on closed source nuget package.

abrugsch commented 1 year ago

@Minmoose

Why is SponsorLink not open-source? And why is it obfuscated?

he has answered this in GH issues raised against SponsorLink and that is that he believes closed source obfuscation is the only way to protect the code from being reverse engineered/blocked/circumvented...

rouke-broersma commented 1 year ago

I have an assumption: What if @kzu open source the source code of SponsorLink? Do you guys still have concerns? I think the major problem in the discussion is no trust on closed source nuget package.

The backend is still closed source, and it would still be collecting PII and sending it to a third party with which no business has an agreement for data collection and for which no one can verify how they use the data they received.

RonSijm commented 1 year ago

I have an assumption: What if @kzu open source the source code of SponsorLink? Do you guys still have concerns? I think the major problem in the discussion is no trust on closed source nuget package.

No. Like, what is even the purpose of adding SponsorLink here? The SponsorLink library says it could be used to add paid features for sponsers... Ok, so what premium / paid features does Moq offer that requires SponsorLink in the first place?

Worst case scenario: this is malicious... Best case scenario: this is unnecessary bloatware

madhon commented 1 year ago

Unfortunatly you decided the approach of blindly collecting PII data into a closed-source app. Doesn't matter if it's hashed or not. You can't f* around with GDPR. I hope you see sense and revert this change and seek a better more open way to monetise the project if you need too. But for now you have decimated anyone's trust in Moq, including mine and I will be removing it from all applications.

Definately cant mess with GDPR, a fine up to โ‚ฌ10 million or up to 2% of the annual worldwide turnover of the preceding financial year in case of an enterprise, whichever is greater, if there has been an infringement.

mikocot commented 1 year ago

I'm an outsider to this, but let me toss my hat in against the apparent prevailing opinions. Because I think they are wrong. .... Let's start here. People apparently did not read this project's license before using it. Here allow me to quote the relevant section, (ALL CAPS in original for EMPHASIS, I have further BOLDED IT):

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

saying you're not liable is not enough to not be liable, what is required by GDPR etc is to be clear about what is collected, for what and how it's processed plus to have clear permission from the user to do so AND let users have insight into this data and allow to modify/remove them. There is nothing that the author has done in thie direction

madhon commented 1 year ago

Chapter V of the GDPR forbids the transfer of the personal data of EU data subjects to countries outside of the EEA โ€” known as third countries โ€” unless appropriate safeguards are imposed, or the third country's data protection regulations are formally considered adequate by the European Commission. Where is @kzu based ?

TETYYS commented 1 year ago

Chapter V of the GDPR forbids the transfer of the personal data of EU data subjects to countries outside of the EEA โ€” known as third countries โ€” unless appropriate safeguards are imposed, or the third country's data protection regulations are formally considered adequate by the European Commission. Where is @kzu based ?

if you would care about all of this you could just read centered h3 text on the authors profile which says so

Joe4evr commented 1 year ago

Why is SponsorLink not open-source? And why is it obfuscated?

he has answered this in GH issues raised against SponsorLink and that is that he believes closed source obfuscation is the only way to protect the code from being reverse engineered/blocked/circumvented...

If that's all it would take, the biggest companies in the games industry wouldn't need to invest billions of dollars a year in their attempts to accomplish the same goal.

Minmoose commented 1 year ago

@abrugsch

Why is SponsorLink not open-source? And why is it obfuscated?

he has answered this in GH issues raised against SponsorLink and that is that he believes closed source obfuscation is the only way to protect the code from being reverse engineered/blocked/circumvented...

That is truly stunning, makes the problem worse tbh, to think that someone feels the need to obfuscate 'nag' code is truly something to behold.

GalaxiaGuy commented 1 year ago

Assuming I support SponsorLink, is there a solution to use it that does not depend on a GitHub account?