- lack of clear leadership and even basic direction
At present I see most of the time volunteered by developers to be spent communicating with users on the bug db and trying to fix bugs. That sounds all well and good to me.
If somebody wants something big implemented that they cannot do themselves, let them compel ("lead") the others to want to work on it. If not, so be it.
scratch-an-itch development is fine and good, but not in total chaos
What is this total chaos? That everybody doesn't get in a room and map out what everybody is going to be doing? This is volunteer work. Some of us are spending quite a few personal funds this week flying somewhere to get in a room together and hash through some issues.
Sure, if everybody running their web site on Apache httpd would pay ASF a few dollars a month, things could change, and maybe some of us could spend our long working hours working just on Apache httpd. But that isn't the situation. And I am not interested in this turning into a big business. And for many of us, our day jobs are good influences on our httpd endeavors anyway, even while they take away time that could theoretically be spent making httpd the way you want it to work.
- cathedral development it appears that more than a few serious discussions have not happened on-list and instead happen on IRC or elsewhere (board rooms?) without apprising the list of what transpired. (Or have there been absolutely no recent design discussions?)
As someone who
1) follows development pretty closely
2) works for a company that has multiple skilled httpd developers and could conceivably host these "board room" discussions
3) hardly ever logs on to IRC, much less sees much discussed there when I happen to be logged on (ooh ooh new conspiracy theory!!!!)
I don't see this being a problem. YMMV.
- patch management many patches posted to this list or the bug db languish in limbo. Very little happens until a core contributor decides to take over a patch (more often than not it is more than simply shepherding it) Little feedback; it often feels like nobody's home to answer the phone...
This is a big hole which will be addressed, even if I have to quit my job, abandon my family, find shelter from the wind and rain somewhere that has WiFi access, etc. (No, not really. But this isn't a simple situation that can be solved by proclamation. We already have the will, we just need to have some procedures to help us focus that will.)
- insufficient (developer) documentation sure, there's the source, but it takes a lot longer to wrap ones head around the Apache2 paradigms than it did for Apache 1.3 BUFFs and such. The barrier to entry is much higher; solid design documents would be infinitely helpful
Documentation is a lot of work and largely thankless. If somebody wants better docs, they should be ready to post patches to what is there already. Or if they actually pay somebody for an Apache-based server, submit doc issues as defects to your vendor. Or pay somebody to do it. Or wait silently for somebody to do it for them.
- many new contributors are frustrated and discouraged
Hopefully keeping focus on patches will be a big help.
But I can't gloss over the fact that this is how new contributers become developers and then able to lead themselves to solutions for problems that they wish to see resolved:
Post patches for bugs that are central enough to core operations that existing developers will be compelled (and skilled enough) to review and shepherd them in. Keep doing it for a while. You'll get commit access. You'll be a "developer" and be able to fix other non-core issues pretty much as you choose.
Posting patches for something relatively obscure or not generally applicable is not the way to become part of the developer community. Some of these patches may find shepherds, but the surer path is to attack problems that affect everybody and/or are in areas that more people have the skills to review.
- dwindling community The apache-dev list focus on 2.0 /to the detriment of 1.3/ is at odds with the rest of the world that relies on the venerable Apache 1.3 - ...
1.3 works well enough for most everybody. That explains the situation well enough for me.
So where do we go from here?
*** We need better patch management
certainly!!!!!!!!!!
*** We need to get back many of the disenfranchised Apache 1.3 developers
Who are these people?
The better option is reopening the 1.3 tree. Release 1.4 and open a 1.5 dev tree, with the specific intent on having the 1.4 release eventually map _directly_ into a _seamless_ upgrade to Apache 2.x, with very easy and clear directions for using a reverse proxy for those legacy 1.3 third-pary modules.) While upgrading is not hard for developers, Apache is not a simple product. We need an even-better (tm) way to get users from There (Apache 1.3) to Here (Apache 2.x). Yes, more trees are extra work, but this community is rapidly deteriorating without them.
I don't expect any of the current Apache developers would be interested in this. But plenty of people join the development community over time (see previous comments) and theoretically the opinions could change.
*** We need to get more people using Apache 2.x
FWLIW, I have the impression that this is taken much more personally by non-httpd-developers than by we httpd developers. Maybe that leads to a certain confusion about why we don't put more effort into certain things (e.g., more doc for module developers).
Apache 2.x is not going to get any better than it is now until more people start using it in the real world (outside the lab).
It's happening. There are enough production sites using Apache 2 or servers based on it to show that it is good enough for many situations. Personally I am not disturbed if a very small percentage of the elephantine WWW is using Apache 2.
Note that there is also plenty of feedback from these experiences, we just need to catch up :)
Take care,
Jeff
