Over the past few days a series of miscommunications between @Gargron, the @MastodonEngineering team, and myself occurred. These did push me to a point of outrage, leading to the original version of this post.
I'm happy to continue spending the time, money, and effort contributing to #Mastodon, and wish to work with the team and Eugen to find better ways to work together.
The team is super busy, need more funding & staff to achieve the full potential.
Let's work on working better together.
@thisismissem @Gargron There is a long history of features not arriving to Mastodon because grandmaster doesn't feel like it 
I would be furious if I was a contributor, so I guess I'm happy I am not 
@gytisrepecka @thisismissem @Gargron
Well this is how BDFL works. I don't really have a problem with that. Someone has to make the decision. In this case it's Eugen.
If people don't like the decisions they're welcome to complain and ask others to complain as well, but at the end of the day their only recourse is to click the fork button.
@stinerman I have a serious problem with the very idea of a BDFL in the context of a project that important for so many underserved, at-risk communities as Mastodon-the-software.
@rysiek @stinerman @gytisrepecka @thisismissem @Gargron
I wanted to say that ISTM that having a BDFL is correlated with having complex interfaces where software assumes everything else will adapt to itself. Alas, when I tried to come up with examples apart from positive examples (Mastodon, systemd, Linux), I've started to doubt the conclusion, given counterexamples such as curl or lots of small projects where this is harder to evaluate (e.g. s6-supervise, honk from the same topical areas as the ones above).
My weakly held opinion is that a good way of reducing the fraction of software people use that has BDFLs is to strive to get more interoperability on a more granular level. I wonder what you think about it.
