This is a classic "do this for me" situation. It's very unhealthy: Imagine a school student who doesn't understand how to write a simple script. Someone else writes it for them, and this original school student now gets the complete credit for the working script.
It's the same idea here. Contributors are literally providing code to a project, where an inactive person is literally getting all the credit. I hate to say this, but you've really been doing free work for this "manager".
Right now, contributors have been writing code, satisfying the needs and wants of the manager. It sounds like a workplace environment: you need to "do this and that" by "so and so date", and that's very unhealthy. From what I understand, it looks like it's been near impossible if contributors have had interests that they wanted to have in the project. Is the "manager's" agenda going to stop that? If the manager doesn't like it, he'll say no, and you will have one unhappy contributor.
The "manager" is just meta-managing, and I don't see any incentive from him to start contributing anytime soon. By setting schedules and goals, he sounds more interested in the logistics of the project, rather than the code base, which means that by contributing, he'll just be a "newbie." One that will have to be taught the base step by step so that he can start making some minor changes.
From the comments, it looks as if the "manager" has others' approving commits, and acting like maintainers to the project. This just worsens the "manager's" position: that he has no sense of the quality or efficiency of the contributions to his project. It shows a lack of commitment and dedication to the project, in that the maintainer doesn't know the internal structures of the code base. If he were to issue a drastic change as a part of his agenda, it may not even be efficient for the contributing to try to implement such a change, as it wouldn't be efficient. Such workarounds would just dirty the code, making it unattractive, and after a period of time, unusable.
I understand that you want to make this work, and I applaud you for that. Many people would literally just give up, so this shows that you still have faith.
Take the time to reflect:
- Is contributing to the project worthwhile? Is benefiting you?
- Do you have a sense of pride or ownership in the project?
- Is there clear communication? Are you, as well as other contributors, able to discuss segments of the agenda?
- Do you feel like you have a voice - that you can raise your concerns and ideas without having any doubts in mind?
If you answered no to any of the questions (especially the last), I would say that there is ground for concern.
In that case, I would recommend the following:
Communicate with the other contributors.
Do other contributors share your concerns? What are these concerns? By collaborating and communicating your thoughts with other people involved in the project, you'll understand the feel and attitude. With people that are basically equal to you in the project hierarchy, you'll feel more at ease to do this.
Talk to your manager.
Figure out your manager's position? Chances are that there could be a reason as to why he doesn't contribute. Does he feel like the project is advancing? Get a feel for his point of view. This will allow you to share and think about any concerns that the two of you have. Once you feel like you've got more information, you'll be able to make more rational decisions as well. Ask him why he still maintains this project, and what his driving force is for setting goals, objectives, and timelines, as well as keeping the repository under his name.
If the community begins to have a sense of understanding, it will improve. Open source development is something I find similar to community development: the project is a collaborative effort between people who share the same ideas and goals, and who wish to improve something.
If all else fails, and you (or other contributors) feel dissatisfied, fork the project. This does you no harm, and you will have more of a say in how the software can move forward. There are still people involved that will be able to support the project. If you do this, I would make sure to say why, and to outline all your concerns, as well as (briefly), any efforts or attempts that you have made to rectify them. Have fun with that new project!
Regardless of the action that you take, keep an open mind. Be open, think positively and think straight, and make sure that you put your best foot forward.