Adopting SponsorLink in v2.0

[kzu]

In order to improve the long-term sustainability of this (and other) projects, we'll be adopting SponsorLink v2.

Please get familiar with it, read the privacy statement and raise any doubts related to it in the SponsorLink repo itself.

All of SponsorLink is OSS too.

What this means for you:

1. If you're not a sponsor (or you haven't synchronized your sponsorship), you will get a IDE-only warning reminding you that the project needs sponsorship.
2. CLI or CI builds will never check for sponsorship.
3. Sponsorship for ThisAssembly is no longer optional for in-IDE usage. (thanks @gumbarros for the convincing argument 😉, and also for being a valuable oss author who, along 35.3k others contributing to 2.3k repositories producing 4.6k packages, will never need to sponsor me to use my stuff, unless they want to 💜 ).

[gumbarros]

Please remove the warning. Warnings are not meant for this, I would donate if this was not so agressive.

[kzu]

Why do you consider a warning to be agressive?

Informational messages are typically not even read, are they? In addition, the warning never causes a build error, so it's just to keep it visible, and it only shows up in the IDE.

Would you mind sharing how many informational messages you have in the same solution where you got the warning? 🙏

[gumbarros]

Would you mind sharing how many informational messages you have in the same solution where you got the warning? 🙏

None, just the ThisAssembly warning. We have a "no-warning" policy in our project and this is mildy-infuring

[gumbarros]

For anyone wanting to disable this message:

<PropertyGroup>
	<NoWarn>TA101</NoWarn>
</PropertyGroup>

[kzu]

Run dotnet build from a regular terminal, or CI, and you'll see there are no warnings in those cases. I'm explicitly accounting for "no warnings" policies so it should never cause a biuld error.

That said, would you have noted the message if had been an Info rather than a Warning? Genuinely curious 🙏

[gumbarros]

Run dotnet build from a regular terminal, or CI, and you'll see there are no warnings in those cases. I'm explicitly accounting for "no warnings" policies so it should never cause a biuld error.

That said, would you have noted the message if had been an Info rather than a Warning? Genuinely curious 🙏

At Rider IDE it's very infuring, when I have a warning I get this popup everytime.

[kzu]

Ah. That's an annoying IDE "feature" 🤔 . I don't have a Rider license and my trial expired LOOONG ago.

Does it make it slightly less infuriating to know you can support the project and get rid of the warning for just $1-$2 say?

Another question: does that annoying popup show up only because you have the warnings as errors setting or is this a regular thing for Rider? (like for any project regardless of any MSBuild settings)

[kzu]

Thanks to the new implicit oss I implemented, @gumbarros and the other 35.3k valuable oss authors contributing to 2.3k repositories producing 4.6k packages, will never need to sponsor me to use my stuff (unless they want to).

See https://www.devlooped.com/SponsorLink/github/oss/?a=gumbarros

[OoLunar]

Sponsorship for ThisAssembly is no longer optional for in-IDE usage.

I think this is really counter-productive for this repository since you'll only be using it in your IDE? Being able to see which build properties you have and what their values are at compile-time is the entire purpose of this project, however to lock it behind a paywall renders 80% of this project as useless and will only confuse new users to think the dependency doesn't work in the first place.

I understand that you're trying to receive sponsorships, however paywalling open source projects will only harm you and frustrate others. While I'm not particularly a fan of the warning, at least it doesn't negatively affect the dev build cycle like the paywall does.

I believe that if you're going to publish code to NuGet, it should be without strings attached. You can absolutely say "Hey, if you want to support this project, here's my Sponsorlink!" and that's okay! However what's not okay is to say "You can't use this project effectively unless if you pay me. Also the person who suggested the paywall will never be forced to pay themselves."
_{This is not an attack against you specifically @gumbarros, I'm going to assume you had best-intentions when suggesting that in the first place.}

Lastly I don't like that my IDE makes unknown network requests when I'm writing code locally. Not only is this bad if you're tight on bandwidth, but this leaks personal identifying information that's prime for bad actors to use against you. Maybe you specifically won't use that information against us, but we are none-the-wiser to know that. Could you add a <ICannotSupportYouDevlooped>true/false</ICannotSupportYouDevlooped> build property at least?

I'm a huge fan of this project as it's incredibly useful to me. I just don't like how it seems to be working against the dev lately. I would love to support you if I could, but unfortunately I'm just a college student who doesn't have any disposable income.

[viceroypenguin]

As an informational, based on the addition of SponsorLink, I have hard-locked all of my projects to use v1.4.3 and will not be updating to v2.0.0+. Will likely develop a personal alternative to avoid things like this.

[kzu]

Fair enough. Any particular qualms about SL v2 itself? Or are you just opposed to it in principle?

I ask because you'll personally never have to sponsor any of my projects, since you're a contributor. (See https://www.devlooped.com/SponsorLink/github/oss/)

[viceroypenguin]

Fair enough. Any particular qualms about SL v2 itself? Or are you just opposed to it in principle?

Opposed in principle.

• No nuget libraries should ever make unexpected api calls during build - this is both a performance and security nightmare, and will get your library banned from secure facilities.
• While sponsoring is an important part of the OSS community, in-your-face-banners like SL are thoroughly annoying to developers and will disincentivize use of your library; in fact, it will likely have the opposite effect of driving users away from your library. You saw this with your debacle with Moq, and there are plenty of other examples in NPM, etc.
• In general, the whole point of OSS is to freely share your code with the community. Sponsorship should be given, not demanded - demanding it goes against the spirit of OSS.

I have 10+ libraries that I support and maintain as OSS, and would never consider attempting to force any consumer to support me. I also consume 15+ OSS libraries that I do not maintain, and would not be able to fairly support all of them. I do have several authors I sponsor, based on the value they provide, but I do so based on my value of it, not based on their public demand for support.

[kzu]

SL v2 makes no API calls whatsoever. It uses all publicly available and approved APIs in Roslyn, namely an additional file and no I/O is involved either.

That's why I asked specifically about feedback on SL.

I appreciate your feedback on the potential outcome of trying this. I'm trying to live from doing OSS, which clearly isn't everyone's goal. We'll see how it goes.

[viceroypenguin]

SL v2 makes no API calls whatsoever. It uses all publicly available and approved APIs in Roslyn, namely an additional file and no I/O is involved either.

Better, but still creating a barrier to entry and an annoyance for users.

I'm trying to live from doing OSS, which clearly isn't everyone's goal. We'll see how it goes.

This is not how people usually end up making a livable income from OSS; usually they do so by either a) getting one or more corporate sponsorships, or b) developing a paid support/additional feature plan. The reality is that only a very few people can successfully make a livable wage from OSS, and none that I know of have ever done so based on individual sponsorships.

You can look at people like Troy Hunt who talk about the fact that everything they did was purely out of their goodness until they got big enough that people were coming to him to sponsor him for conferences and eventually for his website, due to the intrinsic value it had for the larger internet community.

The other thing I will add is that the C# OSS community is just not large enough for many people to make a living on it. Even the people I sponsor generally have less than 20 sponsors, for a total of <$200/mo; it is generally a bit of side income to their regular jobs, not a foundational wage.

Continuing this path with SponsorLink will not earn you many friends, and will likely drive away any potential consumers/sponsors that you may have attracted to begin with.

[kzu]

Sorry to bring bad news to you @viceroypenguin, but neither a) or b) seem to be working great for ImageSharp (you can follow the author at https://x.com/James_M_South/). So I'm deeply skeptical about that approach.

I admire Troy Hunt for sure. I'd rather not have to spend a ton of time away from my family doing conferences all over the globe just for the remote chance that some day that may turn out a profit.

And I'm willing to try something different. Also, you seem to have missed entirely that in v2, sponsorship encompases:

• user: The sponsor is personally sponsoring.
• org: The user belongs to at least one organization that is sponsoring.
• contrib: The user is a contributor and is therefore considered a sponsor.
• team: The user is a member of the sponsorable organization or is the sponsorable user.
• oss: The user is a contributor to other active open-source projects.

(learn more at https://www.devlooped.com/SponsorLink/spec/).

So you see, it's not even for individual sponsorships only. Companies can also sponsor and unlock sponsorship for the entire team. Doesn't that solve the other key no-go?

Also, I disagree on C# OSS not being large enough. I talked with other OSS authors that are effectively making a living through licensing and freemium features, even if that implies a potentially smaller user base.

I'm not looking to make friends, but to make a living, make my projects sustainable and being able to offer good service for them. If folks like the code I produce and are willing to sponsor, that's great. If not, that's fine too. I'm not looking for fame nor glory. I just want to code cool shit, do it OSS, and have it cost a mere cup of coffee a month for my users. If that means I may have fewer users, well, that's just life. But I will for sure be able to offer a much better service to the remaining ones, however few.

[viceroypenguin]

Sorry to bring bad news to you @viceroypenguin, but neither a) or b) seem to be working great for ImageSharp (you can follow the author at https://x.com/James_M_South/). So I'm deeply skeptical about that approach.

I think you misunderstood me. I wasn't trying to say that those would always work - I was trying to say that when it works for someone, those are the success paths. But my final point in that paragraph is that making a livable wage strictly via OSS sponsorship is exceedingly rare.

So you see, it's not even for individual sponsorships only. Companies can also sponsor and unlock sponsorship for the entire team. Doesn't that solve the other key no-go?

No. Because it still doesn't address the fact that a banner-annoyance will turn people off, and is antithetical to the OSS spirit.

I talked with other OSS authors that are effectively making a living through licensing and freemium features, even if that implies a potentially smaller user base.

You made my point for me - that a paid support and/or additional feature licensing plan is how many OSS authors make a living wage, not via sponsorship.

I think you and I have both made our points clear, and I see no reason to reply any further. I think you would find better success via other avenues, and I would be shocked if SponsorLink develops any significant interest outside of your projects; I would personally not use any project that added SponsorLink. Good luck in your endeavors.

[kzu]

Thanks for the feedback, again.

OSS never equaled free, so I don't know why it would be antithetical to it. Also, the fact that something hasn't been done already (successfully, say), is hardly an argument for not trying it.

I can point to vue.js which uses sponsorships and is quite successful. https://vuejs.org/sponsor/

[kzu]

btw @viceroypenguin thanks for your valuable contributions that amount to 38k daily downloads of popular OSS nugets!
From https://www.devlooped.com/SponsorLink/github/oss/?a=viceroypenguin

🤟

[Arithmomaniac]

@kzu:

I'm sympathetic to what you're trying to do, but I'd like to compare to other ways people have been solving the problem asides for asking nicely for sponsors a la Vue:

• Dual-licensing (like RavenDB) or with a source-available license (like Business Source License)
• Demanding you sponsor but without enforcement (e.g. Fody)
• Commercial software with license keys, which you may give to OSS for free (e.g. Visual Studio)

What's going on here, though, feels to me like a bad/misleading combination of the above: it's technically an open-source license (the most permissive), but in practice is nag/license-key software (the most restrictive; neither source-available software nor Fody does this).

I'd flip the posture of libraries using SponsorLink the other way around: they're commercial but shared-source software and tagged in GitHub etc. as such, but if you read the fine print you'll see that you can technically fork the project because it's MIT. (I'd even put a paragraph about SponsorLink inside the License file, before the actual license.)

I think that would be more transparent and up-front than confusing/disappointing people with SponsorLink on obstenstibly-liberally-licensed software.

[viceroypenguin]

I'd flip the posture of libraries using SponsorLink the other way around: they're commercial but shared-source software and tagged in GitHub etc. as such, but if you read the fine print you'll see that you can technically fork the project because it's MIT. (I'd even put a paragraph about SponsorLink inside the License file, before the actual license.

@Arithmomaniac, thank you for putting into words my objection.

@kzu: This is why I consider SL to be antithetical to OSS. You're right that money is not against OSS in general, but that was never my objection. My objection is that nag-ware is against the principle of OSS. The banner basically turns it from an OSS project into a shareware product with the legal ability to fork it.

Consider whether the Linux OS would be different if on every boot, there was a nagware banner that "encouraged" the user to donate to a foundation.

[kzu]

There's a nag on every npm install/restore about a gazillion dependencies needing funding. The whole begging thing for OSS to be sustainable doesn't seem to be working that great anywhere, TBH.

The source is open and freely available for forking and what not. My binary build of at least this package (doesn't mean SL v2 requires this at all) makes this a requirement for IDE usage. But as mentioned, you can fork and maintain your own copy without that. That's not at all against the MIT license, AFAIK.