Stepping down as the Maintainer for the integrated AMD Encoder

This is my official notice that I am stepping down from the maintainer position for the AMD Encoder, as I have had several disagreements with the (only?) maintainer Jim. I would also request to be removed from the OBS Project team immediately. The integrated AMD Encoder plugin is now lacking a maintainer, and good luck to whoever picks it up again.

There are various reasons for this, but the biggest one is the repeated disagreements. In every disagreement i was not treated as an equal, but as someone who didn't know any better and should just be an obedient underling. This way of interacting with one another is simply not acceptable, and therefore I have no further interest in working together with the OBS Project team.

Furthermore there is the lack of clarity and transparency for the OBS project. As there is no roadmap, there is no way to tell what is necessary for a new version, and decisions feel arbitrary due to that. What gets in and what doesn't seems to be up to the preference of someone instead of being planned out from the start. And despite repeated claims to improve this, nothing has happened over the span of two years. Not only that, but several much requested features are just pushed away as niche instantly instead of actually considering them seriously and putting them in a roadmap.

Overall, the state of OBS Project does not sit well with me and I no longer wish to be associated with it. This does not mean that I will no longer develop things for OBS Studio/libobs, just that I no longer want to be associated with the OBS Project team at all. obs-StreamFX and other secret plugins I've developed for clients will stay around until I find another thing to work on.

Thank you for your contributions over the years.

I am sorry you feel that way about the project, but I do contest that progress has not been made. We have implemented a new release cycle with PR freezes and regular beta testing. We have started implementing an RFC system (https://github.com/obsproject/rfcs/pulls). Work is being done to solidify the roadmap and have a clear mission statement. None of this happens overnight, and I do not dispute that it is long, long overdue for the project. We are doing the best that we can, and I am sorry that has not been good enough for you.

I wish you the best of luck in your future endeavors.

For posterity and full transparency, I am posting context behind this particular disagreement:

This is the pull request: https://github.com/obsproject/obs-studio/pull/2335 And this was the discussion that followed my PR response in full: https://imgur.com/a/9IlIvIi

A pull request was submitted to update the AMD Encoder submodule to the latest version by jpark37, which we needed. The numerous changes to the AMD Encoder plugin included a change that automatically formats code with clang-format so that the committer does not have to format the code manually, which is an understandable thing to do. However, the submitter of the pull request, jpark37, reported an issue with it: the project will not build properly when Google's depot tools (used to build Chromium) are installed to a user's PATH environment variable. jpark37 had this issue himself. That's obviously not good. This is due to a custom modification that Google made to their build of clang-format in depot tools, which is annoying and not particularly anyone's fault or anything. It's not Xaymar's fault.

Google's depot tools are an important and vital tool -- not only to our developers due to the browser source, but also anyone who needs to build Chromium or even any core Chromium library -- and because of that fact, I simply wanted to disable the automatic code formatting feature in the AMD Encoder plugin by default. Not even remove it, just disable by default so it can still be used. I did not want to merge it while there were conflicts with Chromium build tools. My proposed compromise to solve this would not have affected Xaymar's build environment, and it would still allow him or anyone else to auto-format if they just had a cmake switch on. Xaymar stated that he disagreed with this and feels that people who have Google's depot tools in their PATH environment variable have broken build setups, but I still opted for compatibility with those build tools on the system because those tools are unfortunately very important to many people, including ourselves. His argument is that people should not have Chromium build tools in their PATH environment variable (despite Google's build instructions saying, and I quote, "Add depot_tools to the start of your PATH" on this page), but my counter argument was that we cannot control what people have in their PATH, and I would opt for caution and harmony with Google's build tools so that it would not impact any of our contributors.

For the underling statement, if I treated people as underlings, I would not have attempted any compromise or attempted to reason. Those links above plus all of the project's entire github history should be very sufficient proof that I've never treated anyone that way.

On the topic of transparency, although there are many features upcoming, the project has mostly been fluid lately rather than based upon a solid roadmap. We can't really very easily have solidified outlines that are rigorously adhered to because the project is still almost entirely volunteer-driven outside of myself. I'm the only one who does this full time, and we get so many pull requests lately that I had to move towards doing almost entirely just pull requests and management-related stuff full time. I have been trying to get more people to help, especially another maintainer for the core project, but getting people of the required experience required is very difficult; I have someone planned and have a budget to fund them but they won't be available for quite some time.

Additionally, on the topic of transparency, I'd like to state in my defense that I almost always specify exactly what's going on with the project in full detail on every progress report and blog post I make. In fact, I specified in the last progress report all of these things, especially that I would be moving towards maintaining and management full time rather than writing specific planned features myself, so I can't help but feel like I've been pretty explicitly transparent.

I understand working with people isn't fun, but often we need to make compromises in order to do so. I feel I have sufficient proof that I always try to compromise and reason with others despite being having executive privileges as the core project author/maintainer.

You have so much potential and skill. People will always have disagreements, and that's something you will find everywhere no matter where you go. Despite our issues with one another, I genuinely wish you the best and acknowledge you. We'll take over the AMD encoder from here on out then if that is your wish. I understand that it's not fun to have to deal with some of these situations, but this isn't the sort of issue I would have expected you to quit contributing over.

... 2335 ...

Unfortunately the PR is just a small part of everything that happened over 2.5 years that ultimately made me quit. The disagreements were just a small part of it, and a lot happened in the first year that made the whole experience negative. Not to mention someone instigating a swarm of death threats which, to date, have not stopped.

Then there's the management of Discord and IRC, though the former has been much less transparent than the latter. I've had a few clients contact me directly after being permanently banned in IRC, some of which I still do work for today. Overall the list of things I've had issues with just outweighs the list of things I like 10:1 now, and I'm quitting before it just becomes overwhelming.

On the topic of transparency, although there are many features upcoming, the project has mostly been fluid lately rather than based upon a solid roadmap. We can't really very easily have solidified outlines that are rigorously adhered to because the project is still almost entirely volunteer-driven outside of myself.

A roadmap does not mean "these features have to be in", just that "these features are likely to be in". It also gives contributors a guideline as to what you would like to see next, and especially with your plan to give out bounties (if that is still a thing), this would give contributors and actual hint as to what they can work on.

I'd like to state in my defense that I almost always specify exactly what's going on with the project in full detail on every progress report and blog post I make.

Counterpoint: The unannounced downgrade of the AMD Encoder which caused me extra work for several months.

Despite our issues with one another, I genuinely wish you the best and acknowledge you. We'll take over the AMD encoder from here on out then if that is your wish.

Same to you. And that would probably be in your own best interest, as I have no further interest in maintaining it.

Feel free to reach out to me regarding any bans in the Discord or IRC, I am happy to review them. That is my responsibility. It takes quite a bit to earn a full ban in IRC.

EDIT: In the interest of transparency, none of these ban concerns were ever raised with myself or anyone else on the team as far as I am aware.

This is probably not the place to discuss such items, but I will post my opinion here regardless because this Issue was brought to my attention.

What Xaymar said in his initial comment is an actual, real problem with the project. The items mentioned will be the demise of the entire OBS project as a whole unless they are addressed -- not discussed, addressed. All it takes is a person who is neutral, and with an open mind, to review the comments on the OBS developer Discord -- I'm not talking about the end-user portion -- to see the exact mentality that is described.

The modus operandi of "key developers" of the project is: "if you aren't part of my clique of worshippers who see eye-to-eye with one another, your opinion does not matter, but thanks for it anyway!" Opinions are asked from specific developers (ex. R1CH -- the individual who continues to push things like digital decibels instead of percentage-based volume metres, chanting a mantra of "the sheeple are morons and need to be taught how to use digital dB"; I am fully aware that PR 2068 recently got merged, where the toggle is effectively hidden (no one would think to right-click anywhere in the properties dialog to find this toggle)). In other words, an echo chamber. I've had separate contributors relay similar concerns to me as Xaymar, and in confidence (and they shall remain anonymous).

When you have a project owner who listens to a select number of cohorts with strong opinions that do not represent the needs/wants of the user base, you end up with a project that is not made for that user base but rather for an elitist group of people. And while that's OK, OBS is indeed the encoder/streaming software used by the majority of the western Internet at this point in time. That is a big responsibility! And while it isn't possible to make every person happy, there have been many not-so-great changes over the past 3-4 years that are the direct result of what I'm referring to.

I'm glad Xaymar is stepping away from something that induces unnecessary stress and makes him feel unappreciated, but he isn't the only one. I would suggest Jim take a full week off and apply some deep introspection. I feel like I should end this paragraph with hashtag #makeobsgreatagain

This is probably not the place to discuss such items, but I will post my opinion here regardless because this Issue was brought to my attention.

You are correct, this is not really the place. I am going to lock this thread after my reply because of that. That said, I have DMs open to anyone in the OBS Discord, and I am on IRC pretty much 24/7. If anyone wishes to discuss any of these topics further either publicly or privately, please do not hesitate to reach out. Community health and happiness is one of my primary responsibilities for the project.

The modus operandi of "key developers" of the project is: "if you aren't part of my clique of worshippers who see eye-to-eye with one another, your opinion does not matter, but thanks for it anyway!" Opinions are asked from specific developers (ex. R1CH -- the individual who continues to push things like digital decibels instead of percentage-based volume metres, chanting a mantra of "the sheeple are morons and need to be taught how to use digital dB"; I am fully aware that PR 2068 recently got merged, where the toggle is effectively hidden (no one would think to right-click anywhere in the properties dialog to find this toggle)). In other words, an echo chamber. I've had separate contributors relay similar concerns to me as Xaymar, and in confidence (and they shall remain anonymous).

This is just not true. We make decisions based on the wants and needs of the community all the time. We see the issues that users deal with every single day, through our support chats and forums. We go well out of our way to try and make everyone happy, often against the personal opinions of many of the contributors of the team. Inevitably, there will be decisions we make that will make some users unhappy, and that is true of any application. We cannot please everyone, so often we need to choose the most correct path as we see it. In the specific context of the dB change, it was discussed at length, and the PR was open for comments for a week and a half before being merged. There were no dissenting opinions, save a single sarcastic remark about users asking what dB is, and very few users overall even batted an eye at the change. Claiming that we're ignoring the needs and wants of our user base for our own personal opinions is baseless, and frankly incredibly rude without an ounce of proof outside us making a decision you did not like or agree with. Especially given the fact that we, admittedly reluctantly, made the concession to add the option to change back to percentage based volumes if users wanted the option. If we weren't listening and didn't care, why would we do that?

Sometimes we get things wrong, and we're not above admitting that. The dB change I don't think is one of them. Happy to discuss further on a personal opinion level with you over in Discord or IRC.

When you have a project owner who listens to a select number of cohorts with strong opinions that do not represent the needs/wants of the user base, you end up with a project that is not made for that user base but rather for an elitist group of people. And while that's OK, OBS is indeed the encoder/streaming software used by the majority of the western Internet at this point in time. That is a big responsibility! And while it isn't possible to make every person happy, there have been many not-so-great changes over the past 3-4 years that are the direct result of what I'm referring to.

If you could be more specific on what "not-so-great changes" have been made, preferably documented on our Ideas page for review, that would be most helpful. Nothing is permanent, and we revert and change things pretty often based on user feedback when we do things that end up not working out.

obsproject / obs-studio

Stepping down as the Maintainer for the integrated AMD Encoder #2346