I looked at the active projects on OpenNTF, and extracted a few which relate more or less to things already implemented using IDF, mostly in tools we use internally.
Please keep in mind that these are not parts of IDF, but stuff we developed in time for internal use, so don't start looking for them after downloading the IDF code and databases (although some parts are readily available in the download - I wish you happy hacking, if you're interested …).
These tools received no attention as commercially valuable assets from our management until now. So it might be that if you ask for them, I'll be allowed to make them freely available. But this is a long shot, and it's not really my call.
(Did I mention that using IDF without helping tools would probably be a traumatic experience even for the developers of IDF? Fortunately, the only critical tool is a pusher for LS libs, the rest is manageable manually in a satisfactory way.)
DbReCompiler
We have some mechanism which is pretty much IDF-independent for maintaining databases in a locale-independent way. We more or less build and maintain databases manually tagged (somewhat like like DGW tags them, only we use more readable and expressive tags), then run a tool which translates them to any given language for which translations are available in a repository. The whole translation ends with a full recompilation of all databases. There is a class DBSet and a class IDFDatabase, which were designed to allow various operations you perform when doing a deployment, such as copying databases, copying configuration documents, applying templates - and also recompiling LS. The code still has some bugs, but is completely usable - all deliveries and setups we do are made using this code. <br/>
Letter Engine
We have a set of libraries which does just that. Based on templates, in collaboration with Word, it can generate Word documents then import them into Notes rich text fields and send them by mail or print them out. Usable also for labels printing - it's all in the template. <br/>
Code Inspect
I initially wrote a simple parser because we needed something to extract documentation a la Javadoc from LS code. Then a colleague took this over and changed it to generate help documents a la Designer help (much of the IDF help is generated this way, the code should still be in there). In parallel, I wrote something which also does a parsing, but across an entire set of databases building up an application, and counts lines of code per function/method, class and library, and avoids parsing the same lib/class/method twice if it is found in two different databases - which with IDF databases happens a lot. It would be easy to add searching capabilities to these parsers. (Our initial goal was a lot more amnbitious: write a LS parser enough good to be able to build a syntax checker atop of it, then move all LS code writing to Eclipse, and have all goodies Eclipse provides for LS editing too, like decent autocompletion. We gave this up, however, because there's more work than we can afford to finalize such a tool.)<br/>
LotusScript tool to parse and create JSON
We often need to transfer data between various representations. To pass data from the server to the browser, you have to convert it to a string (or to a string array). To put some generic data into a document, you need to convert it to fields in a Notes document. To export it for other apps (or import from other apps) you often need to convert it to XML. So whe have developed a class which is significantly simpler both to use and in its structure than XML DOM trees, but is very much alike with these, and which can be used to store any data structure - at least we found nothing until now which is not storeable into that class. Then we developed other classes, one per format, which are able to convert to/from this internal format. So putting anything which already has a readwriter class for this format into JSON is simply a matter of writing a JSON readwriter.<br/>
ASND Mass Mailer
Customer MailMerge from within Notes
This is not so close to IDF. However, on one hand the Letter Engine-related code mentioned above has support for expanding the same template using several sets of parameters, and we use this facility in one of our applications (which you can download as a demo version) to provide specifically a mass mailing facility. Note to those suspecting us of spam: that's not what it's used for, but customers use it for christmas mailings or newsletter-like functions, for instance.<br/>
Code Library
DesignCatalog
We took a different approach. We wrote ourselves something like a source control tool but which also knows to push design. So if you have for instance the same script library in several databases, you can tell the tool it is the same code in all databases. Then, in order to work on this lib, you need to tell the tool in which of the databases to lock the lib. While the lib is locked, you cannot edit it in any other database than the database where it is locked. Also, the user who locked the library is the only person allowed to edit it. After you have locked it, you do your work, then check it in. At check-in time, the tool propagates the changes to all other instances automatically. Also, the lib is exported as XML and placed under CVS, so you can later restore older versions, or compare changes from version to version, etc. Now, code being organized in libs containing only related classes, we do not feel the need to manage individual classes or functions. The tool actually doesn't care whether the design element is a lib, a form or a view, it handles all design elements identically. This allows for a pretty solid code sharing among various databases and applications.<br/>
Template Manager
We use three tools for something similar. First, there is a database where each delivery we prepare for a customer or just for having a snapshot of a stable version of an app. Second, you can generate setup databases from these deliveries, which can be used to either create a new installation or update an existing installation at the customer. Third, there is a database where we can do deployments, can do snapshots of existing deployments (including data, not just design), can back up just the configuration then restore it later, can restore snapshots, manage replicas and so on. This database is used by our testers. Drawback is, all these tools work only with IDF-based applications.<br/>
OpenLog
IDF provides a logging facility very much alike with the Linux system log: you specify a facility, a severity level and a log, and every matching log message gets into that log. However, you are not restricted to text files as log support, but can use all log types provided by NotesLog and also specify logging as message boxes. You do not hard-code the details about the logging into your application, you just log messages with a particular severity and for a particular facility, and the configuration decides where the log message goes. But this type of logging is only intended for debugging. For application logs at the customer, we have a nice log, also supporting severities, which can be embedded into all applications, both IDF-based and non-IDF-based. However, the class implementing the logging operations is based on IDF, so the place from where you log must be IDF-based.