I also had similar interactions, but I'm not sure of the outcome, because I don't know how much it aligned with the project's roadmap.
And this is exactly where I disagree with Antirez' post.
> You are doing work for free, __they are risking their asses deploying what you wrote,___ you both care about quality.
Users of free and open source software don't risk much. They don't need to write it, they can just use it. When there are rivaling implementations for the same feature / concept, they can choose what they want to use. Or write their own implementation. Whatever is the right tradeoff of risk and timesaving for them, but timesaving will trump risk a lot and risk can be estimated through answering questions like "How established is this open source code?", "How big is the community?", "How much testing is there?", "Can I understand the code?"
If there is a bug in the OSS code one project uses and the customer notices, they can report it and someone else might even fix it. If no one does in the time they need it, they have to fork and do it by themself.
Yes, if the code is handling data and data is corrupted, that's some serious risk. By just choosing some more established persistence layer and having backups, this can probably be mitigated. If your data is important, maybe don't run the latest version but wait until bugfixes are released.
So I would urge developers who opensource their code to establish what their users can expect.
If you add any dependency to your project, you Am are taking a risk. It's partially mitigated by open source because you can make downstream changes, but you would be better off writing from scratch many times if you know ahead of time the project will be abandoned.
Sorry, I don't get it. I agree that there is a risk, but the risk is to need to do work at an unpleasant time you couldn't plan for as much as you wanted. "Risking your ass" risk is risk over which you could get fired.
Let's use an example: years ago someone built something in Python 2.6 and added some library because it provided functionality you needed. Now you are in charge and need to upgrade to Python 3.7 because of $REASONS and the library isn't compatible nor maintained.
How is this different from having written the library by yourself? You'll still need to do the transition. And yes, it probably would have been better if someone else did this for you or you knew before, but so is life. Years ago someone made a decision to postpone writing it from scratch and you inherited this somehow.
There is a serious risk it will come like this, but this is not "you risk your ass" risk. No one will get fired over something like this.
If someone is stupid enough to accept changes from upstream without reviews and an attacker added a backdoor to $AUTHENTICATION_LIB and you download version 0.9.1_hacked without checking if this is a legit update, that might be "risking your ass" risk. And someone might get fired for it. But probably is't.
And this is exactly where I disagree with Antirez' post.
> You are doing work for free, __they are risking their asses deploying what you wrote,___ you both care about quality.
Users of free and open source software don't risk much. They don't need to write it, they can just use it. When there are rivaling implementations for the same feature / concept, they can choose what they want to use. Or write their own implementation. Whatever is the right tradeoff of risk and timesaving for them, but timesaving will trump risk a lot and risk can be estimated through answering questions like "How established is this open source code?", "How big is the community?", "How much testing is there?", "Can I understand the code?"
If there is a bug in the OSS code one project uses and the customer notices, they can report it and someone else might even fix it. If no one does in the time they need it, they have to fork and do it by themself.
Yes, if the code is handling data and data is corrupted, that's some serious risk. By just choosing some more established persistence layer and having backups, this can probably be mitigated. If your data is important, maybe don't run the latest version but wait until bugfixes are released.
So I would urge developers who opensource their code to establish what their users can expect.