[FFmpeg-trac] #4002(undetermined:new): reconciliate & merge with libav

[FFmpeg]

#4002: reconciliate & merge with libav
-------------------------------------+-------------------------------------
             Reporter:  calestyo     |                     Type:
               Status:  new          |  enhancement
            Component:               |                 Priority:  wish
  undetermined                       |                  Version:  git-
             Keywords:               |  master
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------
 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.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/4002>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker