[michaelaye]

Dear Omnigroup, dear all!

I would like to share some thoughts on how Omnigroup is dealing with bugs in Omniplan (or maybe in general, I can't say).

IMHO, it is a suboptimal situation for a paying customer, when she
- finds a bug, that actually has a significant impact on her workflow
- is eager to report it,
1. to get a solution, and
2. to help improve an otherwise favourable product
- learns, that it is a known bug
- learns a workable, but inefficient, time-consuming work-around
- learns that most probably there won't be a bug-fix until the next major version!

There are two major points that could improved here, one could be considered a feature, but the other, again IMHO, should be self-understood for a good practice towards the paying customer.
1. (Feature) If there would be a bug database visible to your users, I don't need to report a bug with a time-consuming bug report that is already in your database. And trust me, my bug reports usually cost me time, because I am usually try to find the minimal reproducing test case. (Ask Aaron)
2. If there is a bug that clearly breaks your advertised feature set (XML export e.g.), why is Omnigroup not spending resources on fixing these bugs?
I mean, are you not scared to make your customer base extremely annoyed if your most basic features are not working properly? You can't rest on your sugar-candy GUI laurels forever, you know? ;)

To make it short: I, personnally, can't except the excuse of working full steam on a new version of Omniplan when features of Omniplan that are essential for collaboration are not being fixed for many months.
I would really like to see some resources spent on the current Omniplan for very essential bug fixing only.

What does the community think? What does Omnigroup say?

Have a nice weekend everybody!
Michael

[skwirl]

Originally Posted by michaelaye

1. (Feature) If there would be a bug database visible to your users, I don't need to report a bug with a time-consuming bug report that is already in your database. And trust me, my bug reports usually cost me time, because I am usually try to find the minimal reproducing test case. (Ask Aaron)

Our current system (using the email sent to the support ninjas as "real" feedback) has the disadvantage of being opaque, but otherwise serves our needs well. We've discussed making customer requests more public, but we haven't found a method of doing so that we're happy with yet.

Any solution we came up with would have to handle the years and years of feedback in our existing database. Ideally, it wouldn't require big changes to the way the Support Ninjas help people and record the feedback they receive. It would need to prevent folks from signing up for a bunch of forum accounts in order to game the system.

Thus far, when we've discussed it, it's always ended up looking like it would require more engineering time than we're comfortable pulling away from our other projects.

We're definitely keeping an eye out for good solutions, though. I want to point out that we prioritize partially on the basis of customer reports, so getting duplicate bug reports from our users does help.

Originally Posted by michaelaye

2. If there is a bug that clearly breaks your advertised feature set (XML export e.g.), why is Omnigroup not spending resources on fixing these bugs?
I mean, are you not scared to make your customer base extremely annoyed if your most basic features are not working properly? You can't rest on your sugar-candy GUI laurels forever, you know? ;)

Microsoft Project import/export is something that is very time-consuming to update and more importantly, to test. There's a lot of round-tripping between all the different versions of Microsoft Project and their various file formats. We've been working non-stop on OmniPlan 2.0 to get it ready for private beta, and we share our QA test pilots among all the other released and upcoming iOS and Mac apps. It's been a very busy year and we're stretched a little thin at the moment. We just posted some open positions for QA and support earlier today.

We are aware of the outstanding Microsoft Project import/export bugs in our development database, and with the recent release of Microsoft Project 2010 we've received a lot of reports of not being able to import the new 2010 file format. Knowing that some of our users depend on Microsoft Project compatibility, we diverted some resources from OmniPlan 2.0 to work on Microsoft Project support and will be testing it over the upcoming weeks. I don't have a release date yet, but this will be a free update for all OmniPlan 1.x users and should show up in your software updater when it's ready for release.

[michaelaye]

Dear Aaron,
first let me thank for your fast and comprehensive answer.

It's a pity that the 'good guys' have to suffer again from the 'bad guys' (you being worried about people 'gaming' the system), but I see your point.
But provided you would find a way around determining legitimate accounts (maybe connect it to the program license somehow?), I would expect that you could add a voting system, so that you still have your means of deciding where your resources should be spent.

And very good to hear you are working on the Project Support. I just can't persuade everybody in a 4-country multi-milion Euro project to switch to Omniplan. At least some good news: The European Space Agency is increasing support for Macs, yay! ;)

Best regards,
Michael

[skwirl]

MS Project 2010 support has been added to OmniPlan 1.7. You can check out the sneaky peek builds here.