1 |
Alexis, |
2 |
|
3 |
Alexis Ballier wrote: |
4 |
> All of this because ~10 people cannot work together, well, really, |
5 |
> thank you :) |
6 |
|
7 |
Do you have experience from being in a similar situation? You are |
8 |
being quite judgemental. |
9 |
|
10 |
There are absolutely situations where people so different that |
11 |
cooperation simply can't work. It's pretty lame, but unless you |
12 |
yourself participate at least on the same level as everyone else |
13 |
(on both sides) you really don't get much of a say. |
14 |
|
15 |
It's easy to tell people to "stop fighting, just get along" - but |
16 |
I believ that intentional fighting is quite rare. It's more likely |
17 |
about trying to make one's point. |
18 |
|
19 |
That requires communication, but communication is not always |
20 |
possible. (I don't mean transmissions back and forth, I mean |
21 |
desire to understand the transmissions.) |
22 |
|
23 |
For a long time I idealized open source as being an ideal community, |
24 |
where communication always worked because everyone wanted it to. But |
25 |
that's unfortunately not at all the case. |
26 |
|
27 |
|
28 |
> Can you point out any important problem? |
29 |
|
30 |
I suppose the problem is that "it is not done yet" like Greg |
31 |
sometimes says about things that are being worked on in the kernel. |
32 |
|
33 |
Of course when a work-in-progress is published and someone |
34 |
desperately wants to use it they will try to use it as soon as |
35 |
possible, and if they are unhelpful they will complain and/or run |
36 |
off in their own direction without receiving anyone's communication. |
37 |
|
38 |
If this has happened to you, you will know that such events teach you |
39 |
never to do any work in the open, ie. only publish code when you |
40 |
think that it is completely done. On the other hand you may still |
41 |
want to have feedback during your work. A perfect conflict of |
42 |
interest, which is quite annoying and distracting. |
43 |
|
44 |
|
45 |
> how open source work |
46 |
|
47 |
And how it sometimes doesn't work at all. I mean: It is not useful. |
48 |
|
49 |
In an ideal world people would work more together. Sometimes that |
50 |
simply isn't possible. |
51 |
|
52 |
|
53 |
> > I have no opinion, I stayed out of the discussion and decision about |
54 |
> > that before because I know I have a bias. I let other people decide. |
55 |
> |
56 |
> Note: If pro-libav people would be doing the work of fixing the tree |
57 |
> and ensuring *everything* works with libav I would not mind at all |
58 |
> what the default is. |
59 |
|
60 |
I think this is completely fair! Thanks for that. |
61 |
|
62 |
|
63 |
> I consider FFmpeg superior, but can understand there are different |
64 |
> opinions, however, if this is to lower the tree quality |
65 |
|
66 |
Quality is not a very helpful metric, because it means completely |
67 |
different things for different people. Some people value code |
68 |
readability, maintainability, and correctness very high, other people |
69 |
value having a new idea halfway implemented and released even if it |
70 |
only kindasorta works and is not at all reliable and not on par with |
71 |
previous parts of the code. |
72 |
|
73 |
I see a tendency in myself and in others to not care about what |
74 |
happens on the inside when thinking merely as a user. I see many many |
75 |
people complain about the insides when they are not happy with how it |
76 |
performs. I very rarely see people actually dig in to help fix up the |
77 |
insides. The same pattern exists in pretty much all projects that I |
78 |
know of, and it is quite natural - there are more users than |
79 |
developers. |
80 |
|
81 |
|
82 |
> then it is obvious libav shouldn't be the default. |
83 |
|
84 |
It may be obvious to you, but please remember that others may (are |
85 |
likely to!) have a different metric. |
86 |
|
87 |
|
88 |
> libav should realize they are the actual fork (this is now pretty |
89 |
> clear since the takeover failed and ffmpeg didn't collapse...) and |
90 |
> also rename their libraries so that the internal libav/ffmpeg |
91 |
> fights would not affect their users anymore and projects could use |
92 |
> what they think best... |
93 |
|
94 |
Unless libav considers the API too broken to still be functional I |
95 |
don't see the point of differentiation. A little bit of competition |
96 |
can be good overall even though it is more stressful for both sides. |
97 |
The most important thing is what I asked for already - |
98 |
|
99 |
That users inform themselves, and make informed decisions. |
100 |
|
101 |
|
102 |
Anything else is really just an excuse not to have to form, voice, |
103 |
and defend an opinion - take a stand - which IMO is just as lame as |
104 |
~10 people who cannot work together. |
105 |
|
106 |
|
107 |
//Peter |