I would like to bring to attention some point of the policies and processes that I think should be challenged and reworked.
In the interest of clarity, I will go over everything point by point, and provide my arguments, divided into three sections, one for each of the documents.
Since I would like us to be more open in our discussions, I am sharing this publicly in the hopes of bringing good discussion to this.
Jellyfin Social Contract
Source: https://github.com/jellyfin/jellyfin-meta/blob/master/policies-and-procedures/jellyfin-social-contract.md
Jellyfin funds itself exclusively from donations by individual users. It does not and will not accept any sponsorship or other monetary compensation in exchange for features, priority access, support, or any other work by the community.
While this in nice in theory, it is also false, as currently formulated. We do indeed have sponsorships, notably from DigitalOcean and JetBrains.
While these are not in exchange for features, priority support or other development-related areas, they still exist and, currently, would run against this very part of the social contract.
Furthermore, I don't think funding should be part of the social contract itself, but part of a separate funding policy, similar to how Debian handles it.
Finally, limiting donations only to individual users is a bad call. While we should make clear that priority support will not be given as part of Jellyfin itself, we should still allow contributions from organizations and companies wishing to use and contribute to Jellyfin, perhaps through a Platinum/Gold/Silver/Copper sponsorship system, akin to what multiple other open source projects practice.
Jellyfin is built entirely and exclusively by volunteer contributors who donate their free time to the project. Jellyfin will not hire or pay for development or design effort for the project.
This is similarly out of place in a social contract between the project and its community, and potentially limiting to project growth.
While we shouldn't finance development directly as a project, some services might need payment of some sorts, which would run afoul of this clause.
It should, similar to the previous point, live in a separate Funding Policy, if it is to be kept.
Jellyfin builds upon other free software components such as FFmpeg, and will contribute back to that community as much as possible.
This formulation is too vague.
Something like the following would be much better:
We pledge to be good open source citizens and give back to the community
that helps build Jellyfin.
We will communicate things such as bug fixes, improvements and user
requests to the "upstream" authors of works included in Jellyfin.
Jellyfin will not hide problems
I mainly disagree with the disclosure process in this section, but I will talk more about that once we reach the part about the Jellyfin Constitution.
I should say though, that in practice this has not been the case. A lot of communication that should be public is done through private channels instead of public ones, and this, along with other points I shall discuss later, very much makes the project feels like a "boy's club", where only the people who are "in" are privvy to information, while everyone else is left in the dark.
Jellyfin's priority is to our users, which includes most of our contributors as well - we contribute because we use. We will seek to always support our users to the best of our capabilities. We will prioritize free software in all decisions and ensure that users have the same rights. If the needs of our contributors and our users conflict, we will seek consensus and an amicable solution wherever possible.
I don't like the mention of contributors in this section. It should be "users first", contributor or not.
Being a contributor to Jellyfin shouldn't give you more weight than simply using it.
The "we will prioritize free software first in all decisions" makes no sense here. The idea of this section should be to emphasize that we look at the free software community at large, and engage in being good citizens. Instead, this paragraph currently implies that when we're looking at a solution for something, we look at free software first, which shouldn't be the message here.
Jellyfin's contributors will treat each other and our users with respect
Again, this has nothing to do with a social contract between the project and its users, and fits more into a Code of Conduct.
Jellyfin's leadership team will guide the project towards these goals
Again, this has nothing to do here, in my opinion.
everyone keeps the leadership team accountable.
This is also laughable, as I will outline later.
Jellyfin Constitution
Source: https://github.com/jellyfin/jellyfin-meta/blob/master/policies-and-procedures/jellyfin-constitution.md
The Jellyfin Project is organized into a hierarchical structure with the following layers, which shall be defined in more detail below
I think the organization is too rigid and too pyramidal for it to make sense. More detail will follow in further sections, but I also think this should be in a separate document, akin to the Debian Organizational Structure document.
In the list above, a person or body is usually listed before any people or bodies whose decisions they can overrule or who they (help) appoint - but not everyone listed earlier can overrule everyone listed later.
This makes absolutely no sense.
It's essentially saying "Some people can override others' decisions, but not everyone can".
Again, the organization is essentially a pyramid, with higher levels being able to override decisions made by others, without being able to be elected directly by the people they have the power over (more on this soon).
Nothing in this constitution imposes an obligation on anyone to do work for the Project. A person who does not want to do a task which has been delegated or assigned to them does not need to do it. However, they must not actively work against these rules and decisions properly made under them.
Nothing should be delegated or assigned, except to people who volunteered for a position of responsibility over something. But the structure needs to account for that, which it currently doesn't.
A person may hold several posts at one time, and be part of as many teams as desired.
Yes, of course. But there should also be term limits on those positions, to avoid a handful of people holding the power, as is currently the case, with no recourse for change. More on this below.
The Project Leader is responsible for the overall management of the project direction and releases.
This is way too vague and groups the role of Release Management or Packaging Team with the role of project lead, which is idiotic.
There should be a Release Management/Packaging Team which handles releases and packaging, and it shouldn't be tied to the role of project leader. The functions require different skillsets and types of work, as well as responsibilities.
Furthermore, compared to the Debian Constitution, this is too vague as to the exact roles of the Project Leader and is ripe for abuse.
One example would be Section 5.1.9 of the Debian Constitution, which is completely absent here. I cite: "The Project Leader should not use the Leadership position to promote their own personal views".
In fact, our contribution explicitely states the following: "The Project Leader is responsible for the overall management of the project direction". Taken as-is, this means essentially that the project is dependent on the whims of its current Project Leader, which may veto or push for any one thing they want, which should be impossible for a properly structured project.
While the Project Leader should set a global direction for the project, they should, like outlined in the Debian Constitution, do so by talking with team members and only intervene to help in resolving urgent matters, matters with no current delegate or appoint delegates.
The Project Leader is the final arbiter in any disputes or decisions raised from lower teams and persons where such a decision cannot be reached by more collaborative means within the teams themselves.
The phrasing of this section once again emphasizes how the Project Leader has the ultimate authority, which they shouldn't have.
Per the Debian Constitution, again: "The Project Leader should attempt to participate in discussions amongst the Developers in a helpful way which seeks to bring the discussion to bear on the key issues at hand".
The role shouldn't be about making decisions, but about making sure things run smoothly.
The Project Leader shall also function as Release Manager for the core server, handling the coordination and creation of new releases of the Jellyfin server software. Creation of releases for clients or sub-components is delegated to their respective Function Teams.
This goes with the point made above about merging Project Leader and Release Management, two very different functions.
Why would the Project Leader, whose role should be to ensure the smooth running of day to day operations and team collaboration, also imply the need to be able to:
- Package software
- Cut releases
- Act as a sysadmin by managing server-side scripts to pull and organize releases
These are different skills and completely unrelated to the role of a Project Manager.
The Project Leader must always be a member of both the Leadership Team and the Financial Committee.
This seems ripe for abuse, and gives even more power to what should essentially mainly be a guiding role.
While expenses should first go through the Project Leader for validation, treasurers should be the only ones with direct money access.
The Project Leader shall serve indefinitely at their discretion, but may resign at any time.
This, in my opinion, is unacceptable.
This makes the project essentially a ************, with no recourse in case of abuse, incompetence, disagreement or other issue.
It goes completely counter to the very notion of free software. The constitution as a whole seems to try to make what is essentially a ************ by a minority over the project, as a democracy.
Every role should, in my opinion, have term limits, to ensure the role (and the project as a whole) doesn't get stagnant and rots from the inside.
Since the Jellyfin Constitution is based upon the Debian Constitution, I would propose a term duration of one year for the Project Leader, with voting from all Jellyfin members in a publicly held election.
Upon resignation or in-disposal of the Project Leader, one or more candidates for the position shall be proposed by the Leadership Team.
This promotes the incestuous nature of the Leadership Team, by ensuring that only the Leadership Team can appoint new members to the Project Leader role, while also being the only power to be able to appoint members to itself.
In practice, this makes it so only a select number of members hold any real power over the project's direction and future, and is set up explicitely to make it stay that way.
A system similar to Debian's is much more democratic and difficult to abuse. I quote: "For the first week any Developer may nominate themselves as a candidate Project Leader, and summarize their plans for their term".
The method of election shall be ranked voting instant runoff until one candidate has secured an absolute majority of the vote. In the event that only a single candidate is proposed, and this candidate does not gain a majority of votes among the Contributor Team, the outgoing Project Leader shall cast a deciding vote to confirm or deny the candidate outright. If the outgoing Project Leader does not confirm the candidate, the process shall begin again and the previous candidate is ineligible for further consideration.
This method of voting is, again, ripe for abuse.
A better suited method, explictly intended to avoid the outgoing Project Leader having to confirm anything, would be the Condorcet method. This is already used by Debian, the Wikimedia Foundation, the Gentoo Foundation and the Kubernetes community.
De facto, an outgoing Project Leader should not have any say over who their successor is, although they should still have a vote in the election, as with every other member.
The Leadership Team is responsible for the day-to-day operations of the project and the handling of technical and managerial decisions for the project.
I am not sure there should be a leadership team at all.
They do essentially the role of the current Project Leader, but hold private discussions and hold way too much power.
The Leadership Team is the only group with "Merge" permissions for the core server repositories, and are responsible for the merging of reviewed and approved Pull Requests into those repositories.
Then this should be the "Server Team", not the "Leadership Team". If they handle the direction of a component of the project, they should be that component's team, not one that holds infinite power over the entire project.
The initial Leadership Team was appointed by the first Project Leader during the creation of the project and has and shall continue to grow.
Again, there should be term limits for this, as currently the team elects itself and regulates itself, which is ripe for abuse and promotes an incestuous relationship at the top levels of the project.
The Leadership Team should, but is not required to, include an odd number of active members to ensure majority decisions can be decided effectively.
This is not needed at all, since teams should be able to self regulate (as the Leadership Team should not exist).
Individual component's teams should work on a 2/3rd of votes decision system, to ensure that no matter the amount of people in the team, a consensus can be reached.
New members can be proposed to the Leadership Team when required by the Project Leader
This once again promotes a "boy's club" approach to leadership, and encourages incestuous relationships, where developers have no way of getting any say in things unless they get in the good graces of the Leadership Team and the Project Leader.
Members of the Leadership Team shall be removed from their position after 1 year of inactivity with the project, subject to discussion by the remaining Leadership Team members.
This has not been applied in practice and, even if it was, term limits should be in place for any position affording authority.
The term "inactivity" is also very vague. What constitutes inactivity in the eyes of this sentence?
Some members of the Leadership Team have been essentially invisible from the project at large, either not contributing at all, being MIA or only hanging out in chatroom, yet they are apparently not considered "inactive".
The Financial Committee is a sub-group of the Leadership Team who is in charge of allocating funds from the OpenCollective donation pool.
This, once again, places all the power in the hands of the same few (unelected and unremovable) people.
The Financial Committee shall always include exactly 3 members to ensure transparency in all funds allocations.
Having three members does not provide any transparency by itself.
New members shall be proposed by the existing Financial Committee should the need arise, by direct nomination by the departing member. The new member must be confirmed unanimously by the remaining members.
Same as a lot of other points above, this essentially makes sure the power stays in the hands of a select few, who are unelected and unremovable.
New Subproject Leaders shall be selected by the Project Leader, in consultation with the Leadership Team and existing sub-project contributors, as required.
Projects should elect their own team's chair, as they are the ones closest to the daily work and capabilities of everyone involved in it.
As with other leadership roles, there should be regular elections for this.
Technical Committees exist to facilitate day-to-day decisions on technical matters within the Jellyfin Project, and are empowered to make technical decisions related to their area of expertise.
This should not be the purpose of a Technical Commitee.
They should essentially be there to make decisions that cross multiple projects' jurisdictions and otherwise act in an advisory role. They may override some technical decisions from developers at times, but mainly in cases of issue resolutions.
Membership should not be based upon being in the Leadership Team (which, again, shouldn't exist at all), but appointments should be made by the (elected) Project Leader and the rest of the technical commitee.
The Project Leader should only get a vote in a tie-breaking situation.
Technical Committees shall consist of exactly 3 members
Why 3? Again, section 6.3 of the Debian Constitution makes a lot more sense than this, and has better processes.
Term limits should also apply, to avoid a stagnant set of members.
Technical Committees shall make all decisions by consensus
This limits decisions a lot. Having a 3:1 majority, with a strict minimum of 4 members would allow a lot more leeway for decision-making.
The exact list and nature of the Technical Committees shall be subject to decision by the Project Leader and Leadership Team as required, and Technical Committees shall be created or dissolved as needed by the project as a whole.
The Technical Committee should be a permanent fixture, but should also be able to appoint itself in cases where member counts dip too low. Again, Debian has good policies for this, why change them to worse, more authoritarian ones?
New team member nomination process
Anyone who is currently on the Jellyfin team (defined as a member of #jellyfin-support-team and/or the GitHub organization) may nominate a community member for inclusion in the team.
This makes the process incredibly limiting, and reinforces that "Boy's Club" mentality.
Similar to Debian, potential new members should be able to nominate themselves by providing a letter of intent, then agree to the policy documents.
Eventual advocates should manifest themselves, then the application should be reviewed before being submitted to a public vote of a fixed duration.
If either a majority of votes are positive, or there is a lack of opposing votes after the end of the time period, the nominee should become a part of the organization.
With such a process, the rest of the document is de-facto made irrelevant.
Such a process ensures that "getting in" is doable for everyone and the organization can grow based on contributor interest instead of "being noticed", making us more open as an organization.
I think the current policy documents emphasize a lot of the issues we have as a project, some of which I have already brought up before.
We present ourselves as open and "do-ocratic" (which, per the definition, implies a democracy), but in practice the policies of the project promote a closed loop of leadership, and stiffle potential progress and project growth.
While I am aware that I am directly criticizing a lot of things and indirectly calling out people here, my intention with this is merely to highlight what I feel are deep organizational issues within the project, which would merit being talkked about and fixed.
We should strive to be more open and democratic, or we should remove "Jellyfin is a community [...] effort" and the "we are free software" parts of the Social Contract, because our current policies run counter to these two points.