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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
