ffmpeg has maintained compatibility, making it really easy for downstream users and distro maintainers to keep going, whilst continuously adding new features and improvements, including aggressively merging those placed in libav (I guess as long as they aren't deletions or cleanups?).
I feel like there's a lot to learn in this whole drama and that it hasn't been very deeply explored. libav team originally claimed that ffmpeg's leadership had gone dark/fallen off the map, but they sure came back quickly to express discontentment at the mutiny. libav team undoubtedly has talented people working on it (wasn't DarkShikari on the libav side of the schism?) and libav/ffmpeg share a lot of goals. You'd think they could come to some type of compromise less onerous than this entire saga has been. IMO it's a failure from all sides that this fork was even a thing. A phased, unified, slow, and well-managed release process like Python 2 -> Python 3 might have made all of this unnecessary.
This is at total nit, but I really doubt emulating the Python 2 -> Python 3 release process would go high on anybody's list of successful project evolutions. Given that Python 3 was officially released in 2008, it's worth keeping in mind that as recently as 2014 most new projects were still being created in Python 2.x
That said, given that python 2.7 is being continued to be maintained - but not with new features - for such a long time, and letting python 3 evolve quite quickly until it's now actually beginning (finally, around 3.5ish) to have features which are really appealing to many users (the async stuff, type hinting, etc), I don't think they've done too badly.
They could have made it quicker to happen, but since python2.7 is still a very good language, and works stably on practially every OS you could want, why try to force a change until people are ready?
People bitch about it [the changeover] a lot - not because it's terrible, but because it's lasting such a long time.
AFAIK, NO mainstream OS is shipping python3 as the main python, or even as a default installed python, yet.
Most big libs work in python3 now.
I reckon in 5 years time python3 should be the default install, with 2.7 as the legacy extra package for people who need it.
One way that could have been helpful (and may even be possible?????) would be a -2k flag for python3 which runs in python2.7 compatibility mode, or something. I dunno.
IIRC, Arch Linux does. Bleeding Edge. From the Arch Wiki:
>To install the latest version of Python 3, install the `python` package from the official repositories.
It's still nice to have Python3 be the default as a Python3 developer.
$ pacaur -Qi python
Name : python
Version : 3.4.3-2
Python 3 adoption was a little slower than may have been ideal, but I personally think it was a very successful way to implement breaking changes, especially when it could've been a libav/ffmpeg-style mess.
Given that the schism was based on politics and philosophy, I doubt that a compromise would have been possible.
ffmpeg moves fast and sometimes gets sloppy, and was hard to version for distros. libav wanted slow and careful and clean and wanted to be distro friendly.
Clearly libav tried to Do It Right(tm), but it looks like they ended up on the losing side of the fork. Forks only work when you can get the majority of developers to come along with you.
Meanwhile ffmpeg merged basically everything from libav.
Furthermore ffmpeg made an effort to provide compatibility, even for stuff where libav intentionally broke compatibility.
So basically ffmpeg benefitted from all the work put into libav but not the other way around. Seems to me that they brought this upon themselves.
While the two projects have chosen somewhat different approaches to developing the software, these differences were not what lead to the fork, and neither project particularly resembles pre-fork FFmpeg.