I really am beginning to find all this a turn off. DxO are building what they are building and I am sure they are taking into consideration more than just “forumites” views. I am happy to sit back and see if it works out. If you are not then why not just go somewhere else? This sort of debate is doing nothing to help new users or encourage them to join this forum. In fact you could be turning potential users off. Personally I favour some sort of DAM/File/Exif management at the front end - it does not have to be burdensome I’m sure.
4 Likes
I am curious to know if there is a real technical problem supporting new cameras in previous version, or if it is only part of the business model ?
The point I would like to come to is, why should DXO do the same as the others and not better… by providing camera support to previous version of software if it is only a small amount of work ?
That would be a positive thing against your competitors.
1 Like
I think this is part of the business model. Otherwise there would be some people, that buy a version and use it for ten years with full new body/lens support, without giving a cent, to amortize the costs of the support. Does not make any sense from a company’s point of view. New body/lens support is treated like a feature in every paid software, I know of. There is no difference between time invested to create an optical module and time invested into writing code or testing it.
It’s really not that straightforward. Supporting an older version of a system at the same time you’re supporting the current version can introduce problems and adversely affect the amount of work you’re support team can accomplish.
The effort requires coding, testing, and distribution, to the older software. Once they go down that road, are they obligated to add every new camera/lens combination that comes their way? And how long do they do this for an older version of the software? And for how many older versions of the software should DXO be required to do this?
And then of course it would involve double the work because it would have to be done for both the older Mac version as well as the older Windows version. And finally if somebody is having difficulties with how well the new camera module works on their older version of the software, than should DXO’s support team take the time and effort to review it, and fix it if necessary in an outdated, no longer supported version of their software?
Providing support for multiple versions of the same software is a potential development nightmare regardless of how easy or straightforward an update might seem to an end user. It is time consuming and error prone. Software teams avoid it whenever possible. It goes beyond just wanting users to upgrade to get additional revenue.
I agree Asser. Nothing, especially in terms of software, is forever and eventually one has to upgrade. That is why I cringe at these buy once use forever type of chains. There has to be a regular income stream.
Yes, it depends on how “standalone” an optical module is and whether the module description language changes between versions. If the format remains the same as it was in the previous version, backporting should not be that hard. But we cannot tell this from outside, because we do not know the dependencies. I would expect that a module describes the optical properties of the hardware, without any assumptions of the tool version in use.
Regardless, nothing is implemented until fully tested, and testing takes time. and then a separate distribution package must be created to distribute the change to the older version of the software.
The distribution is not a big problem with the current module plugin system. The modules are not part of the software package. But testing is a problem. They would need to do at least a smoke test. And there is no reason to test an old release, where there is no money to earn.
Any time a development team is spending on support of an old release takes away from the time they are spending on the current release. I am sure few people here would want to see that happen. And, how long do you support that old release. One year? Two years? Ten years? And remember, as I said earlier there would have to be support for both a prior Mac and a PC version, meaning twice the effort. As a result of the logistics, companies avoid that scenario.
When you consider the potential headaches and support costs we should be pleased that both Apple and Microsoft continue to support older operating systems for years after they are replaced. But to expect that from small companies with small development teams, like the DXO, is unreasonable.
Mark
I read somewhere that if you alter the exif data of gx9 to gx8, which is supported , the raw file is accepted.
it has the same sensor and the lenses are also the same, m43 mount.
from that point of view there isn’t very much difference.
The support of new camera’s in earlier versions can be walking on effortless agrement.
If it’s no other work then add in downloadlist and run the test by the users.
No support in otherway then let the user download the module.
But i understand why it’s common to stop adding when new version is released.
Same as updates for repairing flaws.
For support you pay, namely a upgrade.
It’s not good vibe if you bought a new camera just before they released the new version which imply’s no further update’s of cameralist.
Knowing you can’t get the camera listed after that so maybe they can bring in a overlap of a 6months . A deadline of camera’s who are in the market on releaseday.
That should be a fair compromis.
1 Like
Are you aware of any commercial post processing software (not free or shareware) that provides updates after a new version is released? I’ve seen older software getting bug fixes on rare occasions but not functional updates, and new cameras are a functional update. Many of us want to keep our software current anyway so the issue you mention is not a big one for us except when we pay for an upgrade that’s not really an upgrade.
Mark
Yes i am aware of that,( i don’t have this problem myself so i am fine.)
and i agree, but iam pointing out that it is a bit disapointing if you buy a new camera which has to be add to the supportlist of your raw app. and is announced as in the next two months and you discover it’s packed in a upgrade not a update. i can imagine that that person isn’t happy.
So a end of software update of camera support dated for those camera’s which are in store to buy as guideline for last update when the new version , upgrade ,is released would be nice. So you can wait for the upgrade offer and stil use the older application. Now your a bit “forced” in this matter.
That’s all i point out.
The problem I feel in general is software where there are known bugs that are fixed in new versions. Where this is the case I have always felt the version where the bug was identified should be also fixed.
1 Like
In a perfect world what you are suggesting might seem appropriate. But this is, unfortunately, not a perfect world. Application development and support is a far more complicated process than most people realize.
First, with regard to bugs, all software has them but normally not everyone is affected by every bug and often the resolution of a bug that is very important to one person may be completely unimportant to someone else.
There is a cost of time and effort for a software developer to identify buggy code, analyze and fix the code, test it locally, perform a fully integrated test of the changes with the testing team, and prepare and add the fully tested changes to the next release version. It’s not just a question of flipping a switch and you’re done.
Any code change to address a bug or anything else must be fully tested to ensure it works properly under all conditions and does not inadvertently introduce new problems. DXO has to do this twice. Once for the Windows’s version and once for the Mac. Many of the same steps would also have to be performed to apply a bug fix to an older software version on both platforms. You don’t just drop code in and release it in an older version because it may have tested successfully in a new version. You have to analyze the affect of the code change in the older version and test it all over again. And you have to set up a new release version of the older software for distribution. The point is that there are a lot of tasks to be performed, with significant effort involved, to provide support for multiple versions of the same software. Meanwhile your limited resources are now even more limited as they support bug fixes to older versions. And if those bug fixes cause other problems in the older version, well, its back to the drawing board.
Finally, from a development perspective you now need to maintain multiple test environments for current and older versions with a greater potential for the introduction of coding errors and version control issues. Its a potential support nightmare and it prevents developers from spending all their time enhancing the current version of the software.
You know, I agree with John and I don’t care how difficult or complicated it might be. The supplier should not be making their problems mine. If I purchase software I expect it to perform 100% as advertised. If not it should be fixed. I would not expect to buy a car and find the brakes do not work and then have to wait for the new model before it is fixed!
As for Peter’s point, it is a reasonable one. At what point do you know a piece of software is about to become legacy. I am not aware of ever seeing that sort of detail on the sales page so how do I know how to avoid it?
You say that now, but if updates to the current version of a vendors software were suspended for six months while the development team focused on fixing every bug in a previous version I wonder how supportive you would be of that, especially if you were no longer using the previous version, And what about owners of the version before that? Some would consider the range of adjustment of PL’s highlight slider to be bug. Why not go back and fix it in Optics Pro 9 for those that still use it? Software development is about making choices regarding the use of limited resources, and getting the most bang for the buck out of them. Those choices don’t necessarily always make every end user happy.
And by the way your use of cars is an interesting analogy since almost every car model made has dozens of small bugs or anomalies that are not fixed until the next model is released.
Mark
I for one am not saying every bug, I am saying bugs that were known about and a fix was done for an update. In such cases you are probably really taking about one old version. This fix bugs in an update was at its worst with CorelDRAW when Corel were using the business model of annual updates to drive competitor’s out of the market (which they did). No one is saying publishers are acting like this now (or so blatantly), but if you have a model that says you need only update to get features add that you want its a little dishonest. This should include fixing bugs that may stop the version you have from working as it was claimed it would.
Sorry to keep editing , I am dyslexic to keep spotting errors after posting!
If that were the case so be it. I am the customer and I am not here to make it easy for the devs - they are here to sell me what they advertise. Anything else is misleading at the least. Other industries have to deliver what they advertise. Why should it be different for software houses? This is one of the main reasons I have not been happy with ON1 and Skylum’s Luminar. I would agree there are bugs of significance and those off a very low key nature that can be worked around but bugs are bugs and some outfits have certainly taken the p*** in the past.
A well known and annoying bug from your point of view may be a bug that I’ve never seen in my version or is totally unimportant to me, and vice versa. On this forum I see people documenting “bugs” almost every day which I have never seen myself, or which represent that particular user’s impression of how the software should work. Further, the definition of what a bug actually is may be significantly different from person to person. Some people feel a feature that doesn’t work the way they expect it to is a bug… and that is not necessarily correct. As I’ve said software development is about making choices regarding the use of limited resources and as a general rule going back to fix issues in older versions of a vendors software is a very poor use of those resources.
We shall have to agree to disagree. Whilst I accept there are some stranger than life bugs around there are also significant bugs. If it matters to one person it matters not that another could not care less. If the software is not performing as advertised it should be fixed in the current release. As for the use of resources - they are there to create a properly working product. If they cannot do that then there is clearly something wrong at the devs end.