Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support org-wide sponsorships #47

Closed
kzu opened this issue Aug 15, 2023 · 5 comments
Closed

Support org-wide sponsorships #47

kzu opened this issue Aug 15, 2023 · 5 comments
Labels
enhancement New feature or request

Comments

@kzu
Copy link
Member

kzu commented Aug 15, 2023

There were valid arguments in favor of organizations sponsoring the projects, rather than individuals.

I'm not entirely sold on this, but since SponsorLink is not about me, I think this should be accounted for and fully supported.

@kzu kzu added the enhancement New feature or request label Aug 15, 2023
@psimsa
Copy link

psimsa commented Aug 17, 2023

I'm pretty sure that those benefiting from OSS the most are in fact organizations rather than individual developers, at least in terms of monetary gain. If I have to write my own libraries for work instead of using OSS, I get paid the same but the company wastes my productivity because I write Moq instead of solving business problems. I don't personally benefit much from using OSS at work, the company does because I don't have to reinvent the wheel and the company doesn't have to pay for it - to you or to me.

Sure, there are independent devs who actually gain money directly from using OSS. But I doubt they are in majority.

@kzu
Copy link
Member Author

kzu commented Aug 20, 2023

Well, as individuals and developers earning what's probably the highest salary tier even for juniors, we can't really say we can't afford to help other fellow devs which one day might be us too. Especially when sponsorships can be really really affordable (i.e. can even start at $1). Dunno...

@RyuuTDF
Copy link

RyuuTDF commented Aug 21, 2023

Well, as individuals and developers earning what's probably the highest salary tier even for juniors, we can't really say we can't afford to help other fellow devs which one day might be us too. Especially when sponsorships can be really really affordable (i.e. can even start at $1). Dunno...

Hi @kzu,
I've been following this for the past 2 weeks for 'my Corporate Overlords' and I've logged into my personal Github to post my suggestions for you about the org-wide point. As you've stated, the view you have is of a freelance developer, who has not been corporate for quite a while. From your other comments you seem to have contacts at various places like Microsoft and Amazon. My suggestion would be to talk to developers from those places, to get the view of the corporate developer and maybe get shown ways how other packages have already handled this. Implementing this is a big thing as @ewrogers pointed out here: https://github.com/moq/moq/issues/1396#issuecomment-1681030033 , corporate developers will be your majority type of users for any big package.

To illustrate, let me try to give you an example of a corporate viewpoint.
We shall take a company with 250 developers. Let's say every team uses only 1 SponsorLink-package, so the company would have to pay $250 a month. Now keep in mind that this does NOT have to be the same SponsorLink-package, so that money could be going to a bunch of different projects.

This is were a blind spot in your freelance view comes in: Administrative Overhead.
a. In Europe & North America, with the exception of maybe specialized tools for a few employees, the company pays for the tools. Period, it does not matter if it is affordable. It's just way too much hassle for a company to deal with the Administrative Overhead of having all employees send in an invoice every month for each of their tools. This also means the developers have only an advisory role in what tooling is being used.
b. Somebody is going to have to keep track who has to sponsor what, depending on what team they are in.
Developer's time is very expensive, they have to deliver value. Administrative employees are way cheaper, so they will have to spend time on this every month. So say that costs them $50 dollar a month.

So the company is now spending $300 a month. For those $300 they have the following options:

  1. The company keeps using the SponsorLink-package. They'll have to spend time and money on extra administration for no additional benefit.
  2. See if there is a package with corporate licensing that does the same thing. They'll have to pay the cost of the 'Migration Fee', but after that there is very low cost of administration and they might get things like SLAs, Premium Support, X years guaranteed updates

Unless you manage to minimize the Administrative Overhead-aspect, for example using something based off of @jelkevanhoorn's idea in #54 , to get it down to say only $5 a month instead of $50, any company will choose option 2. Simply because: 'If I do have to pay, I am going to get the best value for my money.' and the 'Overlords' of the big majority of your users will force them to move away from any package using SponsorLink.

However, if it is $255 versus the $300, that $45 a month plus the 'Migration Fee' might convince them to stay on the SponsorLink-using package.

Of course in this example there were only 250 developers. Multiply the amount of developers or SponsorLink-packages by 5 or 10 and all the numbers in this example go up very rapidly.

@kzu
Copy link
Member Author

kzu commented Aug 21, 2023

Thanks for the write-up @RyuuTDF!

My view is not that of a freelancer. I worked my whole career in .NET (20+ years) in the corporate world (first as a vendor, then as a partner, then as an employee, a large chunk of it, with Microsoft). I understand all your points.

One key aspect of OSS that changed in those 20+ years, is that nowadays an OSS alternative has the upper hand in terms of Administrative Overhead. In Microsoft at least, getting the green light to use OSS is (was at least until I left a short 3 years ago) frictionless and virtually free (no admin costs that I could notice, it's mostly automated). All other options (regardless of licensing terms) are in a far worse position. Hence my desire to keep that part intact.

The basic assumption you make in your whole argument about administrative overhead is that the company pays for the tools. And since tools would still be OSS, there would be nothing to pay. That said, developers in the corporate world are NOT ignorant about the importance of giving back to a community. For example, Microsoft has a large Give campaign where they match employee donations. It's a really great idea and also quite effective. So, I challenge the assumption that developers, once they understand the predicament their fellow OSS developers are in, wouldn't be sympathetic and actively donate. Sure, it might require raising awareness on the current status quo issues and helping them empathize with what one day could be their own situation (if they find a passion project that ends up being successful).

So, my goal is to raise awareness, and have folks realize that I'll expense my company for these $2 or $50 is a ridiculous thing to do when you earn enough to help all of those devs from your own pocket. AND, perhaps what you WOULD do instead, is raise awareness of your employer so that HE can match-up donations in turn.

Yeah, it might be wishful thinking, I'm aware of that. But I'm not throwing the towel just yet.

@kzu
Copy link
Member Author

kzu commented Aug 30, 2023

Done on https://github.com/devlooped/gh-sponsors/blob/main/src/Commands/SyncCommand.cs#L67-L129 which collects user's orgs, their sponsorships and associates them with the org's verified domain.

@kzu kzu closed this as completed Aug 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants