Do you prefer using a product or a tool?
Straightforward UX, or extensive feature-set?
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.
I hope Pleroma and http://commonspub.org can help make something like this happen.
Straightforward UX, or extensive feature-set?
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.
I hope Pleroma and http://commonspub.org can help make something like this happen.
commonspub.orgCommonsPubCommonsPub-based apps and instances can each have their own mix of functionality and user experience, to meet the needs of their users and communities - without isolating themselves in silos but rather promoting interconnections among diverse communities within the broader fediverse network.
Federated Each instance can interact with other apps that use the same protocol(s) and users can connect with any user that is part of the extended network (aka fediverse).
I think most fediverse apps would be better suited as frontend clients (or mobile apps) which can all connect to the same backend server (probably with some backend plugins or microservices to handle things like video compression).
One advantage would be having one federated identity where I can post toots, articles, photos, videos, events, educational resources, git merge requests, etc, etc, rather than having dozens of disparate identities and contact lists.
One advantage would be having one federated identity where I can post toots, articles, photos, videos, events, educational resources, git merge requests, etc, etc, rather than having dozens of disparate identities and contact lists.
@mayel yeah that was the whole point, alas