Build pauses should be gone

[kzu]

I'm not entirely convinced of this one. For anyone sponsoring, this is a non-issue.

If you are a library author, wouldn't you want this as a reminder to users that they still haven't sponsored? Perhaps the Info diagnostic is enough, perhaps not. In any case, given that users will be able to fairly easily disable the SponsorLink check, perhaps this is indeed pointless.

Updated title since the overwhelming feedback is that this is bad.

[ColinM9991]

If you are a library author, wouldn't you want this as a reminder to users that they still haven't sponsored

A reminder is fine although maybe finding another way of doing this rather than polluting warnings/info/errors. On the other hand, pausing the build is not good since this intentionally interrupts the workflow of a user. Visual Studio is already an awful and slow product, it doesn't need to be any slower.

Better still, given donations are optional, I personally wouldn't want a constant reminder that I should donate. That's not going to incentivize me to donate - if anything it'll convince me not to donate.

[lt-kraken]

I think you're missing the fact that build times might already be absurdly huge. If I were to have 50 packages that make use of SponsorLink, and every single SponsorLink check makes my build wait a second or longer, thats an absurd amount I have to wait before I get a single result from my actual build itself.

I get the point of SponsorLink, but I think you're trying to get attention for the library author in a wrong way.

There is this VS Extension called VSColorOutput (or something of the likes), and all it does to ask for money, is print in the console: This is an open source project, please consider funding me at xxx. If you want, you can turn this message off by doing yyy.

Instead of reading personal identifiable data and sending it towards a third party, it might be worth to see if you can follow a similar approach. Less intrusive and likely way better received.

[gnalvesteffer]

It's intrusive. Interrupting developers to convince them to donate is just like any other form of advertisement. If you're making it inconvenient for people to do what they're trying to do, all it's going to do is make them despise you.

Put a sponsorship/donation link in the readme like other FOSS; unintrusive and simple.

If anything, this'll just make people not want to donate, or donate to a fork that removes this intrusive sponsorship functionality out of spite.

[GurliGebis]

Maybe just open a txt file like other nuget packages does, instead of all this?

[ckuetbach]

How can someone really think this is a good idea?

Lets assume I have lots of libraries (even transient dependencies) and every single one calls out (what needs time) and creates a warning-message (or info) and abuses the part of my IDE, where I review errors and warnings in MY code.

And I would have to wait for seconds every build and scroll through a list of messages, which are NOT about warnings / infos about my sourcecode.

This will lead to frustrated developer and I would definitly turn away from those blackmailing libraries.

[mvastarelli]

Is this pause happening once per build, or once per project that takes a dependency on something using this? I've worked on many repos for employers with +50 projects in a solution and a few with over 100.

Overall, I'm struggling to see how forcing a pause in the build process, or worse, introducing a 500ms Console.Beep() call is going to have the desired effect you're looking for. I wholeheartedly agree that there should be a better mechanism to empower open source developers to earn compensation for their work, but pretty much every developer using a library tied to this is going to fall into one of two camps:

1. Individuals working on their own projects who are likely to immediately uninstall the package in favor of another one without the nagging just on principle.
2. Developers working for a company who had no say in which 3rd party libraries the company chose to use being asked to fork over their own money just to stop being pestered. Case in point, my company uses moq for a lot of their testing. I personally prefer FakeItEasy for my own projects (no offense).

Also, I and most developers I know don't even look at the build output 99% of the time unless something goes wrong.

[JohannSig]

Say that SponsorLink becomes popular and that lots of popular libraries start using it. Does the developer have to sponsor every such library within a (possibly large) project to maintain an optimal build time?

[kzu]

The pause is a prerogative of the library author. They can set their analyzer to zero min/max pause and no pause will ever happen. It's a choice they make. SponsorLink itself doesn't make it for them.

In addition, only ONE diagnostic is reported for any given account/project (say this was xunit and its various packages, they would all use xunit/xunit as account/project), only ONE diagnostic/(optional)pause would happen regardless of how many projects are being built. This is because the roslyn process that spawns the build is reused across all of them, and I'm caching the reported diagnostics across the entire app domain. See https://github.com/devlooped/SponsorLink/blob/main/src/Package/DiagnosticsManager.cs#L10-L18

@mvastarelli who's using Console.Beep()? (perhaps you misread the code... I used that while debugging and in debug mode. Users never get that).

1. If so, the library author should be able to decide how he wants to interact with his users. This includes not pausing at all. SponsorLink doesn't dictate that.
2. No offense taken. In that case, SponsorLink should support org-wide sponsorships that automatically include all members (or X devs for $Y?) of the org.

The build output not being seen is precisely the reason why I went with diagnostics. You do see them alongside warnings and errors.

@JohannSig it would depend on the various library authors. TBH, if lots of OSS developers end up adopting SL, the ideal thing that should happen, IMO, is a Spotify-like arrangement, where a single "all inclusive" sponsorship is given, and then depending on what you use, it's split accordingly among the projects that use SponsorLink.

[Sebbs128]

@kzu doing harm (eg. artificially making builds longer for no technically valid reason) unless payment is received is extortion. Build pauses should be removed. It's that simple.

A far better approach for Sponsorlink would be to enable features for sponsors. But even then, a sponsor-only (ie. private, authenticated) nuget feed for packages containing sponsor-only features would be even better (see #10 )

[gnalvesteffer]

This is such an awful idea and ruins the spirit of OSS.

[kzu]

@Sebbs128 I hear you. Perhaps back in the Shareware days, you would be also claiming that to be extortion. I don't think it is, but I'm willing to consider alternatives that can be equally effective for the OSS library author (not thinking about myself here).

Premium features for sponsors sounds great, the well-known Freemium model. It's a bit more complicated to implement, more overhead for the dev (splitting logic, private feeds and what-not). Not saying that's not a model that has worked very well in many projects.

In this particular case, significant sponsoring uptick would likely convince me to put the (significant) effort to tackle again the full rewrite I was planning. In the meantime, there isn't much I can offer in terms of tiered features...

@gnalvesteffer any thoughts on how you'd get paid for your OSS work? I think it should be a noble goal for anyone to have that as a potential career path: freelance, doing OSS, getting enough sponsorships to live working on their passion projects for as long as they are useful to the community.

[gnalvesteffer]

Surely you don’t make OSS for the money? I don’t make game mods for money for example. It’s all to give back to the overall community. It is a noble effort, to make something that you think should exist that you think shouldn’t be hindered by greed, and to share the source with the world to build and improve upon.

[Sebbs128]

Perhaps back in the Shareware days, you would be also claiming that to be extortion.

It's not the same thing. In the shareware days, the software was either feature complete and at launch encouraged you to support the devs, or additional features were locked behind a paywall (and paying would either give you a license key or an entire new binary containing the now unlocked features).

There is a stark difference between a free version with limited functionality, and actively making the existing functionality worse for the free users (especially in a library where an earlier version without the kneecapping is available).

Consider also that not only is this (keeping build pauses for non-sponsors) against the spirit of OSS, as well as morally and ethically wrong, but extortion is also illegal in many (most?) places. Keeping this is a very dangerous path for you.

[JackDevAU]

I personally don't think adding a time delay at a package level is creating an environment where developers are going to start paying. I think it'll just cause people to fork the project or go to an alternative one.

At the end of the day, everyone needs money to survive but I think adding a delay isn't the right way to go about it. I believe the work you have done with Moq deserves mad money but I think you need to look at alternative ways about getting it. Maybe Talks, Courses, Premium support or just remove the expectation that this is OSS and go private and require a paid key to use it.

I think the intentions around SponsorLink is great in theory but the way people see OSS doesn't align with what SL hopes to achieve.

I wish you all the best!

[Aragas]

I was previously your GitHub sponsor (via @BUTR). I've stopped after SponsorLink was announced. In my opinion, an Info message should be enough. It won't break WarningsAsError and it will be visible enough for users to notice. Any interference with the build process is in bad spirit.

Additional opinion as a sponsor

This is not related to the issue, but removing process spawning and replacing that with a built-in library would also remove a lot of backlash in my opinion. It will still keep the IO issues that some had, but this isn't something that is possible to fix

[wdolek]

Having (artificial) delay is not acceptable. You don't want this library act as "ransomware", do you?

[JohannSig]

@JohannSig it would depend on the various library authors. [..]

@kzu Thank you for your answer. Based on SponsorLink's current behaviour, can you please elaborate on how/why it depends on the library authors? For example (and please add more useful info if you can):

• Is adding the build delay an opt-in feature for the library creator?
• Are build delays additive within a single project, i.e. do they stack up for every library within a project that has/opts into having a build delay?
• Are build delays additive within a solution, i.e. would a VS solution containing multiple projects that reference the same library induce a build delay for each project being built?
• Is the build delay currently capped at some values, regardless of the number of libraries using SponsorLink in a project?

[ghost]

Devils advocate

• If you can make it organisation wide that would be good. If its sponsoring then turn it off.
• You probably want to slow down the pipelines not devs. Devs just trying to write code man, orgs will see slowness in pipeleines and question that

[FBryant87]

The fact intentionally slowing builds is even being proposed suggests resentment has trumped rational thought sadly.

If you're not happy with users benefitting from the library without sponsoring, which I can understand, then you need to treat users as customers.

You've got yourself into a position where you're now perceiving users as freeloading customers, which has made you evidently resentful. If you want customers, then you have to be prepared to do the accounting work to operate as a business.

You can't have it both ways unfortunately, no one does.

[gnalvesteffer]

Adding/keeping the build delay shouldn’t even be on the table. That’s such a scummy and abusive thing to do.

[mvastarelli]

@kzu having thought on this a bit, I think there may be some merits to what you're trying to do, but the approach taken here is dead wrong and punishes the people who would evangelize and help a project grow without providing incentive to companies to actually sponsor/compensate these projects. Setting aside security concerns for a minute, slowing down builds will annoy developers, but won't impact most companies' CI/CD pipelines, so why would they care? In my opinion, I would focus my energy on coming up with a compensation system that's easy for companies to buy into since they're usually perfectly ok with paying for something that provides value and they're also the ones with the deepest pockets. There's a reason why ReSharper licenses for organizations cost almost 3x more than individual licenses.

That said, I think you may have touched on an interesting idea by hooking into the source generators in .net. I've seen a lot of projects impose limitations on how their software could be used in the absence of some kind of license. It's usually hand-written and complex logic that provides no extrinsic business value and increases tech debt. For example, NServiceBus used to limit throughput to 1 message/sec if no license (or an expired one) was provided. Other examples may include limiting workload sizes or disabling parts of the API outright. When crafted properly these types of limits usually have little to no impact on developers, but huge impacts on a company's ability to use the library in a production environment.

It might be useful if there was a library that allowed developers to annotate their code with certain types of limitations, and then through code gen weave them into the compiled binaries automatically. This would give the library authors a clear way to define what those limits should be, how compensation should be handled, and provide a legal framework for enforcing said policy if a company breaches it. Going back to the NServiceBus example, you could potentially weave in a throttle limit when there's no license and lift it (either partially or fully) when there is one. This has no impact on developers and if a company tries to run it in production without a license they'll be in breach and subject to damages by the library author.

[WithLithum]

I personally thinks that adding a build pause and a warning (which means fail if warnings as errors are on) has meanings of "you are using a evaluation product, pay me on GitHub so you get the full product".

[kzu]

But if you had an easy way to disable the warning (albeit manual, not to make it tooooo easy), wouldn't that be enough? You would be explicitly acknowledging that instead of sponsoring, you are choosing to disable the reminder. So you wouldn't be able to argue you didn't know the developer could be sponsored, say.

[kzu]

@mvastarelli yeah, that's an interesting alternative too. The generator could emit code with the limits, and with no limits is built with a license. You'd have to configure the license on the build server though, rather than production deployment (or perhaps on addition to?)

[jeroenwalter]

@mvastarelli yeah, that's an interesting alternative too. The generator could emit code with the limits, and with no limits is built with a license. You'd have to configure the license on the build server though, rather than production deployment (or perhaps on addition to?)

This goes from bad to worse. Next thing you know, some limit on the amount of moq objects per second is imposed if no license is present. I will be advocating stepping away from moq next week at my workplace.

[LuciferSam86]

Yeah, like I said in another issue, I tend to sponsor all my favorite libraries on a rotation. So if I donate for a month and the next 3 months I will donate to other projects, I'll have 3 months of limitations. Doesn't sound that good, tbf.

[jozefizso]

@mvastarelli yeah, that's an interesting alternative too. The generator could emit code with the limits, and with no limits is built with a license. You'd have to configure the license on the build server though, rather than production deployment (or perhaps on addition to?)

You are mistaking open source code with a trialware and licenced software.

[jozefizso]

If you're not happy with users benefitting from the library without sponsoring, which I can understand, then you need to treat users as customers.

Yes, create a business and sell profesional software licenses.

The open source model obviously does not work for your goal of making money.

[jeroenwalter]

I have followed the discussions on Moq and SponsorLink the last couple of days, and these are my 2 cents.

The entire idea behind SponsorLink is ridiculous and its current implementation is malicious.

I understand the desire to want to profit from all your hard work (but don't forget all the contributors to those projects, how do you want to compensate them?). I believe that money is the primary motivation of SponsorLink, so please, behave like a normal business and offer commercial licenses and support/SLA. Opening up SponsorLink for use by other library developers IMO is just a poor excuse to justify the existence of SponsorLink. Stop doing FOSS, it's no longer for you.

In the case of Moq, this is a piece of software that is free, and because it is very easy to obtain via nuget, it has low visibility as an OSS project for most developers that just want to get on with their work. You don't go to the github page to download Moq, no, you read an article somewhere about unit testing, then open up the nuget package manager in Visual Studio, get the nuget package and forget about the rest. Just like all the other packages you get from nuget. Hence low visibility. That is what SponsorLink is trying to "fix", but is does this by spamming the build output with warnings and introducing build delays. That's a ridiculous and malicious way of asking for attention.

Now, all of a sudden, the Moq nuget package is updated, our builds fail, more than 20 developers are pissed and we needed to spend time and effort to find out why.

One might say, well you should have done your due diligence before upgrading. And yes, that's true, and if the release notes had warned about the negative effects of this update, then we wouldn't have upgraded. The release notes were however severely lacking in this regard.

SponsorLink forces end-users, in most case developers of some corporation, who have little to no say in which libraries are used, to install the SponsorLink app and become an individual sponsor of each and every library that uses SponsorLink. If they don't, their build process is hampered with build warnings, that break builds, because of the often used "treat warning as errors". That's unacceptable. What would be acceptable is a Visual Studio extension with a license, like Resharper and other software. For instance, activate the license once, never phone home after.

And it slows down their build process, because of random delays, for each and every library that uses SponsorLink. That's unacceptable. Especially with Moq, as unit tests are run very, very often while developing software.

Not to speak of network timeouts, when the SponsorLink server is slow or even unreachable.

How was the SponsorLink implementation ever considered a good idea? IMO, this is the very definition of malware.

My company has no problem paying for software licenses, but we will not accept any software that introduces nagware or otherwise negatively affects our development time and focus and build processes, not to mention the GDPR and other privacy issues we may have with this.

As stated above, I will advocate replacing Moq with some other library, most likely NSubstitute. Because of the concerns we have regarding the issues related to SponsorLink (e.g. privacy, GDPR, build process), we already have created a build step, that prevents any dependencies on SponsorLink packages.

If this comes over as entitled, then think again. When a library is offered as free, with a BSD license, then we and I think most users, expect it to be free, without hassles and restrictions. Otherwise it isn't free and it requires a business so we can purchase licenses from it. Yes, this may seem thankless, and it is, but there are ways to remedy that, for instance, create commercial licenses.

But we also are reasonable. If software requires a license, we pay for licenses.

Although in this case, seeing how things went the last few days with Moq and SponsorLink (and the continuing intention of @kzu of bundling SponsorLink with Moq), we most likely will ditch Moq. This will cost us several thousand dollars, which could have gone to a commercial Moq license....

[azygis]

I still can't believe this issue is tagged as question, or exists in the first place. Who in their right mind wants to basically extort money publicly?

It's a choice they make. SponsorLink itself doesn't make it for them.

Why even offer the way to do that in SL? It's on the verge of .onion, IMO.

- I'm not selling drugs on the Silk Road. It's other people who use my marketplace.

Obviously, an exhaggeration, but man, it's the same silly "defence". You've done that yourself with Moq since the pause defaults to 0-4s and there's no other configuration in Moq as far as I can see. Degrading any kind of overall solution performance (be it analyze, build, runtime, anything) is one of the dumbest ways to ask for money (more like extort, again). It's not the way to monetize the library. CoreJS drama was just a drop in the ocean at this point.

Sure, I don't have any new suggestions how to profit from OSS that haven't been offered already and shot down by you. Cause is noble, but the approach... Terrible, 1/10.

[StingyJack]

If you are a library author, wouldn't you want this as a reminder to users that they still haven't sponsored?

I dont know anyone who would be OK with having their work impeded by ransomware. Are you really asking that question?

OSS is a labor of love. Its Things we contribute for the Greater Good. Its not always going to be of a higher quality or get to market faster than a commercial product, and that is OK.

Good on you for trying to come up with a creative way to make a living, but there has to be a way to do this that does not immediately alienate the userbase or make it so they cannot use the package anymore.

[kzu]

their work impeded by ransomware

How would checking for sponsorship be ransomware? It's almost the same as checking for a valid license in any commercial software. Why wouldn't THAT be ransomware in your definition?

Perhaps it's sponsorware, oss, but you have to sponsor? Again, I get it that users would prefer someone just does all the work for free and never "bothers" them with anything, oh, and fixes bugs quickly and keeps the project active.

Which is PRECISELY why this is a question for a library author, not the customers which might largely have that attitude.

[ghost]

their work impeded by ransomware

How would checking for sponsorship be ransomware? It's almost the same as checking for a valid license in any commercial software. Why wouldn't THAT be ransomware in your definition?

Perhaps it's sponsorware, oss, but you have to sponsor? Again, I get it that users would prefer someone just does all the work for free and never "bothers" them with anything, oh, and fixes bugs quickly and keeps the project active.

Which is PRECISELY why this is a question for a library author, not the customers which might largely have that attitude.

It certainly is NOT ransomware. It is DRM.. sadly not very good DRM.

I guess its classed as malicious because you exfiltrated information from ones machine without consent.

[jozefizso]

Perhaps it's sponsorware, oss, but you have to sponsor? Again, I get it that users would prefer someone just does all the work for free and never "bothers" them with anything, oh, and fixes bugs quickly and keeps the project active.

People did not assume this in the discussions around Moq and SponsorLink.

Doing commercial support, providing SLAs for money using a business entity was mentioned many times.

[psimsa]

Shouldn't the library author that incorporates SponsorLink be able to specify how "aggressive" they want SL to be in their particular case? I would suggest passing this decision over to the library author through some config, have them decide.

[psimsa]

@kzu In general, I consider it a valid approach, but I'd leave it for future iteration. Too many changes at once are not good in this case.

But in principle - Spotify provides you with free tier that has ads and lower bitrate (=worse quality). GForce Now has (or had, didn't check recently) a free tier that gave you limited game session time and longer waiting period (paying people would be always ahead of you when waiting for available compute). So yeah, I don't see a problem here, in general.

SL allows distinguishing people as

• unregistered customers (no github app)
• registered but free tier (not sponsoring)
• registered paid customers (sponsoring)

Each group can be differentiated in terms of available features. But don't roll out all the limitations at once.

[StingyJack]

How would checking for sponsorship be ransomware? It's almost the same as checking for a valid license in any commercial software. Why wouldn't THAT be ransomware in your definition?

@kzu - its ransomware because the software (Moq) has been widely distributed at no cost (to the tune of around half a Billion downloads) and now that it has spread that far and wide, it has been given the ability to deny those who use it access to their resources or results of it - albeit temporarily - unless they either sponsor/pay you or spend the money to rip out Moq from their codebases. Just because it creates a smaller interruption than a bad actor encrypting someone's data until the victim pays for the decryption key does not change the fact that it an interruption that has to be paid off to remove.

Perhaps it's sponsorware, oss, but you have to sponsor? Again, I get it that users would prefer someone just does all the work for free and never "bothers" them with anything, oh, and fixes bugs quickly and keeps the project active.

You can call it what you want, and yeah, people are too often the wrong kind of lazy, and they can be little red hens, but this is not news. I hope you dont feel like your work has gone unappreciated, that is certainly not the case with Moq until you included SponsorLink. Aren't there FOSS libraries that you use from the ecosystem? Have they helped you? What happens if they follow your example and start putting arbitrary delays in build times?

Which is PRECISELY why this is a question for a library author, not the customers which might largely have that attitude

That choice is mostly an illusion for the library author. Sure. they can do whatever they want in the library they create, but nobody has to use their creation. Its an easy decision to choose something with less hassle or baggage. Currently this is a choice between Moq and NSubstitute, (and others) but very soon there will be a fork of Moq without SponsorLink in it. , As a leading package author, you are setting some really bad precedents with this by creating tools that can damage or even destroy this community. You still have time to fix this, but you need to do so soon.

[kzu]

but nobody has to use their creation. Its an easy decision to choose something with less hassle or baggage

Agreed. So, if they don't have to use their creation (nobody is forcing anyone, not even to update), and it's an easy decision, I don't get precisely what you're complaining about?

there will be a fork of Moq without SponsorLink in it.

Current latest version of moq doesn't have it, so again I'm not sure what you're complaining about or why you would need a fork?

BTW, more power to you if you fork and maintain it yourself forever for free too.

[psimsa]

its ransomware because the software (Moq) has been widely distributed at no cost (to the tune of around half a Billion downloads) and now that it has spread that far and wide, it has been given the ability to deny those who use it access to their resources or results of it - albeit temporarily - unless they either sponsor/pay you or spend the money to rip out Moq from their codebases

I mentioned previously that it should have been a new major version with new EULA to make the distinction clear rather than a minor version bump. However, no existing version was tweaked in any way so not really - nobody is forcing you to update to a different version. I personally have locked all my work projects to 4.18 until the dust settles and path forward is clear (including our security department clearance) and I don't really feel ransomwared in any way.

What happens if they follow your example and start putting arbitrary delays in build times?

How would that be a bad thing? If you don't pay for the product you get worse service/product. I don't see a problem with that. You have a choice of giving few cents a month or have a slightly worse experience. That's fair as far as I'm concerned. Just like when you watch youtube without subscription you get interrupted by ads.

[azygis]

Oh my, this is apparently good for some people. Possibly destroying the whole build of the whole application (like, author is free to set min pause to 50 minutes for whatever reason) apparently is a valid way to extort the $1. Wow.

That's just plain bullshit, sorry. If you want to give a better product for money, give a better product with more features, don't just obliterate the whole solution just because you have one library with a sadistic person behind it.

[LuciferSam86]

Oh my, this is apparently good for some people. Possibly destroying the whole build of the whole application (like, author is free to set min pause to 50 minutes for whatever reason) apparently is a valid way to extort the $1. Wow.

That's just plain bullshit, sorry. If you want to give a better product for money, give a better product with more features, don't just obliterate the whole solution just because you have one library with a sadistic person behind it.

and I will repeat my thought, too. It will hit people who wants to help various authors being sponsors on a rotation. Like 1 month OK, but if for the next 4 months I will sponsor other authors because I like their projects, I will have a X minutes of artificial pause. That is just plain stupid.

[StingyJack]

don't get precisely what you're complaining about?

@kzu the last paragraph mostly.

[kzu]

Wow, you think this random dude from Argentina can destroy the OSS community?

[azygis]

Never underestimate anyone, including yourself. The first iteration of sponsorlink really shows to what lengths analyzers can be abused if someone is willing to go these lengths. One can only hope Roslyn guys have a way to prevent such malicious acts, since verbal (or written, actually) warnings that you shouldn't do this or that (think there were two instances of calling you out here) don't work with you.

As the saying goes - when there's a will, there's a way.

[kzu]

I suggest you get yourself familiar with what an MSBuild task can do also.

[azygis]

I'm familiar, thanks. That's besides the point, but you can pretend to not see the actual problem with it.

Updated title since the overwhelming feedback is that this is bad.

I know, shocker!

[StingyJack]

Wow, you think this random dude from Argentina can destroy the OSS community?

@kzu - One rather bright dude from Argentina that is a leading package author could create software that every other package author starts to include, creating a "Sponsor-Me Tsunami" of nag messages and other noise that could start to turn something pretty good and mostly hassle free (the NuGet Package Community) into the digital equivalent of a beggars alley, where every package install comes with an outstretched hand.

If your goal was to get a few bucks from your hard work, there are already examples of non-invasive ways to do it.

[kzu]

@StingyJack if you take the time to review the actual implementation, you'll realize that I actually thought quite a few of those "nightmare" scenarios to make them less disruptive:

1. The checks happen only once per IDE session. I usually keep my IDE open for days on end.
2. The checks group by publisher, so you'd only get ONE message even if you depend on 20 packages from it
3. The publisher gets to choose how to report things: they could make the diagnostic an Info instead of a warning, and they could request to never pause (I'll remove that as a possibility anyway).

As you see, the goal was not to make a few bucks for myself but to improve the situation for other (dotnet first?) OSS developers too.

[StingyJack]

I usually keep my IDE open for days on end.

Only days? =D

The checks group by publisher,

So 20 publishers = 20 messages and 20 potential pauses, right?

The publisher gets to choose how to report things: they could make the diagnostic an Info instead of a warning, and they could request to never pause (I'll remove that as a possibility anyway).

This is probably discussed under a different issue, but the publisher should not get to choose a warning over an info. It should only ever be at most an informational message. Why would you remove the ability to never pause? If I were to use sponsorlink I would not want to interrupt someone's work.

[kzu]

So 20 publishers = 20 messages and 20 potential pauses, right?

Oh, if there were even 2-5 publishers, I'm sure we'd be at v3+ already working on something better (perhaps an IDE extension to drop the diagnostics altogether?). Yeah, for sure there are far better ways that require larger investments. But right now, there's only ONE publisher, myself. Glad to hear you consider something like SL would be so popular so quickly that there would be no time to iterate and improve 😉 .

the publisher should not get to choose a warning over an info.

Well, wouldn't that cause whatever heat for "not sponsoring him" directed at him? They can already do this (issue a warning for whatever reason they want) today. But it's debatable to give such "power" to the package author, I guess.

Why would you remove the ability to never pause?

Perhaps I didn't express myself clearly. This removes the ability of SL to be configured to cause pauses. A Roslyn analyzer by anyone can still do whatever they want during the build, but if they pause, it wouldn't be SL's "fault" since SL (as of the PR merge) no longer contains any code that performs any pauses. Makes sense?