[FFmpeg-devel] Project orientation

[Jim DeLaHunt]

On 2020-07-04 07:43, Nicolas George wrote:
> [In the FFmpeg project,] [t]here is work in making highly-optimized
> decoders, this work is impressive and creative…. But as far as I can see,
> that is mostly all there is going on. The rest seems to be rather basic:
> fixing bugs…, implementing support for
> features that were decided and designed elsewhere.
>
> And it is not just that it is not happening: there is genuine opposition
> to creativity: things that are not already justified externally, things
> that do not look like well-known patterns, are met with scepticism and
> eventually rejected.
>
> At this point, we should ask ourselves:
>
> Is it what we want the project to be, or is it just what we have let it
> become?
>
> I do not think this evolution is the result of a deliberate choice. I
> think it is more the result of the stress of success and the stress of a
> fork. Success can stifle creativity, because creativity implies the risk
> of failure: the project has become advert to risk.
>
> It has evolved that way, but are we fine with it?
>
> I personally am not….

I am really happy to see this discussion starting up. It is good timing; 
some new governance committees are forming. They might be able to take 
it on. From my perspective as an outside observer, I think the project 
will benefit from you — the people who are at the heart of the project — 
having this discussion.

For what purpose do all of you contribute to FFmpeg? What is the good 
you see FFmpeg doing? What is FFmpeg's purpose?  What stands in the way 
of FFmpeg achieving its purpose, and of you achieving your own 
individual purpose?

For me, several comments in the thread resonated. They have a theme: 
bringing in new participants:

On 2020-07-04 08:37, James Almer wrote:
> …Another thing worth mentioning is a lack of new blood. Despite
> participating in GSoC for a long while, i can't name a student that
> stuck around after the fact. Mind, there are new devs that started
> contributing for other reasons, but perhaps not enough?


On 2020-07-04 11:20, Soft Works wrote:

> …As a developer (without a well-known name) who wants to contribute a patch,
> things can be quite frustrating here. When that patch accidentally hits an
> area of one the very few who are caring and friendly - you're lucky.
> But otherwise, a patch will either be ignored or talked into infinity.
>
> I have a number of things to contribute, but after it didn’t work well
> with small things, I decided not to bother with the bigger ones.

On 2020-07-05 11:42, Steinar H. Gunderson wrote:
> On Sun, Jul 05, 2020 at 08:13:25PM +0200, Manolis Stamatogiannakis wrote:
>> As a fresh contributor, setting up git send-email was a hassle, but
>> not an insurmountable obstacle.
> Speaking only for myself, having sent a single-digit number of patches
> to FFmpeg ever: Setting up git send-email was not a big turnoff. Having your
> patch being not responded to (whether being forgotten, not found interesting
> enough, or whatever other reason) was.


To the extent you decide that you want new participants to join you on 
FFmpeg, I'm sorry to say, I think you have a problem. My own experience 
is that this project is more hostile to newcomers than many other free 
culture projects I know (e.g. Python, Thunderbird, Gnucash, Drupal, 
MusicBrainz, Wikipedia). It's not just your rudeness to each other on 
the email lists. It's not just the inattention to patches from new 
developers. It's also a simple lack of telling newcomers: welcome, we 
are glad you are here, we want your help, we will help you learn.

Even more deeply, the culture of this project is focussed on checking in 
compileable code to the exclusion of other kinds of contribution: 
testing, documentation, support. Those contributions seem not welcome 
simply because they are not code, and code is all that matters.

I suspect that you may find that some of the things that frustrate you 
are linked to work the project does not value. Repetitive questions on 
the ffmpeg-users list may in part result from the inadequate 
documentation, which doesn't tell users what they need to know. Feeling 
stretched thin over too much code without enough tooling might result 
from the too little of the right unit tests. And so on.

I wish you success as you ask yourself these big questions. I hope it 
helps you have a more pleasant time in this project. I am confident it 
will result in a better FFmpeg.

       —Jim DeLaHunt, software engineer, Vancouver, Canada