Clear value proposition, or infinitely customisable?
Slick or austere?
Strictly implementing one vision and set of goals, or adding all kinds of features that different people request or contribute?
Extensive user documented, or code and settings panels (or config files) as documentation?
Historically, the former tends to be proprietary apps, while the latter then to be free software projects that clone the intitial vison/functionality, and then evolve mostly by adding features. The complexity goes up and the UX goes down.
These days we have free software products (eg. Mastodon and Pixelfed) and free software tools (eg. Pleroma).
The question is how do you preserve the user-freedom advantages of tools while gaining the user traction and usability of products?
I suggest one approach could be having a generic backend tool, with standard protocol-based federation and an open API that enables frontend app designers/developers to create slick products that implement all kind of different visions and use cases.
@mayel I think the approach you describe is the best approach.
I prefer tools, but only if they have good products built on them. Not much point me having a fancy hammer and nail without a picture hook and a picture to put up with them.
I'm on a big Emacs kick lately, doing more and more in it. It ticks all of the latter of the questions in the list. I might not have gotten into it tho without spacemacs and org-mode adding polish to the tool below. ('slick' being a relative term here...)