I can tell you that the price is likely to remain the same for the forseeable future.
As far as the future goes, we don't have firm plans at the moment: we're still waiting to get more feedback on the current version. We think we've produced an application that people can really get some good use out of. I can tell you there'll likely be a patch release in the next few weeks or months, but this is mainly a placeholder for any critical bug fixes that prove necessary, and a few tweaks. In terms of appearance and functionality there won't be much of a difference, if any.
We'll also have some help online soon.
In the longer term, we're assessing the feedback we've got since the release of the free 1.0 beta version last year. Initially, analysing the feedback suggested one primary goal, which was the basis of the direction taken by our 2.0: to provide a way of analysing the impact of changes before they occur. And to provide easy ways of getting a diagram of those impacted objects into other applications. Exploring the database schema was a slightly secondary goal, but is still a valid and valuable one.
However, as the beta for 2.0 became increasingly public, we got some even more useful feedback from users dealing with very large databases. Such schemas are so complex that a full diagram isn't really much help in terms of analysing dependencies. There's too much information. Now we did design Dependency Tracker to cope with this: you add a small subset of objects to the diagram, and the application will find the dependencies for you. So you can work bottom up.
Of course some of our users want to browse and explore the dependencies in very large databases, working top down. So we're considering that avenue. Perhaps a more explorer like, potentially more text based interface for tracking dependencies. There could also be support for scripting/automation via an external API; and support for a command line so dependency tracking can be run as part of people's batch processes. We'd likely provide printing and more export options, perhaps to save the dependencies into a database so that DBAs and developers can inspect them with good old SQL.
This approach could be rather different, with a rather different user interface. The diagram might not be as central to the application as it is now. This variant on Dependency Tracker, if it were to come to pass, could be a Professional version for our more hard core users.
So I can't promise anything, but these are some of our thoughts on future directions.
Hope that's of help,
All the best,
Dan J Archer
SQL Dependency Tracker Project Lead
Red Gate Software