Coming out of the Shadows: Getting Buy-in From Your IT Dept

Ahhh…the elusive “blessing” of the IT Department… desperately sought, rarely bestowed. In a previous blog my colleague, Michael, defined Shadow IT as “technologies and systems used by corporate employees that have not been approved by IT Departments”. While companies don’t want to limit innovation that may come “from the shadows”, developers need to face the hard reality that enterprises also don’t want to take on the added risk. Why is this risky for companies? Because lack of control over technologies being used means hundreds of developers individually choosing their own preferred solutions and potentially opening their organization up to compliance related issues or unsupported (and unmaintained) technology.
So how does an organization come out from under Shadow IT (i.e. find a way to mitigate risks associated with rogue technology currently being used) all while keeping their development teams happy? To answer that question let’s start with an example from a developer’s point of view. After several months of using “rogue technology” to build out their applications and processes, developers typically come back to the vendor once they are ready to go “live”. Why do they do this? Because what the developer is focused on (building quality software) is only a subset of what the business needs in order to actually implement it and sometimes navigating their organization (read IT and Legal Departments) can be a bit of a hurdle. Here are a few questions to keep in mind when implementing open source within your organization:
1) What criteria need to be met in order for my IT department to approve the use of open source based solutions in the project?
What we hear most often is that IT departments generally prefer that their developers use a commercial grade software tied to Service Level Agreements that guarantee security updates/patches and on-going product maintenance. These quality guarantees are often critical to the success of a project by ensuring little to no downtime and backed by the end users having access to expert Technical Support should critical issues arise. While you (as the developer) may like working with all kinds of cool new open source solutions, your company needs to know that they can continue to support your code after you’ve moved on. If you’re using an IT approved standardized solution, your organization should be able to easily pick up where you left off.
2) Am I compliant in the way that I am using the software?
Ensuring license compliance means reading through the EULA and double checking your use case details against the license restrictions. A few questions developers need to ask themselves include-am I allowed to use this software in a production setting? Is the software being used for internal purposes or will it be embedded into a product or solution that my organization is going to redistribute externally? Can I legally use the software in the way I intended for my project?
Some of these situations may actually require a commercial license of some description in order to maintain compliancy. In one known instance a development team incorporated open source code into their medical equipment and shipped it for 10+ years. When it was finally discovered, the company ended up facing a very large (and unexpected) “true-up” bill for being out of compliance due to redistributing without an OEM license.
3) What are the legal IP issues? Is having a guarantee of no active GPL/GNU important to my organization’s Legal department?
More often than not, having this guarantee is important. With open source software you can’t be too careful. License Indemnification provides protection against potential IP/copyright/patent infringement lawsuits from community contributors to open source code. For example, there are a hundreds of contributors to open source Perl which means that there are hundreds, if not thousands, of third-party Perl modules available. Each individual module has its own creator, and therefore, its own license that potentially restricts or has very strict requirements around how it can be used. Companies can choose to manage these module licenses on their own or they can use a commercial distribution that has its own license (which overrides the individual licenses) that does the heavy “legal” lifting for them. The end result is managing a single license for indemnification versus potentially thousands.
So while you may start out in stealth mode flying under IT’s radar, should you decide you want to move forward with your new favorite piece of open source technology on a more permanent basis then you’ll need to find a way to transition out of “rogue dev territory” as painlessly as possible and that’s where partnering with a known commercial vendor comes into play.
At ActiveState, we address a company’s Shadow IT concerns by providing commercial distributions that include key license features that IT (and Legal) departments often look for and depend on. ActivePerl, ActivePython and ActiveTcl are all quality assured, monitored continuously for security related issues (like OpenSSL), strategically maintained, technically supported and indemnified solutions that can be heavily relied upon and easily implemented for mission critical applications and projects.
The key thing that I want you to take away here is that Shadow IT is real and it can be dangerous. It’s definitely something companies are concerned with and looking to find a solution for. My advice to developers is be proactive; study the license for the technology and work with your IT department prior to implementing a new piece of software. Always keep in mind the steps needed to make sure your code contribution mitigates risk for your organization while at the same time making sure your new application or project rocks!
Title photo courtesy of Lukas Neasi on Unsplash.