Post
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.
100% 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.)
@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...
@david_chisnall we all wish, but every year there is marketing-driven Google Hurricane season in the Android forecast
@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 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.
@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)
@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.
@david_chisnall You're right, but then there's also the #Debian/flatpak/PyPI/appImage packaging of said software, for both AMD64 and ARM64
