from the perhaps-a-spoon-instead-of-a-fork-next-time? dept.
The leader of the FFmpeg open source project has resigned amid ongoing turmoil among the project's developers.
On Friday, [Michael] Niedermayer announced via the FFmpeg mailing list that he was resigning his role as the project's lead maintainer, largely due to the ongoing schism among its developer community:
will i ever return ? ... i might ..., if theres a nice and friendly environment, no hostile forks or at least none i have to interact with. But i will certainly not return as leader, this is not really a role i ever truly liked, more one i ended up with.
Trouble first arose among the FFmpeg developers in 2011, when a group of contributors decided to fork the project's code into a new project called Libav.
The exact reasons for the schism are hard to decipher. A lot of it seems to boil down to personal bad blood and conflicts over project management, rather than disagreements about technical matters. The fork has proven to be one of the more contentious in open source history.
In his resignation letter, Niedermayer said the ongoing pressures that resulted from FFmpeg and Libav being maintained as separate projects was one of the main factors in his decision to step down:
(Score: -1, Flamebait) by Anonymous Coward on Wednesday August 05 2015, @05:58PM
>waaaaaaahh, this fork is more popular than my code, I feel unappreciated, I'll quit, that'll show them.
(Score: 3, Informative) by janrinok on Wednesday August 05 2015, @06:06PM
Well, after reading TFA, that might not be the case. Debian initially switched to LibAV but has since switched back again. But having 2 groups competing rather than cooperating is a waste of resources and knowledge.
(Score: 1, Flamebait) by Aighearach on Thursday August 06 2015, @07:34AM
having 2 groups competing rather than cooperating is a waste of resources and knowledge
Eh, or the competition magnifies the quality of the result.
Lets not just assume that black is white. What if it isn't?
(Score: 1, Flamebait) by goodie on Wednesday August 05 2015, @06:26PM
Not so sure... I've never heard of Libav until I read this, but have heard and used FFMpeg plenty of times. I don't know what the actual details of the dispute witb libav are but I can imagine that this can quickly become a major pain in the groin to have to merge stuff from two projects and have no cross-project collaboration.
(Score: 1, Informative) by Anonymous Coward on Wednesday August 05 2015, @06:37PM
libav was a hostile fork of ffmpeg. Some distros then ditched ffmpeg for libav and then now more recently those same distros are switching back to ffmpeg instead.
(Score: 5, Insightful) by VLM on Wednesday August 05 2015, @07:01PM
I don't know what the actual details of the dispute witb libav are
Oh, you're better off not knowing. Like watching sausage being made. Its like something out of a daytime drama. Could sell as a drama book or somehow as a movie even to non-techies. It was never really a technological issue. I'm trying to recall which Shakespeare (or other?) dramatic play is the closest to the story.
I don't have a dog in the fight although I have opinions from having watched this for a couple years, but I think its non-controversial to claim that the "press release" is only one very biased side of the long agonizing story.
My controversial and opinionated view is the leader and the team didn't get along absolutely cannot work together, so the team took off and forked, although the fork looked super healthy at first eventually everyone abandoned it and went home (no I'm not kidding, crazy as it sounds!), and whereas two years ago the team wouldn't tolerate working with the leader so they left, you could interpret this announcement as the leader is now the one refusing to work with the team so he left.
I'm sure you'll be totally surprised to hear (groan at sarcasm) that the one dude alone was much faster at stuff like simple security patches, and not having anyone to argue with kind of helped, meanwhile the team found it difficult to apply simple buffer overflow patches within a month because, you know, team, and all that. Some of the Debian debate is dry and technical yet hilarious about how non-productive the team was WRT security issues. I guess one way to look at it is the fork really died like a year (or more) ago and it just took Debian etc that long to notice and dump, so its unfair to evaluate a living team by looking at its performance after its already dead, like some monty python beating a dead horse routine.
Its kind of a maintenance project because nothing changes very fast. Its possible the ideal personnel design for a growing project (like a big team) is not ideal for a semi-static maintenance project. In other words I'm saying the team not getting along with the leader might not matter if, frankly, its a one man project. I'm sure nine women trying to produce a baby in one month would create massive drama, but lets face it, nine women trying to create a baby under no time constraint at all isn't going to work either because its a one person job being team-ed into non-productivity. Everyone's seen stuff like this at work where you take a one person job that can be done in a week and next thing you know there's a giant dysfunctional committee that'll never execute, ever. Never design something more complicated than it needs to be, and honestly sleepy maintenance of a boring video codec probably should be "one dude" in 2015. That's why he was so successful more or less alone when the team forked themselves, its not like a project that small actually needs a team. Meanwhile the team crashed and burned because that's what teams do, they always lower reliability of projects.
Its interesting that the leader and his team were oil and water, but the dude and the general public is, AFAIK, OK dude. Likely the team aren't all crazies. So its a real life example of basically good people just plain old not getting along.
Hopefully the future won't crash and burn.
(Score: 0) by Anonymous Coward on Wednesday August 05 2015, @10:27PM
You had me until you mentioned the thing about nine women trying to have a baby all at once. There's not enough scientific evidence to prove that nine women aren't more productive at having a baby than a single woman.
I'm willing to participate as the male in a scientific harem to help find out. I mean study. Scientific study.
(Score: 2) by zugedneb on Thursday August 06 2015, @01:44AM
Curious on this: how many active people are involved in this, by and large?
Also, how did this happened for that project? As I understand, it is mostly people with expert knowledge that write codecs, or math libs... These type of people tend to be pretty stable, I have observed...
old saying: "a troll is a window into the soul of humanity" + also: https://en.wikipedia.org/wiki/Operation_Ajax
(Score: 2, Informative) by ese002 on Wednesday August 05 2015, @07:17PM
As I recall, the big issue is that some apps require libav. Other apps require ffmpg. Yet it is impossible (or at least very painful) to have both libraries installed at the same time.
(Score: 1, Informative) by Anonymous Coward on Wednesday August 05 2015, @07:33PM
Some of the team were unpleased with their additions not being adopted in good time, forked and used their position with distributions to imply that their fork was the new upstream with a new name. Niedermayer responded by including all changes made in libav in ffmpeg as well as continuing his development and so becoming a superset of the two projects.
I thought his demonstration that he could apply others changes in good time and continue development would have silenced or at least muted the opposition but sadly not.
As the IT crowd says, https://www.youtube.com/watch?v=eVSlE28hOgI [youtube.com]
(Score: 1, Informative) by Anonymous Coward on Wednesday August 05 2015, @08:41PM
I thought *they* had prevailed: they made him apply others’ changes in good time by actually forking.
Children on both sides….
(Score: 5, Funny) by Bot on Wednesday August 05 2015, @08:33PM
ffmpeg: hey what's up?
* ffmpegdevs are fed up
* ffmpeg sees no chains tying ffmpegdevs to the project
ffmpegdevs: o yea?
ffmpegdevs is now known as libav
ffmpeg: ...
Debian: hi libav, ASD?
libav: hehe
quit: libav
Debian: WTF
Debian: ffmpeg you still here?
ffmpeg: Yes, you b*tch.
join: ffmpegdevs
Debian: wb
ffmpegdevs: re
* ffmpeg is fed up
leave: ffmpeg
* Debian groans
Account abandoned.
(Score: 2) by Bot on Wednesday August 05 2015, @08:35PM
s/ASD/ASL/
Account abandoned.
(Score: 0) by Anonymous Coward on Thursday August 06 2015, @06:53AM
Age/Source/Distro :)
(Score: 1) by massa on Thursday August 06 2015, @11:01AM
I was trying to understand who had ASD in your script :D
(Score: 2, Insightful) by Anonymous Coward on Wednesday August 05 2015, @10:12PM
thank you for multimedia support on linux.
I think I dont know enough to be able to express my full appreciation but its important.
free software ruleZ!
(Score: 5, Informative) by Gravis on Wednesday August 05 2015, @10:58PM
one of the issues here is that the LibAV fork is almost compatible but decided to keep the filenames the same. stupidly the debian package maintainers decided that being almost completely compatible was good enough to allow packages that were dependent on ffmpeg to install libav instead. the result is some programs will seemingly randomly bail out when trying to decode some formats. i know this is true with FLAC because QMMP has this exact issue.
a proper solution to this issue would be to create a standard API and let whatever library you choose fill in the details. this takes a lot of effort but i think the resulting API would be a great contribution to the open source community as a whole.