I second this thoroughly. I was was almost driven to start blogging last week by ASF's poor job of maintaining its projects. There was a small bug in Solr. I was not the first to find this bug, and someone had not only reported the bug, but filed a patch on the bug tracker a year and a half ago. The patch was never merged in, nobody provided any feedback as to why the patch wasn't merged in.
One huge plus with Github is that if the official steward of a project would like to hand it off to someone else, or is failing to maintain it, it is trivial for someone else to take over the project.
So your problem is not with the Apache Software Foundation but with the committers of Apache Solr. On Github you can do a pull request and it never being accepted, so same result as your experience in Solr.
As you say it's trivial to someone to take over the project and maintain it but not trivial to anyone to find the right fork of the project when a project has 100+ forks.
I find it ironic that your first post complains that the author is comparing ASF to a sand box, but then you go and suggest that GP should just fork a project. I think you really are missing the point: sandboxing is a bunch of people just forking. A community is when those forks are then cherry picked and re-integrated. Subversion is shit at that. Git is awesome.
I have no skin in this game, but if I were to look at the requirements as you describe them, I'd recommend using git and think you were crazy to use subversion.
I'm not the OP, but if something raises my ire almost enough to make me blog about it, it probably isn't going to irritate me enough to fork a large software project. But the lower the bar for submitting a patch, the more likely you'll get one. And the more everyone will benefit from it (assuming it's a net positive patch).
It can sometimes be hard to fork a project just for a patch to one simple bug. Once again, GitHub really shines here: you can go to any project and see all of its pull requests, so you don't have to go hunting for patches attached to bugs, and it becomes quite clear and public when a project isn't properly or expediently merging in patches.
The GitHub layout is really telling of the new open source philosophy. They put the code front and center (main page), and right above it show you with first class status all the bugs it has (issues link) as well as all the proposed changes (pull requests link).
While forking is a solution, it hardly precludes discussion of other less drastic potential solutions to the problem at hand. It does nicely bound the maximum negative impact that Apache social problems can cause, though.
If you're using git, as the OP suggets, then you're going to fork it just to work on it. Forking isn't dramatic. Code is open source for a reason. If you have a critical bug in code you need running in your infrastructure, take ownership of it and fork it. Then do the dirty work to get the patch pushed back up stream.
If the maintainers really aren't doing what they volunteered to do, then volunteer yourself and get it done.
There isn't One Answer. The point is, you have plenty of alternatives. I don't know why the patch hasn't been applied. I know how I can find out though: I can join the developer mailing list and ask. If that doesn't work, I can track down a developer directly (they're not hard to find once you're on the mailing list) and bug 'em until I get a decent response. If it's clear the maintainers aren't doing their job, raise hell on the mailing lists and push to become a committer yourself so you can do the job right.
While that's happening, you can take the approach of maintaining your own patches so that you're not beholden to anyone in particular.
The whole point of open source is empowerment, not entitlement. No one is entitled to get any bug fixed. It's great when it happens but ultimately, everyone is empowered to make things happen themselves.
So you do agree that there are options beyond forking it or merely "raising a ruckus on the mailing list". My point was precisely that there are additional answers and that just glibly saying "Well, just fork it or accept what the mailing list result is" isn't a good summary of the alternatives, and in the context of what you were replying to borders on deceptive.
In the meantime, the fact that I am rich with options doesn't negate the original discussion, which is that the Apache processes are becoming distinctly suboptimal for the context they work in. The fact that I can just take the software and run with it doesn't fix their processes, and the fact that anybody can do so doesn't excuse broken processes. The fact that we can fork does not mean everybody should just stop discussing Apache processes; it doesn't follow.
I'm still in context: "I was was almost driven to start blogging last week by ASF's poor job of maintaining its projects. There was a small bug in Solr. I was not the first to find this bug, and someone had not only reported the bug, but filed a patch on the bug tracker a year and a half ago. The patch was never merged in, nobody provided any feedback as to why the patch wasn't merged in." "You can just fork it" is not an answer to this problem. I'd say in its own way it's a disguised confession that in fact the problems with the project are indeed so bad that your only hope is to fork it yourself. Well, that still says bad things about the project, regardless of whether I have mitigation options.
Because you act as if a "fork" is a drastic choice, when the reply calmly explained that "fork" doesn't have to mean "hey, let's create a new project and try to poach users into abandoning the original one".
The answers seems to be frank, and based on having absolutely no knowledge of Apache, maybe an appropriate one. It seems like they have a process that works for them, and they are quite interested in continuing with it. And that's fine. For people who want a more (for the lack of a more succinct way of expressing it) Git/GitHub style project, they can fork it and hack away to their hearts content.
That doesn't preclude upstream adoption of code, and it doesn't preclude discussions of improved workflow within ASF.
One huge plus with Github is that if the official steward of a project would like to hand it off to someone else, or is failing to maintain it, it is trivial for someone else to take over the project.