Just today XFree86 opened up their devel list to the public. I think this is a great step forward for the project. I haven't been involved greatly, but I've been following the lists for a while and recently I've been getting more involved. I'm excited for some of the changes towards openness going on in XFree86 recently, and disappointed about other things.
I became a member a few years ago with an interest in the nvidia drivers (they had just come out with their obfuscated but DMA-capable kernel source and I thought my TNT2U was finally going to have good 3d support). I decided I wanted to help out as much as I could, because I wanted fast games and hated Windows. So I joined XFree86, signed the NDA, and got access to the private mailing lists and such. And it wasn't long before I realized I had no clue what I was doing and wasn't going to be useful. I mean, I was fighting with configuring utah-glx. However, I'm an avid list-lurker and I stayed on.
Zoom forward a little, I swapped the TNT2U for a 3dfx and played with the DRI a lot, and started working on DRI for FreeBSD (the only operating system I run any more except for a couple of half-broken, ignored linux installs). This summer there were grumblings about the X maintainer being unreachable. I talked with my mentor and the portmgr folks and became the new maintainer. With that came the right to commit to the ports tree, for better or frequently worse.
I would never be the FreeBSD X maintainer right now if I hadn't been an XFree86 member for quite a while. The background of watching the lists and working with the DRI made me feel I might know enough to handle it. It's a steep learning curve, and I've sent in many, many botched patches. The sync-to-vblank patches I committed to the DRI were insufficient due to my lack of understanding, I've sent in patches that broke the X build on FreeBSD 4.x and 2.2.x, I've committed uncompilable code to the -current kernel, and I've added what later became panicing code to the drm-kmod port used on -stable. But I'm learning. And I think overall I've contributed postively, but I wouldn't have been this involved in these areas if the XFree86 project hadn't been relatively open when I first came to it. I certainly couldn't have made the vblank patches without XFree86 membership.
So I think that being open to new volunteers is very important, whether they contribute or not. If the project doesn't welcome anyone interested in helping, it will lose a lot of potential contributors. One thing that sticks out at this moment is the part of the webpage that says:
> How to Become an XFree86 Developer
> We are no longer accepting applications at this time .
According to David Dawes, probably the most well known XFree86 core member, this is because they are reviewing the member/developer idea for the project. Okay. However, there are still unwelcoming aspects. Go to the website and find where to submit an important patch. Well, there's the Bug Report page, which will send it to XFree86@XFree86.org. Things sent to XFree86@XFree86.org are not tracked, and I've frequently heard it referred to as /dev/null, a black hole, or similar. Of course all of us with clue who aren't helping respond to email@example.com (or the previous lists that merged into it) are responsible, but I'll cop out by saying I've been spending my support time on the FreeBSD lists and GNATS.
So, I think we ought to get a bug tracker. Somewhere that distribution maintainers can point people who have XFree86 bugs not specific to the distribution. Somewhere we can submit patches and track them, with associated state and comments, rather than submit them and wait for them to show up in the repository. Somewhere we could store interesting, mostly done patches that need some finishing but shouldn't be forgotten, or patches that should be discussed before committing. Maybe even a wishlist we could point eager new developers to (The Junior Kernel Hacker tasklist for FreeBSD has had some success). I would be interested in working on the support part of this. Some of the core team has expressed that they have very limited time and don't want to maintain it. Okay. The rest of us will work on it.
The limited volunteer time problem comes up repeatedly. However, volunteers who wish to have CVS access are denied because their patches are deemed not appropriate for inclusion. I haven't tried for CVS access myself, but I expect I would be denied. The fear seems to be that there would be chaos in the repository and that quality would drop. Yet projects like FreeBSD have 300 committers and we work together well for the most part.
What I would do right now if I was XFree86 core: Start mentoring committers. Offer commit access to people who have shown interest in working for XFree86 but haven't proven themselves. Any commit they do must be approved by their mentor before it goes in. Once they have a track record of proposing good commits, their mentor allows them to commit without explicit review. Mentees will work hard to propose good patches so they can be able to commit without the review hassle sooner. There is still the worry of commit wars. I think FreeBSD solves it well in their rules: If a committer disputes a commit, the person that did the original commit must back it out until the dispute is resolved. If they can't resolve it, it gets brought to core (who in the XFree86 case would have been handling the patch anyway). If core at any time doesn't like a patch, they demand its backout, and back it out forcefully and revoke access if it's necessary. (There are also limited penalties for premeditated rulebreaking such as sniping in commit logs, committing to frozen branches, etc.)
It would be tough at the start and take a lot of time from the current core team. However, eventually you should get more active developers and methods for managing when people make mistakes. Then the core team could do things besides handle all the little patches getting submitted. And I think this is necessary. Large numbers of people use XFree86 and there are people who want to contribute (see any of the other repos that exist and the frustrations of people who have tried to contribute directly). More users than for FreeBSD, certainly, yet there are fifty times more FreeBSD committers than XFree86. I keep hearing complaints that XFree86 is slipping, being unable to keep up with new developments and getting worse. Encouraging more active volunteers will be the best way to fight this.