as of "project manager", I am unsure we are talking about the same, Joein this thread:
https://openacs.org/forums/message-view?message_id=352000
Matthew posted idea which seems to be really in good direction, but it doesn't refer to _package_ but to position Project Manager, I believe it is really worth to 'implement'
Torben and others mentioned the package Project Manager. But my point applies to either the Project Manager package (which is really cool, and would be impressive in any context) or a Project Manager person. It is not the lack of either that leads to bugs remaining in the bug tracker for months or documentation being hopelessly outdated.
I suspect what has happened with OpenACS is that the codebase is simply too wide-ranging for the current number of developers--there are areas that simply are not maintained and have not been for years. It is a project that once had a large corporate developer, and now only has volunteers and a few small corporate occasional sponsors. No amount of management can make the code smaller or the developers have more time to devote to their particular pieces of OACS. In fact, heavy-handed management in an Open Source project has negative results in the vast majority of cases--these folks aren't being paid specifically for OACS work, so no one can tell them what to do. (And anyone that wants to without being willing to do an equal measure is not worth having involved in the project. I've got my OSS merit badges from years on the Squid and Webmin and other projects...and in issuing these complaints, I'm volunteering to help fix the problems I'm complaining about.)
Anyway, there are two possible solutions to this problem, and they're both really simple (but hard), and only involve management in the sense that someone with the right privileges here at the website has to make them happen:
- Increase the developer-base. I know this is what this thread is all about, but a glossy website isn't going to overcome real problems. And bringing in developers with big promises only to have them leave frustrated by even the simplest experiments is not going to increase the active developer-base.
- Decrease the code to a size that can be managed by the current developers.
I suspect the latter will be required in order to achieve the former.
