David Chisnall (*Now with 50% more sarcasm!*)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.
✧✦Catherine✦✧@david_chisnall ... though even finished projects, much like buildings or gardens, will require some small amount of ongoing maintenance.
James Widman@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.
Tim Ward ⭐🇪🇺🔶 #FBPE@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
ananas@david_chisnall To add to this: It's OK if your F/OSS doesn't have significant market share. Once you have enough users that your project is guaranteed to stay alive, and you are happy with it, you don't really get much from the extra market share. You have won, you don't need to work for larger market share, there are no shareholders to please with tbat.
Anders Lund@david_chisnall
((maintenance))
((maintenance))
Owl Eyes@david_chisnall You're right, but then there's also the #Debian/flatpak/PyPI/appImage packaging of said software, for both AMD64 and ARM64
Jess Robinson@d1 not necessarily the authors problem
David Cantrell 🏏@d1 @david_chisnall if someone wants to make a flatsnap of my code then I suppose they can, but I shall judge them for their poor choices.
Jef@david_chisnall ok but what am I going to do with all these ideas stuck in my head now...?!
Entire worlds of possibilities sitting there, doing nothing - not enough lifetimes.
Entire worlds of possibilities sitting there, doing nothing - not enough lifetimes.
@david_chisnall a lot of people use the "last update" metric to choose an app. They think: "This software has not been updated for a while; it may have been abandoned"
@parapiglia And, as the maintainer of a F/OSS project, your obligation to those people is...?
@david_chisnall Absolutely no one! Users don't understand that a project no longer has updates because development is stable, not necessarily because it has been abandoned. At every juncture, those who maintain a project can have a clear conscience: it's free code, if anyone is interested, they can fork it.
Translated with DeepL (https://dee.pl/apps)
Morten@david_chisnall True. I honestly think projects are forked too rarely. Someone made something nice. Great. Someone forks it, does something else nice. Great. You don't have to merge that, you can just point out the forks you like in the readme.
@drgroftehauge Absolutely! If your requirements are different to mine, but you can build on top of my work, great! I've saved you work, you owe me nothing (though if you want to buy me a beer sometime, I probably wouldn't say no). If you find bugs in common code and want to share the fixes, that's very nice of you, thank you. If your requirements are very close to mine, let's work together and build something that's better for both of us.
Ni
Glen T, heated, not stirred@david_chisnall Having been through Y2K I suggest that people either charge for their software stiffly enough to afford lawyers and insurance and all other overheads of business, or don't charge a cent and use a GPL licence.
Don't get caught in the middle ground of having to offer 2038-compliance without revenue for the work and insurance for indemnification.
If it is a hobby or scratching an itch, do be able to tell people seeking such compliance that there was never any contract, the license terms were always 'no warranty' and still are.
@david_chisnall we all wish, but every year there is marketing-driven Google Hurricane season in the Android forecast
Florian Schmidt@david_chisnall
It's striking how many comments ignore your point and view it from a "commercial developer" perspective. I admit that it's sometime hard to step outside it, but I too can remember the Open Source community to be about empowering people, not running the economy for free.
Maybe it was a mistake to call those "projects" in the first place. You have no due date, no staff and no budget, so it's not a "project" at all! Nobody would ask you to fix your "hobby" for them...
It's striking how many comments ignore your point and view it from a "commercial developer" perspective. I admit that it's sometime hard to step outside it, but I too can remember the Open Source community to be about empowering people, not running the economy for free.
Maybe it was a mistake to call those "projects" in the first place. You have no due date, no staff and no budget, so it's not a "project" at all! Nobody would ask you to fix your "hobby" for them...
Steven G. Harms100% agree…
But I do think some general guides are very considerate. “Here’s how to think about this thing, here are the big flows to startup; here’s something that never sat right with me…”
Because the void of bad documentation or cognitive tax is readily filled by ai (I’d argue that this has been a huge sales case to the tech.)