Poll on SponsorLink

[kzu]

Hello folks!
Now that we've had a few weeks for things to settle, I'd like to collect some formal data points to perform a more informed retrospective.

[rouke-broersma]

Do note that while privacy were the primary concern, all of the reasons except 'would never pay for oss' are a concern.

[thomaslevesque]

After the feedback from other cases like yours, I've made that change since it makes sense.

In this case, I have no more objection on this topic!

Also, if SL did prove to significantly increase sponsorships, would you adopt it in your libraries? If not, why? On principle or is there something it should do differently?

Probably not, but I'm not in the same situation as you. I maintain one relatively popular project (FakeItEasy), and a few smaller ones, but it's not taking a very significant portion of my time. I do this as a hobby, not as a job, and I like it this way. If I started accepting donations, I would feel obligated to address issues raised by sponsors, and it would cease to be a hobby and become a job. I actually accepted donations for one of my projects a few years ago, and I stopped for this exact reason (I didn't receive much, probably less than $100 over 5 years).

[thomaslevesque]

Oh, also, I'm from Argentina, where we suffer exchange controls and have the second (or third) highest inflation in the world (120% annually by now). Every developer in this shitty environment can afford $1-10 dollars a month. So it's not like I'm a "first world" naive dreamer 😉.

Point taken.

My other argument still holds, though. It's a matter of principle. Even if I could easily afford to pay out of my own pocket, I shouldn't have to pay for something that I need to do my work. Otherwise, where does it stop? Am I supposed to pay for my IDE license too? My laptop? An company is supposed to pay for the tools their employees need.

Anyway, that's just my opinion, and obviously you're free to disagree. As long as you provide both options, it's fine by me!

[kzu]

Do you feel content creators of other kinds (videos, photos, music) feel their craft is a "job" because they get recurring income when their creations hit a sweet spot with consumers? Why is/would/should be different for OSS? Given donations/sponsorships are to the person (or org), NOT the project, wouldn't that mean they are supporting you as a creator, who is free to work on whatever you enjoy? (that presumes GH itself provides a way for sponsors to sponsor specific issues like bug bounties, say).

[rouke-broersma]

Do you feel content creators of other kinds (videos, photos, music) feel their craft is a "job" because they get recurring income when their creations hit a sweet spot with consumers?

Yes absolutely! Anything else is a toxic as fuck attitude and is a one way street to burn-out town.

Why is/would/should be different for OSS?

It shouldn't. It's work. It should be treated as work when it qualifies to be treated as work.

Given donations/sponsorships are to the person (or org), NOT the project, wouldn't that mean they are supporting you as a creator, who is free to work on whatever you enjoy? (that presumes GH itself provides a way for sponsors to sponsor specific issues like bug bounties, say).

That is not a given and I don't know how you jump to that conclusion. If I would donate to something I would donate for the sustainability of a project. Preferably to an organization that distributes the funds in the most appropriate way for sustaining the project. That could for example mean hiring full time developers to work on the project if the project is of sufficient size to warrant such a thing. I would only sponsor a person directly if it were the only option and if I would feel relatively sure that they could use the funds towards the projects i'm interested in.

In fact I would personally advocate against sponsoring Moq because your words and actions make me feel that the donations would go towards supporting your dream of becoming a "creator" instead of towards the sustainability of Moq.

[thomaslevesque]

Do you feel content creators of other kinds (videos, photos, music) feel their craft is a "job" because they get recurring income when their creations hit a sweet spot with consumers?

I have no problem with that.

Why is/would/should be different for OSS?

It shouldn't, necessarily.

For me, personally, receiving donations would make me feel obligated to continue maintaining the project, so I choose not to ask for donations. As I said earlier, I view this as a hobby, so I don't expect any compensation (and in return, I offer no guarantee of any kind). If I no longer enjoy working on OSS, I'll just stop. I already have a full-time job, I don't want another.

But I totally understand this isn't everyone's perspective. In your case, you spend a significant amount of time working on Moq, so maybe it no longer qualifies purely as a hobby. I think as soon as you expect a compensation, it stops being a hobby. And it's fine, if that's what you want.

[jeroenwalter]

I'm missing the option: "Breaking builds by introducing build warnings, because they are treated as errors"

[jeroenwalter]

In a previous comment on another sponsorlink related issue, I've mentioned the exact same point, namely that most users don't know where the library comes from or that it is open source.
So no, I'm not ignoring that, I just don't think that SponsorLink will significantly change that.

[kzu]

Well, unless someone does something to try to change that, it ain't gonna change by itself. I'm trying to do something about it. It may very well fail and not achieve anything. But at least I'll be able to say I tried and didn't just accept the status quo as if it was great and there was nothing anyone could do to improve it.

[jeroenwalter]

And that I understand and I think it's commendable you're trying to change it.
But not in the unfortunate way you kickstarted this whole debacle with moq.
SponsorLink may eventually be a success and maybe it'll lead to improvements in how nuget/ms/github handle oss sustainability.
At least it brought to attention to some moq users, that you are struggling with how little your time and effort is appreciated and compensated.
And it leads to some interesting discussions, as we again can see tonight, but keep in mind that not everyone shares your opinion, your view of sponsorships and who should pay for them.

[kzu]

Thanks. That's fair, and that's why folks have tried many other models before (and now). If those had worked awesomely for everyone doing OSS, I wouldn't be doing this.

[kzu]

AND, due to the awesomeness of MSBuild, SponsorLink can issue warnings WITHOUT ever causing build errors, even if warnings are treated as errors. See devlooped/SponsorLink@f9c6b29 (thanks to @thomaslevesque suggestion).

[canton7]

It's news to me that it was supposed to pause a single build per ide instance: it didn't quite pause every build for me, but it was close!

[canton7]

Fody was brought up as a example of another route you could have taken, in another issue, I'm sure.

I switched away: I used Fody in a couple of projects, which I probably only opened a few times a year, and paying a (not insignificant) monthly subscription for something I only interacted with rarely wasn't a good option. I'd happily have given a one-off donation, but that wasn't an option. But I didn't feel cheated: it was handled openly and transparently, and Simon was very clear that the MIT license was still being honoured.

I've given plenty of one-off donations. And received a fair number myself for the projects I maintain. I also put most of my free time into projects which others use, which is the original contract of FOSS software.

[jeroenwalter]

Nope, I have no problem paying for OSS if there's a commercial license.
OSS is open source, which does not necessarily means it's free.
There's lots of OSS software that's not free and have commercial licenses.
We use several of commercial libraries that are open source.
However, if you publish your source code with an MIT of BSD license, then don't expect to be paid, everybody loves free beer. Some may bring snacks, but don't count on it.

[kzu]

It seems you're talking about "source available" not OSS.

GPT-4 says:

No, there are no OSI (Open Source Initiative) approved licenses that prohibit commercial use. One of the fundamental principles of the OSI's definition of "open source" is that no discrimination against fields of endeavor, including commercial use, is allowed. Therefore, any open source license approved by the OSI allows the software to be freely used, modified, and shared, for any purpose, including for commercial purposes.

[jeroenwalter]

Did you even read that GPT-4 blurb?

I did not mean necessarily only "source available".
For instance dual licensed projects, like Mongoose webserver, which has a gpl license and a commercial license.
https://mongoose.ws/licensing/

[kzu]

Thanks for that trip down GPL :). From Selling Free Software:

Many people believe that the spirit of the GNU Project is that you should not charge money for distributing copies of software, or that you should charge as little as possible—just enough to cover the cost. This is a misunderstanding.

Actually, we encourage people who redistribute free software to charge as much as they wish or can. If a license does not permit users to make copies and sell them, it is a nonfree license. If this seems surprising to you, please read on.

It seems I'm doing something very laudable by trying to charge for OSS!

[stakx]

I'm missing the option "Bad communication". In Moq, SponsorLink was perceived by many as malware/spyware, and that exacerbated all the other concerns and antagonized a lot of people, which is perhaps one of the worst things that could happen to a incubating project.

[kzu]

[canton7]

... And replying with sarcastic gifs is just another example of not taking people's complaints seriously...

[kzu]

You seem to take your opinion as "the people's". I'm just pointing out something that should have been obvious from the beginning: Your opinions are just your opinions. I don't think it's useful at all that you just keep repeating the same thing over and over and adding "the people" all the time as if that makes it a broader "agreement" than what it is: your opinion.

Which, just like mine, are solely mine. I don't speak for "the OSS community" or "the OSS maintainers" or any such community. I speak for myself, and I may just be an idiot who misunderstood everything about everything. I have no pretense of holding "the truth". But you come across as having the exact opposite attitude. Perhaps I'm misinterpreting that too, mind you.

[jaredthirsk]

You seem to take your opinion as "the people's".

The whole Moq/SL thing caused a big uproar and got it dropped by AWS and Microsoft. I'd say 'many people' have spoken, and there are aspects of what they said that you either have yet to grasp, or accept, and I think @canton7 is accurately attempting to address something here.

"That post doesn't clear you, it just makes clear how out of touch you are with what you did, IMO." I didn't answer the poll because this 'out of touch' is the biggest showstopper, and it is an unresolved issue, evidently, despite being a fixable one. (There was no "none of the above" option, which I think hurts the validity of the poll.)

Objectively, there were several communication things you tried to do. Objectively, it was not enough. Subjectively, you say "I'm almost positive that [better communication] will have very little effect in the underlying complaints" while posting sarcastic gifs, and concerns have gone unaddressed because of this wall of stubborn skepticism.

Like it or not, if you want "the people" by and large to respect what you do (even if they don't like it) and trust you to be an honorable maintainer, you have to have to let go of the stubbornness around the idea that all this drama is because people are stingy and greedy, and have some empathy and take people at their word. I don't think you can see the whole situation clearly, otherwise.

Who is going to trust someone who is so untrusting of their users? Not me.
This is a social engineering project as much as anything, and a social blind spot is a major issue.

[kzu]

How are concerns not being addressed? Please go look at https://github.com/devlooped/SponsorLink and let me know.

You seem confused about what's (not) happening with Moq. See https://github.com/search?q=moq+owner%3Adotnet&type=code. Unlike quick over-reactions here, folks at actual companies don't rush in 24 to remove something before getting clarity on the future direction of a project they depend on when something like this happens. I took concrete steps to address the feedback, and that's been noticed.

If you see the download stats and repo stars (kept growing), you might realize it's actually you who has a blind spot here.

I would be a whole more empathetic with folks who are empathetic in turn with what it means to be a (significant) OSS developer. As I said, empathy has nothing to do with the lack of critical thinking you need in order to take people's assertions at face value.

[vafreebird]

You are missing the option "Conflating Sponsors with Customers". You want EVERY user of Moq to be a sponsor or suffer the consequences.
It doesn't even matter how "bad" those consequences are. That's not a sponsor. That's a customer. If you want customers, that is your right. Create a commercial license, require it at a minimum point you deem appropriate and accept purchase orders for said licensing.

[rouke-broersma]

Who is complaining about that? The complaint is the way you're trying to abuse sponsoring as a method of licensing. Not that you want to earn money from the work. It's the masquerading most are having an issue with.

[glanham-jr]

I would not consider this selling software, as it's already on developer and production machines by the point you are wanting to do run your code. Rather, this is compile time telemetry you are gathering and is done so regardless of sponsorship, with privacy concerns as a follow up to your initial release. If you removed the telemetry aspect of it, that would remove all GDPR complaints and most concerns are out of the way. Many NPM packages run this way.

As to quote the article you've linked:

So unless you're going to draw distinctions carefully, the way this article does, we suggest it is better to avoid using the term “selling software” and choose some other wording instead. For example, you could say “distributing free software for a fee”—that is unambiguous.

You aren't charging a fee for distribution, just a telemetry based switch.

Total Commander is a different type of product with a different audience and thus has a different UX. It's proprietary shareware from what I saw, and is an end user and non developer product. Maybe those users don't care about telemetry, as they don't have requirements to block it or even care.

Developers in companies have strict requirements on GDPR within companies and use in production environments, and so your telemetry simply blocks those users from your using your code if that's ok with you. You also have a developer audience that is in tune with privacy and don't like their data, even if hashed, sent to third party servers without a way to stop it. Sneaking in telemetry isn't a good way to maintain relations with consumers.

A much better model that respects privacy would be that we could pay for a license ID we could place in our repo that would prevent the warnings from being generated and not send private info to your servers. But at that point, you are selling a product in some capacity. Your code is quite permissive, so that would just increases the chance of it being forked, and it seems it already has.

If you want to allow sponsorship, compile time messages are great and non-obtrusive. If you want to increase visibility but annoy developers who treat warnings as errors, trigger a warning. If you want to conditionally warn based on telemetry, then you will block swathes of developers who use your code in companies and disgruntled privacy respecting developers. If you wanted to force people to pay money, make the project closed source. If you want people to contribute, make the project LGPL or GPL. If you want to keep it permissive and sell a distribution fee, take it off GitHub and only distribute through your site via request (this is closer to the FOSS article from FSF you mentioned).

It's a situation of having your cake and eating it too - if you want telemetry based switching and are fighting to keep it in your project despite consumer complaints, then the backlash isn't unsurprising and consumer rates will fall. Sadly I am blocked from using your package, so damage has already been done in many places, so it's up to you if you want to repair confidence in developers and companies using your package.

Maybe you'll make more money even with the less consumers, and if that's your only concern, then there isn't a strong need for a poll - just do what you want, it's your repo. Is your primary concern maintaining consumers, or is it raising money for yourself?

EDIT: I fully understand where you are coming from, and wish you had an easier path forward. But it's a very hard domain to monetize shared libraries.

Further, even though you say your software is GDPR complaint, that hasn't actually been evaluated by a third party, and companies will avoid it because of your software license never holds you accountable. Self proclaiming GDPR compliance is likely not enough, and every release you ever do should be evaluated for GDPR compliance by a third party agency.

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.

[glanham-jr]

Not trying to nitpick, but there is a small funny level of irony of referencing an FSF article after having linked a binary blob to their open source software (yes I know it's permitted under the BSD licensed).

[kzu]

If you removed the telemetry aspect of it, that would remove all GDPR complaints and most concerns out of the way

That has happened weeks ago.

Sadly I am blocked from using your package

What a fast company you work at! The problematic versions were gone and unlisted within 24 hours, yet your company was even FASTER than that at blocking? Wow. One-of-a-kind agile. And I'm guessing you ported whatever code you had within those 24 hours too.

[glanham-jr]

What a fast company you work at! The problematic versions were gone and unlisted within 24 hours, yet your company was even FASTER than that at blocking? Wow. One-of-a-kind agile. And I'm guessing you ported whatever code you had within those 24 hours too.

I’m sorry to see you this is how you respond. If there is any discussion not pro-SponsorLink that is not considered, then my last suggestion is to make an announcement you will be adding it back in with XYZ changes and not adding it isn’t going to be considered.

[lmalenfant]

You are missing the choice that the email address when developing is not always the same one used for GitHub so even as a sponsor you might be subject to the negative behavior.

You are also missing the ability for multiple choice, a lot of the issues were equally bad.

Your package is also available on NuGet and from Visual Studio directly so you are assuming that they are familiar with GitHub and the Sponsorship Link.

[kzu]

It's a random <4 seconds (once per IDE instance, again). If it were implemented flawlessly and it was a ONE pause regardless of how many packages are seeking sponsorships, I think it's indeed a very very minor issue.

[lmalenfant]

If it's not that big of a deal, why do it at all? What stops you creating a more annoying delay when you are not getting the sponsorships that you think are enough?

[kzu]

Nothing is stopping any other OSS software to decide things are unsustainable and implement things to try to become sustainable in ways you disagree with. And you're free to switch to another OSS library. But switching from one unsustainable one to the next won't magically fix the underlying issue. There's a reason this is brought up over and over year after year, successful project after successful project. But if you want to play whack-a-mole with free stuff that still haven't gotten to the point of being unsustainable, that's a fun game too. At least keeps you busy learning new stuff, which is always fun!

Incentives matter, IMHO. Anything that raises awareness that you're not contributing to sustain a project you depend on, would be a good thing to make it sustainable in the long run.

[lmalenfant]

https://developercommunity.visualstudio.com/t/Add-sponsorlink-visibility-in-the-NuGet-/10456467

[kzu]

Bear in mind that the only person seeing that icon/message is the one who first installs/updates the package, though. Most projects likely use dependabot for updates, and installing typically happens on File | New and never again. Still, I think it's a great idea.

[canton7]

I'll give another option not on the poll: licensing to individuals rather than to projects is a problem. Consultancies develop projects for clients, and then hand them over. It's relative easy to buy a license for a software package used on the project: if it's a one-off expense then you just put it on M&Es, if it's recurring then you have the conversation with the client and explain the situation, and they factor in the long-term cost.

Licensing to individual developers means that the costs are hard to predict and hard to explain. If the client has multiple large engineering teams, they probably won't know who's going to be involved in the project in future, so ballooning costs become a risk. Given the complexity of some of those conversations (mostly held with people who don't even know what open source is or why we're using it, and btw what's a github?), it's just easier to not use Moq...

[kzu]

There's no licensing. You don't NEED to sponsor, and the project will keep compiling happily ever after. It's like your donation to any other charity. Only you get some benefits for it too (i.e. "faster" build if there was a one-time pause, no messages or whatever).

[canton7]

I don't follow. Do you want people to pay you or not? Because the situation you've set up makes it really hard for people in companies to give you money and avoid build-related frustration. So your only viable outcome is people getting annoyed and switching away, and you getting $0.

[kzu]

@canton7 why would I be making hard for companies to give projects money in the form of sponsorships? See https://github.blog/2023-04-04-whats-new-with-github-sponsors/:

We launched GitHub Sponsors in 2019 with the vision of a more sustainable open source ecosystem. Since then, more than $33 million has been invested in open source across 68 regions of the world.

and:

While in beta, we saw exciting growth in direct funding from 3,500 partner organizations like AWS, American Express, Shopify, and Mercedes Benz. And in 2022, nearly 40% of sponsorship funding came from organizations, with each organization-funded sponsorship worth on average nearly 15X more to maintainers than the average individual sponsorship.

I think you need to open up to the possibility that GH can actually help change the status quo in that regard with that they are doing (and investing in!) with GH Sponsors.

Org sponsorships is now also supported. Another possible outcome would be individual devs sponsoring, then companies having a matching program (like Microsoft Give) where they match employee's sponsorships to double the impact.

[Rutix]

There's no licensing. You don't NEED to sponsor, and the project will keep compiling happily ever after. It's like your donation to any other charity. Only you get some benefits for it too (i.e. "faster" build if there was a one-time pause, no messages or whatever).

@canton7 his reasoning still stands though. Of course, you don't need to sponsor but if you do individual licenses and hand it over you still need to have that conversation. Otherwise, they will find out with the handover that suddenly they have a penalty and an impact on productivity. What I don't understand is that you are so black and white, you are going off on people with statements as "that just means you dont want to pay to OSS", but most of them would be fine to pay if the options they need were there.

[kzu]

@Rutix forget the build pause. Assume there's warning that never causes a build error (it's doable). So, it's entirely optional, has no "penalty" and no impact on productivity. And you can do individual or org sponsorships.

I guess that settles it then? Everyone 👍 ?

[canton7]

Another point worth making is that Moq doesn't have a monopoly on free mocking libraries. For a new project, people are always going to pick the free option, especially if the paid option involves lots of overheads sorting out eg GH sponsorship in your team/company. So your best bet is getting already-happy customers to give you money, but that won't happen if you annoy them. And let's be honest, build pauses are intended to be annoying.

[kzu]

So I guess you picked #3 "Build pause for non-sponsors (even once per IDE instance!)", right?

Nothing is a monopoly, it's all OSS, which is why I don't get that "you're forcing users" or the like. You're free to choose other libraries. And I'm free to offer the best one in town too 😉 . But feel to go over there, only to see those maintainers become frustrated with the non-sustainable situation once they (hopefully for them?) become the #1.

If you think donating with GH sponsors is a "lot of overhead" I can only assume you never used it (oh wait, I don't have to assume... checks profile). If installing a CLI app and running TWO commands is "lots of overhead" for a developer, I'd say you need to hire better deveopers.

[BusHero]

I will pay for OSS if it helps me build a product that will bring me money

[kzu]

The company is already paying YOU a great salary. Reminds me of that co-worker demanding $2 for an airport cart refund for a business trip, despite making top-tier income...

[jeroenwalter]

So we're back to your view that an employee should pay for their own tools.
This is like talking to a wall.

[kzu]

In case you missed it: https://github.com/moq/moq/discussions/1414#discussioncomment-6889581.

I can STILL think paying for your own tools is a valid position, while STILL supporting org sponsorships.

This is like talking to a wall.

Ditto. It seems that you can't be bothered to argue why the company isn't already paying you sufficiently well for you to be sufficiently well-off to be able to sponsor/donate to (work-related) tools you enjoy enough that you want to see the humans behind them do well. I can only conclude you don't really care much for any human behind anything in the supply chain of your employer, regardless of whether they make your life enjoyable or miserable.

In my mind, that's a similar attitude to saying "I pay my taxes, why should I make any donations to any charities at all? The government should take care of anyone in need, that's why I pay taxes".

[doomchild]

In my mind, that's a similar attitude to saying "I pay my taxes, why should I make any donations to any charities at all? The government should take care of anyone in need, that's why I pay taxes".

There are places where that is the main method of helping people in need (with programs like universal healthcare), and it works quite well.

It seems that you can't be bothered to argue why the company isn't already paying you sufficiently well for you to be sufficiently well-off to be able to sponsor/donate to (work-related) tools you enjoy enough that you want to see the humans behind them do well.

You're ignoring the fact that the company made a lot more money off the code than we did for writing it. My team of seven wrote two products last year that collectively made more than $10M for our company. We got paid the exact same amount as the year we spent fixing old stuff and made a fraction of it. If you're going to get on a high horse about devs having decent salaries and ignore that the companies they work for make exponentially more money off those devs' work, you're being a hypocrite.

Your insistence that devs working on company time, using a company computer to write code that they don't own should pay for tools to do so is intensely frustrating. We don't own the code we write, so why should we be paying for the tools to develop it?

[jeroenwalter]

It seems that you can't be bothered to argue why the company isn't already paying you sufficiently well for you to be sufficiently well-off to be able to sponsor/donate to (work-related) tools you enjoy enough that you want to see the humans behind them do well.

I don't want to argue this, we've already established that we have ideologically different viewpoints and I don't expect your view to change. You made this very clear in lots of previous posts. So why bother, you do you.

I can only conclude you don't really care much for any human behind anything in the supply chain of your employer, regardless of whether they make your life enjoyable or miserable.

Don't be so judgmental.
Even though I sympathize with your desire to be compensated for your work, statements like this do nothing to help me sympathize with you as a person.

In my mind, that's a similar attitude to saying "I pay my taxes, why should I make any donations to any charities at all? The government should take care of anyone in need, that's why I pay taxes".

You are not a charity, you are a manufacturer of a product and want to compensated for that. That is called a business. And as such you will be treated.

[jeroenlandheer]

@kzu

It is clear to me (and probably everyone else) that you try to gather feedback that supports your idea while you turn a blind eye to feedback that does NOT support your idea. This is clearly not the way to go at this, nobody will take you seriously.

The "I've seen it all" kind of mentality is not very productive and TBH, reading your reactions here is just annoying. I'm normally not this negative, but to give you a simple tip: just acknowledge you made a mistake, make sure that Sponsorlink doesn't make any comeback in Moq (because I still think it is a great piece of software) and try to win back the trust the community lost in you. (Trust me, that's not going to be easy.) Anything less than this will not cut it for anyone who's serious in developing products.

If you want to earn money making this software, just put it in your license that people need to pay for it, setup a fancy website where people can swipe their creditcard and call it a day. That's how you do these things, not by sneaking in executable code in a development environment.

And we're not just talking about code that is harmless. It's code that scans git repo's, phones home and does things developers aren't aware of, nor give permission to. That's not harmless, it's criminal.

[kzu]

I think you're awfully outdated in where things stand already as of now: https://github.com/devlooped/SponsorLink/blob/main/privacy.md

executable code in a development environment

Otherwise known as analyzers, source generators and build tasks...

[doomchild]

Otherwise known as analyzers, source generators and build tasks...

That's a false equivalence and you have to know it. There's a huge difference between an analyzer that finds a potential problem and a process delaying the build or nagging the developer.

[dsisco11]

First off, I consider all of the options to be valid problems.
I'd also like to rephrase a sentiment I've seen talked around in some of these comments, maybe it will offer a slightly different perspective to you.
About the build time delay and the whole sentiment of "without a carrot, users won't pay".
The different types of incentives should be viewed as forms of "behavioral reinforcement".
You are using negative reinforcement because you are taking something away from users.
No matter how you reframe it as "No, I am offering them faster builds, for a fee" it is not true.
You can only offer someone something that they didn't already have in the first place.

Here is the key takeaway to remember:
What you are doing by decreasing the build time is punishing someone and then selling them respite from the punishment you are causing.

It doesn't matter how small the punishment is, the psychology and side-effects of negative reinforcement still apply.
However, positive reinforcement would be if you could provide the user with something they would not have otherwise (which you did not take away in the first place).
The future, viability, and success of open source CANNOT come from negative reinforcement because people always react negatively in kind. It breeds resentment and will create toxic underpinnings for the OSS community.
Therefore only positive incentives are truly sustainable.

[kzu]

I kindly refer you to the reaction and personal story of the guy from core-js in his funding journey. As you can see there, he's not asking for funding by "offering carrot" (which many seem to assume is the only way), but rather by simply asking for it. You may think this is idiotic, will never work and is even unethical of him. But judging from the results he's achieving at his OpenCollective, I find it hard to agree with your argument:

[dsisco11]

You seem to have focused on the wrong part of my message.
I am saying that, objectively, negative reinforcement cannot be an effective means of funding.

The person you linked to did not use any negative reinforcement, and his listed ultimatums ARE the carrots.
His statement boils down to: either work on the project must cease so he can get a livable wage or he would need donations amounting to such.
Having to quit a project isn't a form of negative reinforcement per se, because nothing the users already had will be taken from them.
Rather, the users would not receive further project developments.
There is a difference, with quitting the carrot is "I no longer work for free, no more releases from now on. But if you pay then we can have more releases."
In this scenario nothing was taken from the users, they didn't have those hypothetical "future updates" yet, so they weren't "taken" because they weren't "given" yet in the first place.
That's the distinction, you can't take something away from people once they already have it (like build speed or whatever).
But you CAN offer them something they don't yet have (more updates, releases, pro version, corporate licensing, whatever).

[kzu]

Read the reply below which supports the exact opposite argument: asking nicely didn't/won't result in recurring revenue for that project.

[rouke-broersma]

I kindly refer you to the reaction and personal story of the guy from core-js in his funding journey. As you can see there, he's not asking for funding by "offering carrot" (which many seem to assume is the only way), but rather by simply asking for it. You may think this is idiotic, will never work and is even unethical of him. But judging from the results he's achieving at his OpenCollective, I find it hard to agree with your argument:

After their outcry they suddenly received a massive influx of donations, yes. But a significant portion of those donations are one-time donations. If you sum the contributions from August they add up to about $3,000, this would make the annual contributions (assuming all contributions on August were recurring) sum to just under $40,000. That's 2-3x what they earned in previous years but imo it is likely to go back down again over time until they have another public outcry. And it is very close to the amount they listed in their own article being too low: https://github.com/zloirock/core-js/blob/master/docs/2023-02-14-so-whats-next.md#what-do-you-think-how-much-money-does-core-js-receive-each-month
So I don't think their story is very solid support of your opinions.

[jeroenwalter]

A single pause per IDE instance will also not get you more sponsors. The reason being, that most people won't see that pause when they're waiting for a build, that may take minutes. Any info messages will also scroll away very fast, so people won't see that as well.
So why bother, it won't improve visibility.
If you want to make shareware, make shareware with a really obtrusive nag screen, but also CLEARLY announce on nuget, release notes, license dialogs and github etc, that it is shareware, so people can make an informed decision before installing or updating the package.

[kzu]

Info messages show up in the VS "Error List". Obviously nobody ever sees info messages in the output window, they are not even displayed there by default. Granted, if a typical solution is like (a subset of) Roslyn's, it's bound to get lost :(

Now, going back to the warning instead of info (keeping the once per IDE session characteristics): that's gonna be harder to miss. And if you have warnings as errors, even less so (you would be able to just "ignore" that "transient" error once per IDE instance to just ignore the ask for sponsorship....).

Thoughts?

[thomaslevesque]

Now, going back to the warning instead of info (keeping the once per IDE session characteristics): that's gonna be harder to miss.

It would certainly be visible for me, as I strive to eliminate all warnings in my code.
In legacy codebases, though, it's common to have solution that have hundreds of warnings; we have one such solution at my current company. The SL warning would probably go unnoticed.
Still, I think the warning is an acceptable solution. Even with warnings as errors, you can use WarningsNotAsErrors to not cause an error for this one (in fact, it could even probably be done by the SL package itself with a .props file)
I also don't get all the fuss about the build pause, especially if it's only once per IDE instance. Most people probably won't even notice it, except maybe in a very small project. But while I don't think it's very annoying, I also think it might as well be removed, because it's not noticeable enough to achieve its goal. I would go with just the warning, to which very few people could really object.

[kzu]

Still, I think the warning is an acceptable solution. Even with warnings as errors, you can use WarningsNotAsErrors to not cause an error for this one (in fact, it could even probably be done by the SL package itself with a .props file)

I had totally forgotten about that feature! Makes it even better than the build pause for sure!

Great point about solutions with tons of warnings. I've been there too. And in large solutions that take a long time to build, it's true it might go missing. I think though that when the warning tells you that you have just wasted a few seconds, you might give it a second thought at donating perhaps? (even if you're reminded once per IDE session that you have wasted <4'' ). Thoughts?

[thomaslevesque]

Personally I don't think the delay would make me want to pay.
Someone who doesn't want to sponsor anyway might be annoyed by the delay, but that wouldn't make them change their mind about sponsoring.
Someone who is willing to sponsor doesn't need the delay as an additional incentive. At best, they will ignore it and maybe sponsor anyway, but not because of it. At worst, it will annoy them enough to not want to sponsor.

[daniel-white]

Missing option: the code obfuscation.

[kzu]

You'd have voted for that over GDPR?

[daniel-white]

Yes absolutely

[kzu]

As the report says: [4.20.0,4.20.2). None of those versions are listed anymore, and the latest public 4.20.69 fixes it.

[lmalenfant]

As the report says: [4.20.0,4.20.2). None of those versions are listed anymore, and the latest public 4.20.69 fixes it.

Only because you removed SponsorLink, are you planning on adding it back in? If so what will make Snyk not consider this "Undesired Behavior"? I am asking this genuinely.

[kzu]

The report says: " It contains a dependency on the SponsorLink package, which runs an obfuscated closed-source executable at buildtime."

Since that ain't gonna come back at all, I consider that an obsolete issue. This is what's eventually coming back: https://github.com/devlooped/SponsorLink/blob/main/privacy.md

[lmalenfant]

That executable spawns OS processes and performs network requests, including transferring a derivative of personally identifying information (a hash of the email address of the developer from 'git config' output) to remote servers.

Doesn't it still do this though?

[kzu]

That question has more than one part. Which "still do" are you referring to?

• spawning an OS process
• performing network request
• transferring derivative of PII to remote servers

The answer to ALL of them is NO. The qualifier for the NO for the first is "unless you explicitly authorize so beforehand".

[qrzychu]

What people are saying is that if you expect every user to be a sponsor then they are no longer sponsors or users, they're customers. And then you're a business. Which is fine, nothing against you trying to earn money off of oss.

Well, whether we want it or not, WE ARE CUSTOMERS. When I create an issue in OSS project, I EXPECT some kind of reaction. Why would I? Nobody owes me anything, especially their time to read how I missuse their library.

Whether SL is the right solution, I don't know. I would prefer some kind of non-profit organization, where me or my employer could sign up, we would tell them which libraries we use, and they would send us a quartetly bill that would then be distributed between OSS authors. Something like this was discussed on recent DotnetRocks podcast, and I think it's a great idea. "Somebody" should get on it! (Shoutout to Evan Czaplicki and this talk about open source)

Like the great Gabe Newell said, just make it easy and convenient to pay, most people will pay.

Also, if you don't want to admit to yourself that you are a customer, just don't upgrade Moq. It works as is, you know exactly which version was the last one without Sponsor Link.

Oh, you want bug fixes and new features? Updates to the latest dotnet? That sounds like a customer to me.

[doomchild]

Introducing warnings (that many of us treat as errors) and build pauses are functionally no different from the satellite radio in my car switching itself on to play an ad for Sirius XM every time I start the car.

And if I'm working on company time with company tools on a company machine, personally paying for one specific library is a no-go. For one, I don't have a choice of whether to use the library or not, that choice was made a long time ago and the library is used in so many projects that removing it would be a seriously non-trivial lift, meaning that I'm forced to either pay up or suffer from irritating nagging from my tools. And secondly, if this kind of scheme caught on, how many other libraries would I wind up being nagged by until I paid up (most of which I am probably forced to use by historical decisions)?

And saying "you make plenty of money, just pay up" ignores mortgages, bills, car notes, food, daycare, and the thousand and one other things that we wind up paying for out of that paycheck. It's tone deaf and suggests that you aren't interested in anything but a payday. And if that's the case, that's fine, but the way to solve that problem is to sell licenses or support contracts, not try to nickel and dime every dev on the planet.

[kzu]

Introducing warnings (that many of us treat as errors)

You can have warnings that never cause errors even if you treat warnings as errors.

You seem pretty sure that there's ONLY ONE WAY to monetize OSS. I disagree. You can say that's "tone deaf". I could easily say the same thing.

[doomchild]

No, I'm sure there are other ways to monetize OSS, but at the current moment, I only know of one that works relatively well, and this setup isn't it.

[kzu]

That sure is one way to never do anything original: to just look at things others have done before without a critical analysis of evolving tools, customs and tech (i.e. GH Sponsors didn't even exist a short few years ago).

Thanks for the feedback.

[doomchild]

There's nothing wrong with doing something original, as long as you're prepared for the possibility that it might not work and can accept that fact and move on to something else.

[kzu]

Oh, I have no grandiose expectations that I have THE solution to OSS sustainability. But I'm willing to try something new.

[hrocha1]

What was, in your opinion, the worst of SponsorLink's implementation at the time?

The worst is that everything the library does only harms the user, there is no upside, only downsides.

SponsorLink that has been included with moq is a textbook definition of malware:

• by distribution (obfuscated binary added to a random minor version of a library without any sort of warning or discussion)
• by behavior (snooping around file system, reading personal data and sending them away without any sort user consent)
• by it's effect (best case scenario it only slows down builds, worse case scenario it breaks builds, slows down IDE etc.)

If there is genuine desire to learn from this then I would suggest you to do the exact opposite. Be open with your users, ask for their consent and provide value for people that do sponsor the project. At least that's what motivates me to support a project like yours (I do pay my own money for some of my developer tools and I sponsor few projects regularly via Patreon).

[kzu]

@hrocha1 would you say the new stuff at https://www.devlooped.com/SponsorLink/ is a step in the right direction? I've been trying to gather feedback over on that repo but have gotten very little (nearly none). I fear no matter much much as I ask for it, some details are bound to not satisfy some, and we'll have a repeat of my posting and integrating SL for ~6+months and then all of the sudden folks complaining they didn't know it was coming.

Also, keep in mind that the primary goal of SL is to bring sponsors to the project, not necessarily to "provide value". It's like asking for Patreon-sponsored libs to give you some value beyond a "thank you!" for your sponsorship. I sponsor shields.io for example, because I enjoy using them, not because I get anything additional by doing so. You could say that what I get is a project that is more sustainable (provided many of us did the same).

[FrankRay78]

what's really important is whether other people are willing to contribute code (not money!) to my subsystem or my open source project. That's what takes the project forward, and if those other people happen to work for other companies that implies that those companies have figured out a way of extracting business value from my open source project, and in order to extract more value, they are willing to contribute new features or capabilities or improve the performance of my subsystem or project. When they do that, it leverages the value that my subsystem or project can deliver to my employer, and makes it more likely that my employer will be happy with my work

Theodore Ts'o, the first North American Linux Kernel hacker, who started contributing to Linux in 1991, and for whom the majority of his career, his salary came from open source work.

https://medium.com/@theodore.tso/open-source-in-shambles-not-so-fast-b0a4a7bab55e

[kzu]

The owner of ImageSharp, the #1 lib for image manipulation on .NET, with 80M+ downloads, suggests otherwise: https://twitter.com/James_M_South/status/1744710437449675259

[ronnyek]

I'd just say these types of moves... introduction of sponsorlink, or how some opensource libraries suddenly transition to restrictive opensource licensing... well these things in my opinion tend to be the downfall of given piece of software or library. In my opinion this leads to detrimental side effects on the reputation of that software.

You kill the trust, and the vibes. I wont use moq not because of soliciting sponsors (though I do think thats kind of a bad move) but more so because I don't trust that more changes wont happen that will break how I consume these libraries etc. Will there be a license change in which I'll have to spend significant efforts removing code from my applications?

At this point in time, approximately 1yr after I've heard grumblings about sponsorlink, I imagine people have moved on, and people are migrating to something else... as moq authors cant really be trusted, but I imagine others are just referencing really old versions of this library and will eventually be leaving.

[rouke-broersma]

You would think so but nah, people have simply accepted the revert:

https://nugettrends.com/packages?months=12&ids=Moq

[kzu]

ImageSharp, the most popular image manipulation library, switched to dual licensing.
Downloads remain strong, with over 114M now: https://x.com/James_M_South/status/1835172258198827204.
Yet the author still cannot make a living: https://x.com/James_M_South/status/1838699698397265946.

[kzu]

Too all the folks suggesting making a living was just a matter of changing the license: https://x.com/James_M_South/status/1835172258198827204

[jeroenwalter]

At least he tries to make a real business for his software. Too bad it doesn't work out for him yet.
I don't think anybody suggested to you that only changing the license would open the flood gates of money, instead they also suggested to treat your project as a business, i.e. take on the responsibility and tasks of a businessman.

[kzu]

Yeah, and that doesn't seem to be working that great, so 🤷‍♀️. My point was precisely that: it's hardly an advise that Just Works. My conclusion from his experience is: that route is probably not worth it.