reconciliate & merge with libav

[Christoph Anton Mitterer]

Hi.

Not sure if anyone has tried this before in the form of a bug (discussions about this topic are of course going on), but I think it should be actually handled as just this:
a bug.

btw: Apart from the fact that I think security should come first followed by functionality - I personally have basically no preference on either of the two projects, neither the people behind them.
The only exceptions are perhaps that I hate trac (used by ffmpeg) and that I think libav is a better name for what both projects do, at least a better name than ffmpeg.
In the following I will name ffmpeg before libav, simply for alphabetical reasons.

1) about forks
Having the possibility to fork is often a good thing and one of the strengths of open source. We've seen many cases in the past, where a fork revived development, solved political problems or greatly improved on the code itself (just take xfree86/xorg, gcc/egcs, openoffice/libreoffice as an example).

It seems that the fork between ffmpeg/libav has either failed such goals or already succeeded with them for both projects, especially from a purely technical POV since ffmpeg seems to more or less simply merge all commits from libav, AFAIK.

2) most other people are simply sick with the current situation
Just google for ffmpeg vs. libav and you'll find dozens of blogs and other commentries, where people write about the forking, it's background, a small comparison about the differences of ffmpeg/libav... basically always concluding that the whole thing is just annoying and at least as of now, not leading to any further benefits for developers (using either of the two) or end-users.

Also, a lot of manpower is wasted because of the fork, be it on an organisational level (when other communities, like recently Debian, argue about ffmpeg vs. libav), a technical level (when developers of other products try to be compatible to both or developers/end-users have to handle bugs/bug-reporting in both).

3) duplicate of development works & security issues
Both projects surely also waste some manpower when they do similar/same things.
Manpower that could be invested much better - after all, what the people from both projects want to do is the development of some all-round multimedia library.

Having two very similar forks, probably doesn't improve the security either.

4) it distracts developers/users
I guess it's quite clear that developers (of 3rd party programs) and prospective users of ffmpeg/libav are rather distracted from using either of the two because of these issues.
The same possibly applies to developers, that directly want to contribute to ffmpeg/libav but who are not inclined to take part in both and/or the "war" between them.

For sure there are more reasons which speak against the forking...

Solution:
Let people try toreconciliate and merge the projects,
and perhaps to not step on anyone's toes, explictly stating: that this is not a victory of one over the other.

Outstanding issues and possible solutions[0]:
1) Naming
Well I guess if the project is called either ffmpeg or libav, than either of the two parties may felt upset and external people may conceive it, as if this project would have "won".
I personally would say:

• "ffmpeg" is imperfect, since the code is about much more than (Fast Foward) MPEG
• "libav" is IMHO already better, at least it av stands for audio/video, but still not optimal since both projects also support e.g. image formats.

So maybe just think about another name? libiav (images/audio/video)? libmultimedia? Well I guess someone else can surely come up with less stupid proposals than these two of mine.

2) Infrastructure
Of course it's a lot of work, but it shouldn't be impossible to merge the infrastructure (repo, bugtracker, website, wiki, domains) of the two projects.
Especially if a new name would be chosen.
The old ones could link to the new ones.

3) Project leadership/maintainers
If there's still open issues about the leadership / maintainer position - simply do what other projects did, e.g. establish a steering committe, which makes binding decisions if necessary.
Such comitte could have e.g. 5 members, 2 from ffmpeg, 2 from libav and maybe a 3rd neutral person (from some other multimedia project?).
Or one could kindly ask an existing similar committe (e.g. Debian's tech-ctte whether it may give it's vote), basically taking the 5th seat ex offico.

4) Security / code quality
If security and/or code quality is a concern (like some of the bloggers basically write, that ffmpeg would support more formats but sometimes on the cost of taking hacky code), simply do what e.g. Linux does:
Make a kind of a staging area of codecs/drivers, which are only activated by compile time options or runtime parameters.

Cheers,
Chris.

[0] It's not that I would be so smart to come up with solutions no one else would have been able to find - actually all of these have been done before by other projects.

[Christoph Anton Mitterer]

I've reported the same bug over at libav's bug tracker at: ​https://bugzilla.libav.org/show_bug.cgi?id=756

[gjdfgh]

What the fuck.

Of course everyone hates this situation and yes it would be a good idea to change it.

Your bug report has 0% chance of fixing anything.

If you really want to fix this situation, you have to convince the key developers on both sides not to behave like children.

Good luck.

[compn]

note that "gjdfgh" does not speak for the ffmpeg project, only himself.

i have to put this warning on every comment in all mailing lists and irc and bug reports and debian flame threads because apparently if even one person makes a joke or insult , its "ffmpeg's problem".

[gjdfgh]

I clearly said both sides are fucked.

[compn]

to respond to your ideas, i like most of them. sure its easy to merge all of the bug trackers and forums and irc and mailing lists. its easy for all of us just to jump to a new git tree, mailing list, irc, etc. i'm not sure if changing the name is a thing we could agree on, but if the name alone is causing some problem, changing wouldnt be that big of a deal.

but... those are technical solutions.

libav team has made it crystal clear, multiple times, including 2 weeks ago at VDD14 multimedia conference, that the problem of the fork is a social issue and cannot be solved via technical means. libav team says they need to meet face to face with michael niedermayer to solve said social issues (see for example this mail at debian devel before vdd14 , ​https://lists.debian.org/debian-devel/2014/09/msg00072.html ).

[compn]

a quick way to settle this would be to have a company sponsor an official fork of both projects.

then have all distros and downstream projects switch to that third fork. making ffmpeg and libav obsolete. all devs who want to keep working on the code will move to the new fork.

history of the projects has shown that voting cannot be agreed upon. even the vote counts were debated endlessly. just look at those threads in 2011 on ffmpeg-devel if you wish to see what voting looks like.

any arbiter of disagreements would have to be a 3rd party.
the server admins would have to be a 3rd party.

i'm up for other ideas of course.

[Christoph Anton Mitterer]

Well maybe, it would be really best to go for a new name for the whole project...libpalantir[0].

Well I surely don't have enough insight about (any) remaining problems with Michael... from what one can read on the web, many things have completely changed since the fork... but it's not up to me to decide whether something was wrong with him before or not and/or whether it is changed enough since then or not.

On the other hand, if a steering committee would take over the ultimate control, it shouldn't be any long that big problem, regardless of whether he'd be the nicest guy on earth or a jackass.
I don't like all people I have to do business with in the open source world and I'm sure some may also think that I'm the idiot. But usually this doesn't keep me from doing stuff and neither them.

Regarding face2face... all that sounds a bit childish to be honest. I agree that close bonds and "seeing" each other can be helpful in projects, so perhaps Michael can move here a bit... but OTOH we're in the open source world and valuable contributions is usually welcomed even if someone wants to remain completely anonymous. So perhaps the libav guys have to move a bit as well.
I mean both seems to be just silly, refusing f2f meetings as well as insisting on them - OTOH I don't know the reasons if video conferences aren't enough for the libav guys, than maybe Michael doesn't want to pay for expensive travels or whatever.

Anyway in the end compromises will need to be made on both sides and likely both sides need a bit of forgiving+forgetting.

Well first find such a company ... I think that will be quite difficult, cause companies and distros (which you want to decide in favour of the "successor") are probably fed up with the situation and don't want to make much further efforts only to see that a merge (possibly) wouldn't work out and the teams would split again after a some time.

To be honest when the fork happened, it looked at first as if libav would "win" and all developers that want to continue simply have to move (just as you say) - well it looked at least like that from my Debian POV ;-)
But the recent discussions with Debian about ffmpeg's reintroduction have probably shown that distros aren't happy at all about the efforts wasted along the fork and the current situation.
So to me it rather seems that the two projects must reconciliate/merge first, and only then distros will follow (once again).

Regarding voting&decision process, I guess it's quite simple:

• either you have a single or small group of people who are for whatever reasons (perhaps historical or major contributions) in charge, like Linus, and things just-work-(more-or-less)™.

Apparently back then this wasn't the case at ffmpeg.

• or you have a single or small group of major contributors, which are in charge because of their role as major contributors (i.e. a do-ocracy) and it doesn't work out (for all people),... this may piss off other contributors and lead to a situation as we have now, which everyone seems to dislike

• or one comes up with a more or less democratic system, e.g. something that Debian has,... voting systems, technical committee, etc..

Of course if no side wants to make compromises, share power with the others, than things will just remain as they are.
But I at least had the impressions that people from both sides dislike the current situation and wanted to change it.

[0] Yeah, I only have stupid names *and* I love Tolkin... unfortunately the meaning of Palantír doesn't exactly fit what ffmpeg/libav does ;)

[pross]

I personally have basically no preference on either of the two projects, neither the people behind them.

Great! Flip a coin, pick one, and move on with your life.

Recommend: wontfix

[compn]

yes, its a common opinion around here i think.
we just want to work on the code. and get paid for it.
why make us do things ? why make us organize ? why make us change our names and mailing lists and irc?

noone can make people kiss and make up. you dont like it? write your project around a wrapper like gstreamer instead of ffmpeg/libav directly. or just pick one and ignore the other.

theres actually a lot of ffmpeg forks, its not like libav is the first.
ffmbc has been around for longer. why isnt ffmbc part of this discussion?

why not ask libreoffice and openoffice.org to rejoin? :)
or maybe debian and redhat? or debian and ubuntu?

because they are different people with different goals and different ideas?

(i dont speak for anyone but myself btw)

[llogan]

Replying to calestyo:

Not sure if anyone has tried this before in the form of a bug (discussions about this topic are of course going on), but I think it should be actually handled as just this: a bug.

I respect your opinions and suggestions, but I do not believe this bug tracker is the right place for this discussion.

[compn]

(we can still comment here, even if the bug is closed.)
(dont let the open/closed nazis get you down)

[compn]

here is the rough transcript from the vdd14 meeting between 6+? libav devels and 4 ffmpeg devels, held in a room with about 30 other people, moderated by two 3rd party volunteers.

​http://paste.ubuntu.com/8488924/

theres a lot of facepalm moments.