Every list posting is potentially a problem-solver for many people, either now or in future. I have staff scanning the lists for questions and answers that could help others as FAQ. My searchable online FAQ database is updated frequently. As a rule, I will not answer support questions personally.
Occasionally, you might encounter a problem that the list can't solve. In that case, I will invite you to e-mail a simple sample project to me demonstrating the problem. Please don't send me files otherwise.
There is an extraordinarily high level of expertise and experience among IBO users so, for this reason, I do not encourage people to post messages demanding that only I answer. Many hands work with IBO in a huge variety of ways. Since the IB code was open-sourced, we have a number of people in our community who are a lot closer to the action with the database engine than I can be. Never count on me to be the person to give you the best solution.
Bug Fixes & Feature Requests
I would rather know about problems (even potential ones) than continue in ignorance. Loading me
down with additions to the bug list and the wish list is fine. However, I can only do so much - so, if you want things implemented more quickly in IBO, I need you to go the extra mile beyond merely pointing things out.
When reporting a suspected bug, please help me and yourself by doing more than merely point things out. You simply cannot take it for granted that I can set up your unique conditions as a test case. If you leave me with a tremendous amount of wading to do in order to set things up, it is usually extremely difficult - often impossible - for me schedule enough of my own unpaid time to reproduce your problem.
Some people express the view that, because I know my components inside and out, it should be simple and trivial for me to test and fix your problem or to try out your idea for a new feature. Don't assume that. If a problem or potential feature is totally obvious to you, then it will be so much more simple and trivial for you to construct a test project that demonstrates it. This way, not only will you save me hours that I don't have to spare but you will point me directly to the heart of things.
Time-lines and Deadlines
In the past I have succumbed to pressure to add a feature here or there, when I should have been more aggressive about freezing my versions. I allowed this practice to delay the full release of v.4. Some users have been "spoiled" by my attitude to this and continue to demand features without fully exploring what is already possible.
Continual sub-releases with minimal gains to the general user base appear to do more harm than good. Some users get very upset, some start to doubt the stability of the product. Unfortunately, too often in the past, it has been the squeaky wheel that got the oil, while I paid too little mind to those who want to stop for a while with a stable, predictable release. I need to be more disciplined and avoid this "feature creep" that has become so prevalent in recent months.
That does NOT mean I'm planning to stop doing any sub-releases. If a significant bug turns up, I will continue, as before, to find, fix, test and turn out a sub-release as fast as I always have done. But it is irritating and unproductive when people press me continually and noisily about when a certain thing will be done, without backing up their requests with a useful demo project and some evidence of need for it. If a minor fix or feature really means something to someone, there is no reason it can't be done if the person is willing to help it forward. The more a person's actions demonstrate to me that s/he is prepared to do what it takes to get quicker resolution, the better cooperation and accommodation s/he will have with me.
Many IBO developers have learned how to work with me along these lines and it is great. We all save time and increase productivity when cooperation is at a maximum.
15 January 2002
Charged private support can be arranged on request. To initiate a support arrangement, please contact me by e-mail.