David, I wonder if you could explain more about your project both here and in your wiki? It sounds interesting, but I usually like a bit more information before I download and unpack files from the internet. Here is the kind of information that would encourage me (and others) to take a look:

• More detailed overview/feature list: OLAP is a big topic and can mean different thinks to different people. I'd like to know what you mean by OLAP and what part of the problem you are providing support for.
• Resource and system requirements: Even "pure Perl" can have lots of OS dependencies. For example one might make assumptions about how globs work; command line arguments, path name syntax for files, file locations, and more. See perlport. Before I download a package from an unknown developer, I like to know that the developer has thought through these issues and whether his/her project will fit my system.
• API documentation: This helps me understand what is in a package and assess whether it might meet my needs. It also gives me a clue as to whether the package is well enough documented to allow me to get up to speed in a reasonable amount of time.
• Source code: On line source code also is a big plus because I can inspect it and see if I trust the style in which it is written. If you want volunteers or monks who don't know you personally to give you feedback, providing access to source code that doesn't require downloading files is likely to substantially increase your chances of getting what you want. Notice how CPAN lets you click through to the source code for any module?
• Team: Is this a solo project? A team effort? Does it have organizational support? Do you want volunteers? If so, what are you doing to find them? I'm going to evaluate a project differently based on the number of players involved and what the project is doing to get more people involved, if anything. I will also offer different feedback and advice because teams and individuals have different resources and options.
• Place in life cycle: Is this pre-alpha? alpha? beta? release candidate? Do you have a release schedule? How stable is the API? I like to know whether the code I'm looking at is mature or preliminary. It isn't a case of right or wrong, good or bad. Explaining your status helps your potential users set reasonable expectations. If I think a package is finished, I'm going to rather harsh if the code is poorly organized. I'll also be very mad if I use the software and the API changes underneath me. On the other hand, if I know the code is preliminary and the author wants feedback and I have the time and interest, I'll do my best to help improve the code. It also helps you attract the right volunteer help: some people like to get in on the early stages. Some people have a taste for the hard work (both technical and social) of incrementally improving an existing codebase.
• Testing strategy: What are you doing to test this software? Do you have a test suite? How large? Are you relying on ad-hoc manual testing? A combination of the two? If so, why? Do you have beta users?
• Bug tracking and maintenance: How do you handle bug reports? How can someone reporting on a bug follow its current status or submit a patch?
• Licensing plans: There are many different open source licenses. Some allow commercial use and some don't. Some try to own the program that uses them. Some only cover the actual project code. Which one do you plan to use?

I hope to hear more soon.

Best of luck, beth