Alexis, Alexis Ballier wrote: > All of this because ~10 people cannot work together, well, really, > thank you :)
Do you have experience from being in a similar situation? You are being quite judgemental. There are absolutely situations where people so different that cooperation simply can't work. It's pretty lame, but unless you yourself participate at least on the same level as everyone else (on both sides) you really don't get much of a say. It's easy to tell people to "stop fighting, just get along" - but I believ that intentional fighting is quite rare. It's more likely about trying to make one's point. That requires communication, but communication is not always possible. (I don't mean transmissions back and forth, I mean desire to understand the transmissions.) For a long time I idealized open source as being an ideal community, where communication always worked because everyone wanted it to. But that's unfortunately not at all the case. > Can you point out any important problem? I suppose the problem is that "it is not done yet" like Greg sometimes says about things that are being worked on in the kernel. Of course when a work-in-progress is published and someone desperately wants to use it they will try to use it as soon as possible, and if they are unhelpful they will complain and/or run off in their own direction without receiving anyone's communication. If this has happened to you, you will know that such events teach you never to do any work in the open, ie. only publish code when you think that it is completely done. On the other hand you may still want to have feedback during your work. A perfect conflict of interest, which is quite annoying and distracting. > how open source work And how it sometimes doesn't work at all. I mean: It is not useful. In an ideal world people would work more together. Sometimes that simply isn't possible. > > I have no opinion, I stayed out of the discussion and decision about > > that before because I know I have a bias. I let other people decide. > > Note: If pro-libav people would be doing the work of fixing the tree > and ensuring *everything* works with libav I would not mind at all > what the default is. I think this is completely fair! Thanks for that. > I consider FFmpeg superior, but can understand there are different > opinions, however, if this is to lower the tree quality Quality is not a very helpful metric, because it means completely different things for different people. Some people value code readability, maintainability, and correctness very high, other people value having a new idea halfway implemented and released even if it only kindasorta works and is not at all reliable and not on par with previous parts of the code. I see a tendency in myself and in others to not care about what happens on the inside when thinking merely as a user. I see many many people complain about the insides when they are not happy with how it performs. I very rarely see people actually dig in to help fix up the insides. The same pattern exists in pretty much all projects that I know of, and it is quite natural - there are more users than developers. > then it is obvious libav shouldn't be the default. It may be obvious to you, but please remember that others may (are likely to!) have a different metric. > libav should realize they are the actual fork (this is now pretty > clear since the takeover failed and ffmpeg didn't collapse...) and > also rename their libraries so that the internal libav/ffmpeg > fights would not affect their users anymore and projects could use > what they think best... Unless libav considers the API too broken to still be functional I don't see the point of differentiation. A little bit of competition can be good overall even though it is more stressful for both sides. The most important thing is what I asked for already - That users inform themselves, and make informed decisions. Anything else is really just an excuse not to have to form, voice, and defend an opinion - take a stand - which IMO is just as lame as ~10 people who cannot work together. //Peter
