Well, I've spent about 10 years writing programs to process text files into very efficient processes (working on world-class optimizing compilers), and about 10 years writing programs to process very large, very complex database files very efficiently. Everywhere I've worked, I've been the one other programmers ask about the really complex performance issues. I'm not that easy to impress technically. And I've been extremely impressed with the ODP technical people.
On the other hand, anyone whose level of technical expertise is limited to "text files bad--databases good" certainly impresses me, although in a different direction. In the real technical world, every design decision is a tradeoff between efficiency for particular classes of operations, efficiency for other kinds of operations, and maintainability. Flat files are obviously much faster for some things; databases are easier for some things. But there isn't anything a database can do that you can't do faster with a flat file -- if only because all modern databases are built on top of flat files, and any CS graduate should be able to hand-roll an efficient database structure in a combination of files and memory. A naive user (or hey, for that matter, an ordinary technical expert) simply can't tell by watching optimized processes what the underlying technology is, let alone how it's being used: it's only when one starts pushing the limits that one can begin to deduce what kind of limits are present, and therefore what the technology was optimized for -- and maybe, just maybe, get a clue to the optimization approach.
In the real world, putting together a Lego model of a transmission doesn't equip you to design transmissions for diesel machinery. It is, at best, preparation of a mindset that (in a sufficiently intelligent and motivated mind) could receive an education that would prepare one to help tweak different types of transmissions for several years -- and then maybe, just maybe, be able to have a clue about what attributes a transmission for a big rig needs.
The ODP design decisions have vindicated themselves in the only way that matters: the original design cruised up to a factor of four beyond its original design limits; with a slightly faster computer and offloaded public access, it is still cruising. "database access" has been near-utility grade; database performance has been (except for when it hit the wall) almost always spectactularly good. During that time, we went through one horrendous file format change (ascii to utf), while maintaining essential user access. It has proved effective at doing what editors need to do most, and extraordinarily efficient at doing what editors do most often.
Anyone who has ever written performance-intensive code for a 50-to-100-million record database is cordially invited to make suggestions. Anyone else is cordially invited to visit the nearest university with a CS department and looking for an opportunity to begin the decade-long process of learning the ability to form a technical opinion worth listening to.
I think we need a test to give people who want to make process or program suggestions to the ODP. It needn't be very difficult:
(1) Have you been reading Dilbert cartoons daily for at least five years?
(2) How many times in the last five years have you not "gotten" it?
(3) How many times in that time have you not thought it was funny?
If we required answers of "more than five years", "less than 5", and "less than 2", then ... I don't think we'd have lost a single sensible suggestion. Because most of these suggestions -- Scott Adams wrote them up long before we ever saw them.
<added>That editor being quoted may have been me. If not, it could well have been me: it did not misrepresent what I would have said. And I should at least express my appreciation that someone cared enough to take the trouble to understand and paraphrase an ODP position. (In the SEO forums, misrepresentation is ubiquitous -- and whether caused by venal malice or mere technical cluelessness, it is the opposite of constructive.) But -- as for any kind of experience, there is only so much of an answer you can comprehend if you've never actually wrestled with the question.
