SponsorLink and supporting OSS more broadly

[kzu]

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

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

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

SponsorLink is now OSS too

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

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

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

[kzu]

Thoughtful blog post here: https://codingbolt.net/2023/08/08/a-deep-dive-into-sponsorlink-implications-for-open-source-and-privacy/

[rouke-broersma]

@kzu there's two main issues:

1. You're collecting email addresses. Even though you say you only send hashes, you send these hashes to your infrastructure. We don't know what you do with these. You could store these hashes (we can't verify because it's your infrastructure) and at some point compare these hashes to hashes you or someone else with access to email address hashes collected from somewhere else. As a non-evil example, you could use this list to give a priority to issues created in this repo based on if the hashed public email of the github user matches a user on your sponsor list, or on your non-sponsor list (since you could save whether a given hash is a sponsor or not, again we cannot verify). You can then also start building out your user info list with the other information you can gather from the github user. This is not a justified use of the email address we configure on our local machine, so for example any employer in Europe would be forced to move away from Moq, so they are not in violation of GDPR.
2. SponsorLink is obfuscated and closed source. It connects remotely to your infrastructure. You or some external entity could modify SponsorLink and/or your private infrastructure with malicious intent and we would not have an easy way of verifying the changes made. It's basically supply-chain malware in the making. It doesn't matter that it only runs on developer machines (at the moment) either because there are tons of developers who still publish from visual studio (yes, the horror).

[maartenvana]

Maybe, just maybe, you should approve #1373 first, to save whatever goodwill there is left. Then try to get a discussion going about how to get sponsers/paid.

That whole PR to add this closed source nonsense to this otherwise great package has only hurt this project and will continue to do so the longer this version is live.

[bartdebever]

I'm pretty sure a discussion about this is pointless, people are already mass removing your software and I'd personally not trust someone that added this to an objectively popular package. Figuring out you made it yourself is even worse.

This seems like a way for you to get more support and money but with this move I'm pretty sure you are going to get the reverse of that. Even IF you revert the PR, I doubt anyone will still trust you or the package and the mass amount of PRs removing Moq within a day confirms that point.

[DanielCordell]

No nefarious purpose, I promise!

I do actually believe you, and I'm glad that you're opening up a place to collect feedback rather than just closing any issues discussing the point. I think people should want to help projects like this continue to support themselves sustainably, just in a way that is agreeable to as many people as possible, and doesn't have any potential security/vulnerability ramifications.

A lot of people are going to be very negative, maybe rightly so, but I think that if we're going to have this discussion it should be from a place of "known safety" for everyone involved (and to reduce the general panic from everyone!) so would seriously consider merging #1373 or some equivalent ASAP, just so everyone can calm down a bit and have this discussion without having to be worried about their own projects.

I do think it is a conversation that needs to happen though, what is the best way that a FOSS developer can continue to make great stuff for the betterment of the entire dev community.

Of course to some people the project may just be "tainted" for good, not necessarily much you can do there, but reverting the change for now will definitely help with anyone who's currently "on the fence".

Edit: https://github.com/devlooped/SponsorLink/issues/16#issuecomment-1670908090

edit: @kzu as other have said, you are now exposed to litigation. I would urge you to remove the 4.20.x versions just to limit the legal risk. It would only take one vindicative organisation to make things worse for you.

This is definitely something else to consider, you (probably) don't want to be at the receiving end of something like this.

[jakoss]

A lot of people are going to be very negative, maybe rightly so, but I think that if we're going to have this discussion it should be from a place of "known safety" for everyone involved (and to reduce the general panic from everyone!) so would seriously consider merging #1373 or some equivalent ASAP, just so everyone can calm down a bit and have this discussion without having to be worried about their own projects.

Exactly, opening discussion after merging the changes without bigger announcement is the biggest issue here i think

[baynezy]

Sponsorship is problematic for many companies as it does not fit into their financial model. Guerilla tactics to run code that harvests information from developers' machines and stores it in a closed system is not the way to solve this problem.

I have no issue with OSS maintainers making money, but you have to understand that if you don't engage your community on how you go about this and just try and sneak (and there is no way you can deny that is what has happened here) a data mining system into your product there is going to be a backlash.

This has just harmed your reputation and now means that many people will have to look for alternatives. Whereas maybe you could have looked at a licensing model or some other vehicle that companies can actually get past their finance department more easily.

[PoteRii]

https://github.com/moq/moq/pull/1373#issuecomment-1670914563 Are you trying to blackmail the community or what? LMFAO

Sorry no time for discussion, got to go remove Moq.

[DanielCordell]

I'm pretty sure a discussion about this is pointless, people are already mass removing your software and I'd personally not trust someone that added this to an objectively popular package. Figuring out you made it yourself is even worse.

@bartdebever Feel this is a bit defeatist no? Maybe I'm being too optimistic here, but a lot of this could easily be attributed to a genuine unintentional mistake on the part of @kzu. I'm sure there are plenty of people who would be perfectly happy if this change was removed, but arguing that the discussion is "pointless" just means that the sort of problems that incite people to do stuff like this never get looked at.

[BenjaminAbt]

You asked for feedback: @kzu, it's too late. You screwed up really hard. Sorry to say that but you have damaged the .NET community very badly after doing very very very great work for many many years.

With https://github.com/moq/moq/pull/1373#issuecomment-1670914563 you started to blackmail the community.

From a financial point of view, by taking this step you have decided that a great many hundreds of thousands of dollars/euros/X will have to be invested in order for projects to remain privacy compliant. The only way to save this now is to accept the PR (https://github.com/moq/moq/pull/1373) now, take the affected versions offline and provide a new version.

However, the damage is beyond repair for us/me. We already revert to 4.18 and then switch to another library. Thanks for Moq. It was great with Moq.

[LarsWesselius]

@kzu Really appreciate all the hard work that went into Moq. No one is denying it's hard work, and often underappreciated. It's fair to ask for something in return.

But I cannot stress enough that you can not do this by introducing a closed source, obfuscated dependency without discussion, and then pushing it as a new version. I'm sure your intentions are good but we can't see the code and we can't afford to assume it's ok. You have a massive user base in massive companies. I reported this to the large company I work at and they shit themselves. Does this not make you see that the way you've gone about this is totally insane?

The problem is now that even if the change is reverted, the trust in its maintainer(s) is gone.

[cdrnet]

SponsorLink would be a reason for me to stop sponsoring this project (if I were a sponsor).

[DibranMulder]

With this change you have just crossed an unreversible line. Trust has been violated and this privacy breach will force users to remove Moq from their code. Not only have you failed in creating a sustainable source of income for yourselves but you just threw away your lives work and lots of work from your users.

I understand that the current OSS work is unsustainable for you. And at times it may feel like everyone is benefitting from you and you don't get anything in return for it. This is true, but remember you have benefited from your work by building a name for yourselves which might open up new opportunities.

If that's not enough you should have considered to go commercial like the guys from IdentityServer did or another direction might be to drop support and go on with a new project and let the community figure it out. Sadly you chose to harden your stance which is going to backfire on you.

Thanks for all to good work on Moq is was great.

[VmPeter]

In your recent blog post, I noticed a delay in the build process for non-backers, indicated by "build paused for 1681ms." Is this intentional, and could you explain the rationale behind it?

Additionally, there are concerns about the security implications of transmitting emails to a remote server, especially given potential vulnerabilities associated with SHA. How do you address these concerns?

From a business angle, if a team of six developers uses their corporate emails in git, are they expected to personally fund software and NuGet packages? Should new team members also bear these costs, especially for tools like Moq? Given that the main beneficiary is the employer, wouldn't it make sense for the company to cover these expenses? How should we approach new members about these potential costs?

Moq is frequently referenced on several Microsoft developer pages as a recommended mocking framework. Do you believe Microsoft will maintain its endorsement of Moq in the future?

Is your motivation genuinely rooted in a desire to improve the FOSS landscape, or might there be underlying sentiments or experiences influencing your decisions?

[ArcadeArchie]

maybe a bit extreme but i recommend for anyone if this isn't reverted notifying your country's GDPR Supervisory Authorities as a last resort

[jakoss]

maybe a bit extreme but i recommend for anyone if this isn't reverted notifying your country's GDPR Supervisory Authorities as a last resort

Too extreme, definitely. This could destroy a person, and i'm certain we do not want to do that..

[kzu]

@rouke-broersma great points! So, if SL itself is OSS too, it might remove those concerns? How would one check sponsorship without resorting to email-based lookup? I wish GH/MS offered this OOB...

Thanks @DanielCordell for the vote of confidence. I just hope more people see this as an opportunity to discuss the very important issue of OSS sustainability.

@LarsWesselius "You have a massive user base in massive companies.". You know how many of that massive user base has sponsored my work? And those massive companies? Never heard of them. Only @aws contributed, once.

[4sneilhighley]

If you want to use sponsorlink to help you write Moq vNext, you should have had it only on that branch, not on the main

[PlayerModu]

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

[kzu]

It's fine for folks to stop advocating for Moq. I think it would be far better to advocate for devs to realize there are actual people behind OSS projects. If you appreciate using OSS, you should be advocating for sponsoring as many projects as you personally enjoy using.

There is a chicken-egg problem with just adding SponsorLink to vNext: it requires a massive amount of work and there's no certainty the SL mechanism will even work at all (as noticed by many raising the GDPR concern).

[mikocot]

even if the whole thing is rollbacked and a satisfying sponsorship system introduced, we would need at least some additional reviewers in the project that would ensure such situation is not going to happen again out of nowhere

[BenjaminAbt]

You know how many of that massive user base has sponsored my work? And those massive companies? Never heard of them. Only https://github.com/aws contributed, once.

With SponsorLink, you have put many people into risk. Your current behavior is making sure that a lot of developers and companies now have to burn money to fix that. Money that you could have profited from yourself with an intelligent move.

Do you really think this step will help you change the problem of sustainable OSS? Short: no.

[xDamon]

I invite everyone to read the SponsorLink announcement to understand the intention behind it. No nefarious purpose, I promise! 🙏

Do you have an explanation on why CPU and GPU utilisation spikes on your blog site? @kzu

[shoter]

@rouke-broersma great points! So, if SL itself is OSS too, it might remove those concerns? How would one check sponsorship without resorting to email-based lookup? I wish GH/MS offered this OOB...

You can create private nuget feed which allows sponsored user to download special version of library without any kind of messages.

And for free version you could always display an info message about sponsorship request. There would be no email checking involved - you would always display a message in free version.

Think outside the box you are currently in.

[karl-sjogren]

In your recent blog post, I noticed a delay in the build process for non-backers, indicated by "build paused for 1681ms." Is this intentional, and could you explain the rationale behind it?

Wow, I read this and thought "Maybe he justs logs how long the API calls took" but after looking through the obfuscated code there actually is a Thread.Sleep() in there at the end..

[kzu]

@BenjaminAbt I'm sorry if I don't believe that said massive amount of developers and companies could have spent that money benefiting me. It hasn't happened in a decade+.

[BerendWouters]

I've learned something from this: I should take a closer look at the (FOSS) packages I am using. I'm a software developer, and I rely on a lot of software written by other people. Sometimes they are being paid for it, but often they're not. I shouldn't blindly implement such packages. If I would've read the announcement regarding this implementation - which was half a year ago - I would've had the time to take a look at this implementation and decide what to do with it. Now I have to act on it too quickly, which puts me in a position I don't like: cornered. I have to adhere to GDPR rules, so I'll need to make some changes (or not upgrade to this version, but security issues and so on). If I'd just taken a look at this 6 months earlier, I wouldn't be in this situation. And maybe this discussion would have taken place in a better setting.

The scariest thing I learned about this all is the fact that I use tooling that can run arbitrary code (code analyzers) on system. I should be more aware of these security risks.

Regarding the entire FOSS discussion: FOSS devs don't get enough credit. Help them.

[kzu]

@karl-sjogren after a grace period, yeah, there's a small random build pause.

If the IDE/Editor provided a mechanism to remind users to sponsor projects they use, this wouldn't be needed at all.

Do you think sponsoring OSS projects should be encouraged or not? Should major OSS tooling vendors (i.e. MS) do more to help?

I spent quite a few nights thinking how to implement something with the tools at hand for a library author... it's tough.

[DanielCordell]

I'm sorry if I don't believe that said massive amount of developers and companies could have spent that money benefiting me. It hasn't happened in a decade+.

@kzu I think the problem there is that nobody is having these discussions, it's just like an "uncomfortable truth" people have learned to ignore and live with. These discussions should happen! But that uncomfortable truth does need to be addressed for FOSS devs to be treated fairly for the work they do for the community.

I know there definitely are packages out there that do get fairly significant support financially through donations and other funding sources. This may sound silly, but maybe you could speak to some other major project contributors to see how they managed to reach the point where they're getting that funding? There may be some general advice that they could give, and who knows, it may be useful for everyone to know in case there are any budding FOSS devs following along here.

[kzu]

@BerendWouters thanks for the thoughtful comment. Yeah, people freak out as if this isn't something you have been able to do for years using just plain MSBuild. Fear not though, the latest 4.20.2 removes SL since it breaks on macos/linux, so that's a no-go. So you're not "cornered". Perhaps now that the discussion is ongoing, the powers that be will give OSS sustainability another look...

[tbolon]

Do you think sponsoring OSS projects should be encouraged or not? Should major OSS tooling vendors (i.e. MS) do more to help?

Yes, but the current situation in GitHub where you have to apply for a beta feature to sponsor as an organization is still the main reason (I speak for my org) I still don't have sponsored such projects.

Based on what happened today I have applied for sponsorship as my org. My main problem is that you have to pledge at least 5000$ per year... But for me it's the main problem about sponsorship and orgs.

As of now, sponsorship seems to be targeted between people, and that's not the way it should be to really collect funds.

[kzu]

@DanielCordell yeah, fair points. When GitHub came out with Sponsors, I thought it was just the first step in making it more broadly visible, easily enforceable/suggested, etc. But it just stayed there. Nothing more than another Patreon. A wasted opportunity. Which kinda forced me to think something to go beyond a button on the repo that very very few will ever even visit.

[LarsWesselius]

@kzu you're just not reading what most people are saying. The way you've done this is terrible. Wanting to be paid, is not. It's your choice to do what you will with Moq, it is anyone else's to stop using it or simply not support you. Whether companies/users should or should not support OSS developers (I think they reasonably should), the way in which you've done this can only be seen as malicious.

[BerendWouters]

@BerendWouters thanks for the thoughtful comment. Yeah, people freak out as if this isn't something you have been able to do for years using just plain MSBuild. Fear not though, the latest 4.20.2 removes SL since it breaks on macos/linux, so that's a no-go. So you're not "cornered". Perhaps now that the discussion is ongoing, the powers that be will give OSS sustainability another look...

Thanks :)

The cool thing is - and we tend to forget that - we are the powers that be. It's my role as a developer to clarify and explain the use of FOSS packages inside my company, and explain how these work. If I can't do that, I shouldn't use these packages. That's my responsibility.

[BenjaminAbt]

I spent quite a few nights thinking how to implement something with the tools at hand for a library author... it's tough.

@kzu, the time and energy would have been better spent talking to the community. So the result is that your reputation, the reputation of Moq are destroyed, the reputation of the .NET community got another scratch - and likely nobody trusts you anymore.

Do you think this helps you or other OSS to build a sustainable funding? I think that both in your case and unfortunately for others you have achieved exactly the opposite. Too bad you just don't read people's feedback and keep blocking instead of acknowledging your immense mistake.

[kzu]

@tbolon why do you think people should not be the ones sponsoring? That's one key thing I disagree with, which is why I implemented SL the way I did. If you think of OSS as music, you are the one enjoying it. Sponsoring orgs would be like paying for music to just the record labels and hoping it trickles down to musicians. Isn't it better to just go direct?

[btastic]

Moq is just a tool in my toolbox for work I have to do for my company. A better analogy would be that a car mechanic will expect the company to pay for his hammer. Not the actual car mechanic.

[kzu]

@BenjaminAbt what am I blocking? My reputation is my code. I keep pushing OSS code every day.

It's great to see you have a ton of public repos yourself, that's awesome!

[Vhab]

You are in violation of GDPR and exfiltrating Personal Identifiable Information from our developers.

I'm not sure how you did not expect this to have backlash.

This is not a smart, nor legal way to engage with your users.

[DavidVollmers]

@kzu I can understand your way of thinking. But I also can just hope for you trying other ways to get sponsored. I love Moq and would love to still use it in the future and yes I never thought about sponsoring you... But I will definetly not sponsor OSS which has closed source dependencies.

[kzu]

@btastic that's one way to see it, sure. I think most devs are so used to companies paying even for their coffee mugs, that they have lost sight that behind the OSS libraries there are fellow devs just like you. It's not a cofee mug, in most cases it's a work of love that takes nights and weekends.

[tbolon]

The money is on my company account. If I pay by myself, it's my personal money that I spend.

If I pay on behalf of my company I must respect some basic accounting rules (receiving an invoice). Donations are a nightmare to manage in terms of legislations and local rules for companies.

So yes, having a company (GitHub) acting as an intermediary is a fine solution, even if they take a part of the money. I still will be way lower that what I must pay for my own salary.

The personal sponsorship is more a personal position, has a lot more sense but IMO will still not be enough to create something sustainable.

[DanielCordell]

@kzu

If the IDE/Editor provided a mechanism to remind users to sponsor projects they use, this wouldn't be needed at all.

You can write anything to the console right now as a reminder, I know NPM packages have done something similar.

I think having a generic "mechanism" is a big ask. Packages can come from different sources (nuget, private sources, local machine), would a "package" need a mechanism to say where it comes from, how you can sponsor it? Would it not be simpler just to add a console message as-and-when.

I definitely think it could be useful getting some MSFT advocates involved in the discussions. You could try reaching out on twitter.

why do you think people should not be the ones sponsoring?

If I'm working in my company environment, it shouldn't be on me to have to personally sponsor any project that the company is using. If I'm working on a personal project though, that's potentially very different circumstances. But exists right now doesn't discriminate between those use cases.

[jakoss]

Not all developers chooses the libraries they use. There is a lot of legacy code where you just get what somebody else used sometime. Similarly way in new projects - some leader might decide to use some library and now i have to suffer 1 second delay every time i build it?

[DanielCordell]

I think a few people in here are being dramatic about reputation and standing in the community. While the feelings are definitely justified it's basically slowly drifting towards nothing better than just name-calling. It's not helping the discussion here move towards any sort of useful conclusion.

[wdolek]

@kzu By closing #1373 you are making it worse. SponsorLink was mistake, this is not the way to go (see comments here). I support any attempt to make companies support OSS, but this wasn't right choice.

[sgtwilko]

@kzu Just to say I've used Moq, and quite liked it, as much as you can like a Mocking library! However you've stirred up the hornets nest, people are unhappy/angry about this. You're probably reacting to the emotions rather than taking a step back and thinking about this rationally.

You asked:

How would one check sponsorship without resorting to email-based lookup?

Just generate a GUID when someone signs up to the app, and have that stored in a .sponsorLink file on their computer.

Thanks @DanielCordell for the vote of confidence. I just hope more people see this as an opportunity to discuss the very important issue of OSS sustainability.

Sustainability has been the problem with open source since it was started, this isn't a new issue, and something you should have been aware of before starting an Open source project.

@LarsWesselius "You have a massive user base in massive companies.". You know how many of that massive user base has sponsored my work? And those massive companies? Never heard of them. Only @aws contributed, once.

Microsoft promote Moq on their website, so may be willing to help, what did was their response when you contacted them?

And just a word of warning, separate from the GDPR discussions: 20/30 years back before we had anti-hacking laws, people who broke into computers were prosecuted for stealing electricity. If you deliberately delay a build people may start remembering those times again...

[mason-bially]

I'm an outsider to this, but let me toss my hat in against the apparent prevailing opinions. Because I think they are wrong.

@DanielCordell

edit: @kzu as other have said, you are now exposed to litigation. I would urge you to remove the 4.20.x versions just to limit the legal risk. It would only take one vindicative organisation to make things worse for you.

This is definitely something else to consider, you (probably) don't want to be at the receiving end of something like this.

@Vhab

You are in violation of GDPR and exfiltrating Personal Identifiable Information from our developers.

@sgtwilko

And just a word of warning, separate from the GDPR discussions: 20/30 years back before we had anti-hacking laws, people who broke into computers were prosecuted for stealing electricity. If you deliberately delay a build people may start remembering those times again...

Let's start here. People apparently did not read this project's license before using it. Here allow me to quote the relevant section, (ALL CAPS in original for EMPHASIS, I have further BOLDED IT):

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

So before you attempt to cast aspersions, maybe consider the liability your company has exposed itself to by using the work of unpaid volunteers with no consideration for how they are compensated for their time and labor. Any GDPR violations are your own.

And as a note of history, these licenses are decades old, and survived those times when computers had a lot more prosecutions involved in them.

@maartenvana and so many others

Maybe, just maybe, you should approve #1373 first, to save whatever goodwill there is left. Then try to get a discussion going about how to get sponsers/paid.

That discussion will never happen. It's only happening now because the developer was pushed to force the issue. The moment the change is reverted everyone will go back to their comfortable reality of exploiting the commons on behalf of their employers.

Maybe, just maybe, you should have considered paying for the work you use everyday years ago.

---

That said I do certainly disagree with using an obfuscated binary. And I also disagree with the use of permissive licenses. Because a solution no one here has apparently considered: just fork it and remove SponserLink, continue to port over the work of the developer and just remove that one feature. It's possible it would even be less money to maintain than changing over to some other library (or you know, you could pay the developer for their work).

This is the flaw with permissive open source licenses in my opinion, a lot of the entitled people filter themselves out when one uses copyleft licenses that protect commons. If someone actually does do the running fork, I hope the developer GPLs their future work.

[abrugsch]

@kzu if your goal is to actually earn sustainable income then corporate sponsorship IS what you want. not a buck here and a buck there. I am friends with the maintainers of a (financially) successful open source project and that's exactly how they are able to float and do it full time. do it by restricting what support activity you do (issue priority/feature requests/early previews of upcoming releases) for non-supporters and prioritizing supporters. if you're wondering what project I'm talking about, it's here: https://www.graphile.org/sponsor/ and I will tell you, thanks to their keystone corporate sponsors who need things like early access and priority support, they are financially independent without resorting to shady malware-like practices.

[valters-tomsons]

Obvious privacy issues aside, what even is the justification for including SponsorLink in the first place? Because right now, it looks like you're just trying to introduce nagware in to people's IDEs.