I receive more and more messages from colleagues working in the GLAM sector, stating that they are not allowed to use OpenRefine for (sometimes) quite the strange reasons.
I will collect some "blockers" here and you may supplement them.
Maybe in the future we will have some FAQ or other document, where we can defuse these "blockers".
No particular order:
Entity has no Java License
Not allowed to install Java
Data is processed on the "internet"
It is a web app and therefore accessible from external computers
No painless way to easily backup and restore project files (another from an IT pro that just didn't like having to move a mouse too much, or manipulate ZIP files on his network)
@b2m thanks for sharing.
What happens after you address their questions? Are they willing to install OpenRefine?
I’m also curious about the backgrounds of the individuals raising these concerns. Are they the actual users, their managers, or representatives from the IT department of the institution?
We have a FAQ, but it combines various topics. I believe it would make more sense to split its content based on the user journey (pre-install, post-install, etc.).
This is interesting; thank you for documenting it. I suggest we create a dedicated FAQ page specifically for IT department questions as part of our documentation. It should serve as a resource that users can easily reference and share with their IT department. This page could also encourage users to reach out to the community on the forum if they have additional questions.
I performed steps 1-3 of the workflow mentioned by b2m. My IT dept justified their refusal of OpenRefine with the following: Setting up automatic update of OpenRefine does not seem to be possible. Therefore, offering OpenRefine on the Employer Portal is problematic, for security reasons, and because of need for automation.
Does this make sense, or not?
Incidentally, Microsoft has a package manager now with WinGet. It would be nice for OpenRefine to submit release packages to the Windows Package Manager app repository (not the Microsoft Store catalog - a different source repo that can also be pointed to with WinGet)
Steps are here if someone in the community wants to volunteer:
This has been my experience also, as a systems librarian in a university.
We’ve progressed past concerns about no vendor support/maintenance, and have gotten to a point where there are two main concerns. Any advice (particularly on the first point) would be much appreciated.
OpenRefine cannot be detected by Microsoft Defender as “OpenRefine uses a non-standard installation architecture and lacks a digital signature for its CPE, which prevents Microsoft Defender—an automated system—from identifying it. Since we have no way to manually intervene, this creates challenges for vulnerability management.”
Manual processes for installing updates (I have referred the IT team to the information on this thread about OpenRefine being available from various package repositories and waiting to see if this helps).
A question for Windows users more generally: aside from signing the installer and executable during our release process, would submitting the files for each release resolve this issue? While I think the ideal situation is that we have all of this automated, perhaps this would be a reasonable stopgap measure to make life easier for our Windows constituency.