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