Closed stakx closed 1 year ago
ghost
commented
1 year ago @kzu absolutely destroyed any reputation this package had. You should fork it and find some maintainers who won't add malware in the future.
The latest release is v4.20.69 and doesn't add/remove any functionality which shows @kzu 's priorities. Absolute clown show.
tonyqus
commented
1 year ago The changelog of 4.20.69
What's Changed
This version looks good to me.
stakx
commented
1 year ago @kzu absolutely destroyed any reputation this package had. [...] Absolute clown show.
I'm not a fan of such absolute statements. I prefer to believe that trust can be earned back, but that requires more than just work on @kzu's part; everyone else also needs to show some willingness to forgive. Or at the very least stop the venom.
What's the point in holding a grudge forever. Sure, if you just want to see Moq burn to the ground because it makes you feel morally justified, and if you don't mind the extra work of looking for a replacement, keep the rage going... but is that a smart choice? I for one would much rather see things repaired as soon and as much as reasonably possible, so that we can all go on using (and working on) a great library and leave this mess behind us.
You should fork it and find some maintainers who won't add malware in the future.
I've considered a fork. I'd certainly be in a good position to do that. But as long as there remains hope that the situation can be fixed, I don't think it would be in the best interest of everyone involved. I'd rather see this project succeed once again, than fragmenting its user base any further.
(Also, "find some maintainers" is far easier said than done. Feel free to fork the project yourself and try. I personally am under no illusion that if I were to fork it, I would remain the sole active maintainer. Look at this repo's history if you want some evidence for that claim.)
karl-sjogren
commented
1 year ago @kzu absolutely destroyed any reputation this package had. You should fork it and find some maintainers who won't add malware in the future.
Well the package itself took a hit that should still be salvageable (sure, that AWS started a PR to remove themselves from the sponsors list really wasn't a good look) but I feel that I don't trust anything that @kzu touches anymore. As long as he has the ability to push new releases without review I'm not adding Moq (or any of his other libraries) to any of my projects and I think that that is how many people feel.
My ideal solution would be that @kzu stepped down (or was removed) from the project completely and any trace of SponsorLink was removed. But seeing that he has contributed almost as much as @stakx I don't really see that happening. It is weird however that the sponsor banners/buttons in this repo is to sponsor @kzu personally and not the actual project.
But I also understand @stakx point of view, forking and finding new maintainers isn't ideal either. Not only is it the hassle of finding those maintainers, but forking would also be a sort of "starting over" with a new name even if it was "Moq"-adjacent. All the articles already written all over the internet would still reference "Moq", the "Moq" package would still be the twelfth most downloaded NuGet package for a long time etc.
WeihanLi
commented
1 year ago From the code review and collaboration perspective, could we avoid PR merged without approvals especially likes the sponsorlink PR https://github.com/moq/moq/pull/1363
stakx
commented
1 year ago @karl-sjogren: I don't want to stray too far from this issue's original request, but I'll address one of your points because I think it's important in order to understand where Moq is headed:
My ideal solution would be that @kzu stepped down (or was removed) from the project completely [...]. But seeing that he has contributed almost as much as @stakx I don't really see that happening.
Comparing our contributions solely by the number of lines of code changed doesn't do justice to @kzu's very crucial contribution: he created Moq. I (and others) merely iterated and expanded on it. Both of those activities are important, but for different time frames: I am quite good at iterating on existing software and keeping the lights on in the short and mid-term. But for the long term, you should want @kzu to stay involved, because he has the vision and the ability to come up with the next-generation version of Moq.
The need for Moq vNext isn't hypothetical, btw.: The foundation upon which present-day Moq is built (LINQ expression trees, paired with dynamic code generation using System.Reflection.Emit) has already reached its limits. LINQ expression trees haven't been kept in feature parity with C# language features since C# version 4 (example: assignment operators, default parameter values, or anything async / await). And .NET Reflection doesn't know about many new C# language and .NET runtime features (example: by-ref structs that can't be boxed). For this reason, today's Moq is going to work less and less well with each new C# / .NET release, there's going to be an increasing number of types that you can't mock with it, and there's not much we can do about that... except come up with Moq vNext. @kzu could do this... if he gets the funding that he needs.
(Please note that I've intentionally focused on our individual abilities and ignored the aspect of trustworthiness above because, like I said earlier, I believe that trust can be earned back.)
It is weird however that the sponsor banners/buttons in this repo is to sponsor @kzu personally and not the actual project.
I see where you're coming from. But this probably deserves a discussion of its own, and I would suggest that we keep it out of this issue in order to stay on topic.
karl-sjogren
commented
1 year ago Fair enough, but as long as there is a risk of this project being the guinea pig of @kzu again it will be really hard to regain the trust of the community.
Baklap4
commented
1 year ago From the code review and collaboration perspective, could we avoid PR merged without approvals especially likes the sponsorlink PR #1363
In addition to this, approval from other people than the pusher without overrides
stakx
commented
1 year ago Setting up a peer review / approval system as a safeguard against merging bad stuff is a reasonable suggestion to make, but that requires at least two active maintainers, long-term... ideally even more than that. Otherwise development can easily get blocked and crawl to a halt, which isn't helpful, either. So you're back at the question of how the project can secure itself more support and resources.
I suggest to have that discussion in a separate issue so it's easier to track it and remain on topic.
Arcalise08
commented
1 year ago Yeah sorry I have to agree with the others here. Once a developer has silently pushed a change like this without feedback or acknowledgement from the community. The bridge is burnt. It takes years to build trust and moments to break it down. I suggest trusted members fork moq to save what remains. The work thats there is good and it deserves to be saved.
jamesbascle
commented
1 year ago I think probably the best way to achieve what you're looking for here stakx is to have kzu turn over ownership to you and maybe a couple other people interested in being a kind of governing council or something. He severely damaged the ability for people to trust software that he distributes. The solution then is to have him not distribute the software. Instead, he would be the primary author/contributor, and someone else(s) would be in charge of packaging and distribution.
I'm sure CTO's across the world have said that nobody is to use software distributed by kzu going forward, and I really struggle to think of any other approach that salvages Moq's reputation and sets kzu up to work on the damn thing.
rzn34
commented
1 year ago I'm sorry to stray off topic here, but the issue of trust is such a crucial point that it not only deserves reiterating, but it's not an exaggeration to say that we have to come to a resolution before talking about the future of Moq:
I prefer to believe that trust can be earned back, but that requires more than just work on @kzu's part; everyone else also needs to show some willingness to forgive. Or at the very least stop the venom.
I also prefer to believe trust can be earned back, but only if you are willing to work for it. What people ultimately wanted to hear is something along the line of:
"I'm very sorry about all the issues that were caused -- I screwed up. Here's what I'm doing to undo the damage, and here's what I will do to ensure something like this won't happen again".
Only then, we can actually talk about a sustainable future of Moq with kzu involved.
Over the past few days, we haven't seen a single line of apology, only a disingenuous attempt to "clarify" his actions.
jamesbascle
commented
1 year ago Over the past few days, we haven't seen a single line of apology, only a disingenuous attempt to "clarify" his actions.
I truly don't think it was disingenuous. I think it must be ascribable to ignorance rather than malice. It did show, however, that he is far removed from the practices of shipping commercial software and working in an enterprise. That he 1) thought it would be incumbent on individual developers to make the nag ware go away and 2) still does not actually see what he's done wrong, indicates that trust will be slow-to-impossible to regain if the project governance structure and especially the Moq Github/Nuget distribution channels stay fully under his ownership.
I still think despite everything, people would more or less be happy to let him develop Moq, but almost nobody wants to see him as the source for distribution.
Fuchs
commented
1 year ago What's the point in holding a grudge forever. Sure, if you just want to see Moq burn to the ground because it makes you feel morally justified, and if you don't mind the extra work of looking for a replacement, keep the rage going... but is that a smart choice? I for one would much rather see things repaired as soon and as much as reasonably possible, so that we can all go on using (and working on) a great library and leave this mess behind us.
There is a difference between holding a grudge and trusting a package and trusting an author. Especially in enterprise environments, but also for people personally. At least on an enterprise level, that trust has been violated and that taint will stay on both the package and the author for a good while. That's not holding a grudge, that's simply risk management. You look at what they did, you look at their reaction and replies, and then you do a risk matrix based on how likely another such incident would be, and the impact of it.
And with that in mind, I indeed think that for moq a fork and/or other contributors would remove some of that taint best.
aschan
commented
1 year ago The need for Moq vNext isn't hypothetical, btw.: The foundation upon which present-day Moq is built (LINQ expression trees, paired with dynamic code generation using System.Reflection.Emit) has already reached its limits. LINQ expression trees haven't been kept in feature parity with C# language features since C# version 4 (example: assignment operators, default parameter values, or anything
async/await). And .NET Reflection doesn't know about many new C# language and .NET runtime features (example: by-ref structs that can't be boxed). For this reason, today's Moq is going to work less and less well with each new C# / .NET release, there's going to be an increasing number of types that you can't mock with it, and there's not much we can do about that... except come up with Moq vNext. @kzu could do this... if he gets the funding that he needs.
Based on the above clarification and the problematic compensation issue regarding FOSS wouldn't Moq vNext be an ideal jump off point for duplicating Duende's transformation of IdentityServer to OSS with a commercial license? Sure, there is a lot of legal and administrative work to get it set up and to maintain it but if done right a commercial license for Moq vNext should facilitate what @kzu is trying to acheive with SponsorLink. All traces of SponsorLink should be removed from the current version of Moq and there would be no need for it in vNext.
In this transformation I do believe it would be in Moq VNext's best interest to not have @kzu as the owner of that project. His contributions should be acknowledge and he should definitely continue as a developer but someone else should be responsible. It is a matter of trust. While I do think the introduction of SponsorLink was a result of naivity rather than malice it did erode that trust. For a commercial license to be accepted the organization/individual(s) maintaining it must be believed to be able to understand and support the requirements and obligations for large enterprises.
psimsa
commented
1 year ago Just out of curiosity, what do you think about the core idea behind SponsorLink itself? I can't help but feeling that if it was driven from the start as a community effort with full transparency, the idea of linking sponsors to libraries is actually pretty great. As far as I can tell from companies I worked on, the main issue companies have with sponsoring OSS is not lack of willingness or funds but the overall headache to fund dozens of small projects from administrative point of view. If there was a credible system where the company could push some funds towards a redistribution system, got an invoice that can be put into accounting, and the redistribution system would know how many and which packages that particular company actually uses and redistribute the funds accordingly, many companies would actually consider it. The execution of this was terrible and rightfully rejected. But I really like the idea itself.
stakx
commented
1 year ago @psimsa:
Just out of curiosity, what do you think about the core idea behind SponsorLink itself?
I too think the core idea behind it has some merit, and that the initial implementation was terribly flawed in several ways. My whole point here is that Moq isn't the best place to discuss SponsorLink, because people are already so biased against it that they likely won't be calm enough to distinguish between SponsorLink the idea, and SponsorLink the terrible first implementation. The majority of people are going to focus on the latter and reject it outright.
As a collaborator of the Moq project, I am first and foremost interested in repairing the damage that was done to Moq. Right now, I am not really interested in SponsorLink and that's why I'm hesitating to discuss it in depth. I think it deserves a calm place where it can be discussed and developed, I just don't think that this repository is the proper place for that, due to what happened last week.
stakx
commented
1 year ago @aschan:
[...] wouldn't Moq vNext be an ideal jump off point for duplicating Duende's transformation of IdentityServer to OSS with a commercial license?
Possibly.
In this transformation I do believe it would be in Moq VNext's best interest to not have @kzu as the owner of that project.
I really can't speak for @kzu, but if I were in his shoes, I'd probably feel quite affronted by such a setup: I'd be graciously allowed (...) to develop Moq vNext for everyone, but prevented from taking ownership of my own creation?! Doesn't strike me as particularly fair. I understand where you're coming from and why you're making that suggestion (the issue of trust), I'm just not sure whether anyone (and @kzu, specifically) would be capable and willing to split intellectual and nominal ownership that way without feeling hurt, or even taken advantage of.
stakx
commented
1 year ago Besides, while many people have asked for a fork or even a new project owner, noone has yet stepped forward. Frankly, seeing the sickening amount of entitlement and cancel culture present in the ongoing discussions, it's not at all an enticing job prospect... if one isn't allowed to make any mistakes or missteps, ever, without getting cancelled right away, one would just set themselves up to be next in line. That's why I believe it would be best for everyone involved to show some more willingness to forgive. That being said, I do agree that @kzu needs to be the one to make the first steps towards mending things. And I'm aware that this isn't an easy process and restoring trust may take a long time... but we need to start somewhere.
aschan
commented
1 year ago @stakx
I really can't speak for @kzu, but if I were in his shoes, I'd probably feel quite affronted by such a setup: ... would be capable and willing to split intellectual and nominal ownership that way without feeling hurt, or even taken advantage of.
Which is completely understandable but the truth of the matter is that @kzu put himself in an impossible situation when injecting SponsorLink into Moq the way it was done. Either way he is going to have to eat humble pie in some form or other to attempt to resolve the situation. If vNext becomes a commercial OSS it is important that it's users/customers have trust in the organization behind it. And I believe @kzu must be an integral part of it given that it is his brainchild and his current involvment with vNext, but I do believe some form of oversight is necessary to appease enterprise organisations.
I worked as a consultant for 20+ years at major retailers, in insurance and financial companies with strict oversight, and at government agencies. For all of these the introduction of SL made Moq 4.2.x anathema to them according to their internal policies regarding third-party software. I am certain they don't want to replace Moq for cost and time reasons but if a major effort isn't made to rectify the situation they will be forced to.
psimsa
commented
1 year ago @stakx
won't be calm enough to distinguish between SponsorLink the idea, and SponsorLink the terrible first implementation
Naturally. But when the dust settles, the idea itself should probably not get forgotten.
if one isn't allowed to make any mistakes or missteps
There are mistakes and mistakes. How can, in his right mind, an OSS developer think that force-pushing a closed-source obfuscated library that gathers and transmits PIIs to the cloud out-of-process without consent was gonna fly?
whether anyone (and @kzu, specifically) would be capable and willing to split intellectual and nominal ownership that way without feeling hurt, or even taken advantage of
Probably not. Then again, when you mess up this bad, there are consequences. And people should be held accountable for their actions, even if that means feeling hurt.
I think that once your project reaches certain threshold of contributors, downloads and widespread use, you are no longer the ruler with unconstrained power over what happens to it, you made the project part of kind of an elite group, together with the likes of .net, react etc., and "unprofessional" is a gross understatement of what happened to Moq. Kzu stepping down himself would be the best thing to happen to Moq - instead, the responses from him I've seen so far didn't make me think it's a good idea to rely on a project where all the power is given to someone this irrational. While (unlike some colleagues) I pushed for the chill-pill so far, waiting for further events, I think there are many who don't want to cancel moq because of the scope of work but it'll be a necessary step if future stability is not somehow ensured.
Arcalise08
commented
1 year ago Frankly, seeing the sickening amount of entitlement and cancel culture present in the ongoing discussions, it's not at all an enticing job prospect... if one isn't allowed to make any mistakes or missteps, ever, without getting cancelled right away, one would just set themselves up to be next in line. T
This guy added what was then a closed source package, which fired an obfuscated process which was only discovered through reverse engineering. To be an admin reading what was going on at the time is nothing short of a nightmare. You can say it was just a mistake. And maybe it was. But man what a mistake to make. Moq has millions of users, there was no discussion on this. No burn in time for SponserLink. And no opting out. We want him paid for his work but this is the wrong way to go about it.
As for SponserLink, I think the idea itself is solid. Although I firmly believe that it's not for a 3rd party to implement. It seems best to let git providers or IDEs themselves implement something like it. There's a lot less security concerns that way.
psimsa
commented
1 year ago Although I firmly believe that it's not for a 3rd party to implement. It seems best to let git providers or IDEs themselves implement something like it
I'm thinking more like some sort of foundation or something that would back the entire project, not just the .Net/Nuget implementation.
Gavin-Williams
commented
1 year ago "twelfth most downloaded NuGet package" - are you serious? And he doesn't make an income from it? Yeah, wow, now I understand why people are talking about the problem with open source and github. That's a massive issue.
tonyqus
commented
1 year ago @Gavin-Williams I think it depends on the type of the open source project. Usually, backend framework or no-GUI project is harder to get income from users. Moq as a test framework is targeting QA or SDET as major users. And big boss (who has finance permission) usually don't care much about QA's work. Even if some kind QA or SDE raise sponsorship application to a big boss/engineering manager, it's hard for them to show big benefits or cost down from using Moq.
wrexbe
commented
1 year ago @kzu absolutely destroyed any reputation this package had. You should fork it and find some maintainers who won't add malware in the future.
Well the package itself took a hit that should still be salvageable (sure, that AWS started a PR to remove themselves from the sponsors list really wasn't a good look) but I feel that I don't trust anything that @kzu touches anymore. As long as he has the ability to push new releases without review I'm not adding Moq (or any of his other libraries) to any of my projects and I think that that is how many people feel.
My ideal solution would be that @kzu stepped down (or was removed) from the project completely and any trace of SponsorLink was removed. But seeing that he has contributed almost as much as @stakx I don't really see that happening. It is weird however that the sponsor banners/buttons in this repo is to sponsor @kzu personally and not the actual project.
With how many nuget's this guy is involved with (317 Packages just from looking at Nuget), I'm not sure that is a realistic option. There is a good chance your using something else he made, or helps with https://www.nuget.org/profiles/kzu
ewrogers
commented
1 year ago "twelfth most downloaded NuGet package" - are you serious? And he doesn't make an income from it? Yeah, wow, now I understand why people are talking about the problem with open source and github. That's a massive issue.
It is a massive issue, and I feel for those devs because most OSS projects are a labor of love (outside acquisition or corporate partnerships). But basically making it into malware (via activism) ain't it.
tonyqus
commented
1 year ago It can be a massive issue if you only think money as income. It depends on how you define income and your religion.
For me, as a buddhist, I believe OSS contribution is maily for the next life instead of this life. We have concept called Karmic debt in Buddhism. OSS can help you reduce the Karmic debt and create a better life for your next life. OSS projects eases the life of most developers, which is best practices of ‘Purdue sentient beings’.
According to my understanding of Karmic debt, both @kzu and @stakx will have a better life in their next reincarnation. However, @kzu may get some consequence on SponsorLink event since it's kind of a mistake. But it doesn't mean this mistake will eliminate what he has done in the past 10 years for Moq. You cannot simply make bad things equivalent to a number of good things. Bad things and good things are two different things in Karmic debt formula. Anything you have done will cause consequence.
ZeroDotNet
commented
1 year ago @kzu replied to this matter in his blog: https://www.cazzulino.com/sponsorlink-feedback.html 👌
y2k4life
commented
1 year ago @ZeroDotNet he did not answer the question and misdirected the question of trust to using one way hash. The question of trust was more the actions taken and not so much the implementation.
No answer is an answer. By not giving a clear answer, direction and vision of SponsorLink related to Moq then one can only assume the worse. And to not answer one who has contributed as much as you have is a red flag. By continuing to talk about SponsorLink here on Moq and not closing issue #1374 is not the answer I'm looking for. Without an answer to your question then one can only assume it will be back and @kzu will continue the experiment. @stakx I'm willing to forgive but because the trust was broken (not one way hash trust), I need something to help with that forgiveness. I can forgive regardless, and I can move on without an answer. But until I have an answer and that is in line with your questions and mine then one can only assume the worse and plan accordingly.
kzu
commented
1 year ago Heya @stakx! Sorry I took some time to respond, I wanted to provide longer-form context that wouldn't be lost in a sea of comments here. Please do let me know what you think now that (hopefully) you have the full context: https://www.cazzulino.com/sponsorlink-feedback.html
This is not a "guinea pig" experiment. If there is ever going to be a Moq vNext that addresses the many issues you properly identified (just an example, #568 which IS supported in vNext), the current status quo (I work countless hours for free) won't work.
So, unless people really think seriously about what they want the ideal experience to be for SponsorLink, integrated into the various libraries (mine and others), vNext just won't happen. Unless you go and do the whole thing yourself, and I'll cheer from afar. And you'll get to pick your own repo and project name too.
Either way, I'll be fine, no hard feelings, and I'll be grateful for your contributions to this project as I'm sure lots of others are. I consider myself lucky that someone stepped up. As you have noticed yourself, that ain't easy to come by, so if you do go that route (and start from scratch), if the status quo doesn't change, you're just going to be kzu v2 down the road (if the project takes off similarly).
Folks seem to think that just yelling at me and trying to get me to apologize loudly and ask forgiveness and bend to the crowd (to be polite) is going to magically fix the OSS sustainability story. Wishful thinking.
y2k4life
commented
1 year ago We have an answer, to summarize the answer to @stakx question.
No
Thank you, good luck with your projects @kzu. I forgive you for breaking the trust (not the one-way hash) I had with your product to not do the unethical things you did with it. I will be moving on. If sponsorship is what you need, I think a different approach would have been better. It would have been different if the buzz on the interweb was "Moq is looking for sponsorship to help with vNext" rather than what we are seeing now. I guess the saying "Any news is good news." Thank you also for bringing this issue to light and I will put in my budget support for OSS projects just not this one if SponsoLink is going to be a part of it.
kzu
commented
1 year ago @y2k4life that's fair. Farewell and good luck to you too. I understand you're feeling "hurt" but since you clearly waited for this reply to "move on", I take it that you didn't even consider how SponsorLink could evolve and actually be something you could support to help this project and others get properly funded, You just wanted confirmation that your "trust" was "regained" by just not having to sponsor at all ever, neither be reminded even with an Info diagnostics and no PII sent whatsoever (which is precisely what I'm working on right now).
So, allow me to be skeptic as to your true intentions here.
psimsa
commented
1 year ago @kzu here is what I am looking for: "SponsorLink will not be part of Moq until it is stable and accepted by the community." Nothing more, nothing less. Can you do that?
I do believe (something like) SponsorLink is definitely something to be evolved because the idea itself is actually great. As I described above - the main blocker I experienced in trying to get companies support OSS is that it's rather complex from organizational and accounting point of view. An automated process would greatly increase willingness of companies to sponsor OSS, as far as I can tell.
kzu
commented
1 year ago @psimsa with all due respect, the only ones who I care for acceptance are other library authors who are similary struggling to get funded. What "stable" means is also fuzzy.
I appreciate the feedback from the community and will do my best to address the concerns (which I'm actively listening to and working on), but the vast majority is just asking for "never put anything in it, we don't care for sponsorships since they will never work and why don't you give up or do X or Y instead". I just can't promise I won't move forward until I can convince everyone, since that seems like an impossible task and beside the point even. Anyone can fork the project when SponsorLink comes back in a more PII-preserving fashion, switch to an alternative, and move on.
It's not as if ImageSharp, NServiceBus, HashiCorp and everyone else before them waited for "the community" to happily accept licensing changes. So what you're really asking is not realistic at all.
y2k4life
commented
1 year ago @kzu you don't understand, my feelings are not hurt. My emotions are not part of this. You can trust or not trust without feelings. I said I was going to move on regardless unless the answer to @stakx question was yes. You are turning my trust in to trust of the product, my trust has nothing to do with the product or if it is using the most advance hash algorithm it has to do with you and your actions regarding Moq and if I can trust you.
The nagging aspects of SponsorLink, the downloading of another app to make it work, the UX impacts, the use in a corporate environment, privacy, obfuscating and source code. Those are all the issue I see with SponsorLink and if corrected would make SponsorLink not be what it is intended to be. Yes, you are addressing them and have address some of them that is a good thing.
When I say good luck with your products, that is plural, I even mean with SponsorLink. Prove us naysayers wrong. I'm just going to avoid it.
jaredthirsk
commented
1 year ago @stakx
That being said, I do agree that @kzu needs to be the one to make the first steps towards mending things.
Can you describe what this would look like to you?
kzu
commented
1 year ago @y2k4life for someone as commited to the project, you seem to be blissfully unaware that:
Arcalise08
commented
1 year ago I appreciate the feedback from the community and will do my best to address the concerns (which I'm actively listening to and working on), but the vast majority is just asking for "never put anything in it, we don't care for sponsorships since they will never work and why don't you give up or do X or Y instead". I just can't promise I won't move forward until I can convince everyone, since that seems like an impossible task and beside the point even. Anyone can fork the project when SponsorLink comes back in a more PII-preserving fashion, switch to an alternative, and move on.
There are so many ways to get funded besides intentionally putting obfuscated email scrapping packages into your project and giving every security admin a heart attack.
There are so many of these ideas on how to get it funded. And honestly SponsorLink might help a bit but isn't gonna suddenly make it a profitable venture.
Having an open discussion on this topic is the best way to approach this. I can't speak for everyone but we supported this library and understand you need to be able to provide for yourself while maintaining it.
kzu
commented
1 year ago Again with that argument? It's been OSS and un-obfuscated for DAYS now. Sigh...
I appreciate the list of alternatives. Not that folks haven't tried those and many more, I'm sure. I'll keep trying to add a (nth) choice if you don't mind. We'll see how it goes.
to provide for yourself while maintaining it.
I think this is missing the point. I create content, which happens to be OSS. I'm not looking to milk y'all for maintaining a 10+ yo project. If anything, I want to blow people's minds with newer, more powerful, more amazing productivity tools and libraries. (yes, that might as well be a Moq vNext that is beyond anything else around).
rubenwe
commented
1 year ago And you'll get to pick your own repo and project name too.
Wow. That's petty AF towards someone that's been a major contributor.
It's not as if ImageSharp, NServiceBus, HashiCorp and everyone else before them waited for "the community" to happily accept licensing changes. So what you're really asking is not realistic at all.
People of course weren't happy with these changes, but especially ImageSharp as a point of reference in .NET land, keeps on delivering great new versions and features to back up their commercial standing.
In your blog post you alluded to wanting to be a content creator. As you may be well aware, the income of content creators does not only depend on the quality of their work, but most of all, on how they are able to sell it to the audience. The problem is not sponsor link itself, but how you sold it.
Wanting to develop vNext of Moq, leaning into the outlined concerns here and going for a business license so you can do it full time would probably have gone over better.
But hey, now you already had your Logan Paul moment. Things can only go up from here :)
psimsa
commented
1 year ago @kzu
with all due respect, the only ones who I care for acceptance are other library authors who are similary struggling to get funded
Well, with all due respect back-at-ya, if you don't get acceptance from those with money - specifically corporates (like Amazon/AWS), you won't get far. Unless you can convince all such authors to unify behind SponsorLink and "fight" the corporations at whatever the cost.
"never put anything in it, we don't care for sponsorships since they will never work and why don't you give up or do X or Y instead"
With all due respect pt. 2, that's not what I said.
It's not as if ImageSharp, NServiceBus, HashiCorp and everyone else before them waited for "the community" to happily accept licensing changes. So what you're really asking is not realistic at all.
I think there is a big difference between making a licensing change and introducing 2-way communication with remote servers. I don't have problem with the idea behind SponsorLink. But, with all due respect pt. 3, it'll take more than an assurance of a single developer that everything is daisies and rainbows before I let it in any project I manage at the company I work for. I will either have to inspect the code myself (or one of my colleagues for that matter) or have an assurance from a wider community of developers who are behind the project.
kzu
commented
1 year ago @psimsa
you won't get far
you seem to think that somehow, I could get LESS far than I've gotten to far 😅
Sorry if I misrepresented your request here. Most seem to just be demanding "total capitulation" (just as the title of this issue, TBH) as the only course of possible action. That won't happen.
2-way communication with remote servers
How so? Have you audited the now OSS code that does the whole thing? Could you be more specific?
wrexbe
commented
1 year ago @y2k4life for someone as commited to the project, you seem to be blissfully unaware that:
- The build pauses will be gone
- The obfuscation has been gone for DAYS since it's all OSS now (what's the point?)
- The sending of email hashes during a build will be gone
- By "downloading of another app" do you mean downloading the GitHub CLI that I'm thinking for v2 of SponsorLink? Or are you confused about what a GitHub App actually is?
I think that is enough for it to be ok. @kzu I wonder how people would feel if you added a text file to the project when you installed Moq. While that could still be a little annoying, people could just remove the file, and it wouldn't change build times. You could also consider adding some public methods that are just like Moq.SponserMe, or something like that, maybe it can print out the message if you call it.
Another way to make money I have seen is offering paid support, I'm sure there are people who would pay for advise on setting up, or improving unit tests. There are also people who work for companies, that could convince their company that they need a support contract (but then rarely ever use it), so they can support the project without needing to pay it themselves. You could even make the contracts about bug fixes, or security fixes, which you would of probably done anyways.
psimsa
commented
1 year ago you seem to think that somehow, I could get LESS far than I've gotten to far 😅
Well - Amazon/AWS for one already got pretty upset, from what I've read around. So yes, you can get less far. Most of those you apparently do not consider acceptance-worthy are your consumers (if we stick to the 'content creator' paradigm) and if you tell them "wuteva, I do what I want" they'll stop being your consumers and there goes your content creation. Many also work for companies that sponsor OSS and if you want a share of that sponsorship you need to be more "accepting" as you put it. And frankly it would be a pity to see both Moq and SponsorLink turn into dust just because of, well, less-than-ideal approach, to put it politely.
How so? Have you audited the now OSS code that does the whole thing? Could you be more specific?
Not yet - I did read the documentation though so my remarks are based on that (though if it got updated in the past maybe 2 days I might not have the most recent info). I will if it comes to choosing between Moq and something else. I am aware that it's been open sourced shortly after the initial poopstorm, and that you're working on resolving the PII problem. Kudos for both btw.
wrexbe
commented
1 year ago Yeah, but he's not getting money or anything for this, having AWS on the project looks cool and all, but it has no effect on his life. He was making this when it wasn't popular, and I'm guessing he just intends to keep making it, popular or not.
psimsa
commented
1 year ago @wrexbe original state: AWS on project, no money desired state: AWS on project, some money current state: no AWS, no money
how is that not less? unless the approach is "unless you pay i don't care if you're on the project" in which case however, again, here goes your content creation, unless you turn purely commercial.
rzn34
commented
1 year ago How so? Have you audited the now OSS code that does the whole thing? Could you be more specific?
OSS is not the issue here. The fundamental issue is that we simply cannot trust you. The fact that you keep emphasizing that this is a OSS sustainability issue rather than a trust issue is making things worse.
Put it simply -- you have the sole ability to distribute the releases. Why should we believe that you aren't going to make local modifications, include a malware again and release it to the wild?
wrexbe
commented
1 year ago He already addressed all the issues, so other then feeling butt hurt, there isn't anything to argue about now. He maintains over 300 libraries, making him stop on this one project is unrealistic, and pointless. He tried out something, and made a mistake, he learned from it. Time to move on. No more drama lama
Arcalise08
commented
1 year ago He already addressed all the issues, so other then feeling butt hurt, there isn't anything to argue about now. He maintains over 300 libraries, making him stop on this one project is unrealistic, and pointless. He tried out something, and made a mistake, he learned from it. Time to move on. No more drama lama
Yeah sure. No more drama lama. We already removed moq from everything around the same time nick chapsas dropped his video on it. Moqs reputation has been severely damaged. There's no point in continuing the discussion though. I will never use it again but maybe some of you will. Good luck with that
The way how Moq is being used as a "distribution channel" for what (at this moment in time) essentially amounts to a social experiment strikes me as really unfair not just to Moq's user base, but (ironically) also to the project itself and all of its contributors. As a frequent collaborator, I've taken great pride in being part of such a widely respected project, and I dare say it's been an essential go-to tool in the .NET ecosystem. (Yes, there are some great alternatives like e. g. NSubstitute or FakeItEasy, and I'm not discounting those; but fact remains that Moq has so far been the most popular of them all.) All of this is now being put into jeopardy in order to get feedback on, and develop, SponsorLink.
I'm not commenting on SponsorLink's potential here – it may or may not be a good idea – but assuming that SponsorLink is actually a great idea worth following up on, then shouldn't it be able to stand on its own legs and get some traction without having to piggy-back on the success of another hugely successful library like Moq?
I know it's been tried before, but in the hope that my ranking as the current top contributor to the project bears some weight, I'd like to kindly and respectfully request that SponsorLink be completely removed from the Moq project, and that it not be brought back again, unless (and only if) it has proved itself to be a viable and generally accepted part of the .NET ecosystem.
If you do need some library to test SponsorLink on, please let it be something other than Moq... Moq is simply too valuable and important to be squandered this way.
P.S.: Some shortcuts:
I've published my personal fork to NuGet, with certain restrictions regarding collaboration; see https://github.com/moq/moq/issues/1396#issuecomment-1684974621.