A community for discussion about open source software! Ask questions, share knowledge, share news, or post interesting stuff related to it!
⠀
Okay, I'm a decision maker overseeing some of those CICD pipelines belonging to a small corp (thankfully not the AI scrapers tho).
I don't make financial decisions, so I can't support FOSS from the corp coffers directly.
Other than caching (that we already do for security purposes), how can I limit our footprint in this?
Assess and cache your package pulls. Make sure you're not pulling unchanging data on each build. Cache partial builds, or proxy dependency-pulled packages.
I don’t make financial decisions, so I can’t support FOSS from the corp coffers directly.
Have you asked?
I have. It just goes nowhere. The number of people you need to sign off what is essentially a donation is just too high. You always hit someone who says "why do we need to do this?" and the answer is "we don't".
You need some actual benefit before most companies will actually pay money. It doesn't have to be huge though. Sometimes support is enough (as long as you don't also offer free support e.g. via GitHub issues). Phabricator did that and it seemed to work.
Open core also definitely works. My company pays for GitHub premium because we need the features - primarily merge trains.
They're very rarely going to donate out of the goodness of their hearts, and if you expect them to do that because you think they are morally obliged to then you're going to be disappointed.
You need a price. If you say, we need this infrastructure or technology and it costs x dollars, that can be justified, approved, and budgeted.
In most places I have worked, “my department uses something we get for free but they really want us to contribute what we can” would go exactly nowhere. Pushing too hard may actually even lead up a directive to switch to something less problematic, maybe even something commercial (that has a definitive price).
I guess we'll need ratelimiting
The deeper I followed the links, the better the articles became
The latter, Sonatype, article, gives some concrete examples of where it went wrong.
and concludes with some actionable suggestions.
In my opinion, if they want this to work, they need to create a shared infrastructure for delivery that they can all use. This infrastructure needs to be a paid service for users with published pricing sorted into service tiers.
The base tier can be free with no support or “community” support. This tier can have a generous but finite usage ceiling. For higher volume users, there is a cost but also some level of “support”. That is, you can call somebody if the infrastructure is not working, performance sucks, there has been a security issue, accounts need to be segmented or merged, etc. You could also charge for performance. Why not both?
This service would operate as an independent company. It would be a service provider to the “foundations” or projects that use it. This means having payroll, legal, accounts receivable, support, and operations (eg. vetting the material they host). It would be a real company (non-profit ideally). However, instead of costing money, the service would distribute some of the fees it collects back to the projects it serves. At the very least, it would make the cost of distribution zero.
The most important part of the above is that there is definitive pricing for high-volume and/or high-need consumers. This can be budgeted and funded just like any other software or service purchase.
Problem solved.