No, I’m not referring to my Gentoo work, and I want to say this immediately. I’m not going away from Gentoo anytime soon, although some of the issues I’ll explain here do apply on Gentoo too. The point is that for Gentoo I feel more motivated because I see more users, and I’m usually able to get results that satisfy them (if we exclude the whole ALSA thing that pissed me off tremendously).
But after the time I wasted on FFmpeg, trying to push for an improvement, albeit minimal, I feel less motivated to work on other Free Software projects. The point is that there are too many people who just seem to consider themselves the only ones keeping the Truth.
Who considers himself the only one to know how optimisations work, who consider any other way taken by other projects a failure, a stupid thing, or simply broken. GNU zealots who despise anything that has not FSF stamp on it; anti-GNU zealots who despise anything that works on Linux or that was added by GCC even when you show him that the same features are available on any other systems. People who do the stuff their way without leaving space to any other solution that wouldn’t hinder their project…
I always try to be open when it comes to accepting patches, and solutions, and critiques. I’m fine with patches that works only for one operating system, I’m fine with reiterating over the same patch three, four, five times to improve it, if there is space to get it accepted. I’m fine with partial patches that covers the generic way things should be done, even if I need to fiddle with them to apply.
I think that Free Software development is somehow imploding, when it comes to people who code just to show themselves as the “Best Guys On Earth”…
Another nail on my motivation comes from xine itself, as Mike announced that there won’t be any change of SCM for xine-lib, leaving me to deal with CVS yet again, and with big changes that requires branching (as I’m sure I won’t be able to complete the changes in a single commit). Dealing with branching and CVS is painful, so I’m not sure if I’ll ever get around fixing the plugins loading problem or to implement Fontconfig support in xine-lib to be able to use more decent fonts instead of the fixed ones.
Add to that that I haven’t heard back from Wheeler about TagLib yet (the version in SVN failed to create a working tarball for me again), so I’m still stuck on RubyTag++ bindings, and you get a quite depressing situation.
Yes, I know there is plenty of working Free Software project, of projects where patches are accepted when they work, even if they might be intrusive, of projects open to suggestions, of developers who look at the practical merits of the features rather than at their design, of developers knowing when to rely on the compiler and when not. I don’t think Free Software is going to die soon, but for sure some of the projects might come down to implode, or simply to get stuck in the foam of self-esteem of certain developers, if to an Open Source you assign a Closed Mind.
actually, i wondered. is there a chance that you would publish your modified ffmpeg ebuilds for the gentoo community to test them out? (like ffmpeg-flameeyes, or ffmpeg with additional USE flag for your patches, with FAT warning, that those are inofficial patches)maybe after some field tests by curious users [you know that gentoo community has plenty of those :)] ffmpeg devs would reconsider whether they should add them or not.
Unfortunately, the patches I wrote don’t apply on FFmpeg SVN anymore already. The problem is that being interleaved in all the header files, as soon as one of them is changed, simply to rename a parameter, the whole patch for that file is rejected, and you have to fix it.This is why I left alone the original patch, as I was first told that a cleanup of the API was needed.Then I was told to submit the patches file-by-file, but when I started actually doing so, I got the cold shower of hearing that it was “an OS hack”..”for binutils”..”because GNU put crap in ELF”. (I don’t even want to comment on the sense of that declaration :P)As it is now, if I svn up my tree, I’ll get a lot of C that would need to be fixed, and there are likely more symbols to export too.It is simple to maintain after it’s merged, because you just have to put an extra macro at the end if you add a function, and in case you change parameters or names you don’t really have to do anything, but it’s impossible to maintain on its own :/