Stop using Moq as a guinea pig to get feedback on and develop SponsorLink

[stakx]

Stop using Moq as a guinea pig to get feedback on and develop SponsorLink

[stakx]

@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.)

[gnurcz]

@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.

[stakx]

@kzu, I think I got a response to my original request... even though it's not the one I was hoping for. Since this issue got a little off-track, I'll try to summarise:

My original request

"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." – from https://github.com/moq/moq/issues/1396#issue-1848634529

How the request got answered

You didn't directly address this request here, so I'll start by citing you from a few other posts:

"First and foremost: folks, just stop panicking and realize the latest Moq doesn't have SponsorLink 🤦‍♀️. To all those with GDPR concerns: it's gone and it won't come back. Email (SHA256) "collecting" won't happen ever again." – from https://github.com/moq/moq/issues/1374#issuecomment-1671240325

Here, its not entirely clear whether SponsorLink itself "won't come back", or just the email collecting aspect of it.

"At this point, I can confirm I won't be bringing back anything that involves PII. This means the implementation will be different, but I think I'll continue to pursue a way to entice users to sponsor. I do want to work on a most awesome vNext, but I won't be able to if no-one will be willing to help." — from https://github.com/moq/moq/issues/1374#issuecomment-1671866096

This likely answers the above uncertainty: it's the email collecting / PII aspect that won't come back.

"either SponsorLink works acceptably for folks and it gets significant traction (for myself but also others wishing to get sponsored for their OSS work), or I’m just giving up on OSS entirely." – from your blog post

You've made abundantly clear how invested you are in SponsorLink, and you've promised that it won't come back in a form that will cause another data privacy nightmare. By not directly replying to my original question, and via the above statements, I think it's reasonable to assume that SponsorLink may return to Moq in the future, in some improved form.

I'm really glad that you've taken steps regarding data privacy and PII, and that's almost good enough for me... only time will tell whether or not the future implementation of SponsorLink will be acceptable to the Moq community. This part of my request remains unanswered for now.

What's still missing for me personally

I believe that in your desire to improve the financial situation of OSS maintainers in the future, you've done the present-day .NET community a great disservice. Even though you have a noble and worthwhile goal in mind, the end does not justify the means. You don't seem to realise (or at least you haven't acknowledged) that people other than you also have a stake in Moq, and disregarding those people's interests was bound to offend them.

Let me illustrate this a little bit.

"[...] others are trying other things. So am I. It may work, it may completely flop and cause Moq users to go to zero. I'm willing to risk it [...]" – from https://github.com/moq/moq/issues/1374#issuecomment-1672221248

To me as a major contributor to Moq, this is unacceptable. Why should I go on caring for Moq and invest my time & passion in it when you, the project owner, are willing to kill it off at any moment (and without including me in the decision process)?

(Btw., this quote should explain why I think the term "guinea pig experiment" fits: you're willing to sacrifice Moq, the proverbial guinea pig, for something you consider a greater good. But I won't insist on using that term any further if you find it inappropriate.)

In your blog post, you also wrote that...:

"For all I knew, the project was almost in a zombie state, and I was on the verge of entirely giving up for good on it." – from your blog post

You even acknowledge me as the main contributor to the project. (I appreciate the credits, btw. Thank you! ❤️) But did it not occur to you to contact me and ask whether I was still interested at all in the project before declaring it abandoned and having your way with it? (My answer would have been this: "Yes, I am still very much interested in contributing to Moq. I have been taking a temporary break from OSS due to being otherwise busy in my life, but I am planning on getting back to work on Moq this autumn / winter.")

This is your project, you created it and you also own the GitHub organization behind it. But you should know that when one contributes to someone else's project for so many years, one slowly makes it their own, too. In my eyes, Moq is, in actual fact, not longer exclusively yours.

I think the people who said that ownership of Moq should be transferred to a group, organization, or foundation were on to something: it may have prevented you, currently the sole nominal owner, of making a decision without consulting other key project members.

For much the same reason, I've also come to believe that any project with more than a single maintainer should be transparent about its decision making process; that is, it should explicitly declare how it is being governed.

In conclusion, I'm surprised and TBH somewhat disappointed in how you handled (or rather mishandled) communication. I'm still hopeful that things can be mended... but at present, I'm inclined to take a step back from this repository and observe how things develop. I would like to keep contributing to Moq, but I have one key requirement:

• The project must be respectable and in good public standing.

What I'm going to do in the meantime

This is my current plan (I'm not making any promises, though):

1. I will continue contributing to Castle DynamicProxy, the library underpinning Moq v4 but also other popular .NET mocking libraries... so this will be to the benefit of all mocking libraries, not just Moq. I enjoy working on DynamicProxy (despite its somewhat convoluted source code 😆) because that kind of low-level meta-programming fascinates me... plus the project is well-governed.

2. I will publish my personal fork of Moq (pre-SponsorLink) to NuGet (likely under the package name stakx.Moq at first). ✅ This fork's source code will remain open, but collaboration will be restricted to project members only. Anyone may ask me (via e-mail) for an invite, but project members will be required to contribute. That is, noone will get anything for free. People can download and use the published package, and if it happens to suit their needs, good for them... but they'll have absolutely no say whatsoever in the direction the fork project takes (they won't even be able to open issues, nor send PRs), unless they're willing to become a part of the project and invest their own time in it. This is in order to keep people from ever acting entitled without an actual basis. It'll initially be my special task to onboard new members so they become familiar with the code base and can become maintainers themselves. TBH, I don't expect the fork will ever get that far, but if it did, it would be renamed and transferred away from my personal GitHub account so that ownership is truly shared among all parties involved.

3. I do not intend to create a Moq vNext of my own. I'm quite possibly lacking the necessary experience with newer tooling such as Roslyn. I still believe you're in the best position for that, and I don't wish to take that away from you or sabotage your efforts. (But I'll still come to the defense of Moq vCurrent.)

P.S.: I realise that this post may sound a little harsh. This whole situation has really made my head spin, and if I am to regain some peace of mind, I feel that I can no longer avoid some uncomfortable facts... but I truly don't mean to give you any offense.

[kzu]

Heya @stakx! Thanks for taking the time to respond. I think taking time and meditating is a crucial part of taking the discussion forward. Some folks just assume I woke up one day with a crazy/stupid idea and just went with it. I shared my thoughts on this with at least one prominent OSS guy as far back as December 2020, so I think that's important context too. I have been ruminating about this for a while (and till I'm sure I totally missed a bunch of scenarios, side effects, and incentive alignment issues!).

Your original request

I'm sorry you had to go fishing around for a response. I was not being intentionally obtuse. To make it perfectly clear: I will bring SponsorLink back to this project (and every other project I work on), and do so in a privacy-preserving way (you can explore the candidate approach). I perhaps avoided saying it in such stark terms because folks were going to assume my intention was to continue "violating" their GDPR/privacy rights and insist "I learned nothing" and what not, instead of what I always planned: put it out, learn from feedback, iterate and improve until it (hopefully) solves the problem I set out to solve (namely, sustainability).

On current Moq, its contributors and you as the main maintainer

As you properly pointed out, more and more new C# features are starting to pile up as unsupported "tech-debt". Moq cannot survive in the long run unless it evolves with C#, or it will eventually (inevitably?) become irrelevant legacy software. I don't think this is hyperbole. So the question of a major rewrite and how it can happen, is not a side-show detail, IMHO.

You made it quite explicit to me in the past too, that you could simply not dedicate enough time to anything vNext. I know you aren't doing the work on the current Moq for the money (there is none, after all!), but can't you envision a world in which you actually could? Quit your current job (or take a sabbatical?) and work full time on something that (as you mentioned) fascinates you? Why should that be a pipe dream?

I had conversations with folks on the GH sponsors side, and on the MS side, and are actively pushing for things like Sponsor based GitHub feature toggling so that that dream becomes a reality. I would love nothing but for you to get paid for the work you do, possibly even do it full-time if that rocks your boat. Users should be able to vote with their wallets on issues that are important to them, and you should reap the benefits of fixing them. Somehow folks act as if that's a terrible goal and an outright disgusting thing to even propose.

You should be free to continue doing it for free, if you so choose, by just not setting up a sponsorable account, though.

On ownership and governance

I am forever grateful for your contributions to the project (past and hopefully future!), as well as the countless others who sent PRs. That said, I don't believe in design by committee. If there is ever a vNext that blows the competition out of the water, it won't happen because we vote in some Zoom meeting on whether we should X or Y. It will only happen if someone (i.e. me) sits down for MONTHS and works TIRELESSLY on it, obsesses over every tiny API naming, over extensibility, over long-term maintainability, and so on. As you pointed out yourself, that won't be yourself, and you would be one I'd considered well positioned to so so! Imagine what it's like for regular users that just consume the thing or report an issue or even send a PR for a very focused change/improvement.

So what are the tools at my disposal to take a shot at doing that? As I explained in my follow-up blog post, the status quo just didn't work no matter how hard I tried. There's also a chicken-egg problem: I'd have to put a MASSIVE effort into it before getting ANY benefits from doing so. And at the end of the road, what would await me is a clamor for a committee to take over whatever I did and "not ruin the project" for them.

That hardly seems like an enticing proposition.

I would like to keep contributing to Moq, but I have one key requirement:

• The project must be respectable and in good public standing.

I never promised anything to anyone other than just publishing my OSS code, pushing a nuget, and hope that fellow devs would find it as useful as I did (and still do!) myself. I cannot promise respectability (I may come up with a crazy idea everyone laughs at! fair enough, that's what you risk putting your ideas and code out there!), neither "good public standing" (anyone is free to think whatever they want about what I do or not do).

I have explained in excruciating detail the reasons and my goals in implementing SponsorLink. Until such time similar features are offered out of the box by VS/VSCode/NuGet/GitHub, I will continue to iterate and improve it and depend on in for any future projects I do. I think it's abundantly clear by now that Sponsorships is ENTIRELY compatible with OSS. From the idea and goals point of view, I don't think I'm doing anything non-respectable or worthy of massive desertion and public scorn.

So, maybe I was a bit (lot?) naive, but I would have thought that the prospect of a revival of a vNext would have been exciting to you, rather than "unacceptable" gamble on my part. Do you have any doubts that if Moq vNext happened it will be massive and leave every other mocking library biting the dust? I have no doubts because I'm quite clear too on the limitations of the underlying techniques we ALL currently use. And I've seen what a totally revamped approach can achieve.

In closing: I deeply appreciate your contributions. I hope SponsorLink takes off, folks start to massively sponsor this and many other projects, and lots more dotnet OSS can flourish as a consequence, and therefore Moq vNext happens too! Which at that point might be sufficiently interesting that you'll consider coming back to the project.

[kzu]

@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.

[kzu]

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.

[rzn34]

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.

[PetterHiab]

@PetterHiab what would you suggest I use to fund the significant work it would take to keep Moq relevant as never-ending features are added to the C# language? Why wouldn't sponsorships from current users be OK for that?

I suggest you stop. Find a new hobby.

[karl-sjogren]

@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.

[stakx]

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.

[psimsa]

@wrexbe

He already addressed all the issues, so other then feeling butt hurt, there isn't anything to argue about now.

I may not be a distinguished OSS developer. But I have 20+ years experience of working in corporations, including Microsoft in Steve Balmer's era, banks, medicals, consultancy etc., and that's not really how this works. You can't expect everything to just go away by providing a code fix, if part of the original problem was that security scanning tools flag you as malware and you make the news for leaking PIIs. This kind of damage sticks for a long time in corporate memory.

[stakx]

@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.

[kzu]

@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.

[jamesbascle]

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.

[y2k4life]

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.

[tonyqus]

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.

[essial]

Unfortunately for us corpo drones, we've already been pulled into backroom meetings by security due to this change. The damage has been done and we (and most likely a lot of other companies) have been mandated to remove MOQ completely. Wonderful, I really needed my technical debt backlog doubled.

This isn't a hate post, as there's nothing really I or even you can do about it. It's your project, free to do with as you wish. It was a fun ride while it lasted, and I wish you nothing but good luck in the future!

[ewrogers]

@PetterHiab what would you suggest I use to fund the significant work it would take to keep Moq relevant as never-ending features are added to the C# language? Why wouldn't sponsorships from current users be OK for that?

There are several solutions to "monetize" a project. I understand the desire, you put time and effort into making something and it only seems fair that if it gives values to folks, that they compensate you in return for that. This is basic capitalism and market economy.

Not everyone is motivated by money (or at least not majorly) and hence the OSS contributions. Most of these types of projects are worked on people out of their own desires without the expectation of compensation. I agree there is a "feels bad" element to that because we all know that many of the pivotal systems (including OSes like Linux) are OSS, outside of proprietary drivers.

The "could have", "would have", "should have" does not matter. If something is donation-ware, you would be hard-pressed to make money on it "out of the goodness" of people's own hearts. And even less likely from a corporation standpoint. Yes, it does happen from time to time but rare and usually not to a sustainable amount where you can quit your full-time job and work on it. It just is what it is, again capitalism.

So, as tough as it may be to hear, you were doomed from the start by making it OSS if money was your goal. And I say this as someone who has built things used by thousands of people that I probably could have made good money on, if I charged for it. My mistake, live and learn.

You do have a couple choices from this point onwards, that would be far superior to the route you have tried to take:

• Free + Paid versions of the Moq library (behind some kind of download/package manager)
  • The "SponsorLink" angle or adjacent is not going work, again sorry I know you don't want to hear that
• Keep current Moq in "archived" state, work on vNext as paid solution
• Paid support contracts (yearly)
• Paid users get to dictate new features/enhancements (vote/poll systems)
• Restrict GitHub issues to paid users (not sure how this can be done, but idea)
• Paid training/consulting with hands-on examples of using the library

The key thing you need to always remember is that enterprise usage is where you will make most of your money. Sure, it sounds nice for the lowly devs to give a few bucks to use this but that isn't going to be the reality. It's going to be companies that say "this is the package we use, its one of the best for this work, we buy it for $X/yr". And someone in accounting signs off on that business expense.

So to tap into that market you absolutely cannot have things inflating build times, phoning home, or being just awkward to use in CI/CD deployments.

Look at something like Telerik components. Do you think they would have taken this approach?

Individuals are getting more and more tired of the endless subscription and micro-transaction model. Now I have another $2 subscription I have to remember and add on? This sounds more like Patreon than enterprise development.

[WeihanLi]

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

[karl-sjogren]

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.

[jamesbascle]

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.

[y2k4life]

@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.

[stakx]

@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.

[kzu]

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).

[wrexbe]

1. The Build pauses should be gone devlooped/SponsorLink#33
2. The obfuscation has been gone for DAYS since it's all OSS now (what's the point?)
3. The sending of email hashes during a build Replace hashed email with something else for user>sponsorship mapping devlooped/SponsorLink#31
4. By "downloading of another app" do you mean downloading the Replace hashed email with something else for user>sponsorship mapping devlooped/SponsorLink#31 (comment) that I'm thinking for v2 of SponsorLink? Or are you confused about what a GitHub App actually is?

@kzu congrates on the progress

4. What is this? https://github.com/apps/sponsorlink

for someone as commited to the project, you seem to be blissfully unaware that:

Don't need the rhetoric though not helping the cause just let me know these have been updated thanks. Lot of crap flying around to keep track of all it, your actions have caused a *** storm.

That is what we in the business call outdated documentation. It's a very common thing to see in open source libraries after a recent change.

y2k4life
So the y2k bug that caused a ton of drama huh. for life? Drama Lama as well I see.

[PetterHiab]

That said, you can always "invest" in replacing it when there's no need for it. I just believe that the next library will eventually be in the same situation as Moq unless OSS sustainability situation changes, so I'm not so convinced that's a good "investment" either.

No. You are assuming everyone thinks like you. Not everyone think they deserve to get paid for things they do on their freetime. For example, I don't expect to get paid for volunteering as a football trainer for kids. Still takes 3 evenings out of the week.

[tonyqus]

The changelog of 4.20.69

What's Changed

• Removed SponsorLink https://github.com/moq/moq/pull/1375
• Remove AWS sponsorship from readme by @kzu in https://github.com/moq/moq/pull/1383
• Add everyone how now DOES sponsor

This version looks good to me.

[stakx]

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.

[kzu]

@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?

[Fuchs]

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.

[wrexbe]

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

It wasn't exactly that important of a library, if you managed to remove all usages in a day or two was it? For such an unimportant library, and you pointing out the drama lama part, is a strong indicator you are in fact a (pulls of your mask) a drama lama.

[TiberiusDRAIG]

Unfortunately for us corpo drones, we've already been pulled into backroom meetings by security due to this change. The damage has been done and we (and most likely a lot of other companies) have been mandated to remove MOQ completely. Wonderful, I really needed my technical debt backlog doubled.

Unfortunately, this is the reality for a lot of us. Even if we as devs don't think it was necessarily nefarious, rather that it was simply extremely naïve, the damage has been done and decisions made for us. A shame it had to end like this, but here we are.

[Arcalise08]

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.

[rubenwe]

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 :)

[rzn34]

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]

The fact that he hasn't gone crazy, closed all the issues, archived the repo, or done anything like that, and he also made changes to address the issue is good enough for me. I've seen many a repo implode from things like this. Remember that he is a dictator in this repo, the fact he isn't abusing that is an amazing plus for him. I live, and breath programming, I have been doing it since I was in elementary school. I also don't give a shit about political things, and enjoy arguing. As far as I'm concerned when someone has to resort to backing up their argument with "I've been programming for yada yada years, at yada yada." That's great, good job, plenty of bad programmers have managed to keep their job for years. If that's all you have to fall back on, you have lost the argument.

[wrexbe]

Well if I was good at arguing then it would stop, and then were would the fun be?

[PetterHiab]

@kzu
so you are using Moq to fund vNext? Why do you think this is OK?

[psimsa]

@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.

[Gavin-Williams]

"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.

[ewrogers]

"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.

[psimsa]

@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.

[Arcalise08]

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.

• You could crowdfund vNext
• Apply for grants from foundations that use Moq
• Restrict larger organizations to paid licenses
• Turn moq into a paid product
• Have a free and paid version of moq

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.

[wrexbe]

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

[psimsa]

@wrexbe
not sure what that was supposed to be - but if it was addressed to me, maybe let me rephrase it and narrow it down: if you bring this kind of shitstorm to heavily-regulated environment, you don't make it gone by saying "sorry, my bad, here's a fix". That's a simple fact. If you don't believe me, ask someone else. I never "backed up" my argument by anything remotely like "I've been programming for yada yada years, at yada yada." It's not about programming qualities or expertise, unlike remarks "breathing programming" - I'm not in business of comparing willies with anyone. What I AM saying though is that in virtually all the places I worked in this would be a major problem that doesn't magically disappear with a new version of the library.

Btw, for someone who claims to enjoy arguing, I would expect a cleaner argument..

[wrexbe]

Alright see ya. No hard feelings

[kzu]

@ewrogers "if money was your goal"

It was never my goal, it still isn't. If it had been, I would have set up a company and dual-licensed it the moment adoption hit a certain threshold, which happened years and years ago with millions of users jumping onboard back in the day.

My mistake, live and learn.

I don't consider doing OSS a mistake to be learned from. I'd love to be able to continue doing it.

No seriously popular project needs $1 from each user in order to be sustainable. Only a small fraction would already be significant. So the argument that "in enterprise, it will never happen" sounds a bit definitive for something that is at least a twist on things done in the past. SponsorLink isn't just a button on a readme on a git repo (like Patreon or GH Sponsors itself). That itself might change the dynamics a bit.

At this time, I'm not really interested in becoming "the Telerik of Moq". Which is why I'm trying this thing. It may flop, it may result in a tiny bit of success and be enough. Time will tell.

being just awkward to use in CI/CD deployments.

Wasn't it absolutely clear that SponsorLink never runs in CI/CD? How is it making any of that awkward? It only ever runs in an editor, while being used, not merely installed.

endless subscription and micro-transaction model

Sure thing. Which would easily be solved by a Spotify-like subscription to (say) SponsorLink itself and you let it take care of splitting amongst your dependencies.

[psimsa]

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]

@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.

[aschan]

@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.

[ZeroDotNet]

@kzu replied to this matter in his blog: https://www.cazzulino.com/sponsorlink-feedback.html 👌

[psimsa]

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.

[aschan]

@PetterHiab

I suggest you stop. Find a new hobby.

This was in no way, shape or form polite nor constructive. I agree that @kzu screwed up and doesn't seem to understand or agree wih the the reason behind the outrage, but we should try to clarify and/or help rather than fall back to childish attacks.

To clarify, the technical implementation of SponsorLink didn't met the expectations from the consumers of Moq but that is secondary to the way it was introduced into Moq's codebase. A third-party (yeah, same author but still) library with a clearly dubious behaviour was injected in a minor version without oversight or "warning". I quote "warning" since @kzu did mention SponsorLink some six months previous but that was in no way sufficient. This is what erodes the trust in the framework and the author. Even if the software in and of itself wasn't (intentional) malware the fact that it uses similar behaviour as malware flags it as a security risk for most consumers. Sneaking it in "under the radar" is what the outrage and loss of trust is all about no matter how well intended.

To answer

@PetterHiab what would you suggest I use to fund the significant work it would take to keep Moq relevant as never-ending features are added to the C# language? Why wouldn't sponsorships from current users be OK for that?

I think sponsorship of future versions of a framework should be convered by the sponsorship of the current framework. I see no problem with this, quite the opposite. The problem with FOSS is that there is no such gurantee or even expectation. And to try and force the issue in this way may is detrimental to the issue. The current solution is to change the license model to a commercial licens. Future solutions may be as suggested; that consumers sponsor a change request and that sum is then forwarded to the developer, and quite possibly a percentage to the maintainers since someone must curate and review the PRs.

I do not think SponsorLink is the way to go, partly because it is now tarnished by this whole debacle. I suggest working with GitHub/Microsoft/etc. to find a common solution backed by the existing infrastructure.

It has already been pointed out but I still think it needs to be stressed. The individual developers using the framework shouldn't necessary be the once sponsoring. In most cases they have not been part of the decision to use a particular framework and they do not benefit financially from it. It is the organization that owns the software using the (F)OSS framework that should sponsor its use.

[stakx]

Thanks @kzu for taking the time to reply. I'm sure the past few days have kept you very busy, so I sort of expected a little delay. I just wanted to acknowledge that I've read both your above reply as well as your blog post, plus that I'm currently trying to gather my thoughts into a sensible order... I'll get back to you shortly.

[PetterHiab]

@kzu It's nice to see your statement 'money is not your goal'. I am still on your side as I can somewhat feel at the beginning
I do have a dream that one day I can tell her proudly that open source can make real money and at least it can raise the family.

You both are delusional. Money is obviously the goal. Stop prentending it isn't and license it for money to companies. Its the only way forward.

[ewrogers]

Just like tip culture in US. In most cases, tip is a must for every deals (usually 10-15% of the deal amount). But can you say tip is just for money? I think it's also about thanksgiving.

Tip culture is not the greatest example for several reasons. It is absolutely US-centric because this has been solved in better ways in nearly every other country. And then it begs the question "to what end?" Do I tip the person who took my order at the fast-food counter?

In software this would be "do I tip the guy who wrote left-pad vs the guy who wrote tokio which is the underpinning of Rust's async system"? Do I tip them the same? Do they both deserves the same amount? Is it based on "work" or just "stars"/downloads?

Then there is question of whether tipping is just a poor way to subsidize what the employer themselves should be doing in the first place -- paying their employees an adequate wage. In the case of software, it's like an unpaid internship/volunteer work vs your first job.

[aschan]

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.

[y2k4life]

@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.

[PetterHiab]

@PetterHiab

I suggest you stop. Find a new hobby.

This was in no way, shape or form polite nor constructive. I agree that @kzu screwed up and doesn't seem to understand or agree wih the the reason behind the outrage, but we should try to clarify and/or help rather than fall back to childish attacks.

To clarify, the technical implementation of SponsorLink didn't met the expectations from the consumers of Moq but that is secondary to the way it was introduced into Moq's codebase. A third-party (yeah, same author but still) library with a clearly dubious behaviour was injected in a minor version without oversight or "warning". I quote "warning" since @kzu did mention SponsorLink some six months previous but that was in no way sufficient. This is what erodes the trust in the framework and the author. Even if the software in and of itself wasn't (intentional) malware the fact that it uses similar behaviour as malware flags it as a security risk for most consumers. Sneaking it in "under the radar" is what the outrage and loss of trust is all about no matter how well intended.

To answer

@PetterHiab what would you suggest I use to fund the significant work it would take to keep Moq relevant as never-ending features are added to the C# language? Why wouldn't sponsorships from current users be OK for that?

I think sponsorship of future versions of a framework should be convered by the sponsorship of the current framework. I see no problem with this, quite the opposite. The problem with FOSS is that there is no such gurantee or even expectation. And to try and force the issue in this way may is detrimental to the issue. The current solution is to change the license model to a commercial licens. Future solutions may be as suggested; that consumers sponsor a change request and that sum is then forwarded to the developer, and quite possibly a percentage to the maintainers since someone must curate and review the PRs.

I do not think SponsorLink is the way to go, partly because it is now tarnished by this whole debacle. I suggest working with GitHub/Microsoft/etc. to find a common solution backed by the existing infrastructure.

It has already been pointed out but I still think it needs to be stressed. The individual developers using the framework shouldn't necessary be the once sponsoring. In most cases they have not been part of the decision to use a particular framework and they do not benefit financially from it. It is the organization that owns the software using the (F)OSS framework that should sponsor its use.

If he needs funding for another project, set up a kickstarter or apply for funding from some foundation. Don't bloat this project.

[tonyqus]

@kzu It's nice to see your statement 'money is not your goal'. I am still on your side as I can somewhat feel at the beginning of this event that you are doing something good for .NET community.

I suggest you come to join .NET Foundation maintainer group. It's a place you can give suggestions to .NET foundation and get feedback from a few authors of popular open source projects. I believe they are your real audience of Sponsorlink. And I did see some members are on your side.

I also suggest you look into web 3 since the payment feature is built-in web 3. Hard to pay and payment middle fee is still a big problem for donation and sponsorship.

Since I'm still travelling these days, I haven't got a chance to take a deep look into the SponsorLink code. I think I will do it and see how we can get rid of collecting git local info and with some other method like sign up or login to get the valid user ID to identity sponsors.

We should figure out a way to encourage potential sponsors to install this daemon if they can benefits from this installation. I think the win-win model is important. I'm still thinking of this these days because I'm also willing to see the booming of .NET open source and the .NET community can be more healthy than now.

My goal of doing all this is just to answer my wife's question all the time: why do you keep doing this non-profitable project all the time? She always blames me on this. It's a bit annoying. :D

I do have a dream that one day I can tell her proudly that open source can make real money and at least it can raise the family.

[stakx]

Thanks for the reply @kzu. Fair enough. I think we can leave it at that for the moment. I appreciate your expression of gratitude, too. I won't be leaving completely, but I think I will put my code contributions on hold for a while and observe how this project is going to recover.

One final note: I think I would be excited about vNext, if I took a closer look and started tinkering around with it. Probably not quite excited enough to quit my regular job for it 😃 (even if I got sponsorship), but Roslyn APIs are definitely fascinating, hobby-wise. Alas, my daytime job is no longer in .NET world (and hasn't been for years!), and it's become challenging enough to simply keep up with what's going on here... familiarizing myself with a technology as complex as Roslyn isn't easily possible for me at this time. But let's wait and see, that may change.

I think we can close this issue as answered (unless you want to keep it open a little longer for others to add their perspective, too, or finish their ongoing discussions).

[stakx]

@tonyqus, I'm sorry to hear that your enterprise didn't succeed. But at least you came away with invaluable life experience and you'll never have to wonder, "what if I had dared"? The world would be a poorer, boring place without risk-takers such as yourself.

[Arcalise08]

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]

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.

[tonyqus]

@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]

@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

[kzu]

@y2k4life for someone as commited to the project, you seem to be blissfully unaware that:

1. The build pauses will be gone
2. The obfuscation has been gone for DAYS since it's all OSS now (what's the point?)
3. The sending of email hashes during a build will be gone
4. 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?

[wrexbe]

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.

[kzu]

@PetterHiab what would you suggest I use to fund the significant work it would take to keep Moq relevant as never-ending features are added to the C# language? Why wouldn't sponsorships from current users be OK for that?

[psimsa]

@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.

[psimsa]

@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.

[Arcalise08]

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

It wasn't exactly that important of a library, if you managed to remove all usages in a day or two was it? For such an unimportant library, and you pointing out the drama lama part, is a strong indicator you are in fact a (pulls of your mask) a drama lama.

It was a major component of our unit testing libraries but nsubsitute works just as well without the security risks

[wrexbe]

@Arcalise08 Not really, with how much attention this repo is getting, I doubt it'll ever not be checked for security issues ever again. It's going to be one of the most secure projects that exists, with alerting tools immediately going off if anything funny happens. Switching off for security reasons is a bad bet. What doesn't kill it, makes it stronger

[psimsa]

If he needs funding for another project, set up a kickstarter or apply for funding from some foundation. Don't bloat this project.

Whoa... Wait. You consider the next version of moq to be a different project from current version of moq?

[ewrogers]

I don't consider doing OSS a mistake to be learned from. I'd love to be able to continue doing it.

I simply meant that once you try to cross the boundaries of (F)OSS to anything paid or donation/nag-ware... it becomes difficult. It is just the unfortunate reality that is very difficult to navigate in a way that makes both parties happy (and in both realms, personal and enterprise).

No seriously popular project needs $1 from each user in order to be sustainable. Only a small fraction would already be significant. So the argument that "in enterprise, it will never happen" sounds a bit definitive for something that is at least a twist on things done in the past. SponsorLink isn't just a button on a readme on a git repo (like Patreon or GH Sponsors itself). That itself might change the dynamics a bit.

I didn't mean every user had to subscribe, it was more around the fact that you would be hard pressed to get enough money from "indie" subscribers to make it worth your time.

• How large is your install base?
• How many do you think would realistically contribute?
• How much does that amount to?
• Is that still worth the time and effort you pour into it?
• What is your minimum goal?

Those are the kinds of questions I feel like are not going to be answered satisfactorily by the reality. Again, leaning on everyday people over larger corporations with deeper pockets is not the winning play.

At this time, I'm not really interested in becoming "the Telerik of Moq". Which is why I'm trying this thing. It may flop, it may result in a tiny bit of success and be enough. Time will tell.

I was just using them as an example of a long-standing "paid" package in the .NET world, and how they handle this kind of thing. It wasn't the "who" but rather the "how" that I was focussing on.

Wasn't it absolutely clear that SponsorLink never runs in CI/CD? How is it making any of that awkward? It only ever runs in an editor, while being used, not merely installed.

I admit I haven't done a deep dive on SponsorLink, but I don't see how you could "auth" into the higher tier without some sort of config/credential. So it'll just nag me in CI/CD, and I can safely ignore that? I can just remove my git creds and it'll ignore it and give me full functionality?

I guess I am a bit confused on the purpose of SponsorLink at that point. Are you trying to unlock features based on subscriptions, or just conditionally nagging the users to fund out of the goodness of their heart?

The former requires auth of some kind (thus CI/CD config) and the latter will just be ignored or considered an annoyance. It's like npm install showing the x packages are looking for funding -- do you think any Node.js developer honestly looks at that?

endless subscription and micro-transaction model
Sure thing. Which would easily be solved by a Spotify-like subscription to (say) SponsorLink itself and you let it take care of splitting amongst your dependencies.

Again, I apologize if I hadn't done my research into SponsorLink and I do think this is probably a best approach in terms of "split my static $X/mo across these allotments". It's just the implementation of how this comes across that I don't see how it works without coming across as an annoyance or yet another thing enterprise teams will flag and have to review for security (phoning home).

It's not my intention to come across as someone raining on your parade. I just get the impression that you may be overly optimistic and even a bit naive in terms of real world implications (judging from your initial attempts).

[tonyqus]

@PetterHiab If it just makes money for oneself, you can say the goal is money. If someone is trying to help every contributor in the community to get sponsorship, it's not just about money. It's about building a healthy community that every developer wanna contribute to open source projects and they benefits from the projects they work on.

Definitely money is important for OSS sustainablity although it's not everything. Most OSS developer give up a project not just because he lose passion, most of the time, he found that he cannot profit from the project. This is the situation @kzu faces. But it's not only kzu. There are hundreds of kzu in .NET community facing the same issue. While maintaining a open source project, they cannot even get a cup of coffee sponsorship from the users. It's not about getting rich. It's just about thanksgiving.

Just like tip culture in US. In most cases, tip is a must for every deals (usually 10-15% of the deal amount). But can you say tip is just for money? I think it's also about thanksgiving.

[Gavin-Williams]

unpaid internship/volunteer work was made illegal in my country in 2009.

[tonyqus]

@kzu Hey, man. I think all your replies are a bit hard (instead of soft). I understand maybe it's part of your characteristics and hard to change. The community/the public usually like someone can be humble and even a bit cowardly. If you keep saying statements like 'I don't care...' or 'I don't promise anything...', the community will keep suspecting your goal. And the respect you wanna gain is usually from humbleness of the author or critical speaker of one project/one company.

I think sometimes too transparent is not good for crisis PR. I have no idea if you two have discussed personally. But I do suggest you should do that for some sensentive topics instead of discussing everything in Github issue. You have a company and I believe you understand what I mean.

And Moq is lucky because this project have @stakx as the co-contributor. And he is trying his best to save this project. In most OSS projects, there is only one major contributor. If it have happened to Moq, this project has been dead. Because no matter what you say, the community has decided you are guility or criminal (they think they are the Judges although I know they are not).

And I did check the law. GDPR is NOT criminal offense. It's just civil offense. But in the whole event, they judge you as a criminal which is very ridiculious. (for example, they say you are putting a gun on their head)

I can frankly tell you that I start to know this accident because one of colleague suggest locking the version of Moq in a PR and I feel a bit weird. It's my first time to see a company is locking a nuget package version. And I start investigating what happened as I'm also a OSS developer. Some colleagues suggest we should find a alternative as Moq is becoming a malware. For the sake of change cost, I suggest we hold on and see what happens. A few teams in my company are still waiting to see what Moq team will finally decide.

So far, what @stakx suggest are all in the right direction. No matter who is the owner of this project, he is doing something good for the project.

[tonyqus]

Probably not quite excited enough to quit my regular job for it 😃 (even if I got sponsorship)

You are smart.

I did quit my job and start a company for my open source project a few years ago. I can 100% sure that this is a big mistake I made in my life. The original plan is that I can get consulting fee and maintainance fee from the potential company users of my open source project. But the fact is that no company is willing to pay. (I'm the guy who really experiences the joke that Fortune 500 companies give you a star and say goodbye)

And I didn't change the license of my project to commercial license, which is another mistake I made. The company eventually becomes a outsourcing company and several years later I go back to work for big companies.

I'm not sure what kzu's company is doing and how the business is. But open source is NOT a good topic of entrepreneurship. There are very few successful cases. Even Docker mother company is not so successful. Usually open source is for big company and for strategic purpose. It's kind of marketing function instead of earning function.

[cmjdiff]

check the law. GDPR is NOT criminal offense.

Case of a criminal prosecution under GDPR that resulted in prison: link

[stakx]

@cmjdiff, you may want to re-read that article. It does not even mention the GDPR. It's refers to the UK's Computer Misuse Act (which, unless I am mistaken, predates the GDPR by nearly 3 decades):

Although this was a data protection issue, in this case we were able to prosecute beyond data protection laws resulting in a tougher penalty [...]

Unusually, the ICO chose to charge him under the Computer Misuse Act, which is the law normally used to prosecute accused hackers.

The penalties available to the ICO in the Data Protection Act 2018 do not include prison sentences. Using the Computer Misuse Act to prosecute a data theft is another example of the way in which UK's data cops are getting creative with the law.

[Baklap4]

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

[jaredthirsk]

@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?

[wrexbe]

@y2k4life for someone as commited to the project, you seem to be blissfully unaware that:

1. The build pauses will be gone
2. The obfuscation has been gone for DAYS since it's all OSS now (what's the point?)
3. The sending of email hashes during a build will be gone
4. 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.

[Arcalise08]

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

[y2k4life]

1. The devlooped/SponsorLink#33
2. The obfuscation has been gone for DAYS since it's all OSS now (what's the point?)
3. The sending of email hashes during a build devlooped/SponsorLink#31
4. By "downloading of another app" do you mean downloading the devlooped/SponsorLink#31 (comment) that I'm thinking for v2 of SponsorLink? Or are you confused about what a GitHub App actually is?

@kzu congrates on the progress

4. What is this? https://github.com/apps/sponsorlink

for someone as commited to the project, you seem to be blissfully unaware that:

Don't need the rhetoric though not helping the cause just let me know these have been updated thanks.
Lot of crap flying around to keep track of all it, your actions have caused a *** storm.

[kzu]

@y2k4life https://docs.github.com/en/apps. It's nothing you download.

[y2k4life]

@kzu thanks as @wrexbe pointed out a documentation bug which was nice until there was more childish rhetoric, someone pulled out of the air something about drama. Need a jump to conclusions mat.

[psimsa]

Good for you. I'm off to bed, it's past midnight.

[psimsa]

same here

[psimsa]

@kzu
So I did some digging into the SL source this morning. It looks pretty harmless from my point of view tbh. Is there a version of Moq (or some whatever testing package) I could use to see it "in action" on my desktop? (basically reference such nuget from a dummy project and see what happens in different scenarios)
In (some) corp environments, it will definitely need a kill switch though. Environment variable perhaps, something like DISABLE_SPONSORLINK=true disables the check? (it could still display some message like "we are sorry you don't want to use sponsorlink, you probably have reasons and we respect that" but basically disable the network check on-demand )

[stakx]

@psimsa:

Is there a version of Moq (or some whatever testing package) I could use to see it "in action" on my desktop?

The SponsorLink repository's README file contains instructions on how to set it up in a project. You shouldn't need Moq specifically to test-drive SponsorLink. That being said, you could use Moq version 4.20.0, but I suspect that due to devlooped/SponsorLink#49, the version of SponsorLink included there might now no longer be functional.

[psimsa]

@stakx
I don't see in the readme an option to quickly test-drive it from consumer point of view, but I only have sporadic amount of time right now. Something like "if you want to see how it works, add "DummySponsorLinkLibrary" to your project". Something like that would help a lot. Moq 4.20 (nice touch on the version btw :-D ) was pulled from nuget.org as far as I can tell.

[stakx]

@psimsa, fair enough, I may have been mistaken about where to find such instructions. However, while Moq 4.20.0 is unlisted on NuGet, you should still be able to install it.

[kzu]

Data is gone and blobs are gone too, so no version of SponsorLink is actually functional anymore.

[psimsa]

Why is there not a facepalm reaction...?

[kzu]

@tonyqus I'm sorry if I'm coming across as a bit harsh. I tried to be very understanding of everyone's points of view. I've felt very little sympathy or understanding of my point of view from most folks, except for a few that were willing to stick their necks above all the angry replies. You have been one, so thanks for that.

Your experience trying to live off of OSS is sobering. I'm sorry it didn't work, and rest assured, you're not the only one telling me this is all pointless. It may very well be so.

[NiklasArbin]

As already mentioned, SponsorLink is the wrong way to approach licensing for CI tooling.

That Moq is part of the CI build process is what limits your options, since what would work for any other OSS running in runtime with the application could be handled in other ways gracefully. Paying for OSS is a solved problem.

The only viable option is an in faith licensing model, where Moq is free for some use cases and requires a license for others.
A significant number of organizations would strive to be in compliance and pay to have a license. Some would not, but the alternative of having a mocking library making network requests from both developer and build machines is not viable.

I've been watching this issue and waiting to see where it would land, but if you're firm about SponsorLink for Moq, we'll just bite the bullet and replace it. We'd been happy to pay a license to avoid the hassle.

[kzu]

CI tooling

SponsorLink never affects CI. It's intended as an in-editor only thing. It always was. It never activates any behavior unless you're actively coding in an editor.

[kzu]

We just sent out

If you're sending that out NOW, when SponsorLink in its current flawed implementation is already gone from Moq's latest package (and won't come back as-is at all), then you are likely out of date (it was gone within 24 hours). SL is even open source now and several steps were taken to ease folk's concerns.

That said, you can always "invest" in replacing it when there's no need for it. I just believe that the next library will eventually be in the same situation as Moq unless OSS sustainability situation changes, so I'm not so convinced that's a good "investment" either.