Oh I see. I'm only vaguely aware of what maypole actually is (something to do with web apps?).

I don't have any call for such a beast, but if I did, I probably wouldn't use anything so complex. You just give yourself the other type of maintenance nightmare.

That of becoming dependant upon a complex framework, which makes your life simpler--once you get past the learning curve--provided it is bug-free and you can adapt your requirements to the solution it provides.

The problems arise when you encounter a bug or limitation that is critical to your app but doesn't make it to the top of the "needs fixing list"; or you need something that doesn't quite fit with it's way of working, or the authors preferences.

You can always make local patches to correct those problems you encounter, but if they go against the authors preferences or pull it in a direction the author is not interested in going, you then have to integrate your local changes with those made by the author at each release.

For a simple package that is bad enough, but as the dependancy chain deepens, so the number of authors grows, and the problems of coordinating local changes get ever worse.

I once read that the time required for a project grows as T**n; where n is the number of non-overridable decision makers involved. The same holds true for the number of independantly controlled interfaces.

If they do what you need, your laughing, but if they start to diverge from your requirements, or worse, each other, you have a nightmare.