Build pauses should be gone #33
Comments
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. |
|
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. |
|
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. |
|
Maybe just open a txt file like other nuget packages does, instead of all this? |
|
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. |
|
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
Also, I and most developers I know don't even look at the build output 99% of the time unless something goes wrong. |
|
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? |
|
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).
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. |
|
@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 ) |
|
This is such an awful idea and ruins the spirit of OSS. |
|
@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. |
|
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. |
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. |
|
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! |
|
I was previously your GitHub sponsor (via @BUTR). I've stopped after SponsorLink was announced. Additional opinion as a sponsorThis 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 |
|
Having (artificial) delay is not acceptable. You don't want this library act as "ransomware", do you? |
@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):
|
|
Devils advocate
|
|
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. |
|
Adding/keeping the build delay shouldn’t even be on the table. That’s such a scummy and abusive thing to do. |
|
@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. |
|
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". |
|
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. |
|
@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. |
|
Yeah, like I said in another issue, I tend to sponsor all my favorite libraries on a rotation. |
You are mistaking open source code with a trialware and licenced software. |
kzu
added
enhancement
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. |
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. |
|
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. |
|
@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
Each group can be differentiated in terms of available features. But don't roll out all the limitations at once. |
@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.
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?
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. |
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?
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. |
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.
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. |
|
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. |
@kzu the last paragraph mostly. |
|
Wow, you think this random dude from Argentina can destroy the OSS community? |
|
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. |
|
I suggest you get yourself familiar with what an MSBuild task can do also. |
|
I'm familiar, thanks. That's besides the point, but you can pretend to not see the actual problem with it.
I know, shocker! |
@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. |
|
@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:
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. |
Only days? =D
So 20 publishers = 20 messages and 20 potential pauses, right?
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. |
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 😉 .
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.
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? |
Yes, it seemed like that was probably a misstatement.
Did you ever think that Moq would be downloaded a half a billion times? I have no reason to believe you couldn't repeat at least some of that. |
|
Thanks for the vote of confidence 🫶. If things get more sustainable, I might just be able to come up with another home run, why not? 🙏 But WRT SL itself, I expect iteration to be needed to address further scenarios that may not be critical at a very early stage. |
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.
The text was updated successfully, but these errors were encountered: