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:

4. Take ownership

Once you implement an open source solution, take ownership of your instance of it.

Open source grows with your organization, in both maturity and scale.

The more it does, the more it presents opportunity for your organization to grow too.

Hire people who know and work in open source, empower your colleagues and staff to explore and contribute to open source so that they’re expanding their knowledge well beyond what they expected to learn from their usual work.

Additionally, create an easy avenue for support within your organization.

You should triage issues with the product you’re using, only passing it on to the developers after you’ve determined it’s an actual bug or issue with the code.

That’s not to relieve upstream of their self-appointed duties, but to assure your organization that the toolchain is being maintained and monitored, and to keep you informed about the needs of your people.

People aren’t trained to suggest features for software, because in proprietary software that’s not usually an option.

As a result, you’ll get some of the best feedback in the form of puzzled grimaces and blank stares, or cryptic emails referencing buttons that never existed.

That confusion is a feature request in disguise, so monitor your coworkers diligently.

This doesn’t mean open source will turn your organization into a software company.

Instead, you’ll have a workforce that’s comfortable with the tools they use on a daily basis, and people who aren’t afraid to adapt those tools to work better for their needs.

5. Brace yourself for improvement

When you unleash open source on your organization’s people, you must learn to expect rapid expansion.

Motivated people with a job to do are ingenious in ways no open source project or CTO can even predict.

Your coworkers will find hidden capabilities, awkward workarounds, exciting plugins, and maybe even custom scripts and workflows that are now only possible because you’ve removed all limitations from the toolset.

The key is to foster that everyday innovation, help it spread quickly through your organization, and even compound upon itself.

This has been the not-so-secret to success for countless companies, so learn to embrace it.

People are eager to make their lives easier by making their own jobs more efficient, so let them do that, and let them share their discoveries with their friends.

Whether you foster this through a site on your intranet, through brownbag lunch demos, or through adopting tips and tricks from people as official policy, the combined imagination of your colleagues can push your organization forward in ways you’d never have expected.

Scaling up and to the right

As that last example indicates, open source is as much culture as it is technology.

If you’re only using the technology side of open source, you may be missing out on an important advantage.

Adopt open source wisely and carefully, but adopt it and share its culture with your organization, because digital transformation is here, and it’s definitely open.

[ How can automation free up more staff time for innovation? Get the free eBook: Managing IT with Automation. ]