They have an internal bug tracking system using current software designed exactly for this sort of thing. And from the standpoint of feasibility, it only makes sense for it to remain internal. Here's why:

 

1. The database is updated every day with dozens if not hundreds of changes. There are notes about current, unreleased versions of the software and how they've fixed problems, notes about when problems will be fixed, details of a technical nature which relate specifically to program code - and all of this is confidential information. Many (I believe a majority) of the bugs reported in there only exist because of new features that are being developed and haven't been released. The database contains all of the bugs, regardless of whether they are in features that customers have seen or not.

 

2. The amount of work that would be required to create and maintain a second database that excluded all of the confidential information would require several full time employees dedicated to that task alone. Much of the information that would have to be stripped would render the reports useless and make it completely unclear that anything was being done to solve the issues. And with as many changes that would happen on an hourly basis, pretty much no one out here reading would be able to keep up with the changes anyway.

 

3. As far as creating our own database of issues, there are several large limitations. First of all, the bugs that customers report make up a tiny fraction of the number that the QA staff finds and the developers fix. If the hope was to get a measure of how well MakeMusic was doing at fixing bugs, this would be a very misleading result. It's also important to note that the bugs discussed here are not necessarily (and in my experience not usually) the ones that are most often reported by customers. So if the idea was to figure out whether the company was fixing the issues that affect the most customers, it again would be very misleading. Without information directly from the development staff, we'd make mistakes about which problems are which. For example, in the bug database, the EPS problem you mentioned is actually broken up into several different bug records, and fixing part of it would not fix all of it. The opposite is sometimes true as well. Some times very different steps and exhibitions of a bug that would appear to us as multiple bugs are in fact the same bug. Sometimes we report issues that turn out not to be bugs but are instead caused by oddities in our computer setups. Some issues are reported as Finale bugs but instead are limitations of other software or standards (such as the MIDI channel volume "bug" that people have talked about a number of times here). And other times behaviors we report as bugs are actually by design. My point is that even after having worked with the database and having become somewhat knowledgeable about Finale, I could not personally create a database from the information posted here that wouldn't be full of mistakes and hopelessly lacking in accurate meaning.

 

---

Windows XP, all updates

 

 

3. It's not supposed to be a complete void. When a new version or update is released, the readme file contains a list of the issues that were addressed. There might be a few fixes that get by here and there that Mark doesn't get informed of and thus doesn't include, but by in large it's pretty complete. Perhaps you'd like to create a database of fixes listed in these updates? And when it comes to the status of bugs that have not been fixed, really the only way to deal with it is to have tech support communicate what they are permitted to at the current time via direct contact with the customer. You can also request of MakeMusic that they continually update the FAQ's on their website. These occasionally contain information about bugs which people commonly run into and propose workarounds.

---

Windows XP, all updates