You’ve heard it before: Open source is everywhere. It’s in your pocket, it’s on your computer, it’s in your organization.
The world has relied, famously, on open technology like TCP/IP, DNS, Apache, SSL and TLS, and so much more, for decades.
But those technologies are generally considered developer tools.
Many people don’t use that technology without the buffer of an expensive, properly licensed application with a trusted brand name in the title bar.
And yet as the world eases its way into comfortable familiarity with open source, many organizations are branching out and letting independent projects take a central role in the everyday IT workflow.
[ Read also: 5 open source tools IT leaders should know about now and Robotic Process Automation (RPA): 6 open source tools. ]
There are many advantages to open source tools: The general ones are well-documented, and there are surely even more unique to the specific project you’re looking to adopt.
5 open source implementation best practices
But change can be disruptive, and introducing a new tool the wrong way can turn your users against not only the tool you want them to use, but also change in general.
Here are 5 factors you should consider when introducing an open source application for broad use within your organization:
1. Measure twice, cut once
You really only have one chance to introduce a new tool.
You may think people will be patient as you work to perfect a solution you’ve put in place, but people start assessing the tools they’re given the moment they go live.
It doesn’t matter how often you tell your colleagues to ignore the broken bits, or to hold off judgement until everything’s set up: The moment they have access to the solution you’re proposing, they’re forming lasting opinions.
Worse still, if something’s not working the way they need it to work, they’ll also start building workarounds, because they have to do their work in spite of your masterplan.
Workarounds quickly become the default.
It’s what your workforce has taken time to develop and learn, and so in the end you can expect them to bypass the tool you’re providing out of habit as well as bias.
As excited as you may be to roll out a new open source tool, keep in mind that you have as long as you need for preparation, but you can only go live once.
Before you implement anything on a widespread basis, give it a trial run either internally or with a trusted test group.
Make sure your solution scales as expected, answers the requirements of everyone who’ll be using it, and is more resilient than your existing toolchain.
If you don’t feel comfortable leaving for a holiday on the day your solution launches, then you’re not ready to launch.
(To be clear, though, it’s not actually advisable to go on holiday the day your solution launches.)
2. Learn the tools, teach the tools
Sometimes, once you’ve learned something new and exciting, you forget there was ever a time you didn’t know it.
This is a pretty common mistake we all make, and it often comes across as a kind of gatekeeping: You get some hidden knowledge, and then you keep it secret from everyone around you simply by not sharing what you’ve learned with others.
It’s easy to fall into this trap when you (or your point person on this project) work with a new tool you want to introduce to your organization.
You spend months and months with a tool until you know it like the back of your hand, sometimes only because you’ve had to fix so many unforeseen problems that arose during testing.
You emerge from the battle beaten but enlightened, and you forget that nobody else went on that journey with you.
You’ve got secret knowledge about the tool you’re about to impose upon your organization, but you’re just one person out of 10 or a hundred or a few thousand who need to understand it.
You likely can’t teach everyone in your organization how a new tool works, because you are only one person.
What you need are ambassadors.
Within every department, there’s at least one person with the propensity to teach others.
Find those people, listen to what they need to know about the new tool, and train them.
Empower them to be champions of the new software, and when you’re ready to go live, let them lead the way.
You should still hold formal training sessions, but get homegrown experts in place early to continue the training once the launch is over.
Encourage and empower your colleagues to learn the tools you provide, and let them be a part of the solution.
[ Read also: 5 open source projects that make Kubernetes even better. ]
3. Let open source software play to its strengths
Open source has many strengths, but the one that matters most is the one that truly cannot be duplicated by proprietary companies: It’s innately noncompetitive.
That doesn’t mean companies using open source are noncompetitive, or that companies selling support for open source are noncompetitive.
It only means that open source software doesn’t need to own the whole space it works within, and that’s a monumental benefit compared to vendors whose goal it is to own your entire stack.
Open source can work alongside proprietary applications and infrastructure (at least, insofar as it’s allowed to do so by the proprietary components).
Your open source solution and your organization’s existing proprietary security blanket can coexist in harmony.
As you phase out bits and pieces of the proprietary dependencies, open source continues to adapt, so take it slow, leave time for resiliency testing, and play to the strengths of open source architecting.
Let's examine two more best practices when implementing open source tools:
