If you were to take some time to walk around and ask people if they believed anything is free, the overwhelming majority would answer no. Most of us understand that there really is nothing free in life. Everything comes at a cost, yet there is one idea that persists — open-source software is free.
I’ve worked on both sides of the table. I’ve been the client who has implemented a customized open-source solution and I’ve been the vendor who has implemented our own proprietary software solution for clients. I’ve learned some valuable lessons along the way.
Many organizations get off track early in the process of identifying a new software solution because they begin by looking for “free” or “low-cost” software that can be adapted to their current workflows rather than looking for software with a good business process that can transform their legacy workflows. I understand why many organizations start here. Budgets are tight and change is hard, especially for long-term employees. The reality is that a software solution with a good business process will streamline your team’s daily workflow and free up time to finally squash that pesky backlog. While this transition is an uphill journey, once you’ve crested that peak, the benefits will be seen across the organization.
If you have worked in digital for any organization (especially within the museums and archives industry), you can probably relate to how I describe my job on a daily basis — 10% technology and 90% unlicensed psychotherapy.
Open-Source vs. Proprietary Software
Cost of Ownership
It is easy to get distracted by the upfront cost of many proprietary solutions, but in the long run, it will generally save you money. The low initial cost of implementing an open-source solution could present some savings, but the long-term costs will generally outweigh that perceived advantage.
One of the biggest benefits of proprietary softwares is that they come packaged with setup and migration services, training and ongoing tech support. Your time is valuable and that support can save you hours of struggling to piece things together, not to mention a few headaches along the way.
If you are seriously considering an open-source solution, ask yourself the following questions:
- Do the decision makers understand that “no upfront costs” for a software license doesn’t mean you won’t need funding for other costs associated with open-source?
- Have you considered the cost of any new hardware that may be needed to run the software?
- Do you have the internal expertise to set up and configure the software?
- Do you have the internal expertise to extract your data from your current system, transform it to meet the requirements of your new system and then migrate it to the new system?
- Do you have internal expertise to train users on the new software and to handle their support requests?
- If any immediate problem occurs, do you have the internal expertise to solve these? If not, you will need to pay a premium for expedited support.
- Do you have the internal expertise to maintain your software — updates, patches, testing and deployment?
- Do you have the internal expertise to make sure that all systems are secure?
- Thinking about security, are you “Eating from a Dirty Fork”? Even though this article was written in 2017, it sheds light onto the security gaps in open-source software.
- Most importantly, even if you do have the internal expertise, do you have time to manage all of the above in addition to your daily tasks and that hefty backlog?
Open-source solutions can offer deep functionality, but will sacrifice usability. You need to consider the usability for your internal and external users. Is the interface user-friendly enough that you won’t end up frustrating your colleagues? If you are trying to share your digital collections with a wider audience, do you really want the interface to be akin to Windows XP?
I’ve seen many organizations adopt an open-source solution, invest significantly in feature customization and end up with an outdated interface that frustrates team members and the public. If you want to continue to only serve researchers who reluctantly accept whatever is provided, that legacy library interface will do just fine.
I’m not here to say that open-source software doesn’t have benefits, but I think it’s important for everyone to understand the inner workings of an open-source community. One of the biggest benefits of open-source is the development community, a resource for software engineers.
If you aren’t happy with the current functionality and have some decent development chops, you can take the old source code, create a new project and build a solution that works for you. But what happens when that single product has been forked into multiple projects? This is when you start to see community infighting that will spiral into a single product becoming multiple products. When this happens, the developer community also splinters, and resources become spread too thin. The worst-case scenario is that the original open-source solution you adopted is abandoned.
Customization vs Configuration
Let’s quickly define customization and configuration in the context of software development.
- Customization: To write new code in the software that meets specific requirements that core functionality doesn’t address.
- Configuration: Use the built-in functionality of the application to meet specific requirements without additional custom code.
When we implement Odyssey preservation software, we rely on configuration as much as possible. We can customize when a requirement can’t be met, but we will never customize the core application. Customizations made to the core application will cause the custom code to break during software upgrades. But as I said before, my job is 10% technology and 90% unlicensed psychotherapy, so let me share a bit of insight.
Don’t be fooled, if your supervisors, colleagues or the general public believe that your chosen solution can be infinitely customized to meet their perceived needs — you will never find peace. If allowed, the end users will want to continually customize the software as a bandaid to avoid the intimidating, but invaluable task of transforming legacy analog workflows to more efficient digital ones.
Our mission at HistoryIT is to #savehistory. One of the core components of that mission is to be sure our clients start with strategy. That strategy needs to inform every single part of your project — from planning, imaging, metadata creation and software. Ultimately, the decision is yours to make, but we want to be sure our clients have enough details to make an informed decision.
Like I said, I’ve been on both sides of the table and so have many of my teammates here at HistoryIT. We’ve integrated decades of experience and built a true digital preservation platform that’s an affordable, flexible and extensible solution that can transform your organization and support the care of your digital collections for the long term.