If you work in an organization that isn’t focused on development, where computer systems are used to support other core business functions, getting management buy-in for the use of open source can be tricky. Here's how I negotiated with my boss and my team to get them to accept and try open source software.
I work in an academic library and use open source for:
- our library catalogue, Evergreen
- our website and archival system, Drupal
- our help desk system, Best Practical
In my field, upper management are not technologists. My immediate managers are librarians, and their bosses are academics and accountants. So, an agreement with them to try out using open source software came down to a series of discussions between myself, the library director, and various members of the university's administration.
Invariably, the first question that was asked was: "Who’s the vendor?" It's a reasonable question considering that every other aspect of the university is managed by a vendor whenever a third party service is required. So, it is important to understand thier perspective and the way they are looking at making decisions. Many times, upper management's primary concern is budgeting, and almost all issues are seen through the prism of finance.
By choosing my words carefully and avoiding these four words, I successfully brought open source to our team.
Open source
Open source to many outside of the tech industry brings to mind thoughts of high risk and low security. So, when talking about "open source," I made a point to include the words "software" and "tools."
When I explained to them that other organizations like Google and Whitehouse.gov use open source software and open source tools, they relaxed a little. Management might not get a great grasp on the technology, but they will understand the value of a reference. It also helped them to know that there were vendors to fall back on; in their mind this helped mitigate some risk.
Free
I naively thought using the words "free software," would immediately appeal to the budget-oriented mindset of upper management, but I was terribly wrong. To people who are used to buying services, the word "free" is a synonym for "junk." The comment of the day in that meeting was: "You get what you paid for." To many, a high sticker price testifies to high quality. So, to these decision-makers, software that cost nothing was an immediate red flag.
If you get asked, "Why does this software costs nothing?," a good response is to talk about how there are businesses that thrive by supporting open source technology. One is Equinox Software that provides support for the Evergreen Library system. Examples that relate to your field, like this one for libraries in my field, have a calming effect. For people familiar with vendors, it is reassuring to know that vendors exist in the open source world, and it helped dispel the myth that our key systems had nothing more behind them than a collection of teenage "hackers" working away in their moms' basements.
Contribute
When I explained the concept of a community of contributors working on and producing open source software, I was asked many questions, like:
- "Are we on the hook for a certain amount of work per month?"
- "How is this going to be managed?"
- "Will it interfere with my other work responsibilities?"
The concern was that they pay my salary, not the community. So, why would they let me use their time to work on the community's project?
To me, contributing to the community is about making the software better for everyone, including us. So, in other words, contributions are a form of shared maintenance. We aren't just contributing; we are doing maintenance.
This idea of "maintenance" was easy to understand and sell because everything requires maintenance, including our Microsoft-based public network. So rather than talk about communities and contributing, I framed the time spent working on the open source software or tool as the "routine maintenance" we would perform for any system.
Development
When I used the term "development," it was met with the response: "We’re not in the software business." Fair enough, we may not be, but the problem here is the meaning of the word. When it is used in fields and industries outside of the tech and software world, "development" might imply to upper management that you want to help build software from scratch.
So, I started talking about "agility" and explained that, "open source would speed our ability to respond to feature requests from our staff and administration."
I reinforced this with simple demonstrations of the flexibility of the software. One useful trick was showing management how I could change the entire look and feel of a whole website by simply clicking on a theme. If you work in the technology world, that’s no big deal, but to others, it can be pure magic.
28 Comments