SponsorLink is now OSS too and no longer bundled

kzu commented 1 year ago

After the feedback yesterday, it was clear that even though the goal of SponsorLink is to make it easier for library developers to get sponsored, the fact that a part of an OSS project referenced a non-OSS dependency was concerning to many users.

As such, everyone can now go and inspect the whole thing (analyzer/package as well as backend azure functions) at the SponsorLink repository. Future versions of the package will come from there, will no longer be ofuscated, and will also have an OSS license.

NOTE: the original private repo is https://github.com/devlooped/SponsorLinkCore and has been archived. It contains the original commit history, which has now been integrated (via cherry-picking) into the single public repo moving forward.

Hopefully you will take this opportunity to help move it forward for the benefit of anyone that wants to be sponsored for their OSS work, and offering a better experience on that front for users too.

A couple comments from the feedback I gathered yesterday on #1374 as well as Twitter/X:

Many brought up the email SHA256 hashing to map users>sponsorships as not sufficiently private. Point taken, that won't be coming back until it's properly fixed as part of https://github.com/devlooped/SponsorLink/issues/31
Warnings for sponsorsing messages disrupt folks using warnings-as-errors. Agreed, I overlooked that scenario. Will fix it as part of https://github.com/devlooped/SponsorLink/issues/32
Build pauses: not 100% sure about this one, but it seems users don't like it. I'd like to collect more thoughts from library authors in particular. It's quite obvious users that aren't sponsoring (and don't intend to either), will be bothered by this. But the focus should be on library authors that want to make their OSS work sustainable. So I'd like folks to keep that in mind as you chime in on https://github.com/devlooped/SponsorLink/issues/33

gnalvesteffer commented 1 year ago

https://github.com/nsubstitute/NSubstitute

CenturySparkle commented 1 year ago

And I thought the npm funding messages were bad. This is worse.

jkonecki commented 1 year ago

Moq currently has 99 contributors (including a handful of bots) - how are you going to distribute the proceeds from SponsorLInk between them, if at all?

As a library author, I would never impact the library users' build process with any delays (this could consume free minutes offered by online services). I wouldn't even annoy them with auto-opening text files on NuGet package installation.

Consider a world in which every NuGet package you use, and every dependency, and dependency of dependency, utilized SponsorLink that added just a couple of seconds to each build. Do you want to live in such world?

“Don't do unto others what you don't want done unto you.” ― Confucius

tacosontitan commented 1 year ago

This is just strange to me.

Why include this at all?
If it must be included, why isn't it an opt-in feature instead of being mandatory?

TeddMcAdams commented 1 year ago

It is clear at this point that Moq needs to be forked and we need come together around a new repository.

sdepouw commented 1 year ago

It is clear at this point that Moq needs to be forked and we need come together around a new repository.

https://github.com/hassanhabib/CleanMoq https://www.nuget.org/packages/CleanMoq

DanielCordell commented 1 year ago

Some people here need to take a step back. He's literally done what we asked here. If y'all aren't gonna be constructive here then genuinely why post anything. There's enough people posting the same stuff in his other issues. If you wanna fork the repo, fork it. If you wanna migrate to NSubstitute, then go do that too.

Thank you @kzu for open sourcing this. Probably a bit too late, and definitely should have been done from the start, but It's a step which will help some people regain some of the trust that was lost.

I hope this continues with a trend of you being able to work with the community on this, rather than dropping something like this as a surprise. Everyone saw how that went the last time!

lee-11 commented 1 year ago

There is a degree of pointlessness here that adds spice to the myopia. Wanting to be paid (call it what you will) requires an elevated amount of knowledge, consideration, and work. There is no easy button. Sending invoices and stuff is a intentionally ignorant simplification of what providing work for compensation involves. OSS doesn't get a free pass here - ethics, fair value, compliance, taxes (OSS isn't possible without infrastructure), etc. are all part of the ecosystem.

So stay "free" and unencumbered or get serious and get paid. Don't try to be "smarter" than the legions before you by ignoring entire concerns you find distasteful but are, in the context of the entire ecosystem, required for everyone's benefit.

Rahtgaz commented 1 year ago

Some people here need to take a step back. He's literally done what we asked here. If y'all aren't gonna be constructive here then genuinely why post anything.

People asked many things. But I clearly got the idea that the vast majority asked for SponsorLink to be completely removed from Moq. And that hasn't been done and clearly isn't going to be done. So I don't know what do you mean by him doing what "we" asked.

It's funny you mention "being constructive". It is precisely what has so many people scratching their heads at the destructive suicide of this project as it unrolls before our very eyes. As someone said before, this is Github drama at its best. But no one was asking for it. Like Jake Paul on Netflix we have to wonder why?

DanielCordell commented 1 year ago

@CenturySparkle mentioned NPM, I'd invite people to read through this if they haven't already. Very similar situation, well worth a read. https://github.com/zloirock/core-js/blob/master/docs/2023-02-14-so-whats-next.md

Rahtgaz commented 1 year ago

Build pauses: not 100% sure about this one, but it seems users don't like it.

And the Sherlock prize of the week goes to...

OrbisWill commented 1 year ago

Build pauses: not 100% sure about this one, but it seems users don't like it.

And the Sherlock prize of the week goes to...

The wording makes it sound like 'not liking it' was an unexpected side-effect. I'm pretty sure it is behaving exactly as designed but maybe I'm missing something :)

DanielCordell commented 1 year ago

But I clearly got the idea that the vast majority asked for SponsorLink to be completely removed from Moq.

@Rahtgaz As far as I'm aware, it's been removed no?, Someone posted a screenshot showing it was no longer bundled, and the MOQ packages that did contain it were removed from nuget. That was my impression at least.

I'm just personally against kicking someone while they're down, especially when they're actually taking steps in the right direction. People seem to just want to vent more than anything, especially when, as of this issue, all he's done is open source the damn thing. What is there to complain about that?

We should be encouraging someone when they make decisions like this. IMO If you wouldn't say it to a colleague you don't know, you shouldn't say it on a GitHub issue. Ofc some people may act like this to colleagues, so who knows.

TeddMcAdams commented 1 year ago

If you look through the git history on this project, it seems that @kzu hasn't done much of anything at all in the last two years, aside from monetization efforts? What ongoing development are we supporting exactly?

https://github.com/moq/moq/commits?author=kzu

DanielCordell commented 1 year ago

If you look through the git history on this project, it seems that @kzu hasn't done much of anything at all in the last two years, aside from monetization efforts? What ongoing development are we supporting exactly?

https://github.com/moq/moq/commits?author=kzu

@TeddMcAdams He was working on https://github.com/moq/labs vNext, among other things. Don't just look in the one repo.

I don't actually know where the code for VNext is (it might not all be public), but I'm on my phone rn so search is a bit ass.

TeddMcAdams commented 1 year ago

@DanielCordell maybe I am missing something, but /src/ seems public over there on labs too? Updated three years ago?

Nothing in the last two years aside from updating sponsorship info? Like you said maybe it isn't all public.

DanielCordell commented 1 year ago

I don't actually know where the code for vNext is, looking through repos on my phone isn't ideal.

He posted this: 20230810_175004

So he's not been doing nothing

TeddMcAdams commented 1 year ago

I am talking about the Moq project specifically. Sure he has a ton of commits elsewhere, like his SponserLink project.

But for someone who is complaining about nights and weekends having to maintain such a big project, I'm not sure what actual maintaining is taking place here specifically?

DanielCordell commented 1 year ago

Lots of contribs Screenshot_20230810-175334

Contribs in private repo (I assume vNext or work maybe?)

Screenshot_20230810-175344

An avid open source contributor!

@TeddMcAdams I can definitely see the point that sponsorships are weird when a project is deemed "stable" and then a new version is getting worked on in the background. The 'old,' thing is basically in maintenance only mode and the next thing that's taking up all the time isn't public yet. That's more of an issue I have with Githubs implementation than anything.

Definitely getting off topic here.

Rahtgaz commented 1 year ago

@DanielCordell The removal of SponsorLink from Moq was due to a bug that was showing in Mac and Linux. Not because there is no longer a desire to add it to Moq. @kzu has made it clear he will be adding SponsorLink back to Moq.

I'm just personally against kicking someone while they're down, especially when they're actually taking steps in the right direction. People seem to just want to vent more than anything, especially when, as of this issue, all he's done is open source the damn thing. What is there to complain about that?

Your soulful attitude is not helpful or constructive either. Despite what you might think. There's a time for kumbaya and a time for shouting. The problem at hand is simply this: A completely unannounced tool that aims to collect my email and send it to a third-party without my permission and without an opt-in mechanism is being added to a mocking library used in my company in around 250 individual C# projects which comprise the totality of our in-business toolset. My IT department has already issued a warning, and frozen the Moq version in our private nuget stream server. Management in the meantime is waiting a few days before deciding whether we are going to migrate our code to an alternative, likely NSubstitute. I am now currently on the second day of estimating the cost for us.

I don't feel warmth in my heart.

amcgregor commented 1 year ago

…even though the goal of SponsorLink is to make it easier for library developers to get sponsored, the fact that a part of an OSS project referenced a non-OSS dependency was concerning to many users

Pretty sure it's the calling home / exfiltration of personally identifying information (PII) that's the offensive bit. May even violate a few laws. Sure, some may have been asking to have the target open-sourced, but more appear to be questioning why this needs to exist in the first place. See also: reports of test suites blocking on these call-homes.

This type of calling-home behavior would get flagged by my local anti-malware protections as unexpected outbound connections are monitored.

Build pauses: not 100% sure about this one, but it seems users don't like it.

This is un-serious. To the degree that I've been forced to add this project to my "never use" list, similar to "is-really-truly-array" (which uses 8 or so NPM libraries such as "is-array", "isarray", "arraylike", … to exhaustively check), "is-even" (basic math fail), and "eslint" (my word). And warn developers within the organization I work for about the PII leakage.

Edit to note: thumbs down? Because a few of y'all think this is being serious? It's a phallus measurement contest and belittling session, with the one caught exhibiting the bad behavior pointing and victim blaming. And exhibiting no understanding of the problem of their behavior.

I try very hard to not point at my Mars 2020 badge. But it's there. @kzu does not appear to have that one. The shame.

(The shame is in not recognizing the unacceptability of PII exfiltration, the trust violation that is unexpected code execution, and not worrying about the possible legal jeopardy / violation of laws these entail.)

Tyrrrz commented 1 year ago

Without taking any sides (I don't agree how @kzu did what he did), it's pretty clear that the .NET community is full of entitled Karens.

"We'll fork your project" is such a laughably empty threat because people ranting for hours on GitHub issues about "million dollars in damages" will be the last ones to enforce it.

DanielCordell commented 1 year ago

@kzu has made it clear he will be adding SponsorLink back to Moq.

Not mentioning the fact that he's not going to be putting back the exact same version as before, he's clearly listening to feedback on the sorts of changes he could make, and the fact that it's now open source means that there's also accountability here.

A completely unannounced tool that aims to collect my email and send it to a third-party without my permission and without an opt-in mechanism is being added to a mocking library used in my company in around 250 individual C# projects which comprise the totality of our in-business toolset. My IT department has already issued a warning, and frozen the Moq version in our private nuget stream server. Management in the meantime is waiting a few days before deciding whether we are going to migrate our code to an alternative, likely NSubstitute. I am now currently on the second day of estimating the cost for us.

I'm sorry you're in that position, I'm literally doing the same thing right now. While I'm also frustrated to be in this position, there's also a time to be constructive here, not just flinging crap at him. One extra angry voice on an issue isn't going to do anything. Why is shoutin on this issue going to help? This isn't twitter, the initial wave I understand completely, but this issue here is supposed to be a first step in the right direction.

deMD commented 1 year ago

But I clearly got the idea that the vast majority asked for SponsorLink to be completely removed from Moq.

@Rahtgaz As far as I'm aware, it's been removed no?, Someone posted a screenshot showing it was no longer bundled, and the MOQ packages that did contain it were removed from nuget. That was my impression at least.

I'm just personally against kicking someone while they're down, especially when they're actually taking steps in the right direction. People seem to just want to vent more than anything, especially when, as of this issue, all he's done is open source the damn thing. What is there to complain about that?

We should be encouraging someone when they make decisions like this. IMO If you wouldn't say it to a colleague you don't know, you shouldn't say it on a GitHub issue. Ofc some people may act like this to colleagues, so who knows.

It's still in https://github.com/search?q=repo%3Amoq%2Fmoq+SponsorLink&type=code . Only the "keystone", in the form of a package reference, was removed https://github.com/moq/moq/commit/a7dcd43c3ca192ad3dcc813f4ddedae96914fe26

Nevertheless, SponsorLink just needs to be removed completely, this is not the way to get any sustainability for FOSS, it will just force developers away:

Email should always be opt-in, no matter how it is hashed.
Sending messages in logs is a no-go. If all packages then want sponsorship are doing that, it will reading my own messages harder, which makes the development experience bad.
Randomly increasing build times is literally hitting developers and companies financially, it wouldn't even surprise me if it is illegal in some countries, or as ChatGPT puts it: Deliberately delaying services with the intention of harming others financially could potentially be considered a form of fraud, breach of contract, or other legal violations depending on the specific circumstances and the jurisdiction you are in.. Now, obviously with Moq having an OSS license that puts it in a gray area, but before doing stuff like this it might be wise to ask legal counsel. At least I know that any package that uses it to nag me into paying for it will be placed on a nice blacklist.

And these issues will just increase 1000x fold if this package is used by more (F)OSS developers, to the magnitude that it might kill OSS as we know it.

HeyBanditoz commented 1 year ago

it's pretty clear that the .NET community is full of entitled Karens.

how would you feel if the lib you're using all of a sudden introduced a binary obfuscated dll that you have no visibility into what it's doing?

SpikeViper commented 1 year ago

here's some refreshment for individuals who have read down to this point

🥤🍔 🥤🍔 🥤🍔

ABruel commented 1 year ago

Some people here need to take a step back. He's literally done what we asked here. If y'all aren't gonna be constructive here then genuinely why post anything. There's enough people posting the same stuff in his other issues. If you wanna fork the repo, fork it. If you wanna migrate to NSubstitute, then go do that too.

Thank you @kzu for open sourcing this. Probably a bit too late, and definitely should have been done from the start, but It's a step which will help some people regain some of the trust that was lost.

I hope this continues with a trend of you being able to work with the community on this, rather than dropping something like this as a surprise. Everyone saw how that went the last time!

Except they didn't. They open sourced it, sure. But it is still being used, it still harvested data without user consent (which is against the law), and it still slows builds to annoy people into sponsoring. None of that is ok.

There's a thing called trust, and it has been broken. You can't just mend it by undoing part of the damage, the very fact they thought this was ok to do is the problem.

wrexbe commented 1 year ago

Other then the broken privacy laws, you could probably sue for damages, because slowing the build process intentionally causes financial harm. I'm not sure there is legal protection when it's intentional.

Tyrrrz commented 1 year ago

it's pretty clear that the .NET community is full of entitled Karens.

how would you feel if the lib you're using all of a sudden introduced a binary obfuscated dll that you have no visibility into what it's doing?

Like I said, I don't agree with what @kzu did. There are ways to bring it up and have a civilized discussion, but this is not it. Threatening the maintainer that you'll "fork their project" or being verbally abusive only creates further antagonization. And if that's your real goal then it's fine, but don't hide under the pretense of "fairness". Especially not if the maintainer already showed that they received your feedback. You expect @kzu to be perfect, while you're all throwing feces at him like a bunch of enraged monkeys 🤷🏻

AshleyMedway commented 1 year ago

Positive steps in my opinion.

Info/notice instead of warning should still achieve the same thing.

I’m a library author and I wouldn’t want to slow down anyone’s build.

Happy to see the email hash removed until a better solution can be found.

TheDanielDoyle commented 1 year ago

Including malicious obfuscated code without a prior community discussion is a big no no. The reasoning around its inclusion is the final nail in the coffin.

Unfortunately, the ship has sailed on loss of trust. You only get one chance in some circles, and Moq has become a blacklisted library.

I do wish the current project owner well. Let this be a lesson to the wider community. We need to do better around supporting maintainers.

gnalvesteffer commented 1 year ago

It shouldn't even be a build message at all. It's not related to a build, it's noise. Put a donation/sponsor link/info in the project's readme. Those that want to sponsor are going to sponsor.

mxmissile commented 1 year ago

Threatening the maintainer that you'll "fork their project"

It's OSS, a project fork should never be taken as offensive or any kind of threat. Forks are a crucial part of how OSS works. (assuming the license allows it of course)

Tyrrrz commented 1 year ago

Threatening the maintainer that you'll "fork their project"

It's OSS, a project fork should never be taken as offensive or any kind of threat. Forks are a crucial part of how OSS works. (assuming the license allows it of course)

Sure, but I'm talking about the people in this thread who bring up forking specifically as a threat.

NzKyle commented 1 year ago

Yeah I personally want nothing to do with any library that leverages this SponsorLink app, at all.

Like many have said if you desire is to get paid for what you are doing then create a licensed version of Moq.

ergoodwin commented 1 year ago

Thanks for making it easy blacklist packages at our org. Anything that takes on a dependency on SponsorLink is on the no-go list.

oridotaoyebode commented 1 year ago

Some comments on here are just spiteful and lack any sort of constructive criticism.

mistakes were made, lessons will be learnt but somethings are better left unsaid.

Some of the comments on here are why contributors end up just going closed source and ask you to pay a license.

Just move on already.

kzu commented 1 year ago

I'm willing to sponsor Moq, but only if the proceeds go to @stakx.

You are assuming he will be working on vnext. That's not necessarily the case.

But you bring a very fair point. What I am willing to say is this: I'm willing to donate in turn to users who send PRs and contributors who merge them, yes. That's another broken part of the status quo.

kasperk81 commented 1 year ago

https://github.com/dotnet/docs/pull/36638

bitbonk commented 1 year ago

@kzu I think your list of issues with SponsorLink is missing the following two issues:

SponsorLink does not work on MacOS and will always produce a waring like the below:

CSC: Warning AD0001 : Analyzer 'Moq.SponsorLinker' threw an exception of type 'System.UnauthorizedAccessException' with message 'Access to the path '/usr/local/share/dotnet/sdk/8.0.100-preview.7.23376.3/Roslyn/bincore/%TEMP%\1M5Ot' is denied.'.
It is agains the "Roslyn analyzer contract" to do external I/O in an analyzer. You closed the issue mentioning this. IANAL, but it could be actually be illegal to ship software that does this. @sharwell might be able to elaborate on this.

cmjdiff commented 1 year ago

After the feedback yesterday, it was clear that even though the goal of SponsorLink is to make it easier for library developers to get sponsored, the fact that a part of an OSS project referenced a non-OSS dependency was concerning to many users.

@kzu I see you still. aren't. listening. I also see you still somehow think this is an OSS sustainability problem.

A couple comments from the feedback I gathered yesterday on #1374 as well as Twitter/X:
* Many brought up the email SHA256 hashing [...]

* Warnings for sponsorsing messages disrupt folks using warnings-as-errors [...]

* Build pauses [...]

I notice a couple of feedback items you don't appear to have responded to. Can you tell us how you've taken on and considered the feedback on the following items?

You presumed yourself entitled to link random users to your sponsorship list, without their consent, by extracting and analysing private and proprietary data on their machines (e.g. reading the contents of their .git directories)
You are asking other project maintainers to send you their sponsor lists to be able to use SponsorLink
You keep trying to make this about some issue in OSS maintainability, rather than your own behaviour

Thanks

gnalvesteffer commented 1 year ago

Hey you should also just access production databases if you can manage to do that on a developer's machine that just so happens to have access to one, and just dump the data to your service too while you're at it!

gnalvesteffer commented 1 year ago

This is a slippery slope to a future where packages are just doing whatever the hell they want during builds. Albeit the harm here is probably minor, and perhaps there are good intentions behind them, this isn't the way to go about it. I'm surprised that such a thing is even supported during builds (though frowned upon by Microsoft according to a previously mentioned post). Seems like such a huge security vulnerability, and is only a matter of time before someone seriously abuses it for far more malicious purposes.

kzu commented 1 year ago

@cmjdiff somehow (watching your profile) I'm not convinced you understand what it even is to be an OSS developer.

I'll close this for now since folks seem to keep repeating the same things: the "privacy" issue (a locally hashed SHA256 of an email, which given that SponsorLink is OSS and you can see what I'm "doing" with those hashes, and that it's no longer shipping anyway), the "obfuscated binary" (no longer an issue, again, OSS + removed) the "reputation/trust" (nothing I can do about you guys there) or the "go commercial" suggestion and a few others, nothing new is being added that I can act or improve upon.

Thanks, everyone for the feedback. Rest assured I read each and every one of your comments. I tried to answer as many as I could, but from this point on, I think the best course of action for you, if you want to continue making suggestions, is to go to the specific issues in the SponsorLink repo.

cmjdiff commented 1 year ago

@cmjdiff somehow (watching your profile) I'm not convinced you understand what it even is to be an OSS developer.

@kzu Observing your behaviour, I'm not convinced you do either.

kzu commented 1 year ago

Roslyn analyzer contract" to do external I/O in an analyzer.

There isn't such a thing. It's like saying because everyone has been warning you not to do private reflection, somehow you're violating some sort of contract.

I've done my fair share of IDE, analyzer and MSBuild work. If instead of a blanket statement I get concrete metrics on specific issues, I'm willing to work even harder to address them.

I'm using many of my own packages with SL included and I haven't personally experienced any noticeable slowdown, neither in editing nor building. I absolutely dogfood everything I build.

kzu commented 1 year ago

@jkonecki

(this could consume free minutes offered by online services)

That can never happen with SponsorLink. It simply does not run unless you're IN AN EDITOR, actually EDITING.

Consider a world in which every NuGet package you use, and every dependency, and dependency of dependency, utilized SponsorLink that added just a couple of seconds to each build. Do you want to live in such world?

That's technically solvable. If/when the issue arises, it can be dealt with. I can think of many many options (batching by sponsor, single wait for all sponsorables, etc.).

“Don't do unto others what you don't want done unto you.”

In a world where everyone is fine giving a capsule of Nespresso away for OSS software they use, I'd be more than happy to do the same.

@tacosontitan you seriously think someone will "opt into being reminded to sponsor"?

@DanielCordell I don't mind the "trust lost". As a library author, if I were evaluating SponsorLink as a mechanism to get more sponsorships, it sure seems a bit (a lot?) less effective being opensource. Maybe not? Dunno. That was the intention behind making its source available only to other sponsorable accounts/authors wanting to integrate it.

@lee-11 "OSS isn't possible without infrastructure", well, I've been doing for ~20 years. I didn't get any "infrastructure" at any point. Also, you mean to say all the effort GitHub put into creating Sponsors in the first place, was totally pointless an misguided?

I recall it being pretty well received by the OSS community when it was announced: https://github.blog/2019-05-23-announcing-github-sponsors-a-new-way-to-contribute-to-open-source/

@TeddMcAdams perhaps you've been too busy with your 15 contributions this year, so I just adjusted my contribution settings so you can just see the public ones I've made too:

I'm around ~2k+ a year for the past 3 years. Not saying everyone is going to use everything I do, but I do a lot more than Moq. As you noted, Moq hasn't been a passion for a while. Tried to reignite that with vNext but it was a lot of work (both on the static proxy generator at https://github.com/devlooped/avatar as well as the moq side at https://github.com/moq/labs) and I lost the streak.

To be noted: I never said I'm introducing SponsorLink because of the massive burden of maintaining Moq. Even the analyzer warning clearly states that funding would go towards developing a new version. Sponsoring is not a "work for hire" contract, mind you.

Imagine a world where you could get a Spotify-like "SponsorLink OSS" subscription (very accessible, say $2-$5?). Then you just use OSS left and right. SponsorLink automatically calculates the amount of each library you use and splits accordingly the earnings amongst the owners.

Kautzman commented 1 year ago

Imagine a world where you could get a Spotify-like "SponsorLink OSS" subscription (very accessible, say $2-$5?).

This is my personal hell. This would be awful. I would rather pay individual projects that I use via patreon or via a box price. (And I strongly favor a box here)

Also, you must be able to see where that is entirely abusable, right? Where people integrating SponsorLink now have a strong incentive to make sure number go up by hitting whatever it is that makes that metric increment? That's not actually something you could implement without bad actors taking advantage.

kzu commented 1 year ago

The only increment in the metric can come from SponsorLink and a code analyzer. If you try to bump your "usage" by making a crappy API that takes 10x more code to do the same thing as another project, you'd ditch it for that one instead.

It's like saying the incentive Spotify put in place is for musicians to make gazillion of 10second songs (or longer songs, don't know the algo). It's users who vote with their usage of your lib.

Also, you can just go scan the Rolyn repo and see how they already have the telemetry about EVERYTHING you do with code in the editor (start at https://github.com/dotnet/roslyn/commit/bfc1752dadc186b7f7662d8bf9b76511ce005168 for example).

lucas-zimerman commented 1 year ago

If you look through the git history on this project, it seems that @kzu hasn't done much of anything at all in the last two years, aside from monetization efforts? What ongoing development are we supporting exactly?

https://github.com/moq/moq/commits?author=kzu

What is the point of having too many commits? it's a mock library, there's no need for constant enhancements.

And he's actually right, what is the point of dedicating 100% of your life to a project that doesn't pay your bills? I see no problem at all on trying to monetise the project that is so helpful to many abroad.

On the other hand, I would recommend some flag to bypass this check, just like windows activate logo on your computer, it'll not make you pay only because you saw that message, it's a nice thing to see on the first runs, but ideally the user should have a way of disabling it.

devlooped / moq

SponsorLink is now OSS too and no longer bundled #1384