1) Complete and fully-functional working programs in executable form as well as complete source code of all work done. Source code must be in compilable condition, so we could use for example our Microsoft Windows Driver Development Kit and Microsoft Visual Studio 2005 and build driver. This is to be clarified, but hopefully all necessary headers to compile IFS shall be present within source code. For example open-source ext2fs for Windows driver could be compiled using DDK. Less dependencies - better!

Unlike FUSE we also need interface for asynchronous operations (i.e. messaging/request-answer queue model). This will be major difference with FUSE interface. In case if data is not available immediately we need a way to 'postpone' request from operating system and produce answer only when data will be available. That could happen within milliseconds or within 5 to 60 seconds.
Data presented as a drive letter in Windows will be collected from different sources, some of sources have high latency. Call with a delay of 2 seconds to one file shall not be bottleneck for calls made to other files which are served faster, if made from different userspace processes accessing filesystem.
Consider that it should work well if different ftp folders are presented within one virtual filesystem as a drive letter. And when different application access files on different ftps they should work "in parallel" but not stucked by slowest one.
2) Deliverables must be in ready-to-run condition, as follows compiled kernel driver for Windows XP family of systems, compiled userspace DLL library, compiled demo application (simple disk with Hello World file - example how to use APIs) and stress-test application that will demonstrate abilities and stability of DLL and driver. Application should have be single executable. DLL should contain calls that would install driver within the system automatically.
3) Delivered stress-test application shall do following tests:

• Coverage for all file operations.
• Ability to simulate randomly different file I/O calls.
• Ability to stress-test using a lot of I/O calls launched from multiple parallel threads, actual validation of solution will be performed on 2-processor computer.
• Ability to fail certain low amount of userspace-driven filesystem part calls with error or with timeout and check for that handling in stress-testing part.
• Minimalistic GUI that would allow us to set number of threads, calls to make (i.e. percentage of errors, calls, etc.), and launch full-time stress-test.
• Goal of these different tests is to PROOVE correctness of your implementation.
• During tests number of threads should be as high as needed to be able near full load on kernelspace <--> userspace linkage, i.e. prooving that solution works stable 24 hours with only 1000 kilobytes per second when CPU load is 1% transfer is a weak proof.
• Implementation without such correctness proof that would not confirm working 24 hours without a failure while running stress-test at full kernelspace <---> userspace bandwidth will be considered unstable and will be returned to Developer to continue testing.
• Stress-test of massively parallel handling of calls (i.e. read call delayed by 100 milliseconds and launched 50000 times per second, having 5000 read calls performed in parallel). That should not make any difficulties.

4) All deliverables will be considered "work made for hire" under U.S. Copyright law. Buyer will receive exclusive and complete copyrights to all work purchased, except for GPL/LGPL license issued to public. The software shall not be based on any GPL / LGPL or any other licensed code. Producing interfaces compatible with FUSE is not considered as derivative of FUSE. It is not derivative, it is separate project, COMPATIBLE WITH FUSE.
5) Buyer respects opensource software movement. Buyer encourages to publish produced program with all source codes under GPL/LGPL license on sourceforge.net under name fuse-win32 and maintain indepentently this FUSE-compatible API for the benefits of opensource community. Buyer, as copyrights holder, allows Developer to put his own name and to grant to 3rd parties usage under GPL or LGPL terms. Buyer however uses software without limitations of GPL, and only Buyer CAN use the software without limitations. The GPL perfectly allows such exceptions as it does not limits copyright holders rights. This should encourage Developer to implement stable solution and gain his online reputation.