Compared to most other open source projects, we have quite a large number of committers. And in addition to that, we have a healthy number of people submitting patches and bug reports.
However, in contrast to pretty much every other open source project out there, we don't have a project leader. This is awesome. And it sucks. It is awesome because when it works well, everyone is equal. The best technical solution wins no matter who proposed it, and work doesn't get bottlenecked by an overloaded authority. It sucks because when it doesn't work, every little change becomes the subject of bike-shedding or outright blocking. It's death by consensus. This can be very frustrating for committers, because every discussion about a new feature can get different consensus every day. And a single person can block your work for weeks. And if it is frustrating for committers, it is doubly so for patch authors. Partly because of the above reasons, but also because they don't know how we work. Patches are dropped in a black hole and "nothing happens" until he starts whining on IRC, in which case he might be dismissed one day and encouraged the next. I agree with Alex that this is not a very efficient or new-developer-friendly model of development. It costs a lot of confusion and frustration which is likely to discourage people from contributing. Therefore I don't think it's productive to dismiss Alex' suggestion with "this is just the way it works". We do have a problem. We have already discussed it on devcon, on the mailing list and countless times on IRC. We just haven't been able to come up with a better model yet. I very much agree with the basic idea that any assistance in making our ad-hoc process more transparent and understandable can only help with alleviating pain and frustration on the part of patch authors. -- Björn
