The feature set of ORF 3.0 is finally getting a solid shape and we are going to publish the development roadmap for 3.0 and maybe the version(s) after.

As the first ORF Software Maintenance Agreements are going to expire on December 1, 2005, it is pressing to let our clients know that renewing the agreement is a good investment: they are going to get improved software for their $99. And definitely we have to give 3.0 a deadline and tell about the expected features.

Now let us forget about how much I am concerned about keeping the deadline (man, it is tight!) and about feature selection, but I am also concerned about our competitors: is disclosing our plans to the competing companies a good idea?

Not that we have some mysterious super-secret technology on stock that is going to change spam filtering for once for all (but we do have a few good ideas :), it is just that our competitors are usually larger than us. I mean, larger by factors. They can easily do in weeks what we do in months and so they can entice our clients by giving them the features earlier that we want to give.

Regardless concerns, I think it is pretty much clear that our clients are first, we must tell them what they are going to get for their money. Competitors are our concern, not theirs. I feel quite naked, though :)

Come on Borland, you can do it better. From the Delphi 2006 page:

• The ultimate productivity force-multiplier for Windows® development
• Ensure visual consistency with customizable VCL designer guidelines
• Easily deploy persisted applications with executable state diagrams
• Seamlessly reverse-engineer, migrate, and re-use existing code

430 downloads on the Getting the most out of ORF guide till 6:00AM. Not that I expected more, but this is far below the total number of clients the guide was sent to. And then we have not counted those who opened it multiple times or used a download manager (with multiple download threads) to download the PDF.

Configuration guides might not be the best way to get client config right, but due to complexity of configuring ORF, this appears to be the only reasonable way. Everything else that I can think of is much more limited, including wizards or downloadable configs. These cannot get the DNS, the IHL or the filtering point selection right, although these are the major reasons for lower ORF performance, by my experience.

I have been working on the new feature set of ORF recently and invented a proprietary method of compiling a feature set.

First I carefully harvested all major feature requests from our 2005 survey data (yes, your voice is heard :) and compiled a nice OpenOffice.Org Calc table. The rows consist of the following:

• relative weight (determined from the number of requests)
• estimated cost
• realistic estimated cost (optimistic cost multiplied with the very optimistic number of 1.8)
• relative price/value ratio (calculated from cost/weight)
• feature name

Now I am at the second step, which means that I am considering to throw away the rating part of my highly scientific table and trust myself that I can pick up the features needed by the users, just likely I did previously. Tables just do not seem to work, even if they are beautified and professional-looking, because they barely have any intuition.

Anyhow, estimations were useful. For example, I have learned that I will need 593 optimistic and 949 realistic days to implement the features requested, which means that we can complete all requests in 3 to 5 years.

Cool! Impossible is our business, I cannot wait to get started :)

Finally, I shortened my to-do list a little, now it is not much longer than the collected works of Shakespeare, although it is definitely less amusing.

The Getting the most out of ORF guide has just been sent for proofreading to Dave to fix the Engrish stuff I carefully inserted to the script.

This is an Insider Blog, where we leak highly confidental information for what we could get fired, so I disclose the highly confidental information that the above guide is a summary of suggestions to get the highest filtering performance out of ORF with the lowest number of false positivies, i.e. to configure ORF the best possible way. I have a little doubt whether we can reach the target audience, but anyhow, I am glad that we finally managed to write this guide, we should have done this years ago.

Ah, yes. This is my first blog entry in our brand new Insider blog. Welcome :)