oooh – can’t agree with that, sorry. Partial functionality is for all practical purposes non-functionality, IMO
We software users, not just music software but any type of software, have accepted the common assertion that “bugs are just a part of software development” for FAR TOO LONG. The law, at least here in the States has enabled developers to get away with it, too, giving software “special” status with regard to “merchantability.”
You wouldn’t patiently accept a significant design flaw in your new car, would you? Or wait 6 months for the manufacturer to iron it out?
The law may be changing, however, The CFC recently rewrote their rules/guidance and now considers software a “product”, instead of a “service.” A number of high-profile court cases have ruled in favor of claimants against developers in this regard. (Which of course led to a massive lobbying effort by developers to persuade lawmakers to pass new legislation/rules to prevent future litigation).
An argument is often made that stricter rules would kill innovation. Frankly, like at least some of you, I’d like to see more focus on quality/reliability than innovation.
It’s also true that configuration CAN and does factor into how a piece of software functions. But in my mind, as long as a user’s hardware meets the minimum requirements as set forth by the vendor, then the software should work – period.
Of course, software IS different from an automobile or a toaster, but the approach to correcting flaws should receive the same sort of urgency those products do. What I’m basically saying is, I agree with the position some have taken in this thread that timely, frequent, and targeted updates – like the ones Reaper uses – should become the norm and not the exception.