For decades, enterprise IT organizations abdicated the responsibility of engineering their networks to big-name vendors that charged them handsomely for the luxury of doing so.
That’s changed with the rise of open source network software. Now, enterprise IT can—and, according to Thursday’s keynote panelist-practitioners, should—reclaim responsibility for network engineering.
“In the past, we were kind of in the position of saying ‘Oh, Mr. Chambers, what router did you bring me today?” joked Colin McNamara, DevOps practice director at Dimension Data. “Now the opportunity exists for network owners to innovate in ways that may align more closely with their actual needs.”
The price IT pays for that empowerment is non-trivial. While open-source code may be essentially free in terms of licensing, the creation and real-world implementation thereof can be quite demanding. IT organizations therefore have to make changes in how they hire, cultivate, and allocate coding talent.
In particular, the panelists warned enterprise IT leaders not to think they can just leech off existing open source projects. One reason not to leech is that projects obviously need contributors. So if no one contributes, the project will be doomed to failure.
The other reason to contribute may be even more critical. With conventional commercial vendors, enterprise IT could count on lots of documentation, training, and pre-sales support to help get staff up to speed on new technology. Not so with open source. Instead, to keep up with the fast pace of open source evolution, enterprise networking teams need to be active participants in the appropriate communities. That way, they aren’t constantly trying to play catch-up with the various enhancements and extensions those communities produce.
Active engagement, however, requires more than merely “throwing some code onto GitHub,” as GitHub Director of Community Jono Bacon put it. Enterprises must allow and encourage staff to participate in the collaborative life of the community—understanding that the associated cost is an important form of technology R&D.
McNamara also emphasized the importance of buying into the “badges away” culture of open source collaboration in which contributors from competing companies temporarily suspend their conflicting interests in favor of their common ones.
Panel moderator Greg Ferro, co-founder of Packet Pushers, added that to participate most successfully in open source projects, enterprise IT has to break free of its typical “cylinders of excellence” where individual SMEs have tightly defined roles—and instead allow people to contribute their talents wherever and whenever they may be most useful to an active project.
Sean Roberts, director of technical program management at Walmart Labs, suggested that enterprise IT organizations can better cope with the rapid pace of open source change by creating two separate code repositories—one for stable code, and one for unstable code. “That way, you can keep up with a project’s most current developments while also maintaining a code base that’s suitable for production environments that have to be completely reliable,” he explained.
Are these pains matched by commensurate gains? Absolutely, according to the panelists. One of these promised payoffs is obviously the creation of code that advances the agility, scalability, economic efficiency, and/or security of enterprise infrastructure. Another is reduced long-term cost of infrastructure ownership—since, in addition to the immediate benefit of innovative code, community contributors also reap the long-term benefit of the ongoing maintenance and upgrades that other contributors plow back into infrastructure code over time.
But perhaps the greatest benefit of participation in open source projects is the way it helps transform an enterprise IT organizations underlying culture and processes. “Code is important, but it’s really just an artifact of a collaborative approach to problem-solving,” Walmart’s Roberts said. “The main benefit of open source is community.”