Microsoft Office - Licensing Questions For 3 Scenarios
-
@scottalanmiller said in Microsoft Office - Licensing Questions For 3 Scenarios:
@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:
@Dashrender said in Microsoft Office - Licensing Questions For 3 Scenarios:
@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:
@wrx7m said in Microsoft Office - Licensing Questions For 3 Scenarios:
@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:
The ERP's dependency might be actually be ACE, and not Excel itself
https://www.microsoft.com/en-us/download/details.aspx?id=54920Hmm. I don't know about that. We don't have access installed on the ERP server or any of the other systems.
It's a shared DLL, just installing Excel would install it on a system
That's some pretty crappy software using that engine if that's the case.
If they specifically want to create a feature which is an integration with Microsoft Excel, should they not use the tools provided by Microsoft to do so?
Absolutely not. That's considered one of the biggest, most amateur and/or "don't care about users" programming blunders. It's one of the most common red flags for bad software. Calling it the "tools provided by Microsoft" makes it sound logical, but when you describe it as "tools provided by Microsoft that require the end users to purchase, maintain, support, and constant fix integration with a tertiary product", then it is clear why only a total idiot or truly uncaring developer would do it. And as it is the second most well known "total screw up" for software development inclusions, there is absolutely no viable excuse for a programmer doing it (the most well known is hard coding to SQL Server for no reason.)
This is one of the standard "free for developers, screws the customer" tools that is used as the industry wide example of how lazy developers are lured into making bad software in order to forcible funnel money into a vendor. And it raises the actual cost of the end product, while generally making it flaky and unstable. We make a fortune supporting software that works this way because the MS Office products deregister or have problems all of the time and it is impossible for the software makers to support it. It literally makes their software "not work" reliably.
It's also one of the most common examples of what huge blunders happen when developers get to make decisions without the insight and oversight of operations teams. Because using these tools is easy for the devs, at the cost of totally screwing the end users and operations teams.
I think you must be missing what's going on here. This removes the requirement to integrate more directly with MS Office, instead relying on a separate library that is provided standalone from Office and thus allows saving to Excel. We've had zero issues with using this library, which is actually pretty uncommon for us.
We do support saving to CSV, but people specifically want excel, and believe it or not, they actually get confused by CSVs. I think this is thanks to how Excel implements CSVs, as well as poor spreadsheet training courses, as well as people who probably aren't qualified to touch a computer.
Honestly, our program is built on a series of poor choices, but I don't think this is really one of them.
-
@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:
We do support saving to CSV, but people specifically want excel, and believe it or not, they actually get confused by CSVs.
CSV is a native format to Excel. If they are confused by it, it's Excel that they are confused by. So Excel would be their problem there.
Not that I'm saying CSV should be used, by point being that they are claiming that they need to work using Excel, and then don't understand Excel basics. It's a problematic combination.
-
@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:
I think you must be missing what's going on here. This removes the requirement to integrate more directly with MS Office, instead relying on a separate library that is provided standalone from Office and thus allows saving to Excel. We've had zero issues with using this library, which is actually pretty uncommon for us.
The issue is flexibility. Using third party libraries, you can integrate with Excel or with anything else. Using the Office libraries, every user, in ever system, is bound by the limitations of the most problematic. It makes deployments more costly, and more complex.
-
@Obsolesce said in Microsoft Office - Licensing Questions For 3 Scenarios:
@scottalanmiller It's good to not only include the MS Tool for perhaps features that nothing else supports (among many other reasons) , but also the FOSS stuff too. Not just the MS stuff, that is very idiotic.
That, too. Those MS Office integrations don't support other tools. So it is a huge lock in. It might work well (although I've never seen this) if you have 100% MS Office installed and it never has any issues itself (never seen that either), but anyone wanting an alternative is totally out of luck.
-
@scottalanmiller said in Microsoft Office - Licensing Questions For 3 Scenarios:
@flaxking said in Microsoft Office - Licensing Questions For 3 Scenarios:
I think you must be missing what's going on here. This removes the requirement to integrate more directly with MS Office, instead relying on a separate library that is provided standalone from Office and thus allows saving to Excel. We've had zero issues with using this library, which is actually pretty uncommon for us.
The issue is flexibility. Using third party libraries, you can integrate with Excel or with anything else. Using the Office libraries, every user, in ever system, is bound by the limitations of the most problematic. It makes deployments more costly, and more complex.
That's true, it's the kind of self perpetuating lock-in that has served Microsoft so well. People use Excel, and they ask for saving to Excel spreadsheet, so we create the integration specially to allow Excel and not include ODF, then we help keep the industry locked into using Excel because that's all we support unless you want to just save to CSV.
As for the cost and complexity of deployments... that could be true, except that the installation of our main software is already so complex and costly that dealing with potentially installing this library is the easiest part. I think we probably only have one other developer who would be able to figure out how to install it. I've never heard of any client's IT that have been able to figure out how to install it (just calls from those who have tried), client services has to do literally every install.
