A few years ago, I was sitting in a windowless conference room, watching a middle manager in the enterprise get ready to speak. From the substance of the conversation and the expression on his face, I knew exactly what he was about to say. "Ugh," I thought, groaning inwardly, "here it comes."
Now, I realize that I owe you a bit of context if I want you to understand my annoyance. So let me flesh out the story.
The Aspiring Agile Enterprise
I spent a lot of years as a software developer before floating my way into management and eventually landing as an independent IT management consultant. It was in this capacity that I found myself at this company, sitting in this conference room.
The company was a Fortune 100, and they were deep in the throes of a sweeping, multi-year agile transformation. And this agile transformation had stalled a bit. So I was there to help them figure out why, in spite of all of the certifications, process changes, official ceremonies, and meticulously planned multi-year backlogs, they still couldn't ship software with any cadence.
Not surprisingly, there were a lot of reasons for this. But at the core of it was viewing "agile" as an official project management methodology, rather than as a combination of modern practice and developer empowerment.
A Tale of Thwarted Agility
And this brings us back to our windowless room and our middle manager. I was suggesting that the teams stop reinventing the wheel, like writing their own loggers and using open source tools instead. He started shaking his head immediately as I suggested this; I knew the tired story that he would use even before he started.
We can't use open source software, and you know it. If some guy says in the license agreement that we have to buy him a beer in order to use the software, then we have to do that. And if we don't, he can sue us for millions.
This was a favorite cautionary tale among the agile-resistant middle managers in the organization. So it wasn't my first time hearing it, nor would it be my last.
And yes, you're reading this right. The canonical cautionary tale was that some open source contributing ne'er-do-well would sandbag a Fortune 100 company with the ol' beer clause. Because that's a well-worn path to riches.
Open Source Struggles in the Enterprise and the Enterprise Struggles to Stay Competitive
I relay this tale because it's both comical and memorable in its facepalm. It's like the stodgy old IT leader's version of a dad joke.
But beneath the absurd premise lies a real concern. Until very recently enterprises have been leery of open source. Deeply leery.
This naysaying comes from multiple sources. First, you have the legal and compliance interest. These folks institute policies to minimize the company's exposure to lawsuits. You've also got the enterprise architecture group, tasked with sizing up tools and trying to standardize across teams or even across programs. And then, of course, you've got the security interest. The company needs to make sure their open source dependencies don't roll out the welcome mat for hackers.
Add all this up, and you've got a company that minimizes risk by ensuring that it won't ship software anytime soon. My tale took place around the release time of Java 8 while this company was holding onto Java 6, perhaps to celebrate its ten year anniversary. They used tortured, home-grown solutions and a custom web server they'd commissioned from somewhere or other.
Writing code there was like time traveling. And that's no way to stay competitive.
Enterprises Need Open Source
Eventually, painfully, but mercifully, reason prevailed. As this company's agile transformation wore on, they began to adopt practices like continuous integration that would let them start delivering more quickly. And they would also modernize their tooling across the board, including responsible ways to bring in and to vet open source tooling.
They had to do this because the competition does it. And they had to do this in order to remain competitive in a landscape where it's really hard to find and retain software talent. Talented people will have a limited tolerance for having outdated technologies and oddball, homegrown frameworks foisted on them.
And none of that addresses the more existential problem that a scrappy startup with no such restrictions at all might run circles around them and start seriously eating into their business. If you're stifling innovation to preserve a safe status quo, you're basically agreeing not to be competitive in the future.
The modern software world moves far too fast to ignore open source. With the rise of Github and talented developers using open source as a portfolio showcase, a lot of the best available tooling comes not from vendors, but from the community.
Enterprises have to find a way to use it.
And Everyone Needs Security
Let me switch gears for a moment, though, and stop giving the enterprise a hard time. Instead, let's look at a way that scrappy startups can face-plant.
Imagine building some bleeding edge new SaaS, getting funding, and feeling pretty good about yourself. The investors are interested, the market is interested, and you're starting to make money. It's an intoxicating feeling.
But then one day, a team member notices some logins that make no sense. As you start to tug on this thread, you find, to your horror, that a massive data breach has happened within your system. Your clients' most sensitive information is scattered to the four corners of the world.
Now you're left to do damage control. Your reputation and brand are in tatters, and a significant portion of your customer base has walked away. Yikes.
This sort of thing represents one of the many battle scars that enterprises build as they become, well, enterprises. Enough of this sort of thing, and you see why companies assemble impressive legal, compliance, and security departments and throw them at the group developing software.
The Future for Everyone Lies in Responsible, Vetted Open Source Solutions
So what, then, is an organization to do? There has to be some kind of responsible path forward. Right?
Well yes, of course there is. And that path forward is responsibly vetted open source software. But it doesn't have to be (and really shouldn’t be) your organization doing manual vetting. Without automation - you’ll begin tearing your hair out for a whole new reason. The sheer volume of artifacts consumed by organizations today would outpace any attempt to manually review them. The right tools, like Sonatype’s Nexus Platform, can accomplish checks in milliseconds, where humans might take hours to reach similar conclusions.
The reality is, enterprises need open source. If that wasn’t clear before - the recent acquisitions of GitHub and Red Hat by tech giants Microsoft and IBM, respectively, should have removed any doubt. They also need security. The good news, you can have both.
About the author, Erik Dietrich
Erik Dietrich is a veteran of the software world and has occupied just about every position in it: developer, architect, manager, CIO, and, eventually, independent management and strategy consultant. He’s the cofounder of Hit Subscribe and writes at daedtech.com. Connect with him @daedtech.
Written by Erik Dietrich
Erik Dietrich is a veteran of the software world and has occupied just about every position in it: developer, architect, manager, CIO, and, eventually, independent management and strategy consultant. This breadth of experience has allowed him to speak to all industry personas and to write several books and countless blog posts on dozens of sites.