I'm not saying that Maypole is not capable of complex things, but there are quickly diminishing returns once you stack more complexity on Maypole. Maypole gives you a quick start if your application fits well into the Maypole model of things. It makes no sense to use Maypole instead of writing your own framework if you have to either bend your requirements to make them fit to Maypole or if you have to bend Maypole to have it fit your requirements.

And as there already is a good ticketing/tracking solution, I would not waste the time by writing and expanding my own solution but rather use the existing solution.

i totaly agree with that. all i tried was explaining, when to use maypole. i tried that in one sentence because i'm lazy, and of corse that was going to fail...
so here's what i wanted to say ... just a little more verbose.

Maypole tries to build every action you can perform by applying methods to tables. so you can create, remove, update and display entrys from a table, list or search complete tables and so on. however, starting with these simple build-in actions you can build quite complex things.
but if your application in some sort of way has problems with that architecture, maybe maypole is not realy what you want .... or maybe you just didn't yet find a nice way of building you app with that model :-)
agreed with that corion?

however, the next incarnation of maypole will bring you a more versatile version of what maypole is now. so it will be able to do virtualy everithing.

i think time will tell what maypole is able to do and where development will go in the future. at the moment i'm involved in some big (but not complex) projects and i'm using maypole successfully. but ASP.net coders say/think that, too.....