> “Make software that people love” is not terribly helpful advice. I think that software needs to be empowering, allowing you to do things that you couldn't have done otherwise (or not nearly as easily). Just like the old hammer/nail analogy, we can only think of solutions within the space of tools, or the language, with which we are familiar. Software becomes painful to use when it breaks the flow, when it disrupts our train of thought. As long as we are aware of its rough edges, we tend to navigate around these on autopilot and stay in the zone. There's also the element of choice: I think that people complain about, or get frustrated with, an application primarily if they feel forced to use it, be it due to company policy, a lack of training material or onboarding, or a perceived lack of free alternatives to commercial products. This is purely anecdotal, but my impression is that people are also more accepting of flaws in a software that they paid for. Free software is often measured against commercial software, where lack of polish or features are perceived as fundamental flaws – without considering the different circumstances.