Remember: It's okay for your F/OSS project to be finished. You don't have shareholders who need you to grow every year. You don't have customers who need to be persuaded to buy a subscription or a new version every year by marketing-driven features. If it solves the problem that you created it to solve, you have won. You now have some software that solves the problem that you had. You are allowed to stop now.
@david_chisnall ... though even finished projects, much like buildings or gardens, will require some small amount of ongoing maintenance.
@whitequark @david_chisnall like when you update the OS and something breaks, or you port it to a new architecture and something breaks...
@JamesWidman @david_chisnall pretty much, yeah. I've seen people argue that this should never happen because other people have an obligation to ensure total, perfect compatibility and that's just nonsense; you built it, you keep maintaining it or it breaks.
@whitequark @JamesWidman @david_chisnall Or there's a CVE against one of the dependencies you're using. If you're not on that continuous update treadmill then there's a range of industries which can't use your project.

@TimWardCam @whitequark @JamesWidman

A few questions there though:

  • Are you using dependencies in such a way that bugs in them could be security vulnerabilities in your use? For example, a vulnerability in a PNG decoder matters a lot for a web browser, but not at all for something rendering bundled PNGs as part of a UI where anyone who could inject a PNG containing an exploit could also just modify the binary.
  • Do you need to do anything for the upgrade? Most of the libraries I maintain aim for close to 100% backwards compatibility. Distributors can bump the shared library revision, downstream projects don't need to. I consider that good manners to my ecosystems.
  • Did you write the code so that regulated industries could use it? If you wrote it to solve a particular problem for you, the fact that it's useful to people in a specific industry is a side benefit, and mostly a benefit to them. They're welcome to upstream the fixes that solve their problems if they don't add much work for you.

@david_chisnall @whitequark @JamesWidman

(1) Tends not to matter at least for some customers - if the scanner finds it you gotta fix it, they can't be arsed with the exception process to verify your claim that it's not exploitable.

(2) Most, yes, but not all Try as an extreme example the Prometheus 0.16.0 -> 1.x upgrade. (Yes I know 0.16.0 is not currently broken, but one day it will be.)

(3) Indeed so. If you're not targeting regulated industries (eg your project is for home use) you don't have this worry.

@TimWardCam @whitequark @JamesWidman

Tends not to matter at least for some customers

Where do these customers come from? How much are they paying you? What agreement do you have to provide a service to them?

I don't think I have any for most of the F/OSS projects I maintain. I'm releasing things that I find useful. If other people find them useful, they can use them without having to reimplement them. If they want to upstream things rather than having to make a fork, and I find their fixes improve the project, I'll take them. If they want to fork and improve the project in ways I disagree with, that's great, I explicitly gave them the freedom to do that!

But they're not my customers unless they're paying me.

If I have customers, then my obligations are driven by my customers' requirements (or, at least, by my ability to retain my customers). But that's not the default situation for F/OSS projects.

@david_chisnall @whitequark @JamesWidman The scenario is a commercial company selling a commercial product to customers in a regulated industry with serious requirements about security issues.

In choosing which F/OSS dependencies they're allowed to make use of the company must, amongst other things, evaluate the F/OSS project's policy re addressing CVEs in its own included dependencies.

If such usage is not a target of your F/OSS project then, sure, you don't have to worry about such things.

@JamesWidman @whitequark for Android apps it is particularly bad, your app will just stop working after a few years and not allowed anymore in the store because so many api changes by Google