2023/08/on-moq-and-our-part-in-the-oss-sustainability-social-contract/

[giscus[bot]]

2023/08/on-moq-and-our-part-in-the-oss-sustainability-social-contract/

Let they who are without OSS sin cast the first stone. Let’s look inward on OSS sustainability issues.

https://seankilleen.com/2023/08/on-moq-and-our-part-in-the-oss-sustainability-social-contract/

[Numilani]

I agree that some things need to change regarding funding of OSS projects. The lack of monetization support from major players like Github, as well as the lack of underlying infrastructure from package managers to restrict access, certainly leaves developers somewhat limited in their capacity to monetize their works.

That said... I think that calling SponsorLink's approach of data exfiltration "not well thought through technically" is a gross understatement. Even ignoring the failing builds due to poor implementation (as that's probably just a bug), adding an obfuscated dependency that scrapes user information and transmits it to a third party, both without consent and without informing the user, is far beyond the pale with regards to what's acceptable, from any developer.

[SeanKilleen]

transmits it to a third party, both without consent and without informing the user, is far beyond the pale with regards to what's acceptable, from any developer.

I think it's easy/simple to think that way. But I've seen a lot of code in the real world across many many clients.

I think the approach overall, and the implementation, was a mistake. I didn't focus on it here because that's not the point I'm trying to make. I want to focus on building an ecosystem where 1) how to sustain this project wouldn't have been a question and 2) there would have been other avenues once monetization became a concern.

[jeme]

The lack of monetization support from major players like Github...

Wait, you don't think that providing a completely free-of-charge service where all of us can host, share and develop our OSS projects is enough?, you think players like Github (Microsoft now) needs to push funds into our projects as well?

In seriousness though, If Microsoft as a whole contributes enough can be debatable, but they are surely been heading in the right direction as of late, and yes, they explore ways to monetize as well - and lately they even explored some maybe less ethical approaches, well indented, still though. - But Github has, for better or worse, become a foundational contribution to OSS IMO.

Anyways, that is IMO also part of the problem here, there is way too much focus on $$ contributions (sponsors) - completely overlooking that within OSS, there is many ways to contribute. That is not saying that it would not be needed to focus on how we can improve the situation and help feed OSS developers, but if one focuses solely on $$ as a worthy contribution, and the rest just gets the bat, I don't feel like it belongs in the OSS family anymore.

[sasakrsmanovic]

Very well written.

Coming more from the marketing side, I'd say that the maintainer could have done better in communications. Sure, there was a blog post outlining what he intended to do. But with these radical changes, and knowing the developer sensibility, communications should have been countdown-style with lots of blogs and tweets blasted out, as well as multiple GitHub discussion communications started on it. In essence - over communicate.

It is possible that even over communication would not have helped but it would have covered more bases and likely caused more support for the move.

[SeanKilleen]

Absolutely. I think the maintainer was trying something. I don't think there was a well formed strategy around "how can I get people to sponsor?" and instead it was "nobody is sponsoring so I might as well do what I want and try this."

If there was more strategy around it, absolutely -- better communication, across multiple media, happening more frequently, would have been important.

In thinking about how to help other maintainers navigate this, I'm realizing that communications templates and guidance might go a long way to helping the whole community. Including that in some of my ideas that I want to flesh out soon.

[ristogod]

Spin it how you will; NO large company, concerned about security, will trust beyond this point. Most large companies already employ irrational and paranoid practices and policies to stave off security related incidents. Moq has gone Bud Light.

[SeanKilleen]

Oh no! The same large companies that never offered any support but we're content to take from this project for years, and who probably leech off of the entire ecosystem, will no longer use this library?

🤷‍♂️

The only sad thing to me there is that, due to the inability of companies to proactively contribute to the pieces of their supply chain despite it being linked to their business, they're going to spend failure demand dollars ripping it out. So it's a lose/lose when it could have been a win/win.

[ristogod]

Yes, those companies. I'm not saying they shouldn't support projects. They don't care, the developers do. And the company doesn't care that the developers care. If the company doesn't have to pay, they won't. So it's the developers that pay, either directly or in their jobs.

[SeanKilleen]

I refuse to accept that the company mentality can't be changed. I've long had some ideas in that space and I think it's about time I put some effort into getting them out there to get the ball rolling. Thanks for the extra encouragement to do that. :)

[egil]

Thanks for writing this. I agree with everything here.

Regarding a better OSS ecosystem, my thinking has been for a while that Microsoft is in an exceptionally unique position to take the lead here. In the .NET and JavaScript ecosystem, they are the owners of most of the tool chain, i.e.: GitHub, Azure DevOps, NPM, NuGet, Visual Studio, VSCode.

They could essentially track what packages/libraries organizations use when building in CI pipelines. This can enable multiple different scenarios, e.g., "library stores", automatic sponsorships. E.g., an organization can set up a monthly OSS budget on GitHub and each month the OSS they are depending in their build pipelines automatically get their cut of the cake (budget).

I think many organizations wants to give back, it can even be a positive branding thing for them (see how much we give back to OSS, aren't we awesome), but it is not an easy plug-n-play-enter-credit-card-info-here and everything just works thing, so it doesn't happen.

Ping me if you want to brainstorm further :)

[y2k4life]

And maybe Microsoft does this via the .NET Foundation. They need to step up to the plate with sponsorship money and get the ball rolling. Enough talk we know what this issue is we need action. That foundation seems to be all talk and I think they need to put their money where their mouth is. After almost 10 years I still don't know what the foundation has accomplished if anything. I don't know why but the Blender Foundation just popped into my head.

[SeanKilleen]

I appreciate this take, and at one time I felt that way too. However after a lot of history/experience I'm not sure if the incentives align now. Imagine that MS creates that ecosystem and OSS devs adopt it. This costs paying Microsoft customers money, and they'd be mad about it toward Microsoft. So it'd take a insignificant amount of political capital, aligned across several MS teams who also may not be aligned.

I think if we want community, the solution has to come from the community.

[egil]

I have actually talked about something like this before, see the Twitter thread linked here. I do think you are right Sean. that it might not be something Microsoft as a whole is able to pull off though. It would have to be directive coming down from a top C-level type.

https://twitter.com/egilhansen/status/1629053655688306688

[hilari0n]

Thanks for your interesting and well balanced article. Mine will most certainly not be like that, with my lack of experience. :)

As for the "OSS contract", I think this is not its full picture.
First, the dark-side addition:
The harsh part of this reality is that the fact that the OSS consumers "abuse" OSS is the result of the "OSS contract" being fully voluntary. When you contribute to OSS, you can hope to be rewarded for it, but you can't expect it. (And yes, I write "you", not "we", because unfortunately I'm not an active OSS contributor yet.) The freedom of the contributor fortunately allows you to determine your scope of contribution on your own, including the freedom to back out from contribution to OSS whenever you see fit, also without being punished for it. If the "OSS contract" would mean, that the OSS consumers should be rewarding the contributors, then it would be expected for the contract to be balanced with the expectation of the OSS contributors to continue contributing (i.e. having their option to back out somehow limited and their scope of contribution somehow defined).
And for the - hopefully - bright-side addition:
Although the "OSS contract" does not guarantee anything specific for the contributors, the reality of it also means, that by contributing to OSS, you can and you do also benefit from OSS. (And here I should probably write "we", as I most certainly do benefit from OSS.) Starting from directly, by consuming OSS products in daily use or incorporating them in our creations, but also indirectly, by being able to consume better third-party products, quality of which benefits from relying on OSS, (instead of having to create or buy every bit of the product). The contribution of the OSS community led to results like e.g. .Net being published as OSS. So it's rather hard to imagine any OSS contributor not being an OSS consumer. From this point of view, the debt, we build up by consuming OSS, we should probably mainly be paying up by contributing to OSS.
But yes, as having OSS available does not pay our bills, nor does it put bread on our tables, the subject of funding OSS contributors is most definitely still on the table. (Although we can't forget about multitude of OSS contributors who don't ask for funding and they fund their part-time OSS work by their own part-time or full-time "commercial" job.)

As for how the situation of the OSS contributors could be improved, I do think, that your suggestion on actions in the OSS platforms is probably the best way to go (at least for now). Although I doubt it can be as easy as global automatic sponsorship (at least not at first).
For a case like with Moq, my first choice would be to act where the consumption of it happens, i.e. in NuGet.org. And there are precedents/examples on how it could be done, e.g. npm will inform you about a possibility to fund packages (or rather their creators), based on the information contained in the packages. Although this method may not be enough, it should be relatively easy to implement first step and it requires only one party to gradually implement it (as Microsoft is the source of the NuGet package specification, to introduce a standardized way to ask for funding in there, and they are the owner of the NuGet.org service, to show the information on the site, and they are the author of the tools consuming the NuGet packages, i.e. the .Net SDK and NuGet CLI, to be able to alters the tools to show this information, and they are the author of the two widely used IDE-s for .Net, i.e. Visual Studio and Visual Studio Code, to do the same in there).
The next one could happen on the more business side of the ecosystem, still within the same one party, i.e. in the Microsoft's Azure DevOps (ADO), where many commercial consumers work and where the money already flows in and could - by easy opt-in switches - be contributed to the OSS consumed in the ADO-hosted development.

[tknarr]

I find myself annoyed at the situation (but not the developer) because I'm caught between a rock and a hard place. On the one hand, this addition is going to be a big issue from a security standpoint where I work not because of the sponsorship issue but because of the unapproved-connection-to-outside-resources bit. From what I can see of it it'll make those connections even if I sponsored. Once the security folks get wind of something like that it's very hard to convince them to reverse course.

On the other hand, I know exactly where the developer's coming from and fully agree with what he wants: financial support at least somewhat equal to the value his software is providing people who can afford to give such support. I've tried to convince employers to chip in some money to the developers of OSS software that what we're developing depends on, but when it gets up to a certain level the accountants take over and ask why they should pay money for something they can use without paying. The idea of thinking of OSS software the same way they think of commercial software that commands huge license fees to use just... draws a blank. As a result, we end up in these situations more and more often.

[SeanKilleen]

I appreciate this comment. I agree that the implementation and overall approach causes problems. I don't envy anyone having to deal with them. And I also appreciate you trying to get your company to contribute. I think that's always the challenge here -- avoiding getting to this point requires proactive conscious consumption and businesses aren't primed to do that unless they're forced to

I've long had an idea that we need tooling to easily make it clear to our organizations which libraries help us out and what they need to continue. I've started on some tooling along these lines already. I may respond to this in the future to get your take on some of that tooling.

[jaredthirsk]

Sean, what if you thought even bigger, and there was a tool for all of society to find underfunded charities and social good programs?
(I imagine a more utopian altruistic world where worthy charities would be noticed sooner, and we'd be less reliant upon government funding social programs and public good programs for every segment of society by forceful taxation.)

[gortok]

First off, thank you for writing about this.

.NET is what we make it.

If we ignore the bad and don't write about the good, it's impossible to make change in the world.

If we throw up our hands and say, "the problem is too big to solve", then it's impossible to make change in the world.

If we hold our community accountable, and work to improve the conditions that got us in this mess, then it's possible we'll change our world.

You bring up great points regarding sustainability; but to borrow from the climate change mess, while I should eat less meat, the emphasis on individual responsibilty over systemic change ignores that it doesn't matter if I go vegan tomorrow, the corporations will still produce far more carbon than I have ever saved by going vegan. Heck, just one executive on one private jet will out-spend me in carbon production.

So let's look at the system. This is where I believe the .NET Foundation is uniquely positioned to help. OSS has a sustainability crisis, and a lot of corporations have seen it as a source of free IP and labor for years. We need an interest group to stand up and work to change that -- to use its position to get its member organizations (or even corporate interests) to pay for the software they use.

They have hamstrung themselves by requiring permissive OSI licenses; and this just furthers the problem: Corporations won't pay for software unless they have to; and permissive licenses mean they don't have to. Until we get dual-licensing, a framework for businesses to pay for the software that powers their enterprise, and a will from our own community to enact this change, it doesn't matter if I pay a dollar to this project or $100, and focusing on my responsibility to pay over the corporations that make millions and billions of dollars while relying on Moq and other open source projects obfuscates the issue.

Our single greatest threat to OSS is burnout and the continued pillaging of OSS efforts by corporations. Until we address that issue head-on, all the other OSS problems pale in comparison.

[SeanKilleen]

In general, I agree. Where we differ is on the role of DNF in it.

Should DNF play a role in that? Ideally yes. But in seeing how things have operated the past few years, I've come to see DNF and Microsoft as being necessarily biased toward the interests of the OSS consumer. I think it's inevitable and can't even blame them; there are more consumers than producers of OSS and MS needs to keep their customers happy. And because of the gravitational pull of MS (and the DNF by dotted line / extension), the ecosystem looks to them for arbitration or policing, which isn't a healthy dynamic IMO. I think that gravitational pull is leftover from the older days and the interia is there when MS/DNF doesn't actively encourage it.

So, I think an organization needs to come into being that provides this balance explicitly. I have some ideas on what that should look like and have for a while. Time for me to start putting it out there.

[SeanKilleen]

Also, thank you as well! I appreciate you continually putting your thoughts out there. I'm trying to get back into the habit.

[adryzz]

+1 for this post.

I agree we should have a way as a community to be able to ask for help when needed, and that announcements in the repository simply aren't enough, although the mantainer has no better way.

This is the same thing as pyca/cryptography all over again, (except for the privacy stuff) where they posted 6 months prior that they were switching to a rust backend and that build machines needed a rust toolchain installed, and everyone got mad the moment their CI builds failed, complaining that they hadn't been warned, when the mantainer had no way of warning downstream consumers other than opening an issue in the repository.

This is a broader issue with transitive dependencies, and especially libraries buried deep in the depencency graph, where few people know your work yet it is critical to everyone's infrastructure, and i hope we find a way to mitigate this issue moving forward.

[jaredthirsk]

It's important that in addition to an OSS Sustainability Social Contract, there is an OSS Good Faith Social Contract. The gist is "do no harm", "don't be underhanded," "be transparent."

I believe both need to be addressed separately. If people freeload on OSS, you can't introduce security risks, watch them cry foul, then blame them for being greedy freeloaders as a way to try to even it out. That's victim blaming. Trust has to be restored, or everything else is a nonstarter, at least as far as this library maintainer is concerned.

I wrote a detailed github comment addressing the Good Faith issues in isolation, many of which the Moq maintainer has already addressed: https://github.com/moq/moq/issues/1374#issuecomment-1676542719

[SeanKilleen]

I think this is a reasonable position even if I differ on some details, and I appreciate the way you summed things up on the GitHub thread, too -- thanks for that!

While I think it's good to consider separately and distinctly (as the clarity of your points underscores), I think that in addition the natural tension between them is good to consider as well. E.g. oftentimes users heap a lot of additional items into their perception of the "good faith" contract you mention, putting more burden on maintainers while simultaneously not fulfilling any part of the social contract.

This has reignited a desire in me to lay this all out in greater detail. I've been working on some impact mapping around this for a while and as a result of this discussion I've committed to getting that out in public for discussion & to get some things rolling that might benefit all sides in the discussion.

[anantumbarkar]

Sean, Good Initiative.

[doublej42]

My issue is corporate budgets. I'd love to have my company donate to the libraries we use but convincing management to give $10 a month to a project that is "free" just does not happen. We don't have any unapproved expenses for an OSS fund would have to go to our board of directors and I would love tips on how to make that work.

[tknarr]

Phrase it in terms the directors understand: dollars. What's the dollar cost of getting licenses for the commercial replacements for all those libraries vs. supporting the F/OSS products (or developing your own replacement if there's no commercial equivalents). Events like the Terraform license change or Moq can be used to make the point that this isn't a hypothetical, it's already happening.

I think it'd be a big wake-up call to the directors too if they saw a list of all the F/OSS libraries that the company's software absolutely depends on and for which there aren't any commercial replacements because all the commercial libraries use those same F/OSS components too. Remember the havoc leftpad created.