"Be conservative in what you do, be liberal in what you accept from others."
Terrible advice. Far better is:
"Rigidly define what you do and rigidly define what you accept from others."
"Be conservative in what you do, be liberal in what you accept from others."
Terrible advice. Far better is:
"Rigidly define what you do and rigidly define what you accept from others."
The point is that, in the real world, there are subtle variations outside of your control and de facto standards arise independently and have slight differences before official standardization can occur because of the need to ship product. Attempting to stomp your foot to demand others conform to your way is unrealistic, unreasonable, and childish. Utility is had in working-around quirky differences for maximum practical compatibility while persuasively encouraging projects with minor incompatibilities to adopt conforming behavior.
I didn't interpret it that way. Compatibility can be a great vector for attacks.
It works much better than on paper designs with rigid u I/o.
Then, once you've done that, recognise that what comes in will not match what you said and you can either have software that doesn't do what the users need and want it to do, or software that accepts input that doesn't quite match requirements.