Missing formatting and introduction
Democracy and consensus in FLOSS projects
Introduction here
One finding that was very consistent between all developers in Jellyfin from the interviews was the idea that FLOSS and decision making therein is wholly democratic. One developer said that the actual changes are decided by a “majority rules’’ mindset. He said that it is “(…) completely democratic. Majority wins. Although we always try to discuss every opinion given so many times that, if a minority thought of something but it was convincing enough for the majority, that minority’s opinion ends up implementing.” (Interview #5, Jellyfin). He noted provided an in depth explanation for how they approach these decisions and said the following:
“When there are different opinions among us, we generally follow two mantras:
A) How do alternatives/similar software accomplish this? […] or B) The contributor who is proposing the changes is the one who choses how to do it. This mostly happens when we see that Netflix, Spotify, Amazon Prime, Plex, etc. Do the same thing in a completely different way and there are a lot of different opinions among us” (Interview #5, Jellyfin)
These quotes support the idea that any external party can influence the project in any way independent given the argument is strong enough. However, it would seem that rather than a true democracy there is some merit involved in the decision making as it happens. One developer called the project a “(…) sort of a “do-ocracy”, as we call it. Meaning that usually, if you really want something done, we expect you to open a pull request for it.” (Interview #1, Jellyfin). This would then inherently limit non-code contributions as they, as a currency in the project, do not hold the same value as code contributions. At the same time however, project management contributions have already shown to be accepted in the project which suggests that other types of contribution do exist. Other contributors did however confirm that code is likely the most understood and valued type of contribution. One developer argued that “if you want a feature, don’t just be like, ‘Oh, excuse me. Would you mind doing this?’ Go out and code it and, you know, learn what you need to learn to implement it” (Interview #6, Jellyfin). In other words, it would seem that non-code contributions are accepted in FLOSS projects. This could include translation work, helping new users or otherwise. Yet, the consideration that code itself is the main type of contribution needed to advance the project might be a detriment to designers and might also be in conflict with the “if you want it, make it” mantra that is present in the FLOSS projects. This is also supported by the fact the developers still argue that the project direction is still mostly influenced by internal members, as they have the best understanding of the underlying code and what is possible (Interview #8, #7). Also, the internal project members’ Matrix channels are also something that is still a factor and to what extent the discussion there shapes the project is not immediately clear. To summarize, it seems that considering the foundation for contributions is important in these projects especially when receiving non-code contributions. Discussions are necessary for project members to agree on how this bias is handled, and designers need to be wary of how they make suggestions and argue for changes as their contribution will be met with the “if you want it, make it” mantra.
Discuss
Summary
*