Screenshots: open, save and matching documents. Download the code from here.
I wasn't saying that something along these lines couldn't be developed as proprietary software. I meant that, as a hobbyist programmer with other interesting things to do, I could never have built such a system from scratch if I couldn't make use of many hundreds of thousands of lines of free software code. Since the cost of implementing newdocms on top of free software systems is much lower than the cost of the alternatives (eg, write an OS from scratch or perhaps license code from Microsoft or Apple), I think that this sort of innovation (ie, someone has an idea and implements it at the OS level without having to write/"buy" and entire OS) is only possible for individuals thanks to free software.
Other issues that have been brought up:
TheBrain: I just installed the beta version of this app. It looks great (and ready, too, something that newdocms isn't meant to be!), however, as far as I can tell (after using it very briefly) it neatly illustrates my point: this isn't integrated at the OS level. To access a file through TheBrain, you need to go through the application: you can't simply fire up any Windows app and access your files directly, nor can you save your files into TheBrain if the application wasn't started from inside TheBrain. (Perhaps I am wrong -- as I said, I only had a very brief look at it.) That's precisely what I meant with the (admittedly poorly phrased) comment about the importance of free software: if you aren't free to modify the underlying system, you'll never get a chance to do it in a fully-integrated way.
"In a HFS it is easier to find often-accessed files": newdocms offers shortcuts, "simple text strings which act as keys to retrieve often-accessed documents". This mechanism complements the attributes system, and is meant to address precisely that sort of criticism.
"Using newdocms requires a lot of discipline": So does a HFS when used right! Just as (in newdocms) you can save a document as "uncatalogued" (ie, no metadata available), you can save all your documents in a HFS under the same directory with irrevelant file names. The result is similar: in both cases it would be just as hard to find what you are looking for. The main difference is that with newdocms the metadata you do provide is much more useful when later you try to find your document.
"It would be great if this worked with emails, too": I know! In one of the TODO files there is a reference to "integration with KMail"...
"What about multi-user systems/networks?": Currently newdocms only supports a single user, because the metadata defined by a user is only available to that same user (since it is stored as a file in the user's home directory). Future versions could include support for work-groups (and remote access) through the use of a true database server to store the metadata. Combining that with the storage of the documents in a public location (and the use of file system permissions) both data (the documents) and metadata could be selectively available to multiple users.
"Wouldn't it be much better if there was a way to automatically catalogue documents in an accurate way?": Yes, it would. A compromise (between automatic and fully manual cataloguing) could be achieved through support for "document templates": the user could define a series of attributes which, by default, apply for all documents of a certain kind (eg, "letters to my boss"). Then, when such a document was saved and marked as a "letter to my boss" all the relevant attributes would be automatically defined, although the user would still have the chance to modify them or define others. (Actually I did implement this feature, but discarded it because I mistakenly concluded that document collections made templates useless...)
"All metadata is lost when a document leaves the system!" (Or: "When you import a document you have to catalogue it for yourself, even when it has already been catalogued by someone else on another system!"): newdocms doesn't currently support the transmission of metadata together with exported/imported documents. That is a very important feature if such system is to be adopted, but I needed to get newdocms working before I worry about how people using newdocms share metadata. :-) Besides, some level of user intervention would always be required when importing a foreign document, because different users might have different category trees and mapping a user's concepts to those used by another one is not a task computers can currently perform.
"newdocms isn't 'fully-integrated' with all applications, nor does it really work 'at the OS level' (eg, command line programs don't work)": That is true; newdocms is intended to work with graphical apps, so what I modified was the GUI system (presently there is support only for KDE). However, I would venture saying that -- since using KDE (or GNOME) in GNU/Linux and *BSD is pretty much the same from a user's perspective -- for my purposes the "OS" is actually the graphical shell (or desktop environment) which intermediates virtually any interaction between an average user and her computer. For that reason, I feel inclined to stand by my statement that "newdocms works at the OS level", even though users of 'grep', 'find' and friends will disagree with me. Those who use such UNIX CLI tools on a regular basis (eg, programmers, system administrators, etc...) and whose work relies on a fixed directory structure (eg, source code trees, system configuration files, web sites, etc...) might therefore consider newdocms not very useful.
"BeOS already allowed you to specify arbitrary file attributes": I never used BeOS on a regular basis, but as far I can tell although BeOS did allow you to specify file attributes it didn't use them as the standard way to browse and organize your documents: that was still done through the HFS. You can regard that either as a limitation of newdocms (afterall, it isn't possible to browse your documents in the traditional way) or as meaning that newdocms brings something really new to this discussion. Specially given its support for "concept attributes" and a category tree, I opt for the latter... but then I am not really the right person to give an opinion on that issue. :-)
"The interface is difficult to use and ugly": I know! Do you want to help me do something about it? :-)