reconciliate & merge with libav
|Reported by:||Christoph Anton Mitterer||Owned by:|
|Blocking:||Reproduced by developer:||no|
|Analyzed by developer:||no|
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:
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...
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:
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.
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.
 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.
Change History (12)
comment:10 by , 8 years ago
|Status:||new → closed|
|Version:||git-master → unspecified|