Wine developer frustration

[Kyle Auble]

On Thu, Jun 18, 2015 at 2:08 AM, Alexandre Julliard wrote:
 > So now I want to take a step back, and take the time to look at what we
 > are doing wrong, and listen to new ideas. I'd like to encourage
 > everyone, but especially people who are disgruntled or have given up
 > hope that we'd ever change, to send (either in this thread or by private
 > mail) their suggestions for what we should be doing differently, and how.

Sorry if this starts in a new thread; I had stopped emails from
the list for a while so I'm replying through the archive. I haven't
really contributed to the Wine project since working on the wiki a
couple years back, but I thought I might have some useful input.

For several years, I've flirted at times with contributing code to the
core project. I never have, for personal reasons more than anything;
other things just pop up in life. From what I've seen though, you're
all definitely very talented and sharp, and your communication skills
are actually pretty good, even if messages are terse at times. But I
have noticed several instances of what, I think, might be the project's
central problem.

To put it in parable, the Wine community (and not just the programmers)
seems like a team of strong, speedy soccer players with great footwork
and stamina... yet everyone just swarms the ball like in a youth
league. I hope nobody takes offense, but that's the quickest way I
could explain it. Sometimes people work on the same problem, sometimes
separate concerns, but at least from the outside, there doesn't seem to
be much deep coordination.

If I can toss out ideas, I think the community could really use more of
two things: strategy and logistics. I know there's the grand mission
statement to become everyone's favorite Windows API implementation,
even Bill Gates' ;) And there are the release criteria. A strategy
though isn't just about setting goals, but also committing people and
resources to those goals after seeing things clearly and thinking ahead
some. I don't know if a sign-off system or making peace with
wine-staging would be part of this, but if Alexandre personally wanted
to try something different, my first thought is taking an approach
that's a little less field officer and a little more grand vizier.

Now the logistics thing is interesting because I don't think that's a
group issue so much as a material one. I could be very wrong here since
I don't have a ton of experience, especially with large projects, but I
wonder if the project's ancillary tools and documentation are rich
enough. For a code-base as large as Wine's, maybe a broader ecosystem
of tools could make a big difference. Beyond making the project more
accessible to new developers, it might help the veterans step on each
other's toes less when different philosophies spring up (like the
wine-staging debate).

I know in my case, all the little catches in the build process and
changes to my system that need to be managed (especially on an amd64
distro) are discouraging. I'm sure I could work past them if it became
a major hobby of mine, but at this point in my life, it's enough to
change my calculus about actively testing or developing patches. Even
if you're willing to go through the manual tedium necessary to start
testing, it's not easy to find simple answers to problems that pop
up because the documentation is scattered about and contradictory.

I hope I haven't come across as presumptuous; Wine is a great project
with a lot of great people. I just noticed a pattern in all the hurdles
I hit while trying to become more involved, and they seem to match up
with what others are describing here.

- Kyle