joshuaboniface
commented
3 years ago Having read this, I debated going point-by-point, but I think my response covers the general gist.
On the whole, you seem to be unsatisfied with the organizational structure I chose for this project (which is fully unique, as our project was in a very unique situation). That is on you. From my perspective, our organizational scheme works well. For instance our "do-ocracy" has shown basically no problems, we have not stopped any attempts to bring items into the org (including Vue, artwork repository, numerous clients, etc.), have not tried to block client implementations or plugins that are not rule-breaking, nothing. And on the server side, two LT members are very active server devs working to continue the server revamp.
You frequently mention "abuse". Can you point to any instances where I have "abused" my power as project leader? I have been, as I've declared many times, extremely hands-off on both day-to-day decisions (allowing contributors to decide them among themselves) as well as several larger things which I let the contributors as a whole decide. Again, aside from offering some constructive advice (which is usually ignored), I have not forced anyone to do anything, nor can I, except to enforce the goals of the project.
Further, you seem to fundamentally misunderstand why I have chosen this organization structure. I will make it blunt: I am benevolent dictator because I trust myself and the current LT to ensure that this project does not become monetized, user-abusing, or misguided by financial motives. The entire goal of this project is to not follow the footsteps of Plex and Emby in becoming closed-source, user-hostile software products which are driven primarily by a profit motive. The power I have given myself and this team, and which we have always held in a de facto fashion, is designed specifically to prevent this, while still giving the actual contributors - of which, I have always admitted, I barely am - the power to make decisions on the technical direction of the project on their own.
I will also take this opportunity to say: we are not Debian. We are not an Operating System. While their organization structure forms a major inspiration for this structure, they are not identical, and we also do not have 20+ years of project history and growth to stand upon. I'm sure Ian Murdock was quite strict in his leadership in the early days to steer Debian in the direction (philosophically and morally) that he thought was right, and it was only through that effort that they were able to become a "democratic" project that upholds those views.
You state:
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 stifle potential progress and project growth.
I disagree and see no conflict between these. Again, I have been extremely hands-off. Do-ocracy does not imply democracy, it implies do what you want to do and if we don't like it, we say so. Only if it contravenes the overall goals do we block it. So far, this has been extremely rare.
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.
Thousands of words to "merely" tell me you think I run the project like shit. How else am I supposed to take this, especially in light of previous incidents?
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.
So you disagreed with this entire document when I posted it in March, but are waiting until now to voice these opinions. Why, exactly? Further, I again see no conflict between these too. It is a community effort. A community organized by me and the other elements of the leadership team. It is not a free-form anarchist democracy, not under my leadership.
I will fully admit I have been somewhat absent from direct contribution for several months. It's mostly due to other obligations and priorities, and a desire to allow the team to continue doing their work; but it is also, to be blunt, due to burn-out over having to deal with this sort of near-endless conflict over the project, mostly between yourself and other members of the team, and in which have clearly not succeeded despite many attempts.
I am no longer interested in expending effort to do so. If you are this unhappy with my leadership style and the project structure, you are free to leave and fork. That is your recourse. You already left once, and I expended an extreme amount of social and personal mental effort - completely burning myself out to the point where I very nearly left the project entirely - to (attempt to) soothe over the situation, including writing out all these policy items so they would be clear, and taking many of your desires into account. The PR for these documents was a draft for over 2 months. You approved it. Where was this "feedback" then?
On a few specific points from the body:
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.
The line reads, and I quote, emphasis added:
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.
Neither DigitalOcean or JetBrains are asking for such things, and instead both have a simple policy of helping FLOSS projects in exchange for a simple banner. This is not the same thing, and I thought my wording made that very clear.
This is similarly out of place in a social contract between the project and its community, and potentially limiting to project growth.
We will not pay people for development, which is what this is talking about, because that leads directly to financial incentives for the project, and avoiding this is part of our very clearly stated goals.
Being a contributor to Jellyfin shouldn't give you more weight than simply using it.
Yes, it should. We need contributors more than users. Without contributors, nothing gets done. If users don't like an aspect of the project, they are free to contribute to change it. That is "do-ocracy".
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.
I'm not sure you understand the intention of this paragraph. It is saying, in effect, "If we have a choice between doing something the FLOSS way or a proprietary way, we will pick the former". Given that most of the core code is GPL, to even build the project we must use FLOSS tools anyways, and that is not what this paragraph is talking about.
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).
Yes, because the ultimate goal is to keep final authority in the hands of those of us who founded the project and ensure it continues with our ideals.
This is way too vague and groups the role of Release Management or Packaging Team with the role of project lead, which is idiotic.
Because I was the only one to volunteer for these roles when no one else was concerned with them. Again this document is not just a philosophical outline but a statement of how the project organization works in practice right now.
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.
No, it should not be, especially not a project founded on specifically ideological grounds. I'm sorry, but my concern is literally "if half the project decided that it's OK to put in ads and pay themselves from donations, a democracy allows that". If you're OK with that, then as stated above you are fundamentally misunderstanding our project's goals, motivations, and why I chose this structure. Also again, more talk of "abuse" for which there is no evidence, and I do take personal offense to the insinuation. I will stop members from making choices that are actively destructive to the goals of the project, like putting in ads, charging for features, or abusing users. Not technical decisions.
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. This makes the project essentially a dictatorship, with no recourse in case of abuse, incompetence, disagreement or other issue.
If you think I'm incompetent, leave and fork. I won't try to stop you this time.
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 dictatorship by a minority over the project, as a democracy.
No, it is not. This is how all software written by a single author works. The only difference here is that this person is not you, it is me, and I'm not writing the software itself. Instead I operate as an ideological guide while also taking on numerous roles that were and still for the time being are required due to lack of interest from anyone else. The in-progess CI changes are (to my benefit) already working towards removing my requirement to be a release manager.
heyhippari
thornbill
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
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.
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.
This formulation is too vague.
Something like the following would be much better:
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.
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.
Again, this has nothing to do with a social contract between the project and its users, and fits more into a Code of Conduct.
Again, this has nothing to do here, in my opinion.
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
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.
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 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.
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.
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 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.
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:
These are different skills and completely unrelated to the role of a Project Manager.
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.
This, in my opinion, is unacceptable.
This makes the project essentially a dictatorship, 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 dictatorship 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.
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".
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.
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.
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.
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.
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.
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.
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".
This, once again, places all the power in the hands of the same few (unelected and unremovable) people.
Having three members does not provide any transparency by itself.
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.
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.
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.
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.
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 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
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.