From a user point of view, there are many features that Pleroma has that Mastodon does not. Pleroma allows the upload of many file types that are not supported in Mastodon. Pleroma allows you to make hyperlinks in your posts and fully supports Markdown and a limited set of HTML tags and also some BBCode. These are some of the first features I can think of off the top of my head.
Pleroma is community-run, meaning that a decision isn’t taken by one person
Pleroma is very flexible, a bit too much sometimes from a developer/maintainer point of view but it’s really nice to have from an admin point of view
Pleroma is actually using ActivityStreams in it’s database so it is future-proof and can evolve to non-microblogging (I actually quite want to replace peertube’s backend with pleroma after having tried to host a peertube instance), Mastodon is still storing it in a typical GnuSocial/OStatus way.
Mastodon has a very poor documentation, most of the API endpoints are lightly described in their Pull Requests, and for reimplementing the API in pleroma I basically always reversed it and then looked at the bits of documentation (when it was present…) to confirm my ideas
Pleroma is/was done mostly from fediverse users that came years before Mastodon, so it isn’t a mastodon clone but is quite related (a lot is taken from classic Twitter, Mastodon is from modern twitter).
Also this is quite offtopic but I think there must be more experimental implementations in the fediverse, I think pleroma has quite done it’s experimentations, stuff added will be explored but I feel like there is a lot of things we can’t do and sadly a lot of new implementations are clones.
Pleroma is community-run, meaning that a decision isn’t taken by one person
Personally I think, this is very important. Also based on personal experiences.
As an implementor I would like to get some details how you do this internally.
Is there an election of people taking the decisions?
Any other hints how to ensure good governance?
Also this is quite offtopic but I think there must be more experimental implementations in the fediverse
Full Ack. Feeling that this is totally ontopic …
We’re pretty much doing it by the usual lazy consensus of contributors being organised via public chatroom + ticket-tracker.
And as a rule of thumb our repo changes should be reviewed by another core-dev unless it’s a minor change, helped by not having direct commits to the main branches (develop and stable).
Maybe not the greatest in terms of governance but I think we’d rather not have extraneous bureaucracy and I think it’s quite robust.